Reverting a queue manager to a previous version on z/OS

After migrating to IBM MQ for z/OS Version 9.2.0 LTS or Version 9.2.0 CD, from either Version 9.0.0 or Version 9.1.0, we can backward migrate, or fallback, to the version you were using prior to migration. Backwards migration is not supported for a CD release such as Version 9.1.5.

Before starting

Certain function available in Version 9.2.0 can affect the ability to backwards migrate. These functions are not enabled by default, but if you have enabled these functions, we need to remove them prior to performing backwards migration.

We should not exploit new Version 9.2.0 functions, until we are sure that we will not need to perform backwards migration.

If the queue manager has z/OS data set encryption policies applied to one or more of its active logs or page sets, or SMDS, then these policies need to be removed, and the data decrypted, prior to backwards migration. This process is described in Backwards migration considerations when using z/OS data set encryption .

If the queue manager makes use of any of the new CipherSpec options available in Version 9.2, these options need to be removed and replaced with a CipherSpec that was previously used on the channel, prior to backwards migration.

If the queue manager makes use of Advanced Message Security interception on server-to-server message channels, then this configuration needs to be removed, once all relevant messages have been sent to their target location. See Overview of Advanced Message Security interception on message channels for more information.

About this task

A queue manager can only be backwards migrated, if it outputs the CSQY039I message at start up. In this case we can use the information in this topic to perform the backwards migration.

Backwards migration is normally only performed immediately after a migration fails for some reason. However, it is possible to perform backwards migration at any time if the CSQY039I message is output at queue manager start up.

If a queue manager issues the CSQY040I message at start up, backwards migration is not supported, and the procedure described in the following text is not applicable. If we have a back up of the queue manager data, prior to the migration, you could use that data to start the queue manager up at the earlier release.

Procedure

1. Ensure that the queue manager does not have any offline page sets. If it does, use the command CSQUTIL FORMAT to bring the page sets back online.
2. Shut the queue manager down cleanly.
3. Run the command START QMGR BACKMIG(vrm) where vrm is the version, release and modifier value of the release previously migrated from, for example 900. This value is output in the CSQY039I message at queue manager start up.Attention: We need to remove the period characters from the message output. The queue manager starts up, rewrites its data in a format suitable for backwards migration, and shuts down. If the command processes successfully, the CSQY045I message is output. If the CSQY043E message is output, examine the messages displayed to resolve the problem and retry the command again.
4. Switch back to use the MSTR and CHINIT started procedure JCLs with the Version 9.0.0 or Version 9.1.0 libraries, as required.

   If data set aliases are being used for load libraries, switch the aliases to refer to the Version 9.0.0 or Version 9.1.0 libraries.

   For example, an alias named MQM.MQP1.SCSQLOAD, referring to MQM.MQV920.SCSQLOAD, needs to be changed to refer to MQM.MQV910.SCSQLOAD, or MQM.MQV900.SCSQLOAD, as required.

5. If you had planned to define a QMINI data set and you had added CSQMINI DD to your MSTR started procedure, remove the CSQMINI DD card.
6. Revert to using the system parameter module (CSQZPARM) used with IBM MQ Version 9.0.0 or IBM MQ Version 9.1.0, prior to migration, and linking to the Version 9.0.0 or Version 9.1.0 code, as required. Important: If you were previously running at Version 9.0.0 with OPMODE(COMPAT,nnn) and you have enabled function at Version 9.2.0, which is protected by OPMODE in Version 9.0.0 you need to recompile your ZPARMs to OPMODE(NEWFUNC,900).
7. Verify the backwards migration by starting the queue manager, channel initiator and, listener or listeners separately.
8. Check for, and resolve, any errors that occur during start up. Once all three components start up cleanly, we can combine the start up of the three components, if required.
9. Verify correct functioning of existing applications.

Results

Your queue manager will now be running at the version of code it was originally migrated from.Note: It is not necessary to fall back the early code to the previous version, for this installation, when reverting your queue manager to an earlier version.

Early code refers to the IBM MQ load modules that must be loaded into the Link (LPA) for IBM MQ to act as a z/OS subsystem. When a command is issued to a queue manager, or when an application connects to a queue manager, the first action taken by the IBM MQ system is to load the early code.

The LPA must contain the IBM MQ early code modules from the latest version of IBM MQ running on the system. For example, if a Version 9.0.0 and Version 9.2.0 queue manager run on the same system, the early code for Version 9.2.0 must be loaded in the LPA.

See Early code for more information.

Parent topic: Migrating a single IBM MQ z/OS queue manager to Version 9.2