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

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

Before you begin

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

You should not exploit new IBM MQ for z/OS 9.2.0 functions, until you are sure that you 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 IBM MQ for z/OS 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 you 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.

Notes:

• After performing a START QMGR BACKMIG(vrm), the queue manager is ready to be started at the specified level.

  If, instead, you start the queue manager at a higher version level than was specified for the BACKMIG operation, the queue manager forward-migrates the queue manager to the higher version, and it is no longer possible to backwards migrate unless you repeat the START QMGR BACKMIG operation.

• The BACKMIG operation makes direct changes to the page sets of IBM MQ and the objects stored on them. This means that you can restart the queue manager at the specified BACKMIG version, even if an IPL occurs before queue manager restart, or if the queue manager is started on a different LPAR.

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 you 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.

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: You need to remove the period characters from the message output.
   You should include the PARM parameter, if it is used usually with the START QMGR command.
   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 IBM MQ 9.0.0 or IBM MQ 9.1.0 libraries, as required.

   If data set aliases are being used for load libraries, switch the aliases to refer to the IBM MQ 9.0.0 or IBM MQ 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 9.0.0 or IBM MQ 9.1.0, prior to migration, and linking to the IBM MQ 9.0.0 or IBM MQ 9.1.0 code, as required.
   Important: If you were previously running at IBM MQ for z/OS 9.0.0 with OPMODE(COMPAT,nnn) and you have enabled function at IBM MQ for z/OS 9.2.0, which is protected by OPMODE in IBM MQ for z/OS 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, you can combine the start up of the three components, if required.
9. Verify correct functioning of existing applications.