Overview of migration, coexistence, and interoperability

The goal of migration is to reconstruct your earlier version of WebSphere® Application Server in a Version 7.0 environment. Coexistence allows you to create a mixed-version environment that is not in conflict and allows the nodes of all versions to start and run at the same time. Coexistence also facilitates rollback and allows one or the other version to run at one time. Interoperating is exchanging data between two coexisting product installations or between products on different systems.

Frequently asked questions

Can I simply point to the new WebSphere Application Server for z/OS® Version 7.0 datasets and restart my servers?

No. WebSphere Application Server for z/OS Version 7.0 requires that you migrate your Version 5.1.x or Version 6.x configuration up to the Version 7.0 level.

Be aware of the following issues when migrating to Version 7.0:
  • Any variables that belong to applications or products other than WebSphere Application Server are not migrated but are brought over to the new environment as is. Therefore, check any other product upgrades before migrating to ensure that all of these variables are still accurate after migration.
  • Before performing migration from Version 5.1.x or Version 6.x to Version 7.0, verify that you do not have any region constraints (such as IEFUSI limits) in place. These constraints can cause unpredictable Java Virtual Machine (JVM) errors.
What is the basic migration process?
  1. Install the SMP/E code for WebSphere Application Server for z/OS Version 7.
  2. Use the z/OS Migration Management Tool or the zmmt command to create the migration utilities that you need to perform the migration.
  3. Run these jobs.

    A new Version 7.0 configuration is created—separate from your existing Version 5.1.x or Version 6.x configuration—that is based on the Version 5.1.x or Version 6.x configuration information.

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.

Diagram of nodes that need to be migrated.

Although a standalone application server only has one node, that node needs to be migrated. The steps are essentially the same as the steps for migrating any other node, except that you do not have to have a deployment manager running. Read Migrating a z/OS standalone application server: Checklist for a checklist of activities for migrating a standalone application server node.

What do the migration utilities do?

Table 1. Purposes of the migration utilities.

The migration utilities serve the following purposes:

Utility Purpose
BBOWMG1B (standalone application server migrations)

BBOWMG1F (federated node migrations)

Enables all servers on the node being migrated to be configured to start in Peer Restart and Recovery (PRR) mode

