This example shows the WebSphere MQ commands (MQSC) that you can use in WebSphere MQ for z/OS for distributed queuing with queue-sharing groups. This example expands the payroll query scenario of the example in Chapter 27, Message channel planning example for z/OS to show how to add higher availability of query processing by adding more serving applications to serve a shared queue.
The payroll query application is now connected to queue manager QM3 and puts a query to the remote queue 'PAYROLL QUERY' defined on QM3. This remote queue definition resolves to the shared queue 'PAYROLL' hosted by the queue managers in the queue-sharing group QSG1. The payroll processing application now has two instances running, one connected to QM4 and one connected to QM5.
Figure 90. Message channel planning example for WebSphere MQ for z/OS using queue-sharing groups
All three queue managers are assumed to be running on z/OS. In the example definitions for TCP/IP, QM4 has a host name of MVSIP01 and QM5 has a host name of MVSIP02. Both queue managers are listening on port 1414 and have registered to use WLM/DNS. The generic address that WLM/DNS provides for this group is QSG1.MVSIP. QM3 has a host address of 9.20.9.31 and is listening on port 1411.
In the example definitions for LU6.2, QM3 is listening on a symbolic luname called LUNAME1. The name of the generic resource defined for VTAM for the lunames listened on by QM4 and QM5 is LUQSG1. The example assumes that these are already defined on your z/OS system and are available for use. To define them see Defining yourself to the network using generic resources .
In this example QSG1 is the name of a queue-sharing group, and queue managers QM4 and QM5 are the names of members of the group.
Producing the following object definitions for one member of the queue-sharing group makes them available to all the other members.
Queue managers QM4 and QM5 are members of the queue sharing group. The definitions produced for QM4 are also available for QM5.
It is assumed that the coupling facility list structure is called 'APPLICATION1'. If is not called 'APPLICATION1', you must use your own coupling facility list structure name for the example.
The shared object definitions are stored in DB2 and their associated messages are stored within the Coupling Facility.
DEFINE QLOCAL(PAYROLL) QSGDISP(SHARED) REPLACE PUT(ENABLED) GET(ENABLED) +
CFSTRUCT(APPLICATION1) +
DESCR('Shared queue for payroll details')
DEFINE QLOCAL(QM3) QSGDISP(SHARED) REPLACE USAGE(XMITQ) PUT(ENABLED) +
CFSTRUCT(APPLICATION1) +
DESCR('Transmission queue to QM3') TRIGGER TRIGTYPE(FIRST) +
TRIGDATA(QSG1.TO.QM3) GET(ENABLED) INITQ(SYSTEM.CHANNEL.INITQ)
The group object definitions are stored in DB2, and each queue manager in the queue-sharing group creates a local copy of the defined object.
For a TCP/IP connection:
DEFINE CHANNEL(QSG1.TO.QM3) CHLTYPE(SDR) QSGDISP(GROUP) TRPTYPE(TCP) +
REPLACE DESCR('Sender channel to QM3') XMITQ(QM3) +
CONNAME('9.20.9.31(1411)')
For an LU6.2 connection:
DEFINE CHANNEL(QSG1.TO.QM3) CHLTYPE(SDR) QSGDISP(GROUP) TRPTYPE(LU62) +
REPLACE DESCR('Sender channel to QM3') XMITQ(QM3) +
CONNAME('LUNAME1')
For a TCP/IP connection:
DEFINE CHANNEL(QM3.TO.QSG1) CHLTYPE(RCVR) TRPTYPE(TCP) +
REPLACE DESCR('Receiver channel from QM3') QSGDISP(GROUP)
For an LU 6.2 connection:
DEFINE CHANNEL(QM3.TO.QSG1) CHLTYPE(RCVR) TRPTYPE(LU62) +
REPLACE DESCR('Receiver channel from QM3') QSGDISP(GROUP)
QM3 is not a member of the queue-sharing group.
The following object definitions allow it to put messages to a queue in the queue-sharing group.
The conname for this channel is the generic address of the queue-sharing group.
For a TCP/IP connection:
DEFINE CHANNEL(QM3.TO.QSG1) CHLTYPE(SDR) TRPTYPE(TCP) +
REPLACE DESCR('Sender channel to QSG1') XMITQ(QSG1) +
CONNAME('QSG1.MVSIP(1414)')
For an LU 6.2 connection:
DEFINE CHANNEL(QM3.TO.QSG1) CHLTYPE(SDR) TRPTYPE(LU62) +
REPLACE DESCR('Sender channel to QSG1') XMITQ(QSG1) +
CONNAME('LUQSG1) TPNAME('MQSERIES') MODENAME('#INTER')
These definitions are required for the same purposes as those in the first example.
DEFINE QREMOTE(PAYROLL.QUERY) DESCR('Remote queue for QSG1') REPLACE +
PUT(ENABLED) XMITQ(QSG1) RNAME(APPL) RQMNAME(QSG1)
DEFINE QLOCAL(QSG1) DESCR('Transmission queue to QSG1') REPLACE +
USAGE(XMITQ) PUT(ENABLED) GET(ENABLED) TRIGGER TRIGTYPE(FIRST) +
TRIGDATA(QM3.TO.QSG1) INITQ(SYSTEM.CHANNEL.INITQ)
DEFINE CHANNEL(QSG1.TO.QM3) CHLTYPE(RCVR) TRPTYPE(TCP) +
REPLACE DESCR('Receiver channel from QSG1')
DEFINE CHANNEL(QSG1.TO.QM3) CHLTYPE(RCVR) TRPTYPE(LU62) +
REPLACE DESCR('Receiver channel from QSG1')
DEFINE QLOCAL(PAYROLL.REPLY) REPLACE PUT(ENABLED) GET(ENABLED) +
DESCR('Reply queue for replies to query messages sent to QSG1')
When you have created the required objects, you must do the following.
For a TCP/IP connection each member of the group must have a group listener started that is listening on port 1414.
STA LSTR PORT(1414) IPADDR(MVSIP01) INDISP(GROUP)
The above entry starts the listener on QM4, for example.
For an LU6.2 connection each member of the group must have a group listener started that is listening on a symbolic luname that corresponds to the generic resource LUQSG1.
STA LSTR PORT(1411)