Backward migration to earlier supported releases of IBM MQ for z/OS

After installation of a new release of IBM MQ for z/OS®, you carry out queue manager migration by stopping the queue manager, which is running with the prior release of code, and restarting the queue manager using the new release of code.

Maintenance in a queue sharing group

In a queue sharing group, individual queue managers can be migrated forwards to IBM MQ Version 9.0, while those that remain at either IBM WebSphere MQ Version 7.1.0 or IBM MQ Version 8.0.0 can continue to function. This allows you to upgrade queue sharing group queue managers to Version 9.0 at different times, maintaining the high availability of the queue sharing group.

The function required to enable lower level queue managers to tolerate Version 9.0 additions to QSGDISP(GROUP) and QSGDISP(SHARED) objects is incorporated in the same authorized program analysis reports (APARs) which provide backward migration capability.

Code levels supported

Migration support is provided from both IBM WebSphere MQ Version 7.1.0 and IBM MQ Version 8.0.0 to IBM MQ for z/OS Version 9.0.

The backward migration APARs are PI64465 for IBM WebSphere MQ Version 7.1.0, and PI64466 for IBM MQ Version 8.0.0. Important: PTFs for these APARs must be applied on IBM WebSphere MQ Version 7.1.0 or IBM MQ Version 8.0.0 prior to attempting to fall back from IBM MQ for z/OS Version 9.0.0 Long Term Support (LTS) release.

Backwards migration is not supported for a Continuous Delivery (CD) release.

PTFs for these APARs are the Migration and Toleration PTFs for Version 9.0 described in Plan for migration to the latest release.

Service has been discontinued for versions of the product prior to IBM WebSphere MQ Version 7.1.0. No backward migration capability is available for these versions.

The IBM MQ for z/OS Version 9.0.0 and IBM MQ for z/OS Version 9.0.1 early code installed in the link pack area (LPA) is downward compatible. The code supports queue managers running at IBM WebSphere MQ Version 7.1.0 and IBM MQ Version 8.0.0.

Once updated to the Version 9.0 level, and the queue manager subsystem refreshed using the REFRESH QMGR TYPE(EARLY) command, the early code need not be changed for any subsequent forward or backward migration activity

Message

CSQ3111I <cpf> CSQYSCMD - EARLY PROCESSING PROGRAM IS V9.0 LEVEL 008-000

is displayed during startup in the queue manager joblog and indicates that the queue manager is using the correct level of early code.

Limitations and restrictions

IBM MQ for z/OS Version 9.0 uses a migration switch to support backward migration by preventing use of certain new functions, that cannot be backward migrated, until the installation confirms that backward migration is no longer required.

The migration switch is configured through a change to ZPARM using the OPMODE parameter of CSQ6SYSP.

While OPMODE is set to COMPAT, it is possible to backward migrate from a Long Term Support (LTS) release, although certain new functions are not available. Once OPMODE is set to NEWFUNC, all new functions are available, but it is no longer possible to perform backward migration.

Backwards migration is not supported for a Continuous Delivery (CD) release. Queue managers running a CD release of IBM MQ must be started with OPMODE=(NEWFUNC,90x). For example, a Version 9.0.1 queue manager must be started with OPMODE=(NEWFUNC,901).

The MQSC command DISPLAY SYSTEM command displays three values, the operation mode, either COMPAT or NEWFUNC, and two version numbers. The first version number indicates to which version of IBM MQ for z/OS we can fall back to. The second version number indicates level of new functions that are available

When the operation mode is COMPAT, then the version number indicates to which version of IBM MQ for z/OS we can fall back.

The value of OPMODE displayed during startup in message CSQY101I reflects the operation mode requested using ZPARM. Queue manager initialization evaluates the requested operation mode in combination with local state and other members of the queue sharing group, to determine the actual operation mode displayed with DISPLAY SYSTEM.

We cannot backward migrate a queue manager, newly created at Version 9.0, to a prior release. A queue manager migrated forward to Version 9.0 remembers where it was migrated from, and it is only possible to fall back to that remembered prior version.

Certain connection types (IMS, BATCH and RRSBATCH used by WAS and Db2® stored procedures) allow an application to connect to multiple queue managers concurrently. If required, these queue managers can be running different levels of IBM MQ code. In such a scenario, the adapter code (usually referenced through a STEPLIB DD statement or environment variable) must be loaded from libraries corresponding with the highest level of the queue managers connected. This ability for the adapter code to support connections to older queue managers means that in a backward migration scenario it is possible to just restart the MSTR and CHIN procedures with the back level code, and not change connecting jobs.

The operations and controls ISPF panels, CSQOREXX, from IBM MQ for z/OS Version 9.0, are able to connect to and administer queue managers from a prior release. However, the ISPF panels from lower releases are not able to connect to IBM MQ for z/OS Version 9.0. When migrating, or during fall back, either use the same version ISPF panels as the level of code the queue manager is running, or use CSQOREXX from the higher release of code. In a mixed level queue sharing group, the IBM MQ for z/OS Version 9.0 panels must be used to administer Version 8.0.0 or Version 7.1 queue managers, as ISPF panels from earlier releases do not tolerate responses from any Version 9.0 queue managers.