[z/OS]

Adding a queue sharing group to existing clusters

Add a queue sharing group on z/OS® to existing clusters.

Before you begin

Note:
  1. For changes to a cluster to be propagated throughout the cluster, at least one full repository must always be available. Ensure that your repositories are available before starting this task.
  2. Queue sharing groups are supported only on IBM® MQ for z/OS. This task is not applicable to other platforms.
Scenario:
  • The INVENTORY cluster has been set up as described in Setting up a new cluster. It contains two queue managers, LONDON and NEWYORK.
  • You want to add a queue sharing group to this cluster. The group, QSGP, comprises three queue managers, P1, P2, and P3. They share an instance of the INVENTQ queue, which is to be defined by P1.

About this task

Follow these steps to add new queue managers that host a shared queue.

Procedure

  1. Decide which full repository the queue managers refer to first.

    Every queue manager in a cluster must refer to one or other of the full repositories. It gathers information about the cluster from a full repository and so builds up its own partial repository. It is of no particular significance which full repository you choose. In this example, choose NEWYORK. Once the queue sharing group has joined the cluster, it communicates with both of the full repositories.

  2. Define the CLUSRCVR channels.
    Every queue manager in a cluster needs to define a cluster-receiver channel on which it can receive messages. On P1, P2, and P3, define:
    
    DEFINE CHANNEL(INVENTORY.Pn) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
    CONNAME(Pn.CHSTORE.COM) CLUSTER(INVENTORY)
    DESCR('Cluster-receiver channel for sharing queue manager')
    

    The cluster-receiver channel advertises the availability of each queue manager to receive messages from other queue managers in the cluster INVENTORY.

  3. Define a CLUSSDR channel for the queue sharing group.
    Every member of a cluster needs to define one cluster-sender channel on which it can send messages to its first full repository. In this case we have chosen NEWYORK. One of the queue managers in the queue sharing group needs the following group definition. The definition ensures that every queue manager has a cluster-sender channel definition.
    
    DEFINE CHANNEL(INVENTORY.NEWYORK) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
    CONNAME(NEWYORK.CHSTORE.COM) CLUSTER(INVENTORY) QSGDISP(GROUP)
    DESCR('Cluster-sender channel to repository at NEWYORK')
    
  4. Define the shared queue.
    Define the queue INVENTQ on P1 as follows:
    
    DEFINE QLOCAL(INVENTQ) CLUSTER(INVENTORY) QSGDISP(SHARED) CFSTRUCT(STRUCTURE)
    

    Start the channel initiator and a listener program on the new queue manager. The listener program listens for incoming network requests and starts the cluster-receiver channel when it is needed.

Results

Figure 1 shows the cluster set up by this task.
Figure 1. Cluster and queue sharing group
Cluster and queue sharing group are described in the surrounding text.

Now messages put on the INVENTQ queue by LONDON are routed alternately around the four queue managers advertised as hosting the queue.

What to do next

A benefit of having members of a queue sharing group host a cluster queue is any member of the group can reply to a request. In this case perhaps P1 becomes unavailable after receiving a message on the shared queue. Another member of the queue sharing group can reply instead.