After this job completes, you must start all servers on the node being migrated and wait for them to stop. PRR processing mode resolves any outstanding transactions, clears the transaction logs, and stops the server. This job is not needed for a deployment manager migration, and it is optional for configurations that do not use distributed transaction (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.1.x or Version 6.x administrative console by going to Resources > JDBC providers and checking to see if you have chosen any XA providers such as DB2®, Apache Derby, and so on.

BBOWMG2B (standalone application server migrations)

BBOWMG2F (federated node migrations)

Disables PRR mode and returns all servers to normal operating state

You are not required 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.1.x or Version 6.x administrative console by going to Resources > JDBC providers and checking to see if you have chosen any XA providers such as DB2, Apache Derby, and so on.

BBOMBHFS or BBOMBZFS (standalone application server migrations)

BBOMDHFS or BBOMDZFS (deployment manager migrations)

BBOMMHFS or BBOMMZFS (federated node migrations)

Optional: Creates a file system and mount point for the Version 7.0 configuration root, and mounts the file system

If you want to use an existing file system to contain the Version 7.0 configuration, you must manually create the mount point specified when you create the migration definition and verify that the file system is mounted rather than run this job. In either case, the configuration file system and mount point must be created and the file system must be mounted before proceeding with the migration.

For standalone application server migrations, the following utilities:
  • BBOWMG3B
  • BBOWBPRO
  • BBOWBPRE
  • BBOWBPOS
For deployment manager migrations, the following utilities:
  • BBOWMG3D
  • BBOWDPRO
  • BBOWDPRE
  • BBOWDPOS
For federated node migrations, the following utilities:
  • BBOWMG3F
  • BBOWMPRO
  • BBOWMPRE
  • BBOWMPOS

BBOWMG3x runs the complete migration of the node from Version 5.1.x or Version 6.x to Version 7.

BBOWxPRO just creates the WebSphere Application Server home and default profile.

BBOWxPRE just runs the migration pre-upgrade process.

BBOWxPOS just runs the migration post-upgrade and finish-up (change file permission) processes.

BBOMBCP (standalone application server migrations)

BBOMDCP (deployment manager migrations)

BBOMMCP (federated node migrations)

Copies the generated Job Control Language (JCL) procedures to start the servers to the specified procedure library

If you choose to have your Version 7.0 configuration make use of different JCL start procedure names, this utility updates the new Version 7.0 configuration, substituting your new JCL names for the names that existed in your original Version 5.1.x or Version 6.x configuration.

Where should you run the migration jobs?

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

What happens when a node is migrated?

The migration utilities transform the contents of your present WebSphere Application Server Version 5.1.x or Version 6.x configuration file system and merge them into a new, separate Version 7.0 configuration file system.

Are my existing configuration lost during migration?

During the migration, the original WebSphere Application Server Version 5.1.x or Version 6.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, are all of them migrated?

Yes. The utility detects all servers and migrate all, including the node agent. One invocation of the migration utilities against the node migrates all the servers in the node.

Must I stop the servers in a node 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.

When an application server node that is part of a WebSphere Application Server, Network Deployment configuration is being migrated, the previously migrated Version 7.0 deployment manager for that cell must be 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 running in order 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. WebSphere Application Server Version 5.1.x and Version 6.x can coexist with Version 7.0 in the same cell and on the same logical partition (LPAR).

Can my newly migrated WebSphere Application Server for z/OS Version 7.0 deployment manager still communicate with the Version 5.1.x or Version 6.x nodes?

Yes. A deployment manager that is migrated to the Version 7.0 level of code can manage a Version 5.1.x or Version 6.x node. Changes made through the administrative console are applied to the node. Remember the following points:
  • When a deployment manager is migrated to Version 7.0, a new Version 7.0 primary configuration is created. The Version 5.1.x or Version 6.x primary configuration still exists. But when the Version 7.0 deployment manager makes changes to the configuration, the changes are made to the new Version 7.0 primary configuration. While it is still possible to use the Version 5.1.x or Version 6.x code, therefore, any changes made in Version 7.0 are not seen when the older code is restored.
  • A Version 5.1.x or Version 6.x deployment manager has no ability to manage a Version 7.0 node.
  • A WebSphere Application Server Version 7.0 WebSphere Application Server, Network Deployment cell can contain mixed releases of Version 5.1.x or Version 6.x nodes, but there is no mixed-node management support for Version 6.0.1.x.
    The Version 7.0 migration tools still migrate these nodes during deployment-manager migration, but they issue a warning message that the nodes cannot be managed by the Version 7.0 deployment manager. You can then perform one of the following actions based on your needs.
    • Upgrade all Version 6.0.1.x nodes to at least Version 6.0.2.

      This action allows the nodes to be administered by a Version 7.0 deployment manager.

    • Migrate these nodes to Version 7.0.

Is there a sequence to performing a multinode migration?

Yes. Migrate according to the following sequence:
  1. Always migrate the deployment manager first.
  2. Application server nodes on the same system as the deployment manager or on other Multiple Virtual Storage (MVS) images can then be migrated.

Is it possible to have cells at WebSphere Application Server for z/OS Version 7.0 coexist with other cells at Version 5.1.x or Version 6.x?

Yes. It possible to have cells at WebSphere Application Server for z/OS Version 7.0 coexist with other cells at Version 5.1.x or Version 6.x for a sysplex or any given MVS image. The following restrictions exist:
  • A cell can contain servers at Version 5.1.x, Version 6.x, and Version 7.0 levels.
  • A cell can contain z/OS and non-z/OS nodes; however, the deployment manager must be at the highest version level in the cell and any nodes on platforms other than that on which the deployment manager is located must be at Version 6.0 or later.
  • A server on a z/OS node cannot be clustered with a server on a non-z/OS node.
  • An LPAR can contain more than one node from the same cell.
  • Each LPAR has at most one daemon per cell with servers on that LPAR regardless of how many nodes from that cell are configured for that LPAR.
  • For a given LPAR, a daemon must be at or above the version level of all servers on that LPAR that are in the daemon's cell, regardless of node.
  • All servers in the same node must be at the same version level.
  • The deployment manager must be at or above the version level of any server in the cell.
  • The controller and its servants must be at the same version level.
  • No two cells can have the same cell short name.
  • Other considerations exist for separate cells, regardless of whether they are at different versions of the code. For example, you must have a separate configuration file system mount point and separate JCL procedures.



Related tasks
Migrating product configurations
Migrating and coexisting application servers
Preparing to migrate a z/OS standalone application server
Preparing to migrate a WebSphere Application Server, Network Deployment cell for z/OS
Migrating a z/OS standalone application server: Checklist
Migrating a z/OS deployment manager: Checklist
Migrating a standalone application server on the z/OS operating system
Migrating a z/OS deployment manager
Migrating a z/OS federated node
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Feb 6, 2014 2:48:53 AM CST
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-zos&topic=cmig_overview
File name: cmig_overview.html