Changing the default to separate cluster transmission queues to isolate message traffic

You can change the default way a queue manager stores messages for a clustered queue or topic on a transmission queue. Changing the default provides you with a way to isolate cluster messages on a gateway queue manager.

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

To implement the architecture with multiple clusters queue, your gateway queue manager must be on Version 7.5, or later. All you do to use multiple cluster transmission queues is to change the default cluster transmission queue type on the gateway queue manager. Change the value of the queue manager attribute DEFCLXQ on QM1 from SCTQ to CHANNEL; see Figure 1. The diagram shows one message flow. For flows to other queue managers, or to other clusters, the queue manager creates additional permanent dynamic cluster transmission queues. Each cluster-sender channel transfers messages from a different cluster transmission queue.

The change does not take effect immediately, unless you are connecting the gateway queue manager to clusters for the first time. The task includes steps for the typical case of managing a change to an existing configuration. To set up a queue manager to use separate cluster transmission queues when it first joins a cluster; see Adding a queue manager to a cluster: separate transmission queues.

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, SYSTEM.CLUSTER.TRANSMIT.CL2.QM3, in the gateway queue manager. The message is routed by an alias queue in the gateway queue manager. The alias queue definition is clustered in all the clusters. It targets a queue in one of the clusters. 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 with separate cluster transmission queues on the gateway queue manager.

Procedure

Change the gateway queue manager to use separate cluster transmission queues.
```
*... On QM1
ALTER QMGR DEFCLXQ(CHANNEL)
```
Switch to the separate cluster transmission queues.
Any cluster-sender channel that is not running switches to using separate cluster transmission queues when it next starts.

To switch the running channels, either restart the queue manager, or follow these steps:
1. List the cluster-sender channels that are running with SYSTEM.CLUSTER.TRANSMIT.QUEUE.
```
*... On QM1
DISPLAY CHSTATUS(*) WHERE(XMITQ EQ 'SYSTEM.CLUSTER.TRANSMIT.QUEUE')  
```
  The response is list of channel status reports:
  
  AMQ8417: Display Channel Status details. CHANNEL(CL1.QM2) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1412)) CURRENT RQMNAME(QM2) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) AMQ8417: Display Channel Status details. CHANNEL(CL2.QM3) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1413)) CURRENT RQMNAME(QM3) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) AMQ8417: Display Channel Status details. CHANNEL(CL2.QM5) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1415)) CURRENT RQMNAME(QM5) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) AMQ8417: Display Channel Status details. CHANNEL(CL1.QM4) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1414)) CURRENT RQMNAME(QM4) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
2. Stop the channels that are running
  For each channel in the list, run the command:
```
*... On QM1
STOP CHANNEL(ChannelName)
```
  Where ChannelName is each of CL1.QM2, CL1.QM4, CL1.QM3, CL1.QM5.
  The response is that the command is accepted:
  
  AMQ8019: Stop WebSphere MQ channel accepted.
3. Monitor which channels are stopped
```
*... On QM1
DISPLAY CHSTATUS(*) WHERE(XMITQ EQ 'SYSTEM.CLUSTER.TRANSMIT.QUEUE')  
```
  The response is a list of channels that are still running and channels that are stopped:
  
  AMQ8417: Display Channel Status details. CHANNEL(CL1.QM2) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1412)) CURRENT RQMNAME(QM2) STATUS(STOPPED) SUBSTATE( ) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) AMQ8417: Display Channel Status details. CHANNEL(CL2.QM3) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1413)) CURRENT RQMNAME(QM3) STATUS(STOPPED) SUBSTATE( ) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) AMQ8417: Display Channel Status details. CHANNEL(CL2.QM5) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1415)) CURRENT RQMNAME(QM5) STATUS(STOPPED) SUBSTATE( ) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) AMQ8417: Display Channel Status details. CHANNEL(CL1.QM4) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1414)) CURRENT RQMNAME(QM4) STATUS(STOPPED) SUBSTATE( ) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
4. Start each stopped channel.
  Do this step for all the channels that were running. If a 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 CHANNEL(CL2.QM5)
```
  The response is that the command is accepted:
  
  AMQ8018: Start WebSphere MQ channel accepted.
5. Monitor the transmission queues being switched.
  Monitor the gateway queue manager error log for the message AMQ7341 The transmission queue for channel CL2.QM3 is SYSTEM.CLUSTER.TRANSMIT.QUEUE|CL2.QM3.
6. Check that SYSTEM.CLUSTER.TRANSMIT.QUEUE is no longer used
```
*... On QM1
DISPLAY CHSTATUS(*) WHERE(XMITQ EQ 'SYSTEM.CLUSTER.TRANSMIT.QUEUE') 
DISPLAY QUEUE(SYSTEM.CLUSTER.TRANSMIT.QUEUE) CURDEPTH
```
  The response is list of channel status reports, and the depth of SYSTEM.CLUSTER.TRANSMIT.QUEUE:
  
  AMQ8420: Channel Status not found. AMQ8409: Display Queue details. QUEUE(SYSTEM.CLUSTER.TRANSMIT.QUEUE) TYPE(QLOCAL) CURDEPTH(0)
7. Monitor which channels are started
```
*... On QM1
DISPLAY CHSTATUS(*) WHERE(XMITQ LK 'SYSTEM.CLUSTER.TRANSMIT.*') 
```
  The response is a list of the channels, in this case already running with the new default cluster transmission queues:
  
  AMQ8417: Display Channel Status details. CHANNEL(CL1.QM2) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1412)) CURRENT RQMNAME(QM2) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.CL1.QM2) AMQ8417: Display Channel Status details. CHANNEL(CL2.QM3) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1413)) CURRENT RQMNAME(QM3) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.CL2.QM3) AMQ8417: Display Channel Status details. CHANNEL(CL2.QM5) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1415)) CURRENT RQMNAME(QM5) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.CL2.QM5) AMQ8417: Display Channel Status details. CHANNEL(CL1.QM4) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1414)) CURRENT RQMNAME(QM4) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.CL1.QM4)

What to do next

Test the automatically defined cluster transmission queue by sending a message from QM2 to Q1 on QM3, resolving queue name with the queue alias definition Q1A
1. 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
2. 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
Consider whether to reconfigure security, by configuring security for the cluster queues on the queue managers where messages for the cluster queues originate.