The version naming scheme for IBM MQ for Multiplatforms

From IBM® MQ 9.0, releases have a three digit Version, Release, and Modification (VRM) code or a four-digit Version, Release, Modification, and Fix (VRMF) level code.

From IBM MQ 9.0, the full version of IBM MQ is described by a three-digit or four-digit number.

[Long Term Support] For the Long Term Support (LTS) release model, the number consists of a four-digit VRMF code.

[Continuous Delivery] For the Continuous Delivery (CD) release model, the number consists of a three-digit VRM code on z/OS® and a four digit VRMF code on Multiplatforms, where the final digit is always a zero.

The VRMF acronym stands for:


Version.Release.Modification.Fix

The two release types are distinguishable by the modification number in the version.release.modification (v.r.m) release identifier.

Long Term Support releases have a modification number of zero, for example, 9.0.0.

[Continuous Delivery] Continuous Delivery releases have a modification number that is non-zero, for example, 9.0.1, 9.0.2, and so on.

The version and release parts of the code are significant; they identify the service life of a release. To run a queue manager at a different VR level, you must migrate the queue manager, its applications, and the environment in which it runs. Depending on the migration path, the migration might require more or less effort.

7.5, 7.1.0.6, and 8.0.0.4 are examples of IBM MQ version codes for previous versions.

You can find the full version level of an IBM MQ installation by typing the command dspmqver, or DSPMQMVER on IBM i. It returns the full three-digit VRM, or four-digit VRMF code.

Versions and releases of IBM MQ are known by the first two digits of the VRMF code. The two digits are sometimes prefixed by a V, such as 9.0. A version of IBM MQ always has a release level, even if it is the first release in a version.

The first release is normally labeled V x.0, for example, IBM MQ 8.0. Occasionally, the first release of a version on a specific platform is not labeled V x.0. It is numbered to correspond the command level that has been implemented on the platform.

The third digit in the VRMF identifies the modification level of a release. A change in the third digit does not change the release. For example, after upgrading IBM MQ to modification level 8.0.1, the release of IBM MQ remains 8.0. However the command level does change to 801.

Notes:

Backward migration is not possible. To be able to restore an earlier version or release level of a queue manager, you must back it up before upgrading. If you do restore it, you restore the queue manager, and its data, to the state it was in when you backed it up.
Backward migration is possible only if you are using the LTSR model.

The fourth digit in the VRMF code represents the fix pack level. For example, the first fix pack of the IBM MQ 9.0.0 LTS release is numbered 9.0.0.1. Fix levels do not affect the command level of the queue manager. No migration is required, and fix levels do not affect the service end date of a release.

From 1Q 2023, there are two types of maintenance:

Fix packs: Fix packs contain roll-ups of all defects fixed since the previous fix pack delivery (or GA). Fix packs are produced exclusively for Long Term Support (LTS) releases during their normal support lifecycle.
Cumulative security updates (CSUs): CSUs are smaller updates and contain security patches released since the previous maintenance (GA). CSUs are produced for LTS releases (including releases in extended support), and for the latest IBM MQ Continuous Delivery (CD) release, as required to deliver relevant security patches.

Therefore, for maintenance releases in or after 1Q 2023, the fourth digit in the VRMF represents either a fix pack number of a CSU number. Both types of maintenance are mutually cumulative (that is, they contain everything included in older CSUs and fix packs), and both are installed using the same mechanisms for applying maintenance. Both types of maintenance update the F-digit of the VRMF to a higher number than any previous maintenance: fix packs use “F” values divisible by 5, CSUs use “F” values not divisible by 5.

For maintenance releases before 1Q 2023, the fourth digit in the VRMF always represents the fix pack level. For example, the first fix pack of the IBM MQ 9.0.0 LTS release is numbered 9.0.0.1.

Attention: From IBM MQ 9.0, the name is changed, for example, to 9.0.0-IBM-MQ-Windows-FP0001.

Applying updates

Refresh packs and fix packs for a particular version/release are cumulative, from the initial release. You can apply any higher numbered refresh, or fix pack, of the same version/release to upgrade directly to that version level. You do not have to apply the intervening fixes. Refresh packs and fix packs are obtained as service through Fix Central.

The latest modification level is also used to refresh the version of IBM MQ available through Electronic Software Download using Passport Advantage®, or on physical media.

When you order IBM MQ you receive the latest version of the LTS, or CD product, depending on which support model your enterprise is using.

The result of installing a manufacturing refresh is almost the same as applying the refresh pack to an earlier fix level of IBM MQ. There is one important difference. Refresh packs are applied using a maintenance procedure, manufacturing refreshes are installed using an installation procedure. You can "unapply" a refresh pack to return to the previous fix level you had installed. You can only uninstall a manufacturing refresh, which removes IBM MQ from your system.

In addition to fixes packaged as refresh packs and fix packs, you can also obtain interim fixes for IBM MQ. You get these from Fix Central. Interim fixes are also known as emergency or test fixes, and are known collectively as interim fixes. The naming scheme for refresh and fix packs extends to interim fixes. Interim fixes are known either by their fix name, or by the list of APARs they fix.

When you apply new fix packs or refresh packs, all interim fixes are removed. The documentation with the fix pack or refresh pack tells you if the APARS associated with the interim fixes you have applied have been fixed. If they have not, check to see if there are new interim fixes, at the new level, for the APARs that concern you. If there are not, consult service. They might either tell you to reapply the interim fix, or supply a new interim fix.