Plan your queue sharing group (QSG)
The easiest way to implement a shared queuing environment, is to configure a queue manager, add that queue manager to a QSG, then add other queue managers to the QSG.
A queue sharing group uses Db2 tables to store configuration information. There is one set of tables used by all QSGs that share the same Db2 data sharing group.
Shared queue messages are stored in a structure in a coupling facility (CF). Each QSG has its own set of CF structures. We need to configure the structures to meet your needs.
Messages can also be stored in Shared Message Data Sets (SMDS). Message over 63KB in size cannot be stored in the CF. We need to use SMDS to store these messages on shared queues.
Message profiles and capacity planning
We should understand the message profile of our shared queue messages. The following are examples of factors that we need to consider:
- Average, and maximum message size
- The typical queue depth, and exception queue depth. For example, you might need to have enough capacity to hold messages for a whole day, and the typical queue depth is under 100 messages.
If the message profile changes, we can increase the size of the structures, or implement SMDS, at a later date.
To be able to handle a large peak volume of messages, we can configure IBM MQ to offload messages to SMDS when the usage of the structure reaches user specified thresholds.
We need to decide if we want to duplex the CF structures. This is controlled by the CF structure definition in the CFRM policy:
- A duplexed structure uses two coupling facilities. If there is a problem with one CF, there is no interruption to the service, and the structure can be rebuilt on a third CF, if one is available. Duplexed structures can significantly impact the performance of operations on shared queues.
- If the structure is not duplexed, then a problem with the CF means that shared queues on structures in that CF will become unavailable until the structure can be rebuilt in another CF.
IBM MQ can be configured to automatically rebuild structures in another CF in this case. Persistent messages will be recovered from the logs of the queue managers.
Note that it is easy to change the CF definitions.
We can define a structure so that it can hold nonpersistent messages only, or so that it can hold persistent and nonpersistent messages.
Structures that can hold persistent messages need to be backed up periodically. Back up your CF structures at least every hour to minimize the time needed to recover the structure in the event of a failure. The backup is stored in the log data set of the queue manager performing the backup.
If we are expecting to have a high throughput of messages on your shared queues, it is best practice to have a dedicated queue manager for backing up the CF structures. This reduces the time needed to recover the structures, as a less data needs to be read from queue manager logs.
Channels
To provide a single system image for applications connecting into an IBM MQ QSG, we can define shared input channels. If these are set up, then a connection coming into the queue sharing group environment, can go to any queue manager in the QSG.
We might need to set up a network router, or Virtual IP address (VIPA) for these channels.
We can define shared output channels. A shared output channel instance can be started from any queue manager in the QSG.
See Shared channels for more information.
Security
You protect IBM MQ resources using an external security manager. If we are using RACF, the RACF profiles are prefixed with the queue manager name. For example, a queue named APPLICATION.INPUT would be protected using a profile in the MQQUEUE class named qmgrName.APPLICATION.INPUT.
When using a queue sharing group we can continue to protect resources with profiles prefixed with the queue manager name, or we can prefix profiles with the queue sharing group name. For example qsgName.APPLICATION.INPUT.
We should aim to use profiles prefix with the queue sharing group name because this means there is a single definition for all queue managers, saving you work, and preventing a mismatch in definitions between queue managers.
- Plan your coupling facility and offload storage environment
Use this topic when planning the initial sizes, and formats of our coupling facility (CF) structures, and shared message data set (SMDS) environment or Db2 environment.Parent topic: Plan the IBM MQ environment on z/OS
Related concepts