![[z/OS]](ngzos.gif)
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 9.0, while those that remain at either IBM WebSphere® MQ 7.1.0 or IBM MQ 8.0.0 can continue to function. This allows you to upgrade queue sharing group queue managers to IBM MQ 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 IBM MQ 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 7.1.0 and IBM MQ 8.0.0 to IBM MQ for z/OS 9.0.
![[Long Term Support]](nglts.gif)
Important: PTFs for
these APARs must be applied on IBM WebSphere MQ 7.1.0 or IBM MQ 8.0.0 prior to attempting to fall back from IBM MQ for z/OS 9.0.0
Long Term Support (LTS) release. ![[Continuous Delivery]](ngcd.gif)
Backwards migration
is not supported for a Continuous Delivery (CD) release.
PTFs for these APARs are the Migration and Toleration PTFs for IBM MQ 9.0 described in Planning for migration to the latest release.
Service has been discontinued for versions of the product prior to IBM WebSphere MQ 7.1.0. No backward migration capability is available for these versions.
The IBM MQ for z/OS 9.0.0 and IBM MQ for z/OS 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 7.1.0 and IBM MQ 8.0.0.
Once updated to the IBM MQ 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
CSQ3111I <cpf> CSQYSCMD - EARLY PROCESSING PROGRAM IS 9.0 LEVEL 008-000
Limitations and restrictions
IBM MQ for z/OS 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, an IBM MQ 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 you 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 you 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.
You cannot backward migrate a queue manager, newly created at IBM MQ 9.0, to a prior release. A queue manager migrated forward to IBM MQ 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 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 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 9.0 panels must be used to administer IBM MQ 8.0.0 or 7.1 queue managers, as ISPF panels from earlier releases do not tolerate responses from any IBM MQ 9.0 queue managers.