Various configurations are mapped during product-configuration migration.
Migration
always involves migrating a single profile to another single profile on the
same machine or a separate machine. Examples include a WebSphere Application
Server Version 6.0.x deployment manager migrating to a Version 6.1 deployment
manager profile and a Version 6.0.x application server migrating to a Version
6.1 standalone application server profile.
Migration
involves the copying of your configuration from a previous release of a WebSphere
Application Server product into a new release.
Migration
always involves migrating a single profile to another single profile on the
same iSeries server. The migration tools map objects and attributes existing
in the version or WebSphere Application Server from which you are migrating
to the corresponding objects and attributes in the Version 6.1 environment.
Many migration scenarios are possible. The migration tools map objects and attributes existing in the version from which you are migrating to the corresponding objects and attributes in the Version 6.1 environment.
The migration tools map a non-default value directly into the Version 6.1 environment.
If the -portBlock parameter
is specified during the call to WASPostUpgrade,
however, a new port value is given to each application server that is migrated
to Version 6.1.
The migration tools convert appropriate command-line parameters to Java virtual machine (JVM) settings in the server process definition. Most settings are mapped directly. Some settings are not migrated because their roles in the WebSphere Application Server Version 6.1 configuration do not exist, have different meanings, or have different scopes.
It is best that you reinstall the resource into the new WebSphere Application Server directory. Whatever you choose to do, the final step is to reset the reference to the new location of the application.
If the old resource that the generic server was managing is not installed under the old WebSphere Application Server installation, nothing further is required.
When migrating all WebSphere Application Server Version 5.x or 6.0.x EAR files to Version 6.1 using the wsadmin tool, the WASPostUpgrade tool uses the default maximum Java heap size value of 64 MB to install the EAR files.
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError
Increase the maximum Java heap size, and follow the example below to install the application.
Example of installing the application on WebSphere Application Server Version 6.1
wsadmin -conntype NONE -c "$AdminApp install C:\\WebSphere\\AppServer\\installableApps\\ EAR_file_name {-nodeployejb -appname app_name -server server_name -node node_name}"
Example of installing the application on WebSphere Application Server Network Deployment Version 6.1
wsadmin -conntype NONE -c "$AdminApp install C:\\WebSphere\\DeploymentManager\\installableApps\\ EAR_file_name> {-nodeployejb -appname app_name -cluster cluster_name}"
The JMS server was changed in WebSphere Application Server Version 6.0.x from type MESSAGE_BROKER to type APPLICATION_SERVER. Any queues or topics that it owned have been migrated into the default messaging provider, which is based on service integration technologies. In Version 5.x and earlier, jmsserver was its own MESSAGE_BROKER server in a Network Deployment environment; in the base environment, it was contained within APPLICATION_SERVER types.
All JMS resources were left untouched and should work without modification. Further migration of these resources can be performed by running scripts or bats provided by the Version 6.1 default messaging provider.
You can migrate a WebSphere Application Server Version 5.x or 6.0.x node that belongs to a cell without removing the node from the cell.
Migrate the deployment manager first, before migrating any base nodes in the cell.
Use the same cell name when migrating Network Deployment from Version 5.x or 6.0.x to Version 6.1. If you use a different cell name, federated nodes cannot successfully migrate to the Network Deployment Version 6.1 cell.
Migrating a base WebSphere Application Server node that is within a cell to Version 6.1 also migrates the node agent to Version 6.1. A cell can have some Version 6.1 nodes and other nodes that are at Version 5.x or 6.0.x levels. See Coexistence support for information on restrictions on using mixed-release cells.
Migration copies files from prior version directories into the WebSphere Application Server Version 6.1 configuration.
Migration copies files from prior version directories into the WebSphere Application Server Version 6.1 configuration.
Migration does not overlay property files.
RARs that are referenced by J2C resources are migrated if those RARs are in the old WebSphere Application Server installation. In this case, the RARs are copied over to the corresponding location in the new WebSphere Application Server installation. Relational Resource Adapter RARs will not be migrated.
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar"> ... </resources.j2c:J2CResourceAdapter>
If you have a cluster-level resource, this resource must be in the same location on each cluster member (node). Using the above example, therefore, each cluster member must have the RAR file installed at location ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar. ${WAS_INSTALL_ROOT} is resolved on each cluster member to get the exact location.
In the migration of a deployment manager, the tools migrate the cluster files on the deployment manager, including the resourcexxx.xml files.
In the migration of a managed node, the tools process each J2C adapter. Files such as RAR files are migrated differently depending on whether you are migrating from Version 5.x to Version 6.x or from Version 6.0.x to Version 6.1.
Because the profile structure changed in Version 6.0, migration from Version 5.x to Version 6.x copies files such as RAR files from the location set for the WAS_INSTALL_ROOT variable to the location set for the USER_INSTALL_ROOT variable and modifies any paths to reflect these changes.
Migration from Version 6.0.x to Version 6.1 copies files such as RAR files from WAS_INSTALL_ROOT to WAS_INSTALL_ROOT and from USER_INSTALL_ROOT to USER_INSTALL_ROOT.
If you have a RAR file in the WAS_INSTALL_ROOT for Version 6.0.x, for example, the migration tools do not automatically copy the file from WAS_INSTALL_ROOT to USER_INSTALL_ROOT as they would do in a Version 5.x to 6.x migration. This maintains the integrity of the cluster-level J2C resources.
During the migration of the deployment manager, only WebSphere Application Server Version 5.x samples for federated nodes are migrated. Equivalent Version 6.1 samples are available for all other Version 5.x samples and all Version 6.0.x samples.
Java 2 security is enabled by default when you enable security in WebSphere Application Server Version 6.1. Java 2 security requires you to grant security permissions explicitly.
There are several techniques
that you can use to define different levels of Java 2 security in Version
6.1. One is to create a was.policy file as part of the
application to enable all security permissions. The migration tools call the wsadmin command
to add an existing was.policy file in the Version 6.1 properties directory
to enterprise applications as they are being migrated.
This is the default.
For example, existing keyfiles and trustfiles are moved out of the SSLConfig repertoire and new keystore and truststore objects are created.
All
SSL configuration repertoires of the System Secure Sockets Layer (SSSL) type,
except those that belong to the daemon, are converted to the Java Secure Socket
Extension (JSSE) type.
The location for these directories is typically within
the installation directory of a previous version. The default location for stdin, stdout,
and stderr is the logs directory
of the WebSphere Application Server Version 6.1 installation root.
In
WebSphere Application Server for z/OS, outputs for stdin, stdout,
and stderr are directed to SYSOUT by default. If they
are redirected to the configuration directory of a previous version, you might
need to change this in the Version 6.1 JCL.
The
location for these directories is typically the logs directory
under the WebSphere Application Server profile directory. For WebSphere Application
Server Version 6.1, the default location for the stdin, stdout,
and stderr files is the logs directory
located under the WebSphere Application Server profile directory—for example,
the logs directory for the default profile is /QIBM/UserData/WebSphere/AppServer/V61/Base/profiles/default/logs.
The migration tools attempt to migrate existing passivation and working directories. Otherwise, appropriate Version 6.1 defaults are used.
If
WebSphere Application Server for z/OS user IDs have home directories in the
configuration directory of a previous version, you should update them before
migration to reside in another location.
In a coexistence scenario, using common directories between versions can create problems.
The migration tools migrate all ports. The tools log a port-conflict warning if a port is already defined in the configuration. You must resolve any port conflicts before you can run servers at the same time.
This results in your transport ports being brought over as they are. This is the default.
This results in the transport ports being converted to the implementation of channels and chains. From an external application usage standpoint, they will still act the same; but they have been moved to the TransportChannelService.
For more information on the WASPostUpgrade command,
see WASPostUpgrade command.
You must manually add virtual host alias entries for each port.
The specification level of the Java 2 Platform, Enterprise Edition (J2EE) implemented in WebSphere Application Server Version 6.0.x required behavior changes in the Web container for setting the content type. If a default servlet writer does not set the content type, not only does the Web container no longer default to it but the Web container returns the call as "null." This situation might cause some browsers to display resulting Web container tags incorrectly. To prevent this problem from occurring, migration sets the autoResponseEncoding IBM extension to "true" for Web modules as it migrates enterprise applications.