Queue-sharing groups

If you have not previously used queue-sharing groups, do not introduce them now. Wait until you have migrated to V6.0. If you are using queue-sharing groups, migrate them to V5.3.1.

This might affect Tasks 8, 9, and 15 in Customizing your queue managers.

The steps outlined below are designed to let you migrate an existing queue-sharing group containing V5.2 queue managers to V5.3.1. The sequence has been designed so that at no stage is an outage of the entire queue-sharing group required. V5.2 and 5.3.1 queue managers can coexist within a queue-sharing group, however, some functions are not supported on the Version 5.2 queue managers and some operations are not available until all queue managers in the queue-sharing group have been migrated to V5.3.1. See Coexistence of WebSphere MQ V5.3.1 and earlier versions for more information about the coexistence of different versions.

 

Applying MQSeries for OS/390 V5.2 migration & coexistence PTFs

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

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

Similarly, once a V5.3.1 queue manager has been started in a queue-sharing group we cannot start a V5.2 queue manager as a member of the group unless it has the 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.2 queue manager so that it is compatible with WebSphere MQ for z/OS V5.3.1. This means that the PTF contains some replacement DBRMs and some new DBRMs. You should bind these DBRMs into new plans with a 221 version number (as detailed in the job supplied in the HOLDDATA of the PTF). For example: 

    BIND PLAN(CSQR221) -     
MEMBER(CSQR220) -      
...

    binds replacement DBRM CSQR220 into a new plan CSQR221.

    This means that you have two sets of plans, those with a 220 version number for queue managers without the PTF, and those with a 221 version number 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, so after applying the migration & coexistence PTF, MQSeries for OS/390 V5.2 expects plans with a 221 version number to exist.

  3. Bind the DBRMs supplied in the PTF into 221 version plans using the job supplied with the PTF, CSQ45B21.

  4. Grant execute authority on new DB2 plans to the same userids as for existing 220 version plans, using the job supplied with the PTF, CSQ45G21.

  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 the DB2 data-sharing group have been started with the migration & coexistence PTF applied.

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

To migrate the tables:

  1. Customize and run the CSQ45ATB sample JCL in thlqual.SCSQPROC supplied with WebSphere MQ for z/OS V5.3.1. 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.

    5. Create a temporary DB2 table and save the channel definitions.

    6. Delete the existing channel table. Create a new, larger channel definition table and reload the saved definitions.

    7. Modify the existing tables, and create the new tables required for WebSphere MQ for z/OS Version 5.3.1.

    8. Rebind the DB2 plans for MQSeries V5.2.

  2. Bind the V5.3.1 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. Rebind the DBRMs supplied with the PTF, by rerunning the job CSQ45B21 supplied with that PTF.

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.