Multiple queue manager versions in a queue-sharing group

A queue-sharing group can have V5.2 and V5.3.1 or Version 5.3 queue managers active and accessing shared queues and other shared objects. Both are full participants within the queue-sharing group functions introduced in MQSeries for OS/390 V5.2 such as shared objects, shared security profiles, and routing of commands within the queue-sharing group by the CMDSCOPE parameter on MQSC commands. The V5.3.1 queue managers can also use the new V5.3.1 functions, but with the restrictions described below.

We recommend that you only have a mixed version queue-sharing group for the time it takes to migrate all queue managers to V5.3.1. Whilst the queue-sharing group contains mixed version queue managers, WebSphere MQ for z/OS Version 5.3.1 allows prototyping with new V5.3.1 facilities on a V5.3.1 queue manager, and tolerates operation at the MQSeries for OS/390 V5.2 level.

 

Function restrictions in a mixed queue-sharing group

We cannot alter a CF structure object from CFLEVEL(2) to CFLEVEL(3) until all queue managers in the queue-sharing group have been started at Version 5.3.1 level.

We cannot delete a CF structure object until all queue managers in the queue-sharing group have been started at V5.3.1 level.

V5.2 queue managers cannot connect to the Coupling Facility structure identified by the CFLEVEL(3) CF structure object, which means they can neither access the queues defined on it, nor messages stored on the queue.

Since CFLEVEL(3) CF structures, and queues defined on them, are not available to V5.2 queue managers, there are some restrictions on how some queues are used. These are outlined in Table 77.

Table 77. Restrictions on queues when using mixed queue-sharing groups
Type of queue Restriction
SYSTEM.QSG.TRANSMIT.QUEUE For best results, this queue should be on a structure accessible to all members of the queue-sharing group. However, this means it cannot be used for transporting persistent messages within the queue-sharing group.
SYSTEM.QSG.CHANNEL.SYNCQ This queue must be accessible to all channel initiators in the queue-sharing group. Therefore, if you are running a channel initiator on an MQSeries for OS/390 V5.2 queue manager, the queue must not be defined on a CF structure at CFLEVEL(3).
Shared transmission queues These queues must be accessible to all channel initiators in the queue-sharing group. Therefore, if you are running a channel initiator on an MQSeries for OS/390 V5.2 queue manager, the queue must not be defined on a CF structure at CFLEVEL(3).

In WebSphere MQ for z/OS V5 Release 3.1 the channel initiator does not require that a process definition exists if you want WebSphere MQchannels to start automatically when messages arrive on the transmission queue. However, these process definitions are still required for triggering channels from V5.2 queue managers, so it is recommended that you still define process definitions for triggering channels until the entire queue-sharing group has been migrated to Version 5.3.1.

We can define and alter objects with QSGDISP(GROUP) from a V5.3.1 queue manager. Those objects and their resulting copy objects are accessible on all the queue managers, but on V5.2 queue managers the new Version 5.3.1 attributes and values are not available.

We can define objects with QSGDISP(GROUP) on a V5.2 queue manager and those objects are accessible on all queue managers. However, we cannot use any new attributes. Do not alter the attributes from a V5.2 queue manager, because any new attributes will be lost.

On a V5.2 queue manager, commands using new V5.3.1 keywords and attribute values (but not new commands) can be entered for routing to a V5.3.1 queue manager using CMDSCOPE. Such commands, on whatever version queue manager, routed to a V5.2 queue manager using CMDSCOPE will fail.