The version naming scheme for IBM MQ (On platforms other than z/OS )

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

The full version of IBM MQ (On platforms other than z/OS® ) is described by a four-digit VRMF code.

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.

The VRMF acronym stands for:

 Version . Release . Modification . Fix

8.0, 7.5.0.1, and 7.0.1.0 are examples of full IBM MQ version codes.

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 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 V8.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 Vx.0, for example, IBM MQ V7.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.

In documentation, the release level is sometimes dropped from the VRMF code, for example, V7. Dropping the release level can lead to ambiguity, if the context is not clear. For example, V7 might mean the whole of V7, or the release level V7.0, as opposed to the release level V7.2, or V7.3.

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 7.0.1, the release of IBM MQ remains 7.0. However the command level does change to 7.0.1.

The significance of the distinction between release and modification level concerns migration, and the service life of a product. Queue manager objects, such as queue managers, channels, queues, and messages do not require migration to upgrade to a new modification level. Nor do they require migration if the modification level is removed ¹ . Migration might be required for a version or release level change.

Note: 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.

A new version or release has a new service end date. New modification levels generally do not result in a new service end date. But if a modification level is announced, then a new service end date might be announced too.

The fourth digit in the VRMF code is the fix level. 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.

Trailing zeros in the VRMF code are never significant, but are sometimes quoted for clarity. For example, you might see 7.0.0 to distinguish it from 7.0.1, and 7.0.1.0 to distinguish it from 7.0.1.1. 7.0.0 is no different from 7.0 or 7.0.0.0, and 7.0.1 and 7.0.1.0 are the same level.

Modification levels and fix levels are known by three and four-digit VRMF codes. 7.0.1 is a modification level and 7.0.1.2 is a fix level. Modification levels are shipped as refresh packs, and fix levels as fix packs.

A refresh or fix pack is named using a two part name that uniquely identifies it. The first part of the name is a truncated VRMF. The second part of the name is the name new refresh or fix pack. So, for example, the name of the fix pack 7.0.1.2 for Windows is 7.0.1-WS-MQ-Windows-FP0002, and the name of the refresh pack 7.0.1 for Windows is 7.0-WS-MQ-Windows-RP0001.

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 a manufacturing refresh at the latest modification level. 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.