This topic applies only on the z/OS operating system.

Frequently asked questions about the migration process

This article answers several frequently asked questions about the WebSphere Application Server for z/OS migration process.

Can I simply point to the new Version 6.0.x data sets and restart my servers?

No. WebSphere Application Server for z/OS Version 6.0.x requires that you migrate your Version 5.x configuration up to the Version 6.0.x level.

Be aware of the following issues when migrating to Version 6.0.x:
  • Any variables that belong to applications other than WebSphere Application Server will not be migrated but will be brought over as is. Therefore, check any other product upgrades before migrating to ensure that all of these variables will still be accurate after migration.
    WebSphere Application Server Version 5.02 uses SDK 1.3 while WebSphere Application Server Version 6.0.x uses SDK 1.4, for example, and the following Java SDK z/OS environment-variable changes were made between SDK 1.3 and SDK 1.4:
    • IBM_JAVA_ZOS_TDUMP_PATTERN was changed to JAVA_DUMP_TDUMP_PATTERN
    • IBM_JAVA_ZOS_TDUMP was not ported forward
      You cannot code IBM_JAVA_ZOS_TDUMP=No or JAVA_DUMP_TDUMP=No to prevent the JVM signal handler from calling IEATDUMP to produce transaction dumps. To prevent this, you can use the JAVA_DUMP_OPTS environment variable. For example,
      JAVA_DUMP_OPTS="ONDUMP(NONE),ONOUTOFMEMORY(NONE),ONERROR(NONE),ONEXCEPTION(NONE)"
      will take no diagnostic actions for any conditions handled by the signal handler.

      See the IBM Developer Kit Diagnostics Guide for more information on using the JAVA_DUMP_OPTS environment variable.

  • Before performing migration from Version 5.x to Version 6.0.x, make sure that you do not have any region constraints (such as IEFUSI limits) in place. These can cause unpredictable JVM errors.

What is the basic migration process?

Install the SMP/E code for WebSphere Application Server for z/OS Version 6.0.x. Use the Customization Dialog walk-throughs to create the migration utilities that you need to perform the migration. When you run these jobs a new configuration is created—separate from your existing Version 5.x configuration—that is an exact copy in every way except that it will be at the Version 6.0.x level.

Is migration a node-by-node activity?

Yes. The process of migrating the configuration involves running the supplied utilities against each node in your configuration.

With a standalone application server you have only one node, but that node needs to be migrated. The steps are essentially the same as you would perform for any other node, except you do not have to have a deployment manager up and running. See Checklist of migration activities for standalone application server node for a checklist of activities for migrating a standalone application server node.

What do the migration utilities do?

The migration utilities serve the following purposes:

Utility Purpose
BBOWMG1B (standalone application server migrations) Enables all servers on the node being migrated to be configured to start in PRR processing mode. After this job completes, you must start all servers on the node being migrated and wait for them to terminate. PRR processing mode resolves any outstanding transactions, clears the transaction logs, and terminates the server. This job is not needed for a deployment manager migration, and it is optional for configurations that do not use XA connectors.

This job is required only if you are using XA adapters and you need to migrate the XA logs. Check your resource providers in the Version 5.x administrative console by going to Resources > JDBC providers and checking to see if you have chosen any XA providers such as DB2, Cloudscape, and so on.

BBOWMG1F (federated node migrations)
 
 
 
BBOWMG2B (standalone application server migrations) Disables PRR mode and returns all servers to normal operating state. There is no need to start all servers after this job completes. This job is not needed for a deployment manager migration, and it is optional for configurations that do not use XA connectors.

This job is required only if you are using XA adapters and you need to migrate the XA logs. Check your resource providers in the Version 5.x administrative console by going to Resources > JDBC providers and checking to see if you have chosen any XA providers such as DB2, Cloudscape, and so on.

BBOWMG2F (federated node migrations)
BBOWMBMT (standalone application server migrations) Optional: Creates an HFS and mount point for the Version 6.0.x configuration root. If you want to use an existing HFS to contain the Version 6.0.x configuration, you must manually create the mount point specified in the Customization Dialog rather than run this job. In either case, the HFS and mount point must be created before proceeding with the migration.
BBOWMDMT (deployment manager migrations)
BBOWMMMT (federated node migrations)
BBOWMG3B (standalone application server migrations) Performs the migration of the node from Version 5.x to Version 6.0.x.
BBOWMG3D (deployment manager migrations)
BBOWMG3F (federated node migrations)
BBOMBCP (standalone application server migrations) Copies the generated JCL procedures to start the servers to the specified procedure library. If you choose to have your Version 6.0.x configuration make use of different JCL start procedure names, this utility will update the new Version 6.0.x configuration, substituting your new JCL names in place of the names that existed in your original Version 5.x configuration.
BBOMDCP (deployment manager migrations)
BBOMMCP (federated node migrations)

