Migrating queue managers to new-function fix packs

This scenario illustrates running different levels of queue manager from a single installation using new-function fix packs. New function fix-packs are available on platforms other than z/OS®. It contrasts migrating a queue manager to new command levels in new-function fix packs, to migrating a queue manager to a new command level in a new release. The scenario explains the relationship between new-function fix packs and maintenance fix packs.

Before you begin

In this section, IBM® WebSphere® MQ Version 7.1 is used as the current release, and the release is denoted by r; the subsequent release is denoted by R.

The scenario starts with a single installation of IBM WebSphere MQ Version 7.1, Inst_1. Inst_1 is the primary installation; see Figure 2. For illustration, there are two queue managers, QM1 and QM2 . QM1 stays at the 7r0 command level, QM2 moves to the highest command level available.

The use of version numbers and command levels is illustrative, and does not imply anything about future releases.

About this task

Figure 1 has time advancing down the Y-Axis, as new fix packs are released. On the X-Axis are different command levels. As a queue manager is migrated to a new command level, it shifts across the diagram. Each column represents the fix levels a queue manager at a particular command level can run at.

Figure 1. Migration of queue managers to new command levels using new-function fix packs
Time advances down the Y-Axis, as new fix packs are released. On the X-Axis are different command levels. As a queue manager is migrated to a new command level, it shifts across the diagram. Each column represents the fix levels a queue manager at a particular command level can run at.

Figure 1 is a little complicated, but it captures lots of details about new-function fix packs to help you remember them. The steps in the task explain the details in the figure. Some of the principle features of Figure 1 are explained in the following list:

Maintenance level and Command level

The maintenance level is a fix pack with a V.R.M.F. code; see The version naming scheme for IBM WebSphere MQ on UNIX, Linux, and Windows. V.R.M.F codes are one to four digits, always punctuated by periods. Trailing zeros are sometimes omitted in descriptions, but never when a V.R.M.F code is used to label a fix pack. Version 7.5 is an example of using a V.R.M.F code to describe the version of IBM WebSphere MQ.

The command level is the command level property of a queue manager; see CommandLevel (MQLONG). Command levels are three-digit codes.

Command levels and versions are related. Up to Version 7.1 the command level and the first three digits of the V.R.M.F. code always matched. From Version 7.1, with the introduction of new-function fix packs, the command level of a queue manager can be greater than the first three digits of an installation. The difference arises, if the queue manager has been associated with a new command level using the strmqm command.

From Version 7.1 the rule that links command levels and V.R.M.F levels has been changed. The rule is that when a new version of IBM WebSphere MQ is released, it has a command level greater than released in a new-function fix pack in the previous release. Usually this means that a new release of IBM WebSphere MQ changes the version or release level, rather than the maintenance level.

In Figure 1, the maintenance level, on the Y-Axis is labeled with V.R.M.F codes, and the command level, on the X-Axis, with command levels. Note how the illustrative release of 7.R increases the released command level from 7r0 to 7R0, and 7R0 exceeds the highest command level shipped in a new-function fix pack, 7r5 .

Reversible and One-way upgrades

The mechanism to apply and remove fix packs varies by platform. You can apply any fix pack that changes only the maintenance or fix level of a release to an installation. Fix pack application is reversible. When you remove a fix pack, you restore the previous release level. So applying 7.r.0.3 to 7.r.0.1, and then removing it, restores the installation to 7.r.0.1 .

Sometimes, you can change an installation to a particular V.R.M.F level by upgrading the installation with a manufacturing refresh. If you install a manufacturing refresh, you can only return to the earlier release level by uninstalling, and reinstalling; see Upgrade, migration, and maintenance of IBM WebSphere MQ on UNIX, Linux, and Windows.

Applying a manufacturing refresh to modify the maintenance and fix level of a release is the same process as upgrading to a new version or release of IBM WebSphere MQ. Neither can be reversed without uninstalling.

However there is a particular aspect of upgrading to a new version or release that is different from upgrading to a new maintenance or fix level. If you start a queue manager after a version or release upgrade, the command level of the queue manager is automatically increased. You can then no longer start the queue manager with the installation from the previous release.

On the diagram, an irreversible upgrade is shown by the One-way arrow between 7.r and 7.R. To prevent an accidental migration, you can rename the new installation. After renaming, rerun the setmqm command to associate a queue manager with the new release before running the strmqm command to migrate it.

If the upgrade applies only to the maintenance or fix level, you can restart the queue manager with the previous installation, if you reinstall it.

Manufacturing refresh maintenance releases are not distinguished from applying and removing fix packs on the diagram. Both are represented by reversible arrows in Figure 1.

Multiple installations

You might choose to have a different installation for each maximum command level supported by an installation. Each column on the diagram would represent a different installation.

You need only one installation at Version 7.1 to be able to select any command level released with Version 7.1 for a queue manager. Eventually, if you intend to run Version 7.1 and version 7.R in parallel, you must have two installations. The scenario that follows uses a single installation.

