Overview of migration, coexistence, and interoperability

The goal of migration is to reconstruct your earlier version of WebSphere Application Server in a nearly identical Version 6.1 environment. One goal of coexistence is 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; another goal is to create an environment that 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.

New feature New or updated for this feature pack New feature: The following rules and restrictions apply to migration and coexistence if you have a WebSphere Application Server Version 6.1 feature pack installed: newfeat

Introduction [AIX HP-UX Linux Solaris Windows] [iSeries]

WebSphere Application Server Version 6.1 can coexist with Version 5.x and Version 6.0.x. Depending on the previous version of WebSphere Application Server, there might be port conflicts that need to be resolved. See Coexistence support and Configuring ports for more information.

WebSphere Application Server Version 6.1 migration leverages the existing configuration and applications and changes them to be compatible with the WebSphere Application Server Version 6.1 environment. Existing application components and configuration settings are applied to the Version 6.1 environment during the migration process.

If you use an earlier version of WebSphere Application Server, the system administrator might have fine-tuned various application and server settings for your environment. It is important to have a strategy for migrating these settings with maximum efficiency and minimal loss.

You can perform incremental migration of your WebSphere Application Server Version 5.x or 6.0.x configuration by calling the migration tools multiple times, each time specifying a different set of instances or profiles.

Migration involves the following main steps:
  1. Testing your applications in a nonproduction WebSphere Application Server Version 6.1 environment, and making any changes to the applications that are necessary to ensure that they run in that environment.
  2. Migrating those applications and your configuration to Version 6.1.

    This step can be performed by using the migration tools shipped with the product.

The migration tools migrate applications and configuration information to the new version as described in Migrating product configurations. See Using the migration tools to migrate product configurations.

[AIX HP-UX Linux Solaris Windows] The Migration wizard provides a graphical user interface to the migration tools. The Migration wizard can call the migration tools, or you can run them directly. See Using the Migration wizard to migrate product configurations.

The migration from WebSphere Application Server Version 5.x or 6.0.x to Version 6.1 is fairly routine. Important reference articles for this migration include the following articles:

If you neither migrate nor coexist with an earlier version of WebSphere Application Server, you are choosing to ignore the previous installation and you can run only one version at a time because of conflicting default port assignments. It is possible for both versions to run at the same time without conflict if you use non-default ports in the earlier version. To set up coexistence with WebSphere Application Server Version 5.x or 6.0.x, ensure that unique ports are selected during profile creation for the Version 6.1 installation. To set up coexistence with an existing installation of Version 6.1, select the radio button that states "Install a new copy of the V61 Application Server product" during installation.

You can resolve conflicting port assignments by specifying port assignments for coexistence during profile creation, by wsadmin scripting or by using the Servers > Application Servers > server1 > Ports administrative console page to ensure that WebSphere Application Server Version 6.1 can run with an earlier version.

See Wsadmin tool.

Coexistence processing changes the following configuration files:
  • virtualhosts.xml
    • HTTP Transport Port
    • IBM HTTP Server Port
    • HTTPS Transport Port
    • HTTP Administrative Console Port
    • HTTPS Administrative Console Secure Port
  • serverindex.xml
    • Bootstrap Address
    • SOAP Connector Address
    • DRS Client Address
      Deprecated feature Deprecated feature: This port is deprecated and is no longer used in the current version of WebSphere Application Server.depfeat
    • [This information applies to Version 6.0.x and previous servers only that are federated in a Version 6.1 cell.] SAS SSL ServerAuth Listener Address
    • CSIV2 SSL ServerAuth Listener Address
    • CSIV2 SSL MutualAuth Listener Address
    • WC adminhost
    • WC defaulthost
    • DCS Unicast Address
    • WC adminhost secure
    • WC default secure
    • SIB Endpoint Address
    • SIB Endpoint Secure Address
    • SIB MQ Endpoint Address
    • SIB MQ Endpoint Secure Address

See Port number settings in WebSphere Application Server versions for more information.

Consider these issues in a migration or coexistence scenario:
  • Conflicting context roots when attempting to share the same Web server.

    Follow the procedure in Migrating Web server configurations to learn how to configure a Web server for sharing between WebSphere Application Server versions.

  • [AIX HP-UX Linux Solaris Windows] If your deployment manager is configured to run as non-root, follow the instructions in Migrating a previously non-root configuration to root to change the ownership and file permissions of the deployment manager directories after running the WASPostUpgrade command.

    See WASPostUpgrade command.

    This must be done before starting the WebSphere Application Server Version 6.1 deployment manager.

  • [AIX HP-UX Linux Solaris Windows] If your node agent or application server has been configured to run as non-root, follow the instructions in Migrating a previously non-root configuration to root to change the ownership and file permissions of the node directories after running the WASPostUpgrade command.

    See WASPostUpgrade command.

    This must be done before starting the WebSphere Application Server Version 6.1 node agent or application server.

  • A WebSphere Application Server Version 6.1 deployment cell can contain mixed releases of Version 5.x or 6.0.x nodes, but there is no mixed-node management support for Version 6.0.0.x and Version 6.0.1.x.
    The Version 6.1 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 6.1 deployment manager. You can then do one of the following based on your needs.
    • Upgrade all Version 6.0.0.x and Version 6.0.1.x nodes to at least Version 6.0.2. This will allow them to be administered by a Version 6.1 deployment manager.
    • Immediately migrate these nodes to Version 6.1.

