+

Search Tips | Advanced Search

Queue manager migration

After upgrading an installation, queue manager migration might be required. Migration takes place when you start a queue manager. We can remove an upgrade before you have started a queue manager. However, if you remove the upgrade after a queue manager has been started, the queue manager will not work.


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. Changes in the maintenance and fix level, M and F in the VRMF, never cause automatic queue manager migration. From Version 7.1 onwards, 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, we 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. We can decide to install the fix pack, but not use the new function. Whether or not we 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.

We 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, we need to perform the verification on a different server, or in a virtualized environment on the same server. If the platform we are upgrading supports queue manager coexistence, we 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.

Note: If we are migrating a queue manager through multiple release levels, one level at a time, you must start the queue manager after each upgrade to migrate it. We must also start all the channels, to ensure they are migrated.

When migrating queue managers that are members of a cluster, migrate full repositories before partial repositories. This is because an older repository cannot store newer attributes introduced in a newer release. It tolerates them, but does not store them.


Restoring a queue manager to an earlier release

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

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

  • We can only backwards migrate a queue manager from an LTS release to an earlier LTS release. This statement also applies to those CD releases that have the same VRM as an LTS release, for example Version 9.2.0 CD. For more information, see IBM MQ release types.
  • From Version 9.1.0 the OPMODE parameter has been removed.

    A Version 9.2.0 LTS or CD queue manager can always be backwards migrated to the release it was previously running at, if the release was one of Version 9.0.0 LTS or Version 9.1.0 LTS.

Parent topic: Migration concepts and methods


Related concepts


Related tasks

Last updated: 2020-10-04