Adding a cluster and 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 to isolate the messages to a particular cluster queue.

Before starting

The steps in the task are written to modify the configuration illustrated in Figure 1.

The gateway queue manager must be on Version 7.5, or later.
Construct the overlapping clusters shown in Client-server application deployed to hub and spoke architecture using IBM MQ clusters in Create two-overlapping clusters with a gateway queue manager by following the steps in that task.
Do the steps in Figure 1 in Adding a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager to create the solution without the additional cluster. Use this as a base for the steps in this task.

About this task

The solution to isolating message traffic to a single application in Adding a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager works if the target cluster queue is the only cluster queue on a queue manager. If it is not, you have two choices. Either move the queue to a different queue manager, or create a cluster that isolates the queue from other cluster queues on the queue manager.

This task takes you through the steps to add a cluster to isolate the target queue. The cluster is added just for that purpose. In practice, approach the task of isolating certain applications systematically when we are in the process of designing clusters and cluster naming schemes. Adding a cluster each time a queue requires isolation might end up with many clusters to manage. In this task, we change the configuration in Adding a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager by adding a cluster CL3 to isolate Q1 on QM3. Applications continue to run throughout the change.

The new and changed definitions are highlighted in Figure 1. The summary of the changes is as follows: Create a cluster, which means we must also create a new full cluster repository. In the example, QM3 is made one of the full repositories for CL3. Create cluster-sender and cluster-receiver channels for QM1 to add the gateway queue manager to the new cluster. Change the definition of Q1 to switch it to CL3. Modify the cluster namelist on the gateway queue manager, and add a cluster transmission queue to use the new cluster channel. Finally, switch the queue alias Q1A to the new cluster namelist.

IBM MQ cannot transfer messages from the transmission queue XMITQ.CL2.QM3 that you added in Adding a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager to the new transmission queue XMITQ.CL3.QM3, automatically. It can transfer messages automatically only if both transmission queues are served by the same cluster-sender channel. Instead, the task describes one way to perform the switch manually, which might be appropriate to you. When the transfer is completed, you have the option of reverting to using the default cluster transmission queue for other CL2 cluster queues on QM3. Or we can continue to use XMITQ.CL2.QM3. If you decide to revert to a default cluster transmission queue, the gateway queue manager manages the switch for you automatically.

Figure 1. Using an additional cluster to separate message traffic in the gateway queue manager that goes to one of a number of cluster queues on the same queue manager

Procedure

Alter the queue managers QM3 and QM5 to make them repositories for both CL2 and CL3.
To make a queue manager a member of multiple clusters, it must use a cluster name list to identify the clusters it is a member of.
```
*... On QM3 and QM5
DEFINE NAMELIST(CL23) NAMES(CL2, CL3) REPLACE
ALTER QMGR REPOS(' ') REPOSNL(CL23)
```

Define the channels between the queue managers QM3 and QM5 for CL3.

*... On QM3
DEFINE CHANNEL(CL3.QM5) CHLTYPE(CLUSSDR) CONNAME('localhost(1415)') CLUSTER(CL3) REPLACE
DEFINE CHANNEL(CL3.QM3) CHLTYPE(CLUSRCVR) CONNAME('localhost(1413)') CLUSTER(CL3) REPLACE

*... On QM5
DEFINE CHANNEL(CL3.QM3) CHLTYPE(CLUSSDR) CONNAME('localhost(1413)') CLUSTER(CL3) REPLACE
DEFINE CHANNEL(CL3.QM5) CHLTYPE(CLUSRCVR) CONNAME('localhost(1415)') CLUSTER(CL3) REPLACE

Add the gateway queue manager to CL3.
Add the gateway queue manager by adding QM1 to CL3 as a partial repository. Create a partial repository by adding cluster-sender and cluster-receiver channels to QM1.