Another variation is to follow the rolling fix pack approach described in UNIX, Linux, and Windows: Staging maintenance fixes. You can maintain two installations at Version 7.1, one at the current fix level, and one either at a later or earlier fix level. You might then install version 7.R as a third installation, or replace the Version 7.1 installation at the older fix level.

Migrating queue managers

The migration paths for queue managers are shown by solid arrows on the diagram. Some of the solid arrows are broken, to avoid cluttering the diagram with too many lines. If the migration to a higher command level jumps command levels, you do not have to migrate it through the intervening commands levels.

To migrate a queue manager to a higher command level in a new-function fix pack, you must start the queue manager with a special parameter:
Read syntax diagramSkip visual syntax diagram strmqm  -e CMDLEVEL=Level  QMgrName
Level is the three-digit command level.

The queue manager stops immediately the migration process is complete. When you next start it, it runs at the new command level. The queue manager cannot be restarted at a lower command level. This rule means that you must associate the queue manager with an installation that includes a command level at least as great as the current command level of the queue manager.

Restoring queue managers
To restore a queue manager to a lower command level, you must back up the queue manager before you migrate it to the higher command level.

Procedure

This procedure keeps both QM1 and QM2 at the current maintenance level, QM1 at command level 7r0, and QM2 at the latest command level.

  1. Download fix pack 7.r.0.1, when it is released.

    The initial system has two queue managers running 7.r.0.0 at command level 7r0; see Figure 2.

    Figure 2. Initial state, QM1 and QM2 at command level 7r0, and fix level 7.r.0.0
    The same picture as figure 1, but showing the initial state highlighted. QM1 and QM2 at 710 and 7.1.0.0
  2. Apply fix pack 7.r.0.1 to Inst_1 .
  3. Restart the queue managers.
    • Both queue managers are now running using Inst_1 at the 7.r.0.1 maintenance level, and the 7r0 command level; see Figure 3 .
    Figure 3. QM1 and QM2 at command level 7r0, and fix level 7.r.0.1
    The same picture as figure 2, but showing the first state highlighted.
  4. Apply fix pack 7.r.0.2.
    1. Repeat steps 1 and 2 with fix pack 7.r.0.2 .
  5. Restart QM1.
    • QM1 is now running using Inst_1 at the 7.r.0.2 maintenance level, and the 7r0 command level.
    • The queue manager is not automatically migrated to the 7r1 command level.
  6. Migrate QM2 to the 7r1 command level. 
    strmqm -e CMDLEVEL=711 QM2
    • QM2 is using Inst_1 at the 7.r.0.2 maintenance level, and has been migrated to the 7r1 command level.
  7. Restart QM2.
    • QM2 is now running using Inst_1 at the 7.r.0.2 maintenance level, and the 7r1 command level; see Figure 4 .
    Figure 4. QM1 at command level 7r0 and fix level 7.r.0.2; QM2 at command level 7r1 and fix level 7.r.0.2
    The same picture as figure 1, but showing the second state highlighted.
  8. Apply fix pack 7.r.0.3 and migrate QM2 to the 7r5 command level.
    1. Repeat steps 4 to 5 with fix pack 7.r.0.3 .
    2. Repeat steps 6 to 7 with command level 7r5 .
    • QM1 is using Inst_1 at the 7.r.0.3 maintenance level, and is running at the 7r0 command level.
    • QM2 is using Inst_1 at the 7.r.0.3 maintenance level, and has been migrated to the 7r5 command level; see Figure 5 .
    Figure 5. QM1 at command level 7r0 and fix level 7.r.0.3; QM2 at command level 7r5 and fix level 7.r.0.3
    The same picture as figure 1, but showing the third state highlighted.
  9. Migrate QM2 to version 7.R
    • On UNIX, Linux, and Windows:
    1. Install version 7.R, with the installation name Inst_2, alongside Version 7.1 .
    2. Set up the local environment to the installation Inst_2.
      Windows:
      "Inst_2_INSTALLATION_PATH
\bin\setmqenv" -s

      The -s option sets up the environment for the installation that runs the setmqenv command.

      UNIX:
      . 
Inst_2_INSTALLATION_PATH/bin/setmqenv -s
    3. Run the setmqm command to associate QM2 with Inst_2. 
      setmqm -m QM2 -n Inst_2
    4. Run the strmqm command to start QM2 and migrate it to version 7.R. 
      strmqm QM2
    • QM1 is using Inst_1 at the 7.r.0.3 maintenance level, and is running at the 7r0 command level.
    • QM2 is using Inst_2 at the 7.R.0.0 maintenance level, and has been migrated to the 7R0 command level; see Figure 5 .
    • Inst_1 remains the primary installation.
    Figure 6. QM1 at command level 7r0 and fix level 7.r.0.3; QM2 at command level 7R0 and fix level 7.R.0.0
    The same picture as figure 1, but showing the final state highlighted.