Upgrade and migration of IBM MQ on z/OS

We can install new releases of IBM MQ to upgrade IBM MQ to a new release, or version level. Multiple installations at the same or different levels can coexist on the same z/OS® instance. Running a queue manager at a higher level requires migration.

When you install a new VRM level of IBM MQ on z/OS using SMP/E, it creates a set of IBM MQ libraries. The libraries for different VRM levels of IBM MQ can coexist on the same instance of z/OS. We can then run different queue managers against different release levels of IBM MQ on the same z/OS instance.

If you start a queue manager running on a later release level, then migration of the queue manager to that release level is required. Even if the difference is only in the modification level, some migration might be required. The migration tasks that you must perform to migrate from one version to another are documented in Plan to migrate IBM MQ to a later version on z/OS; see also Changes that affect migration.

From Version 7.0.1, after we have fully migrated a queue manager to a new version or release, reverse migration is not possible. For Version 7.0.1 and later versions, we have control over when migration takes place, using a new CSQ6SYSP parameter, OPMODE; see OPMODE on z/OS. If your queue manager is on Version 7.0 or earlier, we can revert to an earlier release. You might have to contact your IBM support center for a backward migration PTF.

Use OPMODE, we can migrate all your existing applications to the new release level, and still be able to revert to the previous release level. Once you start changing applications, or adding applications that use new function, we cannot revert to the previous level of the product. OPMODE applies to migration from Version 6.0 to Version 7.0.1 onwards.

1. Regression test your existing applications.
2. Develop new applications, and change existing applications, to use the new function in the release.

1. Apply the coexistence and backward migration PTFs to all the queue managers you are going to upgrade. After applying the PTFs, we can run queue managers of different levels in the same queue sharing groups. We can also reverse the migration of a queue manager back to your current level.
2. Upgrade the first queue manager.
3. Check all your existing applications run correctly on this queue manager.
4. Bring all the queue managers in a queue sharing group up to the new level, and check that existing applications continue to work correctly.
5. Change the setting of OPMODE so that applications can use new function on all the queue managers in the queue sharing group. Note: Step 5 is the point of no return. We can no longer run that queue manager at the previous level of the product.
6. To enable new Version 7.1 or later, function, restart all queue managers within the queue sharing group.

1. To allow queue managers at the earlier release level to coexist with ones at the later release level. In particular for queue managers to coexist in the same queue sharing group.
2. To handle queue manager data and logs formatted using the data definitions of the later release.

Characteristics of different types of upgrade on z/OS

When you upgrade from one release to another on z/OS, the impact of the change depends on the extent of the change in VRM level. The VRM codes are explained in The version naming scheme for IBM MQ for z/OS.

Note that migration is required if the version, release, or modification number changes.

From Version 7.0.1, all upgrades from Version 6.0 or later to a Version 9.0 Long Term Support (LTS) release are reversible if the OPMODE has not been set to NEWFUNC.

Upgrades to a Continuous Delivery (CD) release are not reversible.