Also, add CL3 to the name list of all clusters connected to the gateway queue manager.
```
*... On QM1
DEFINE CHANNEL(CL3.QM3) CHLTYPE(CLUSSDR) CONNAME('localhost(1413)') CLUSTER(CL3) REPLACE
DEFINE CHANNEL(CL3.QM1) CHLTYPE(CLUSRCVR) CONNAME('localhost(1411)') CLUSTER(CL3) REPLACE
ALTER NAMELIST(ALL) NAMES(CL1, CL2, CL3)
```
Add a cluster transmission queue to the gateway queue manager, QM1, for messages going to CL3 on QM3.
Initially, stop the cluster-sender channel transferring messages from the transmission queue until we are ready to switch transmission queues.
```
*... On QM1
DEFINE QLOCAL(XMITQ.CL3.QM3) USAGE(XMITQ) CLCHNAME(CL3.QM3) GET(DISABLED) REPLACE
```
Drain messages from the existing cluster transmission queue XMITQ.CL2.QM3.
This subprocedure is intended to preserve the order of messages in Q1 to match the order they arrived at the gateway queue manager. With clusters, message ordering is not fully guaranteed, but is likely. If guaranteed message ordering is required, applications must define the order of messages; see The order in which messages are retrieved from a queue.
1. Change the target queue Q1 on QM3 from CL2 to CL3.
```
*... On QM3
ALTER QLOCAL(Q1) CLUSTER(CL3)
```
2. Monitor XMITQ.CL3.QM3 until messages start to be delivered to it.
  Messages start to be delivered to XMITQ.CL3.QM3 when the switch of Q1 to CL3 is propagated to the gateway queue manager.
```
*... On QM1
DISPLAY QUEUE(XMITQ.CL3.QM3) CURDEPTH
```
3. Monitor XMITQ.CL2.QM3 until it has no messages waiting to be delivered to Q1 on QM3. Note: XMITQ.CL2.QM3 might be storing messages for other queues on QM3 that are members of CL2, in which case the depth might not go to zero.
```
*... On QM1
DISPLAY QUEUE(XMITQ.CL2.QM3) CURDEPTH
```
4. Enable get from the new cluster transmission queue, XMITQ.CL3.QM3
```
*... On QM1
ALTER QLOCAL(XMITQ.CL3.QM3) GET(ENABLED)
```
Remove the old cluster transmission queue, XMITQ.CL2.QM3, if it is no longer required.
Messages for cluster queues in CL2 on QM3 revert to using the default cluster transmission queue on the gateway queue manager, QM1. The default cluster transmission queue is either SYSTEM.CLUSTER.TRANSMIT.QUEUE, or SYSTEM.CLUSTER.TRANSMIT.CL2.QM3. Which one depends on whether the value of the queue manager attribute DEFCLXQ on QM1 is SCTQ or CHANNEL. The queue manager transfers messages from XMITQ.CL2.QM3 automatically when the cluster-sender channel CL2.QM3 next starts.
1. Change the transmission queue, XMITQ.CL2.QM3, from being a cluster transmission queue to being a normal transmission queue.
  This breaks the association of the transmission queue with any cluster-sender channels. In response, IBM MQ automatically transfers messages from XMITQ.CL2.QM3 to the default cluster transmission queue when the cluster-sender channel is next started. Until then, messages for CL2 on QM3 continue to be placed on XMITQ.CL2.QM3.
```
*... On QM1
ALTER QLOCAL(XMITQ.CL2.QM3) CLCHNAME(' ')
```
2. Stop the cluster-sender channel CL2.QM3.
  Stopping and restarting the cluster-sender channel initiates the transfer of messages from XMITQ.CL2.QM3 to the default cluster transmission queue. Typically you would stop and start the channel manually to start the transfer. The transfer starts automatically if the channel restarts after shutting down on the expiry of its disconnect interval.
```
*... On QM1
STOP CHANNEL(CL2.QM3)
```
  The response is that the command is accepted:
  
  AMQ8019: Stop IBM MQ channel accepted.
3. Check that the channel CL2.QM3 is stopped
  If the channel does not stop, we 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 we cannot restart the other queue manager to synchronize the channel.
```
*... 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(STOPPED) SUBSTATE(MQGET) XMITQ(XMITQ.CL2.QM3)
4. Start the channel, CL2.QM3.
```
*... On QM1
START CHANNEL(CL2.QM3)
```
  The response is that the command is accepted:
  
  AMQ8018: Start IBM MQ channel accepted.
5. 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(SYSTEM.CLUSTER.TRANSMIT. QUEUE|CL2.QM3)
```
6. 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 .
7. Delete the cluster transmission queue, XMITQ.CL2.QM3.
```
*... On QM1
DELETE QLOCAL(XMITQ.CL2.QM3)
```

What to do next

Test the separately clustered 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

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

Before starting

About this task

Procedure

What to do next

Related concepts

Related tasks

Related information