Adding a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager

Modify the configuration of overlapping clusters that use a gateway queue manager. After the modification messages are transferred to an application from the gateway queue manager without using the same transmission queue or channels as other cluster messages. The solution uses an additional cluster transmission queue to separate message traffic to a single queue manager in a cluster.

Before you begin

The gateway queue manager must be on Version 7.5, or later, and on a platform other than z/OS®.
Construct the overlapping clusters shown in Figure 1 in Creating two-overlapping clusters with a gateway queue manager by following the steps in that task.

About this task

On the gateway queue manager, QM1, add a transmission queue and set its queue attribute CLCHNAME. Set CLCHNAME to the name of the cluster-receiver channel on QM3; see Figure 1.

This solution has a number of advantages over the solution described in Adding a remote queue definition to isolate messages sent from a gateway queue manager:

It requires fewer additional definitions.
It supports workload balancing between multiple copies of the target queue, Q1, on different queue managers in the same cluster, CL2.
The gateway queue manager switches automatically to the new configuration when the channel restarts without loosing any messages.
The gateway queue manager continues to forward messages in the same order as it received them. It does so, even if the switch takes place with messages for the queue Q1 at QM3 still on SYSTEM.CLUSTER.TRANSMIT.QUEUE.

The configuration to isolate cluster message traffic in Figure 1 does not result in as great an isolation of traffic as the configuration using remote queues in Adding a remote queue definition to isolate messages sent from a gateway queue manager. If the queue manager QM3 in CL2 is hosting a number of different cluster queues and server applications, all those queues share the cluster channel, CL2.QM3, connecting QM1 to QM3. The additional flows are illustrated in Figure 1 by the gray arrow representing potential cluster message traffic from the SYSTEM.CLUSTER.TRANSMIT.QUEUE to the cluster-sender channel CL2.QM3.

The remedy is to restrict the queue manager to hosting one cluster queue in a particular cluster. If the queue manager is already hosting a number of cluster queues, then to meet this restriction, you must either create another queue manager, or create another cluster; see Adding a cluster and a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager.

The diagram shows two-overlapping clusters connected by a gateway queue manager. A message flows from an application in one cluster to the other cluster, through the transmission queue, XMITQ.CL2.QM3, in the gateway queue manager. The message is routed by an alias queue in the gateway queue manager. The alias queue is clustered in all the clusters. It targets a queue in CL2. Queue manager aliases in the gateway queue manager point to the real queue managers in each cluster. — Figure 1. Client-server application deployed to hub and spoke architecture using an additional cluster transmission queue.

Procedure

Create an additional cluster transmission queue for the cluster-sender channel CL2.QM3 on the gateway queue manager, QM1.
```
*... on QM1
DEFINE QLOCAL(XMITQ.CL2.QM3) USAGE(XMITQ) CLCHNAME(CL2.QM3)
```
Switch to using the transmission queue, XMITQ.CL2.QM3.
1. Stop the cluster-sender channel CL2.QM3.
```
*... On QM1
STOP CHANNEL(CL2.QM3)
```
  The response is that the command is accepted:
  
  AMQ8019: Stop WebSphere MQ channel accepted.
2. Check that the channel CL2.QM3 is stopped
  If the channel does not stop, you can run the STOP CHANNEL command again with the FORCE option. An example of setting the FORCE option would be if the channel does not stop, and you cannot restart the other queue manager to synchronize the channel.
```
*... On QM1
start  
```
  The response is a summary of the channel status
  
  AMQ8417: Display Channel Status details. CHANNEL(CL2.QM3) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1413)) CURRENT RQMNAME(QM3) STATUS(STOPPED) SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
3. Start the channel, CL2.QM3.
```
*... On QM1
START CHANNEL(CL2.QM3)
```
  The response is that the command is accepted:
  
  AMQ8018: Start WebSphere MQ channel accepted.
4. Check the channel started.
```
*... On QM1
DISPLAY CHSTATUS(CL2.QM3)  
```
  The response is a summary of the channel status:
  
  AMQ8417: Display Channel Status details. CHANNEL(CL2.QM3) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1413)) CURRENT RQMNAME(QM3) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(XMITQ.CL2.QM3)
5. Check the transmission queue was switched.
  Monitor the gateway queue manager error log for the message AMQ7341 The transmission queue for channel CL2.QM3 is XMITQ.CL2.QM3.

What to do next

Test the separate transmission queue by sending a message from QM2 to Q1 on QM3 using the queue alias definition Q1A

Run the sample program amqsput on QM2 to put a message.
C:\IBM\MQ>amqsput Q1A QM2 Sample AMQSPUT0 start target queue is Q1A Sample request message from QM2 to Q1 using Q1A Sample AMQSPUT0 end
Run the sample program amqsget to get the message from Q1 on QM3
C:\IBM\MQ>amqsget Q1 QM3 Sample AMQSGET0 start message <Sample request message from QM2 to Q1 using Q1A> no more messages Sample AMQSGET0 end