Characteristics of upgrades and fixes

For IBM MQ, 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.

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. Attention: On z/OS Continuous Delivery releases, certain PTFs will increase the modification level, and therefore, should be considered an upgrade.

On all other platforms we must reinstall the product.

Characteristics of different types of upgrade

An upgrade can take one of three different forms:

1. Installation of new code on top of existing code. We might be able to roll back an upgrade applied in this way; it depends on the platform. Generally speaking, we cannot roll back the installation of new code. To restore the old code level, we must retain the old installation media, and any fixes you applied.
2. 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, we must reinstall it and any fixes.
3. Side by side installation.
   • On z/OS we can install different code levels alongside each other on the same server. In the JCL 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.

   We must not infer from this, that we 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. We can retain any queue managers that we have created.

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 and migration 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.

On the following platforms, changes in version, release, or modification level are not fully reversible, but changes in fix level are reversible under certain conditions.

• UNIX
• Linux
• Windows
• IBM i

An irreversible upgrade implies that we must back up the queue managers, or the 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 we do not take a backup, we 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.

Parent topic: Applying upgrades and fixes to IBM MQ

Related concepts

• Upgrade and migration of IBM MQ on z/OS