Migrating queue-sharing groups to V6

This might affect Tasks 9, 10 and 16 in Customizing your queue managers.

The steps outlined below are designed to let you migrate one or more existing queue-sharing groups containing V5.3 or 5.3.1 queue managers to V6. The sequence has been designed so that at no stage is an outage of the entire queue-sharing group required. V5.3 or 5.3.1 and V6 queue managers can coexist within a queue-sharing group, however, some functions are not supported on the V5.3 or 5.3.1 queue managers and some operations are not available until all queue managers in the queue-sharing group have been migrated to V6. See Multiple queue manager versions in a queue-sharing group.

Once all queue managers in the queue-sharing group have been migrated to V6 you can take full advantage of new V6 function.

 

Applying MQSeries for OS/390 V5.3 or 5.3.1 migration & coexistence PTFs

Note:
This step can be performed at any suitable time in preparation for a migration to WebSphere MQ for z/OS V6 or as part of normal maintenance. It is not dependant on V6 being available.

We cannot add a V6 queue manager to a queue-sharing group, or start an existing queue manager in a queue-sharing group at V6 level, until all the queue managers in a queue-sharing group within the DB2 data-sharing group have had a migration & coexistence PTF applied. This is because V6 requires new DB2 tables and additional changes to existing DB2 tables.

Similarly, once a V6 queue manager has been started in a queue-sharing group we cannot start a V5.3 or 5.3.1 queue manager as a member of the group unless it has a migration & coexistence PTF applied.

You need to take the following steps:

  1. Apply the PTF.

  2. The PTF changes some of the DB2 operations performed by the V5.3 or 5.3.1 queue manager so that it is compatible with WebSphere MQ for z/OS V6. This means that the PTF contains some replacement DBRMs. You should bind these DBRMs into new plans with a 530 or 531 version number (as detailed in the job supplied in the HOLDDATA of the PTF). The new plan names are as listed in the sample program CSQ45BPL, which is supplied with the PTF.

    This means that you have two sets of plans, for queue managers without the PTF and for queue managers with the PTF applied. Module CSQ5PLAN (and its aliases) also changes the DB2 plans to be used by WebSphere MQ in the PTF names.

  3. Bind the DBRMs supplied in the PTF into new version plans using the job supplied with the PTF.

  4. Grant execute authority on new DB2 plans to the same userids as for existing V5.3 or 5.3.1 plans, using the job supplied with the PTF.

  5. By turn, stop each queue manager and restart it so that it picks up the new code level.

  6. Perform testing of the new code level.

 

Migrating DB2 tables

Note:
This step cannot be performed until all queue managers defined in a queue-sharing group within the DB2 data-sharing group have been started with the migration & coexistence PTF applied.

If you have queue managers defined in the queue-sharing group that cannot be started with the PTF, they can be removed from the queue-sharing group using the CSQ5PQSG utility.

To migrate the tables and all queue-sharing groups

  1. Customize and run the CSQ45ATB sample JCL in thlqual.SCSQPROC supplied with WebSphere MQ for z/OS V6. This performs the following steps:

    1. Prepare the DB2 tables for the bind in the next step.

    2. Bind the new DB2 plan for the CSQ5PQSG utility.

    3. Grant execute authority to the DB2 plan.

    4. Check that the data-sharing group is in a state suitable for migration, using the MIGRATE DSG function.

    5. Modify the existing tables, and create the new tables required for WebSphere MQ for z/OS V6.

    6. Rebind the DB2 plans for WebSphere MQ V5.3 or 5.3.1.

  2. Bind the V6 DBRMs into plans and grant execute authority to them using the supplied jobs CSQ45BPL and CSQ45GEX, as described in Task 9: Set up the DB2 environment.

To migrate one queue-sharing group at a time

  1. Customize the CSQ45ATB sample JCL in thlqual.SCSQPROC supplied with WebSphere MQ for z/OS V6, editing the step that executes the MIGRATE QSG function and specifying the name of the first queue-sharing group that is to be migrated. Run the job. This performs the following steps:

    1. Prepare the DB2 tables for the bind in the next step.

    2. Bind the new DB2 plan for the CSQ5PQSG utility.

    3. Grant execute authority to the DB2 plan.

    4. Check that the queue-sharing group is in a state suitable for migration, using the MIGRATE QSG function.

    5. Modify the existing tables, and create the new tables required for WebSphere MQ for z/OS V6.

    6. Rebind the DB2 plans for WebSphere MQ V5.3 or 5.3.1.

  2. Bind the V6 DBRMs into plans and grant execute authority to them using the supplied jobs CSQ45BPL and CSQ45GEX, as described in Task 9: Set up the DB2 environment.

  3. To migrate subsequent queue-sharing groups, use the MIGRATE QSG function of CSQ5PQSG for each queue-sharing group to be migrated. It is not necessary to run CSQ45ATB for any queue-sharing group other than the first to be migrated.

If these jobs fail because of a DB2 locking problem, it is probably due to contention for a DB2 resource, especially if the system is being heavily used. Resubmit the job later, preferably when the system is lightly used or quiesced.