Before you begin the process of migrating to a new version of WebSphere® ESB, you should be aware of these considerations.
The following rules, restrictions, and considerations apply to migration and coexistence if you have WebSphere ESB version 6.2 installed.
For information about coexistence, see Coexisting with other WebSphere product installations
Prior levels of WebSphere ESB will continue to run at the higher prerequisite levels.
Version 6.1.x and version 6.0.2.x 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.
To support coexistence, see Link pack area, link list, and STEPLIB to make sure you properly set up LPA and STEPLIB.
In particular, note that the default daemon port definition for both versions is the same when installing to coexist with WebSphere ESB version 6.1.x or version 6.0.2.x.
See Default port assignments for default port information.
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 WBIPostUpgrade phase of migration. You can typically see trace output of around 30 MB for this phase.
This ensures that your system has all of the necessary prerequisites and supports the new level of WebSphere ESB.
Note that in this mixed-release environment, there might be some restrictions on what you can do with servers at the older release level. For details, see Creating application servers. There might also be restrictions on creating clusters and cluster members. For details, see .Creating application clusters
At version 6.2, the deployment manager can manage both version 6.1.x nodes and version 6.0.2.x nodes.
If you use the DB2 for zOS Local JDBC Provider (RRS) in the version 6.0.x or 6.1.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.2. The version 6.2 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.2 migration tools will handle the migration to the DB2 Universal JDBC Driver Provider and there will be no postmigration activity required.
Search the information center for your version 6.0.x or 6.1.x product to find information on configuring a DB2 Universal JDBC Driver Provider for WebSphere ESB 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.
For more information, see Using the DB2 Universal JDBC Driver to access DB2 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.
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 ESB version 6.2 migration utilities.
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 file system to use intermediate symbolic links.
The Enabling Trusted Applications option, which permits the WebSphere ESB for z/OS runtime to perform certain privileged operations on behalf of application code, is required for all WebSphere ESB 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 ESB 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.2.
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 (*).
For more information, see System Authorization Facility classes and profiles
BBO.SYNCID.cell_shortname.cluster_transition_nameThe following example contains RACF commands that you might use to accomplish this:
RDEFINE FACILITY BBO.SYNCID.cell_shortname.cluster_transition_name UACC(NONE) PERMIT FACILITY BBO.SYNCID.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 as long as the new identity has READ access to the BBO.SYNC.servant_user_ID SAF SURROGAT profile.
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.
For more information, see Application Synch to OS Thread Allowed.