The goal of migration is to reconstruct your earlier version in
a nearly identical Version 6.0.x environment, including applications, configuration
settings, universal resource identifier (URI) descriptors, and Web server
context roots. The goal of coexistence is to create a mixed-version environment
that is not in conflict; this allows the nodes of all versions to start and
run at the same time.
New in WebSphere Application Server Version 6.0.1 and later is the "Migrate
V5.x Nodes to V6 Nodes" option off of the main Customization Dialog panel.
See Migrating product configurations as a starting
point for your case-specific WebSphere Application Server Version 6.0.x migration.
While the migration process has been simplified in WebSphere Application
Server Version 6.0.x, there are still restrictions of which you need to be
aware:
- WebSphere Application Server Version 6.0.x does not provide support for
migrating a WebSphere Application Server Version 5.x configuration that contains
an internal JMS provider in WebSphere Application Server Version 5.x. The
JMS applications must be manually installed and reconfigured post-migration
to use the WebSphere Application Server Version 6.0.x JMS provider.
- Certain programming model extensions (PMEs) previously contained in WebSphere
Business Integration Server Foundation are now included in the WebSphere Application
Server Version 6.0.x runtime. Some unsupported PMEs will not be migrated.
See Tips for migrating programming model extensions for
more information.
- WebSphere Application Server Version 5.0.x cannot coexist with Version
6.0.x in the same cell on the same system image (LPAR). If you have multiple
WebSphere Application Server Version 5.0.x nodes, including the deployment
manager node, on the same LPAR, all nodes MUST be migrated to WebSphere Application
Server Version 6.0.x at the same time. All nodes must be migrated sequentially
before starting any WebSphere Application Server Version 6.0.x node in the
LPAR.
- If you are currently running your WebSphere Application Server Version
5.0.x node using STEPLIB, you must verify that profile_root/bin/setupCmdLine.sh contains
the STEPLIB of the load libraries. Some 5.0.x nodes might not contain the
installation-generated STEPLIB statement. In these instances, you must add
the STEPLIB manually to the "OS/390)" section of the setupCMDLine.sh file
before running the migration utilities. Here is an example from a setupCMDLine.sh file
in a properly configured system:
STEPLIB=BOSS.VICOM.W000020.SBBOLPA:$STEPLIB
STEPLIB=BOSS.VICOM.W000020.SBBOLD2:$STEPLIB
STEPLIB=BOSS.VICOM.W000020.SBBOLOAD:$STEPLIB
export STEPLIB
See the "Setting up STEPLIB" article in the Version
5.0.x information center.
- Migration support requires that both the source and target WebSphere Application
Server for z/OS systems are on the same LPAR. 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.0.x migration utilities.
- WebSphere Application Server for z/OS does not support the WASPreUpgrade,
WASPostUpgrade, and WASProfile command-line tools. You must use the Customization
Dialog to generate the migration jobs.
The remaining migration articles assume that WebSphere Application Server
Version 6.0.x is being installed in an environment where it must coexist with
prior levels of WebSphere Application Server. Consider the following items
while planning to enable coexistence:
- Update prerequisites to the levels required by WebSphere Application Server
Version 6.0.x. Prior levels of WebSphere Application Server for z/OS will
continue to run at the higher prerequisite levels. For more information, see Prerequisites needed for WebSphere Application Server for z/OS.
- Set up WebSphere Application Server Version 6.0.x to eliminate potential
LPA conflicts with a prior Version 5.x installation. WebSphere Application
Server Version 6.0.x and Version 5.x both 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, WebSphere
Application Server Version 6.0.x and Version 5.x product code can not be in
LPA at the same time.
- Utilize WLM DAE when configuring WebSphere Application Server Version
6.0.x to allow both the use of a specific server name by Version 6.0.x and
by a server on Version 5.x.
- Review the ports that are defined to ensure that the WebSphere Application
Server Version 6.0.x installation does not conflict. In particular, when installing
to coexist with WebSphere Application Server Version 5.x, note that the default
daemon port definition for both Version 6.0.x and Version 5.x is the same.
High availability manager and core group functionality are included in
WebSphere Application Server Version 6.0 and later.
WebSphere Application Server for z/OS Version 6.0.x continues to support
HTTP transports while adding support for transport chains.
When you are ready to begin the migration process, see Migrating product configurations, which is a starting point for the planning
information, Customization Dialog walk-throughs, and WebSphere Application
Server Version 5.x to Version 6.0.x migration explanations for standalone
application server nodes, deployment managers, and federated nodes.