I recently wrote a post giving a high level introduction to queue sharing groups (QSGs), and their benefits (mainly high availability). One of the most important points is that shared queues, and the messages on them, can be accessed by any queue manager in the QSG.
I got a question on that post about how to set up queues in a QSG, and where are the messages stored, so I thought I would write another blog post to answer that question.
Object definitions are stored in Db2
There are a few things that are required in order to set up a QSG. In particular (and most relevant to this topic), you need:
- A parallel sysplex (with a coupling facility)
- A Db2 data-sharing group
The Db2 data-sharing group is a very similar concept to an MQ QSG. It means that queue managers in the QSG can access the same data in DB2 from any system in the sysplex.
MQ uses Db2 to store various bits of information about the QSG, such as the queue managers that are members of the QSG, and object definitions, such as CF structures and shared queues. When you define a shared queue, the queue definition is stored in Db2, where it can be accessed by any queue manager in the QSG.
Messages on shared queues are stored in the coupling facility
While shared queue definitions are stored in Db2, the messages on those shared queues are stored in the coupling facility (CF). Specifically, they are stored in CF list structures. The CF should be accessible from any system in the sysplex, which means that any queue manager in the QSG will be able to access the shared queue messages in the CF.
Defining shared queues
Before you can define a shared queue, you need a CF structure where the messages will be stored. (You can put up to 512 shared queues on a single CF structure, so you donâ€™t need a new CF structure for every shared queue.)
The CF structure needs to be defined in two places:
- In MQ, as a CFSTRUCT object. For example, issue the following command to define a CFSTRUCT named APPLICATION1:
- In the z/OS CFRM policy. This is where you specify various structure attributes such as the size of the structure and in which CFs the structure can be allocated. The structure is known to z/OS by the CFSTRUCT name, prefixed with the QSG name. For example, if the QSG name is QSG1, the APPLICATION1 structure in the previous example would be defined in the CFRM policy with the name QSG1APPLICATION1.
Now that you’ve created the CF structure, you can define a shared queue on it. Doing this is very similar to defining a private queue, you just need to specify a couple of additional parameters. For example, this command defines a shared queue named SHRDQ1, on the APPLICATION 1 structure:
DEFINE QLOCAL(SHRDQ1) QSGDISP(SHARED) CFSTRUCT(APPLICATION1)
The QSGDISP parameter tells the queue manager that this is a shared queue, and the CFSTRUCT parameter tells the queue manager which CF structure this queue should go in.
When are shared queue messages not stored in the CF?
Thatâ€™s the basic introduction to setting up a shared queue. Of course, itâ€™s not always that simple! Shared queue messages are not always stored in the CF, for one of two reasons:
- The message is over 63KB in size. “Large” messages cannot be stored in the CF, and must be stored elsewhere.
- The CFSTRUCT has been configured to store message data elsewhere, in order to use less space in the CF.
In these cases, the message data is written to a shared message data set (SMDS), and a small amount of data is written to the CF structure that tells the queue manager where to find the message when it is got from the queue.
If youâ€™re not putting messages over 63KB to shared queues, or need to offload data from the CF to save space, then you donâ€™t have to configure SMDS, so I wonâ€™t go into detail about SMDS here. Maybe thatâ€™s a topic for a future blog post!
Thereâ€™s plenty more information about how messages are stored on shared queues (including SMDS) in the MQ Knowledge Center here: https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.pro.doc/q003660_.htm