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.
About this task
Migrating each queue manager comprises the bulk of the work of migrating a queue-sharing group. Approach migrating a queue sharing group as requiring some extra tasks that must be performed during the migration of each queue manager. A good approach is to create a migration plan incorporating queue-sharing group migration; see z/OS: Migration planning to the latest release.
Queue-sharing group migration affects steps 4, 8, 11, and 12 of z/OS: Review and modify queue manager customizations from the previous release
Procedure
-
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.
-
Apply IBM MQ for z/OS migration and toleration 1 PTFs for the latest version of the product to the earlier version
code; see
IBM MQ Support, Migration PTFs.
-
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.
-
Perform the additional hold action tasks of binding new and changed DBRMs into plans
-
Stop and restart each queue manager so that it picks up the new code level.
-
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.
-
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.
- 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.
- Run the customized CSQ4570T and CSQ4571T jobs.
- Customize the CSQ45BPL and CSQ45GEX samples, in thlqual.SCSQPROC
- The header information in CSQ45BPL and CSQ45GEX describes how to customize the samples.
- Run the customized jobs, CSQ45BPL and CSQ45GEX.
- Migrate the tables for one queue-sharing group at a time.
- Customize the CSQ4570T and CSQ4571T samples, in thlqual.SCSQPROC, supplied with the latest version of the IBM MQ for z/OS product.
- Run the customized CSQ4570T and CSQ4571T jobs.
- Customize the CSQ45BPL and CSQ45GEX samples, in thlqual.SCSQPROC
- The header information in CSQ45BPL and CSQ45GEX describes how to customize the samples.
- Run the customized jobs, CSQ45BPL and CSQ45GEX.