IBM MQ upgrades and fixes

The term upgrade applies to changing the version V, release R, or modification M of a product. The term fix applies to a change in the F digit.

When you upgrade from one release to another, or apply maintenance refresh packs, fix packs, or interim fixes, the impact of the change depends on the extent of the change in V,R,M,F level. The VRM codes are explained in The version naming scheme for IBM MQ (On platforms other than z/OS ).

At each change of V, R, or M, the command level on the queue manager changes, but on a change to F, the command level does not.

On distributed platforms, after an upgrade has been applied, the only way to back out a V.R.M change is by:

Uninstalling the product code and reinstalling the code, or
Installing the old level of code alongside the existing code and using the setmqm command to associate the queue manager with the other installation.

The general rule, is that if you have carried out an install that causes the command level of the new installation to be updated, and started the queue manager, you cannot back out the changes.

Characteristics of fixes

Application of a fix pack, interim fix, or a program temporary fix (PTF) using a maintenance installation tool should be called a fix.

Fixes, applied using a maintenance installation tool, can be rolled back completely, as long as no queue manager migration has taken place on:

AIX®
Windows
z/OS®

and IBM MQ is returned to its previous code level.

On all other platforms you must reinstall the product.

Characteristics of different types of upgrade

An upgrade can take one of three different forms:

Installation of new code on top of existing code. You might be able to roll back an upgrade applied in this way; it depends on the platform. Generally speaking, you cannot roll back the installation of new code. To restore the old code level, you must retain the old installation media, and any fixes you applied.
Removal of the old level of code, followed by installation of the new level. The installers on very few platforms require you to remove an old installation first. Needless to say, to restore the old code level, you must reinstall it and any fixes.
Side by side installation.
- On z/OS you can install different code levels alongside each other on the same server. In the Job Control Language to start a subsystem, you select the code level to use.
- On UNIX, Linux®, and Windows, you associate a queue manager with an installation, and start the queue manager. In IBM MQ, running multiple queue managers at different command levels on the same server is termed queue manager coexistence.
You must not infer from this, that you can select different installations to run a queue manager at different times. Once a queue manager has been run, it is subject to the rules regarding reverting to earlier or later command levels.

Note: The term upgrade does not imply that an IBM MQ installation can be directly upgraded from one level to another. On some platforms, an upgrade requires that you remove the previous IBM MQ installation. You can retain any queue managers that you have created.

[z/OS] On z/OS, reversibility of an upgrade has two parts; backout of the installation to the previous code level, and reversion of any queue managers that have been started at the new code level, to work with the previous code level again. See Upgrade, migration, and maintenance of IBM MQ on z/OS for more information.

The rules regarding the reversibility of an queue manager to run on a previous code level is dependent on the platform.

Distributed On IBM i, UNIX, Linux, and Windows, changes in version, release, or modification level are not fully reversible, but changes in fix level are reversible under certain conditions.

An irreversible upgrade implies that you must back up the queue managers, or your system, before upgrading, to be able to restore your queue managers. Taking a backup of a queue manager requires you to stop the queue manager. If you do not take a backup, you are not able to restore IBM MQ to its previous level. Any changes you make on the new level cannot be restored onto the backup system. Changes include the creation or deletion of persistent messages, and changes to queue managers, channels, topics, and queues.