Before you begin the process of migrating to WebSphere Application Server Version 6.1, there are some considerations of which you need to be aware.
You must first migrate the Version 5.x or 6.0.x deployment manager to an unaugmented Version 6.1.x deployment manager and then augment the target deployment manager afterwards.
You can create a new standalone application server profile in Version 6.1.x with the appropriate feature pack installed and augment it.
You can create a new profile in Version 6.1.x with the appropriate feature pack installed, augment it, and then add the new node to a Version 6.1.x cell that has an augmented deployment manager.
This ensures that your system has all of the necessary prerequisites and supports the new level of WebSphere Application Server.
On Solaris x64, WebSphere Application Server Version 6.0.2 runs as a 32-bit application even though the underlying platform is 64-bit. This is because the underlying Java virtual machine is 32-bit. WebSphere Application Server Version 6.1 runs as a 64-bit application because the underlying Java virtual machine is 64-bit. JNI applications compiled in a 32-bit environment for Version 6.0.2 cannot run in the 64-bit environment of Version 6.1.
Prior levels of WebSphere Application Server will continue to run at the higher prerequisite levels.
In particular, note that the default daemon port definition for both versions is the same when installing to coexist with WebSphere Application Server Version 5.x or 6.0.x.
See Port number settings in WebSphere Application Server versions for default port information.
See Coexisting.
Note that in this mixed-release environment, there might be some restrictions on what you can do with servers at the older release level. There might also be restrictions on creating clusters and cluster members.
To avoid configuration problems, use servlet APIs to control the file location instead of using the default location.
If you create a profile with a new cell name, the migration will fail.
MIGR0378E: The node name of the new configuration must be the same as the old configuration: {0} for this environment.
If you installed an application in your old environment with Use Metadata From Binaries set to true and during that installation or a future update of the application you made a change to the application's metadata (such as JNDI resource references or database entries for example), the change might be lost when you migrate.
When Use Metadata From Binaries is set to true, the administrative code only updates the metadata in the binary EAR file. This option is not supported in a mixed cell; therefore, it is automatically turned to false as part of migration. When this happens, the expanded metadata in the configuration directories take precedence over the values in the binary EAR file. This causes the values from the original EAR file installation to take precedence over any updates that you might have made.
If Version 6.1 does not support a level for which JSP objects are configured, the migration tools recognize the objects in the output and log them.
If you have used a smaller heap size in the past, you can use the default heap size of 50.
This ensures that your system has all of the necessary prerequisites and supports the new level of WebSphere Application Server.
If the WebSphere Application Server Version 6.1 product modules are not loaded into LPA and Link List prior to running the migration job, the job will not complete successfully.
The JMS applications must be manually installed and reconfigured after migration to use the WebSphere Application Server Version 6.1 JMS provider.
If security is not enabled for WebSphere Application Server Version 6.0.1, this requirement does not apply and there is no specific service-level requirement for the migration.
STEPLIB=BOSS.VICOM.W000020.SBBOLPA:$STEPLIB STEPLIB=BOSS.VICOM.W000020.SBBOLD2:$STEPLIB STEPLIB=BOSS.VICOM.W000020.SBBOLOAD:$STEPLIB export STEPLIB
Therefore, you cannot migrate an existing configuration to a different z/OS LPAR. You also cannot migrate to or from a non-z/OS operating system using the WebSphere Application Server Version 6.1 migration utilities.
You must generate the migration jobs using the Customization Dialog or z/OS Migration Management Tool and then submit them according to the generated instructions.
Prior levels of WebSphere Application Server will continue to run at the higher prerequisite levels.
WebSphere Application Server Version 5.x, 6.0.x, and 6.1 require the placement of some code into LPA (SBBOLPA). In addition, additional product code (SBBOLOAD) should be placed into LPA for performance reasons. Because of naming conflicts, however, more than one version of product code can not be in LPA at the same time.
In particular, note that the default daemon port definition for both versions is the same when installing to coexist with WebSphere Application Server Version 5.x or 6.0.x.
See Coexisting.
Note that in this mixed-release environment, there might be some restrictions on what you can do with servers at the older release level. There might also be restrictions on creating clusters and cluster members.
If you have multiple WebSphere Application Server Version 5.0.x nodes, including the deployment manager, on the same LPAR, all nodes must be migrated to WebSphere Application Server Version 6.1 at the same time. All nodes must be migrated sequentially before starting any WebSphere Application Server Version 6.1 node in the LPAR.
If you configure your Network Deployment environment using the default value for the product file system path in the Customization Dialog, it will result in all the nodes pointing directly at the mount point of the product file system. This makes rolling maintenance in a nondisruptive manner almost impossible. If a cell is configured in this way, applying service to the product file system affects all the nodes at the same time; and if multiple cells are configured in this way, applying service to the product file system affects all the cells at the same time.
You might want to specify what is referred to as an "intermediate symbolic link" between each node's configuration file system and the actual mount point of the product file system. This strategy is described in the WebSphere Application Server for z/OS V5 - Planning for Test, Production and Maintenance white paper.
See the Washington Systems Center Sample WebSphere for z/OS ND Configuration white paper for more information about this issue and its relationship to applying maintenance. See the WebSphere for z/OS: Updating an Existing Configuration HFS to Use Intermediate Symbolic Links instructions for information on obtaining and using a utility that would allow you to update an existing configuration HFS to use intermediate symbolic links.
Normally, the batch-job output from the migration is very small unless you enable trace. The trace output size varies depending on the parts of migration for which you have enabled trace. The largest trace producer is the WASPostUpgrade phase of migration. You can typically see trace output of around 30 MB for this phase.
If you use the DB2 for zOS Local JDBC Provider (RRS) in the Version 5.x or 6.0.x configuration that you are going to migrate, you must change your configuration to use the DB2 Universal JDBC Driver Provider before or immediately after you migrate to Version 6.1. The Version 6.1 migration tools do not migrate the provider for you.
MIGR0442W: Not migrating DB2 for zOS Local JDBC Provider (RRS) jdbc provider. Manually create a DB2 Universal Driver provider as a replacement. See DB2 documentation for further details.
DSRA8213W: JDBC provider, DB2 for zOS Local JDBC Provider (RRS), is no longer supported by WebSphere Application Server. Applications should use DB2 Universal JDBC Driver Provider Type 2.
If you do this, the Version 6.1 migration tools will handle the migration to the DB2 Universal JDBC Driver Provider and there will be no post-migration activity required.
Search the information center for your Version 5.x or 6.0.2 product to find information on configuring a DB2 Universal JDBC Driver Provider for WebSphere Application Server for z/OS.
This tool is a Jython script that migrates DB2 for zOS Local JDBC Providers (RRS) to DB2 Universal JDBC Driver Providers one node at a time. A white paper that accompanies the tool explains how to install and configure the DB2 Universal JDBC Driver before running the tool to migrate your configuration. The tool and white paper are available from the product Support site at http://www.ibm.com/support/docview.wss?uid=swg27007826.
This tool is a Jython script that migrates DB2 for zOS Local JDBC Providers (RRS) to DB2 Universal JDBC Driver Providers one node at a time. A white paper that accompanies the tool explains how to install and configure the DB2 Universal JDBC Driver before running the tool to migrate your configuration. The tool and white paper are available from the product Support site at http://www.ibm.com/support/docview.wss?uid=swg27007826.
The Enabling Trusted Applications option, which permits the WebSphere Application Server for z/OS runtime to perform certain privileged operations on behalf of application code, is required for all WebSphere Application Server for z/OS servers that use the LocalOS registry or SAF authorization.
This allows both the administrator and the system security administrator to determine whether or not the feature is used. This implementation also allows restrictions on which identities the application can assume.
If you migrate from a previous version of WebSphere Application Server and need these features, you should create the required SAF profiles. If these profiles are not present and properly set up, a cell using the LocalOS user registry or SAF authorization will fail when brought up on Version 6.1.
BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name
RDEFINE FACILITY BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name UACC(NONE) PERMIT FACILITY BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name ID(controller_userid) ACCESS(READ) SETROPTS RACLIST(FACILITY) REFRESH
The cluster_name SAF facility profile is replaced by the cluster transition name for unclustered servers. If you want all servers in the cell to have Enabling Trusted Applications enabled, replace the cluster name with a wild card (*).
BBO.SYNC.cell_shortname.cluster_transition_nameThe following example contains RACF commands that you might use to accomplish this:
RDEFINE FACILITY BBO.SYNC.cell_shortname.cluster_transition_name UACC(NONE) PERMIT FACILITY BBO.SYNC.cell_shortname.cluster_transition_name ID(controller_userid) ACCESS(CONTROL) SETROPTS RACLIST(FACILITY) REFRESH
The cluster name is replaced by the cluster transition name for unclustered servers. If you want all servers in the cell to have Sync to OS Thread Allowed enabled, replace the cluster name with a wild card (*).
If the controller user ID has READ access to the BBO.SYNC profile and the com.ibm.websphere.security.SyncToOSThread variable is set to true, an application might request Sync to the OS Thread. The application might assume the identity of either the caller or a role-related user ID to access resources. In order for the servant to run with a different application ID, however, the servant needs READ access to the SURROGAT profile BBO.SYNC.application_userid.
If the controller user ID has CONTROL access to the BBO.SYNC profile and the com.ibm.websphere.security.SyncToOSThread variable is set to true, then an application might request Sync to OS Thread. The application might assume the identity of either the caller or any role-related user ID to access resources. SURROGAT profiles are not checked.
If you have used a smaller heap size in the past, you can use the default heap size of 50.