Frequently asked questions [z/OS]

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

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

Be aware of the following issues when migrating to Version 6.1:
  • Any variables that belong to applications or products 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.1 uses SDK 1.5, 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 or 6.0.x to Version 6.1, 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?
  1. Install the SMP/E code for WebSphere Application Server for z/OS Version 6.1.
  2. Use the Customization Dialog walkthroughs to create the migration utilities that you need to perform the migration.
  3. Run these jobs.

    A new Version 6.1 configuration is created—separate from your existing Version 5.x or 6.0.x configuration—that is based on the Version 5.x or 6.0.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.

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 Migrating a standalone application server: Checklist 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)

BBOWMG1F (federated node 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 or 6.0.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.

BBOWMG2B (standalone application server migrations)

BBOWMG2F (federated node 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 or 6.0.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.

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 6.1 configuration root, and mounts the file system. If you want to use an existing file system to contain the Version 6.1 configuration, you must manually create the mount point specified in the Customization Dialog and make sure 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.
BBOWMG3B (standalone application server migrations)

BBOWMG3D (deployment manager migrations)

BBOWMG3F (federated node migrations)

Performs the migration of the node from Version 5.x or 6.0.x to Version 6.1.
BBOMBCP (standalone application server migrations)

BBOMDCP (deployment manager migrations)

BBOMMCP (federated node migrations)

Copies the generated JCL procedures to start the servers to the specified procedure library. If you choose to have your Version 6.1 configuration make use of different JCL start procedure names, this utility will update the new Version 6.1 configuration, substituting your new JCL names in place of the names that existed in your original Version 5.x or 6.0.x configuration.

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 transform the contents of your present WebSphere Application Server Version 5.x or 6.0.x configuration file system and merge them into a new, separate Version 6.1 configuration file system.

Will my existing configuration be lost during migration?

During the migration, the original WebSphere Application Server Version 5.x or 6.0.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.1 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. WebSphere Application Server Version 5.1 can coexist with Version 6.1 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.1 nodes cannot exist in the same cell on the same LPAR.

Can my newly-migrated WebSphere Application Server for z/OS Version 6.1 deployment manager still "talk" to Version 5.x or 6.0.x nodes?

Yes. A deployment manager migrated to the Version 6.1 level of code can manage a Version 5.x or 6.0.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.1, a new Version 6.1 "master configuration" is created. The Version 5.x or 6.0.x master configuration still exists. But when the Version 6.1 deployment manager makes changes to the configuration, it makes them to the new Version 6.1 master configuration. So while it is possible to use the Version 5.x or 6.0.x code, any changes made in Version 6.1 will not be seen when the older code is restored.
  • A Version 5.x or 6.0.x deployment manager has no ability to manage a Version 6.1 node.
  • A WebSphere Application Server Version 6.1 deployment cell can contain mixed releases of Version 5.x or 6.0.x nodes, but there is no mixed-node management support for Version 6.0.1.x.
    The Version 6.1 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 6.1 deployment manager. You can then do one of the following based on your needs.
    • Upgrade all Version 6.0.1.x nodes to at least Version 6.0.2. This will allow them to be administered by a Version 6.1 deployment manager.
    • Immediately migrate these nodes to Version 6.1.

Is there a sequence to performing a multinode migration?

Yes, there is.
  1. Always migrate the deployment manager first.
  2. WebSphere Application Server for z/OS 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.1 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 WebSphere Application Server for z/OS Version 6.1 coexist with other cells at Version 5.x or 6.0.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:
  • A cell can contain servers at versions 5.0.x, 5.1.x, 6.0.x, and 6.1.x.
  • 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.
  • Version 5.0.x cannot coexist with Version 6.1 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.1 at the same time.
  • Only one version of the code can exist in LPA/LNKLST; the rest must be included in STEPLIB.

    See Link pack area, link list, and 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 configuration file system mount point and separate JCL procedures.



Related tasks
Migrating product configurations
Migrating and coexisting
[z/OS] Preparing to migrate a standalone application server
[z/OS] Preparing to migrate a Network Deployment configuration
[z/OS] Migrating a standalone application server: Checklist
[z/OS] Migrating a deployment manager: Checklist
[z/OS] Migrating a standalone application server: Customization Dialog walk-through
[z/OS] Migrating a deployment manager: Customization Dialog walk-through
[z/OS] Migrating a federated node: Customization Dialog walk-through
[z/OS] Migrating a standalone application server
[z/OS] Migrating a deployment manager
[z/OS] Migrating a federated node
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 2:56:59 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-dist&topic=cmig_overview
File name: cmig_overview.html