Queue manager migration

Migrating a queue manager to a later release

On IBM® MQ for z/OS®, queue manager migration is required after upgrading to a different version, release, or maintenance level of the product. The upgrade changes the command level. The current command, or VRM, level is shown in the z/OS console log.

On IBM MQ for Multiplatforms, queue manager migration is always required for changes in the first two digits of the VRMF code. Changes in the maintenance and fix level, M and F in the VRMF code, never cause automatic queue manager migration. A change in the command level always requires queue manager migration, but if the change is shipped in a maintenance or fix pack, you have the choice of whether to increase the command level, and cause queue manager migration.

Command level always increases with a change in version or release. If you decide to use new function introduced in a maintenance level upgrade, you must change the command level. The converse is not the case. You do not have to change the command level when the fix level changes. You can decide to install the fix pack, but not use the new function. Whether or not you use the new function, the installation of the fix pack increases the maximum command level supported by the installation. Run the dspmqver command to display the current maximum supported command level.

Queue manager migration is the process of converting persistent queue manager data from one version to another. Persistent queue manager data includes log files and data in the queue manager directory. The data records changes to objects such as messages, subscriptions, publications, queue managers, channels, queues, and topics.

Queue manager migration is required and largely automatic.

On z/OS, you must migrate queue managers manually between compatibility mode and new function mode by setting the OPMODE parameter.

You can reduce the downtime and risk caused by queue manager migration, by verifying the new version first, using a different queue manager. Unless the platform supports queue manager coexistence, you need to perform the verification on a different server, or in a virtualized environment on the same server. If the platform you are upgrading supports queue manager coexistence, you can install the new version of IBM MQ on the same server, verify it, and minimize downtime to the time required to stop, backup, and restart the queue manager.

Restoring a queue manager to an earlier release

For IBM MQ for Multiplatforms, you cannot restore a queue manager to an earlier release level after you have migrated it to a new release. You must back up your system before starting backwards migration. You can either back up queue manager data, or use a backup queue manager; see Backing up and restoring IBM MQ. Before backing up, you must stop the queue manager.

For IBM MQ for z/OS, the following considerations apply to migration:

• It is impossible to revert to an earlier release after switching a queue manager to new function mode by running with OPMODE NEWFUNC. Provided that you have not switched the queue manager to new function mode, you can backwards migrate, as described in Migration PTFs.
• From IBM MQ 9.0, you can backwards migrate queue managers only if you are using the Long Term Support (LTS) release model, and provided that you have not set the OPMODE to NEWFUNC. For more information, see IBM MQ release types.
• On z/OS, you must migrate queue managers manually between compatibility mode and new function mode by setting the OPMODE parameter. If you have never switched a queue manager to new function mode, you can still run it against the earliest release it is compatible with. You must have applied compatibility PTFs to the earlier release before starting a queue manager at the new command level. The compatibility level is shown in the log.