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

Carry out the instructions in this topic to migrate a single IBM MQ queue manager on z/OS .

About this task

To migrate an IBM MQ queue manager on z/OS to a different version, we need to carry out the:

• Process described in Preparing to migrate a single IBM MQ for z/OS queue manager
• Detailed steps in this topic, using the links within this overview.
  1. Update the initialization input data sets; see step 1.
  2. Stop or disconnect all the applications using the queue manager; see step 2.
  3. Stop the queue manager and its channel initiator; see step 3.
  4. Update STEPLIB for the queue manager and the channel initiator; see step 4.
  5. If we have planned to define a QMINI data set, update the queue manager startup JCL to add the CSQMINI DD card; see step 5.
  6. If using Advanced Message Security set the AMSPROD attribute; see step 6.
  7. Start the queue manager and its channel initiator; see step 7.
  8. Test that everything is working correctly. If there is a problem starting the queue manager, revert the queue manager to a previous version; see step 8.

  9. Optionally, migrate the mqweb server; see step 9.

Procedure

1. Update the initialization input data sets. Each IBM MQ queue manager gets its initial definitions from a series of commands contained in the IBM MQ initialization input data sets. These data sets are referenced by the Data Definition (DD) names CSQINP1, CSQINP2, and CSQINPT defined in the queue manager started task procedure. The channel initiator started task procedure has a similar data set referenced by the CSQINPX DD name.

   See Customize the initialization input data sets for more information on the initialization input data sets.

   The samples supplied for the initialization input data sets can change between versions of IBM MQ. We must review the customization you have made previously to CSQINP1, CSQINP2, CSQINPT, and CSQINPX, and merge them into the initial definitions provided with the latest version of the product. See Changes to initialization input data sets for more information.

   Attention: DEFINE SUB for SYSTEM.DEFAULT.SUB is no longer permitted in the CSQINP2 input data set. DEFINE SUB commands can instead be issued from the CSQINPT input data set. The CSQINPT input data set is processed each time the publish/subscribe engine is started, either during queue manager startup, or when the publish/subscribe engine is started with the ALTER QMGR PSMODE(ENABLED) command. See Issuing commands to IBM MQ for z/OS for more information on using the CSQINPT input data set.
2. Stop or disconnect all the applications using the queue manager (for example, CICS, IMS, or batch) and the IBM MQ channels that are connected to other queue managers.
3. Stop the queue manager and its channel initiator.
4. Update the STEPLIB for the queue manager, channel initiator and, if appropriate, AMS, started task procedures to use the Version 9.2 libraries.
5. Update the queue manager startup JCL to add the CSQMINI DD card; see The QMINI data set for further information.
6. If the queue manager is configured to use AMS then, from Version 9.1.3, there is no longer an AMS enablement module, which in earlier versions of IBM MQ allowed the AMS address space to start. Instead, the AMS address space will only start if you have told the queue manager that it is entitled to use AMS by setting the AMSPROD attribute. If AMS is being used, set the AMSPROD attribute; see Associating AMS with a PID for more information.
7. Start the queue manager and its channel initiator.
8. Test that everything is working correctly. If there is a problem starting the queue manager, consider reverting the queue manager to a previous version; see Reverting a queue manager to a previous release.
9. If we have configured the IBM MQ Console or REST API, migrate the mqweb server. If you only have one queue manager on the z/OS system, migrate the mqweb server to Version 9.2.
   1. Stop the mqweb server started task.
   2. Edit the mqweb server started task.
      • Change STEPLIB to reference the Version 9.2 libraries.
      • Change INSTDIR, PATH and LIBPATH to reference the IBM MQ Version 9.2 files in Unix System Services.
      • Review JAVA_HOME, and change it to reference the latest version of Java on the system, if necessary.

      For more information on configuring the mqweb server started task procedure, see Create a procedure for the mqweb server.

   3. Ensure that the mqweb server is associated with the correct product ID. Note: Version 9.2 does this in a different way compared to earlier versions. See Associating the mqweb server with a PID for more information.
   4. Start the mqweb server started task.
   5. Test that the queue manager can be accessed in the IBM MQ Console and REST API.

   If we have more than one queue manager on the z/OS system, running at different versions of IBM MQ, we should already have created a new mqweb server at the latest level . Use the new mqweb server to access queue managers that have been migrated to Version 9.2. We might need to change the HTTP host name or port used by applications that use the REST API.

Results

We have migrated the IBM MQ for z/OS queue manager to the latest release.

What to do next

Follow the instructions in Post migration tasks to complete the migration process.

• Changes to initialization input data sets
  Sometimes the initialization input data sets samples change between versions of IBM MQ.
• 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.

Parent topic: Migrating IBM MQ for z/OS - order of tasks