z/OS: Migrating queue sharing groups from a previous version of the product

You can migrate one or more existing queue-sharing groups containing queue managers in a previous version of a product to the latest version. At no stage is an outage of the entire queue-sharing group required.

1. Ensure that all members of the queue-sharing group have been started at the same version, before migrating any queue managers in the queue-sharing group to the latest version,.

   Do this, by migrating the queue managers at the oldest version in the queue-sharing group to the same version as the other queue managers. For example, if the queue-sharing group currently contains queue managers at Version 7.0.1 and Version 7.1, migrate the Version 7.0.1 queue managers to Version 7.1, before migrating any queue managers in the queue-sharing group to Version 8.0.

2. Apply IBM MQ for z/OS migration and toleration ¹ PTFs for the latest version of the product to the earlier version code; see IBM MQ Support, Migration PTFs.
   1. Apply the PTFs to the libraries of the earlier version of the product.
      If you need to rebind a plan or package, follow the instructions in the PTFs, and rebind the packages using the instructions in CSQ45BPK.

      If you rerun the bind of the plan, or package, while queue managers are active, the bind fails with a locking problem if any queue manager in the DSG using the plan is active.

      You can either shut down the queue managers using the plans, or suspend the queue managers use of Db2. See Suspending a connection to Db2® for further information.

   2. Perform the additional hold action tasks of binding new and changed DBRMs into plans
   3. Stop and restart each queue manager so that it picks up the new code level.
   4. Perform testing of the new code level.
   • These steps can be performed at any time in preparation for a migration to the latest version of IBM MQ for z/OS, or as part of normal maintenance. It is not dependent on the latest version being available.
   • Migrating an earlier version queue manager to a later version queue manager within a queue sharing group is restricted. The restrictions are, that all the earlier version queue managers in the queue-sharing group must have been started at the same earlier version, and that all the earlier version queue managers have had the earlier version backwards migration from the latest version, and coexistence with the latest version PTFs applied.
   • After a queue manager for the latest version has been started in a queue-sharing group, starting an earlier version queue manager is restricted. You cannot start an earlier version queue manager as a member of the group, unless it has migration and toleration PTFs applied.
   • The latest version requires new Db2 tables, and additional changes to existing Db2 tables. The PTF changes some of the Db2 operations performed by the earlier version queue manager. The changes make an earlier version queue manager compatible with the latest version.
   • The PTF contains a new set of Database Request Modules (DBRM). After binding Db2 with these DBRMs, you have two sets of plans: one set for queue managers without the PTFs and the other set for queue managers with the PTFs applied.
3. Migrate your Db2 tables.
   • You must have applied the migration and toleration PTFs to all the queue managers in the queue-sharing group before migrating Db2 tables.
   • If the jobs described fail because of a Db2 locking problem, it might be due to contention for a Db2 resource. Locking is more likely, if the system is being heavily used. Resubmit the job later, preferably when the system is lightly used or quiesced.
   • You can either migrate the Db2 tables one queue-sharing groups at a time, or all queue-sharing groups at the same time. For more information, read the header information in the jobs.
   • Migrate the tables for all the queue-sharing groups at the same time.
     1. Customize the CSQ4570T and CSQ4571T samples, in thlqual.SCSQPROC, supplied with the latest version of the IBM MQ for z/OS product.
        • The header information in CSQ4570T and CSQ4571T describes how to customize the samples.
     2. Run the customized CSQ4570T and CSQ4571T jobs.
     3. Customize the CSQ45BPL and CSQ45GEX samples, in thlqual.SCSQPROC
        • The header information in CSQ45BPL and CSQ45GEX describes how to customize the samples.
     4. Run the customized jobs, CSQ45BPL and CSQ45GEX.
        • The customized jobs are run as part of step 8 of z/OS: Review and modify queue manager customizations from the previous release.
        • This step binds the latest version DBRMs into plans, and grants execute authority to them.
   • Migrate the tables for one queue-sharing group at a time.
     1. Customize the CSQ4570T and CSQ4571T samples, in thlqual.SCSQPROC, supplied with the latest version of the IBM MQ for z/OS product.
        • The header information in CSQ4570T and CSQ4571T describes how to customize the samples.
        • Edit step 8 of z/OS: Review and modify queue manager customizations from the previous release that executes the MIGRATE QSG function, specifying the name of the first queue-sharing group that is to be migrated.
     2. Run the customized CSQ4570T and CSQ4571T jobs.
     3. Customize the CSQ45BPL and CSQ45GEX samples, in thlqual.SCSQPROC
        • The header information in CSQ45BPL and CSQ45GEX describes how to customize the samples.
     4. Run the customized jobs, CSQ45BPL and CSQ45GEX.
        • The customized jobs are run as part of step 8 of z/OS: Review and modify queue manager customizations from the previous release.
        • This step binds the latest version DBRMs into plans, and grants execute authority to them.