Where should the migration jobs be run?

Run the jobs on the same system on which the node being migrated resides.

What happens when a node is migrated?

The migration utilities will copy the contents of your present Version 5.x configuration HFS into a new, separate configuration HFS, changing them along the way as needed to support Version 6.0.x:

Will my existing configuration be lost during migration?

During the migration the original Version 5.x configuration tree is unaffected. If for some reason the migration fails before completing, your previous configuration still exists.

If my node has multiple application servers, will all of them be migrated?

Yes. The utility will detect all servers and migrate all, including the Node Agent. One invocation of the migration utilities against the node will take care of all the servers in the node.

Do the servers in a node have to be stopped to perform the migration?

Yes. In a multinode configuration it is possible to have the other nodes still running. But any node that you want to migrate must have its servers stopped.
Note: When an application server node that is part of a Network Deployment configuration is being migrated, the previously migrated Version 6.0.x copy of the deployment manager for that cell must be up and running. This is because part of the migration involves the use of the wsadmin scripting function to synchronize the newly migrated application server node with the deployment manager. The deployment manager must be up to perform that synchronization.

Is it possible to have a cell operating with only some of the nodes migrated and others not?

Yes, that is possible. Version 5.1 can coexist with Version 6.0.x in the same cell and on the same LPAR. When migrating from Version 5.0.x, however, you need to migrate the deployment manager node and other application server nodes on that same MVS image one right after the other — or essentially at the same time. Version 5.0.x and Version 6.0.x nodes cannot exist in the same cell on the same LPAR.

Can my newly-migrated Version 6.0.x deployment manager still "talk" to Version 5.x nodes?

Yes. A deployment manager migrated to the Version 6.0.x level of code can manage a Version 5.x node. Changes made through the administrative console will be applied to the node. There are a few things to keep in mind:
  • When a deployment manager is migrated to Version 6.0.x, a new copy of the "master configuration" is created. The old copy of the "master configuration" (the Version 5.x copy) still exists. But when the Version 6.0.x deployment manager makes changes to the configuration, it makes it to the new Version 6.0.x copy of the master configuration. So while it is possible to use to the Version 5.x copy of the code, any changes made in Version 6.0.x will not be seen when the older code is restored.
  • A Version 5.x deployment manager has no ability to manage a Version 6.0.x node.

Is there a sequence to performing a multinode migration?

Yes, there is:
  1. Always migrate the deployment manager first.
  2. Version 5.0.x application servers that reside on the same node as the deployment manager must be migrated next. Version 5.1 and Version 6.0.x nodes can coexist in the same cell and on the same LPAR, so any Version 5.1 nodes do not need to be migrated immediately. See Coexistence support for more information on coexistence.
  3. Application server nodes on the same system as the deployment manager or on other MVS images can then be migrated.

Is it possible to have cells at Version 6.0.x coexist with other cells at Version 5.x?

Yes, it is. This is true for a sysplex or any given MVS image. There are some restrictions, most of which have been present in past versions as well:
  • No two cells can have the same cell short name.
  • Version 5.0.x cannot coexist with Version 6.0.x in the same cell on the same LPAR. If you have multiple Version 5.0.x nodes on the same LPAR, all nodes must be migrated to Version 6.0.x at the same time.
  • Only one version of the code can exist in LPA/LNKLST; the rest must be included in STEPLIB.
  • There are other things you must consider for separate cells, regardless of whether they are at different versions of the code; for example, you must have a separate HFS mount point and separate JCL procedures.



Related tasks
Preparing to migrate a Network Deployment configuration to Version 6.0.x
Preparing to migrate a standalone application server node to Version 6.0.x
Customization Dialog walk-through for migrating a standalone application server node
Customization Dialog walk-through for deployment manager
Migrating a standalone application server node
Migrating a deployment manager node
Migrating a federated application server node
Migrating a federated application server node on another MVS image
Related reference
Checklist of migration activities for a Network Deployment configuration
Checklist of migration activities for standalone application server node
Reference topic    

Terms of Use | Feedback

Last updated: Sep 20, 2010 11:08:29 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-mp&topic=rins51migover
File name: rins_51migover.html