Multiple queue manager versions in a queue-sharing group

A queue-sharing group can have Version 5.2 and Version 5.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(R) for OS/390(R) Version 5.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 Version 5.3.1 queue managers can also use the new Version 5.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 Version 5.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 Version 5.3.1 facilities on a Version 5.3.1 queue manager, and tolerates operation at the MQSeries for OS/390 Version 5.2 level.

Function restrictions in a mixed queue-sharing group

You 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.

You cannot delete a CF structure object until all queue managers in the queue-sharing group have been started at Version 5.3.1 level.

Version 5.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 Version 5.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 Version 5.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 Version 5.2 queue manager, the queue must not be defined on a CF structure at CFLEVEL(3).

In WebSphere MQ for z/OS Version 5 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 Version 5.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.

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

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

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