Clustering: Example configuration of multiple cluster transmission queues

In this task you apply the steps to plan multiple cluster transmission queues to three overlapping clusters. The requirements are to separate messages flows to one cluster queue, from all other message flows, and to store messages for different clusters on different cluster transmission queues.

About this task

The steps in this task show how to apply the procedure in Clustering: Planning how to configure cluster transmission queues and arrive at the configuration shown in Figure 1. It is an example of three overlapping clusters, with a gateway queue manager, that is configured with separate cluster transmission queues. The MQSC commands to define the clusters are described in Creating the example clusters.

For the example, there are two requirements. One is to separate the message flow from the gateway queue manager to the sales application that logs sales. The second is to query how many messages are waiting to be sent to different departmental areas at any point in time. The SALES, FINANCE, and DEVELOP clusters are already defined. Cluster messages are currently forwarded from SYSTEM.CLUSTER.TRANSMIT.QUEUE.

The diagram shown three clusters, one for each department, overlapping with a gateway queue manager. It shows how messages are stored on different cluster transmission queues before being forwarded by the gateway queue manager to queue managers in the different clusters. — Figure 1. Example of specific transmission queues for different departmental IBM® MQ clusters

The steps to modify the clusters are as follows. For the definitions, see Changes to isolate the sales queue in a new cluster and separate the gateway cluster transmission queues.

Procedure

The first configuration step is to Select the type of default cluster transmission queue to use .
The decision is to create separate default cluster transmission queues by running the following MQSC command on the GATE queue manager.
```
ALTER QMGR DEFCLXQ(CHANNEL)
```
There is no strong reason for choosing this default, as the intention is to manually define cluster transmission queues. The choice does have a weak diagnostic value. If a manual definition is done wrongly, and a message flows down a default cluster transmission queue, it shows up in the creation of a permanent-dynamic cluster transmission queue.
The second configuration step is to Isolate any message flows that must not share a cluster transmission queue with other flows .
In this case the sales application that receives messages from the queue SALES on SALESRV requires isolation. Only isolation of messages from the gateway queue manager is required. The three sub-steps are:
1. Configure the destinations of the flows so that each target queue is the only queue in a specific cluster, on that queue manager .
  The example requires adding the queue manager SALESRV to a new cluster within the sales department. If you have few queues that require isolation, you might decide on creating a specific cluster for the SALES queue. A possible naming convention for the cluster name is to name such clusters, Q. QueueName, for example Q.SALES. An alternative approach, which might be more practical if you have a large number of queues to be isolated, is to create clusters of isolated queues where and when needed. The clusters names might be QUEUES. n.
  
  In the example, the new cluster is called Q.SALES. To add the new cluster, see the definitions in Changes to isolate the sales queue in a new cluster and separate the gateway cluster transmission queues. The summary of definition changes is as follows:
  1. Add Q.SALES to the namelist of clusters on the repository queue managers. The namelist is referred to in the queue manager REPOSNL parameter.
  2. Add Q.SALES to the namelist of clusters on the gateway queue manager. The namelist is referred to in all the cluster queue alias and cluster queue manager alias definitions on the gateway queue manager.
  3. Create a namelist on the queue manager SALESRV, for both the clusters it is a member of, and change the cluster membership of the SALES queue:
```
DEFINE NAMELIST(CLUSTERS) NAMES(SALES, Q.SALES) REPLACE
ALTER QLOCAL(SALES) CLUSTER(' ') CLUSNL(SALESRV.CLUSTERS)
```
    The SALES queue is a member of both clusters, just for the transition. Once the new configuration is running, you remove the SALES queue from the SALES cluster; see Figure 2.
2. Create the cluster-sender and cluster-receiver channels for any new clusters you have created following a systematic naming convention .
  1. Add the cluster-receiver channel Q.SALES. RepositoryQMgr to each of the repository queue managers
  2. Add the cluster-sender channel Q.SALES. OtherRepositoryQMgr to each of the repository queue managers, to connect to the other repository manager. Start these channels.
  3. Add the cluster receiver channels Q.SALES.SALESRV, and Q.SALES.GATE to either of the repository queue managers that is running.
  4. Add the cluster-sender channels Q.SALES.SALESRV, and Q.SALES.GATE to the SALESRV and GATE queue managers. Connect the cluster-sender channel to the repository queue manager that you created the cluster-receiver channels on.
3. Define a cluster transmission queue for each isolated destination on every queue manager that sends messages to the target queue .
  On the gateway queue manager define the cluster transmission queue XMITQ.Q.SALES.SALESRV for the Q.SALES.SALESRV cluster-sender channel:
```
DEFINE QLOCAL(XMITQ.Q.SALES.SALESRV) USAGE(XMITQ) CLCHNAME(Q.SALES.SALESRV) REPLACE
```

The third configuration step is to Create cluster transmission queues to meet governance or monitoring requirements .

On the gateway queue manager define the cluster transmission queues:


DEFINE QLOCAL(XMITQ.SALES)  USAGE(XMITQ) CLCHNAME(SALES.*)  REPLACE
DEFINE QLOCAL(XMITQ.DEVELOP) USAGE(XMITQ) CLCHNAME(DEVELOP.*) REPLACE
DEFINE QLOCAL(XMITQ.FINANCE) USAGE(XMITQ) CLCHNAME(SALES.*)  REPLACE

What to do next

Switch to the new configuration on the gateway queue manager.

The switch is triggered by starting the new channels, and restarting the channels that are now associated with different transmission queues. Alternatively, you can stop and start the gateway queue manager.

Stop the following channels on the gateway queue manager:
```
SALES. Qmgr
DEVELOP. Qmgr
FINANCE. Qmgr
```

Start the following channels on the gateway queue manager:


SALES. Qmgr
DEVELOP. Qmgr
FINANCE. Qmgr
Q.SALES.SAVESRV

When the switch is complete, remove the SALES queue from the SALES cluster; see Figure 2.

Creating the example clusters

The definitions and instructions to create the example cluster, and modify it to isolate the SALES queue and separate messages on the gateway queue manager.

About this task

The full MQSC commands to create the FINANCE, SALES, and Q.SALES clusters are provided in Definitions for the basic clusters, Changes to isolate the sales queue in a new cluster and separate the gateway cluster transmission queues, and Remove the sales queue on queue manager SALESRV from the sales cluster. The DEVELOP cluster is omitted from the definitions, to keep the definitions shorter.

Procedure

Create the SALES and FINANCE clusters, and the gateway queue manager.

Create the queue managers.

Run the command: crtmqm -sax -u SYSTEM.DEAD.LETTER.QUEUE QmgrName for each of the queue manager names in Table 1.

Table 1. Queue manager names and port numbers
Description	Queue manager name	Port number
Finance repository	`FINR1`	`1414`
Finance repository	`FINR2`	`1415`
Finance client	`FINCLT`	`1418`
Sales repository	`SALER1`	`1416`
Sales repository	`SALER2`	`1417`
Sales server	`SALESRV`	`1419`
Gateway	`GATE`	`1420`

Start all the queue managers

Run the command: strmqm QmgrName for each of the queue manager names in Table 1.

Create the definitions for each of the queue managers

Run the command: runmqsc QmgrName < filename where the files are listed in Definitions for the basic clusters, and the file name matches the queue manager name.

Definitions for the basic clusters

finr1.txt


DEFINE LISTENER(1414) TRPTYPE(TCP) IPADDR(localhost) CONTROL(QMGR) PORT(1414) REPLACE
START LISTENER(1414)
ALTER QMGR REPOS(FINANCE)
DEFINE CHANNEL(FINANCE.FINR2) CHLTYPE(CLUSSDR) CONNAME('localhost(1415)') CLUSTER(FINANCE) REPLACE
DEFINE CHANNEL(FINANCE.FINR1) CHLTYPE(CLUSRCVR) CONNAME('localhost(1414)') CLUSTER(FINANCE) REPLACE

finr2.txt


DEFINE LISTENER(1415) TRPTYPE(TCP) IPADDR(localhost) CONTROL(QMGR) PORT(1415) REPLACE
START LISTENER(1415)
ALTER QMGR REPOS(FINANCE)
DEFINE CHANNEL(FINANCE.FINR1) CHLTYPE(CLUSSDR) CONNAME('localhost(1414)') CLUSTER(FINANCE) REPLACE
DEFINE CHANNEL(FINANCE.FINR2) CHLTYPE(CLUSRCVR) CONNAME('localhost(1415)') CLUSTER(FINANCE) REPLACE

finclt.txt


DEFINE LISTENER(1418) TRPTYPE(TCP) IPADDR(localhost) CONTROL(QMGR) PORT(1418) REPLACE
START LISTENER(1418)
DEFINE CHANNEL(FINANCE.FINR1) CHLTYPE(CLUSSDR)  CONNAME('localhost(1414)') CLUSTER(FINANCE) REPLACE
DEFINE CHANNEL(FINANCE.FINCLT) CHLTYPE(CLUSRCVR) CONNAME('localhost(1418)') CLUSTER(FINANCE) REPLACE
DEFINE QMODEL(SYSTEM.SAMPLE.REPLY) REPLACE

saler1.txt


DEFINE LISTENER(1416) TRPTYPE(TCP) IPADDR(localhost) CONTROL(QMGR) PORT(1416) REPLACE
START LISTENER(1416)
ALTER QMGR REPOS(SALES)
DEFINE CHANNEL(SALES.SALER2) CHLTYPE(CLUSSDR) CONNAME('localhost(1417)') CLUSTER(SALES) REPLACE
DEFINE CHANNEL(SALES.SALER1) CHLTYPE(CLUSRCVR) CONNAME('localhost(1416)') CLUSTER(SALES) REPLACE

saler2.txt


DEFINE LISTENER(1417) TRPTYPE(TCP) IPADDR(localhost) CONTROL(QMGR) PORT(1417) REPLACE
START LISTENER(1417)
ALTER QMGR REPOS(SALES)
DEFINE CHANNEL(SALES.SALER1) CHLTYPE(CLUSSDR) CONNAME('localhost(1416)') CLUSTER(SALES) REPLACE
DEFINE CHANNEL(SALES.SALER2) CHLTYPE(CLUSRCVR) CONNAME('localhost(1417)') CLUSTER(SALES) REPLACE

salesrv.txt


DEFINE LISTENER(1419) TRPTYPE(TCP) IPADDR(localhost) CONTROL(QMGR) PORT(1419) REPLACE
START LISTENER(1419)
DEFINE CHANNEL(SALES.SALER1) CHLTYPE(CLUSSDR) CONNAME('localhost(1416)') CLUSTER(SALES) REPLACE
DEFINE CHANNEL(SALES.SALESRV) CHLTYPE(CLUSRCVR) CONNAME('localhost(1419)') CLUSTER(SALES) REPLACE
DEFINE QLOCAL(SALES) CLUSTER(SALES) TRIGGER INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE) PROCESS(ECHO) REPLACE
DEFINE PROCESS(ECHO) APPLICID(AMQSECH) REPLACE

gate.txt


DEFINE LISTENER(1420) TRPTYPE(TCP) IPADDR(LOCALHOST) CONTROL(QMGR) PORT(1420) REPLACE
START LISTENER(1420)
DEFINE NAMELIST(ALL) NAMES(SALES, FINANCE)
DEFINE CHANNEL(FINANCE.FINR1) CHLTYPE(CLUSSDR) CONNAME('LOCALHOST(1414)') CLUSTER(FINANCE) REPLACE
DEFINE CHANNEL(FINANCE.GATE) CHLTYPE(CLUSRCVR) CONNAME('LOCALHOST(1420)') CLUSTER(FINANCE) REPLACE
DEFINE CHANNEL(SALES.SALER1) CHLTYPE(CLUSSDR) CONNAME('LOCALHOST(1416)') CLUSTER(SALES) REPLACE
DEFINE CHANNEL(SALES.GATE)  CHLTYPE(CLUSRCVR) CONNAME('LOCALHOST(1420)') CLUSTER(SALES) REPLACE
DEFINE QALIAS(A.SALES) CLUSNL(ALL) TARGET(SALES) TARGTYPE(QUEUE) DEFBIND(NOTFIXED) REPLACE
DEFINE QREMOTE(FINCLT) RNAME(' ') RQMNAME(FINCLT) CLUSNL(ALL) REPLACE
DEFINE QREMOTE(SALESRV) RNAME(' ') RQMNAME(SALESRV) CLUSNL(ALL) REPLACE

Test the configuration by running the sample request program.
1. Start the trigger monitor program on the SALESRV queue manager
  
  On Windows, open a command window and run the command runmqtrm -m SALESRV
2. Run the sample request program, and send a request.
  
  On Windows, open a command window and run the command amqsreq A.SALES FINCLT
  
  The request message is echoed back, and after 15 seconds the sample program finishes.

Create the definitions to isolate the SALES queue in the Q.SALES cluster and separate cluster messages for the SALES and FINANCE cluster on the gateway queue manager.

Run the command: runmqsc QmgrName < filename where the files are listed in the following list, and the file name almost matches the queue manager name.

Changes to isolate the sales queue in a new cluster and separate the gateway cluster transmission queues

chgsaler1.txt


DEFINE NAMELIST(CLUSTERS) NAMES(SALES, Q.SALES)
ALTER QMGR REPOS(' ') REPOSNL(CLUSTERS)
DEFINE CHANNEL(Q.SALES.SALER2) CHLTYPE(CLUSSDR) CONNAME('localhost(1417)') CLUSTER(Q.SALES) REPLACE
DEFINE CHANNEL(Q.SALES.SALER1) CHLTYPE(CLUSRCVR) CONNAME('localhost(1416)') CLUSTER(Q.SALES) REPLACE

chgsaler2.txt


DEFINE NAMELIST(CLUSTERS) NAMES(SALES, Q.SALES)
ALTER QMGR REPOS(' ') REPOSNL(CLUSTERS)
DEFINE CHANNEL(Q.SALES.SALER1) CHLTYPE(CLUSSDR) CONNAME('localhost(1416)') CLUSTER(Q.SALES) REPLACE
DEFINE CHANNEL(Q.SALES.SALER2) CHLTYPE(CLUSRCVR) CONNAME('localhost(1417)') CLUSTER(Q.SALES) REPLACE

chgsalesrv.txt


DEFINE NAMELIST (CLUSTERS) NAMES(SALES, Q.SALES)
DEFINE CHANNEL(Q.SALES.SALER1) CHLTYPE(CLUSSDR) CONNAME('localhost(1416)') CLUSTER(Q.SALES) REPLACE
DEFINE CHANNEL(Q.SALES.SAVESRV) CHLTYPE(CLUSRCVR) CONNAME('localhost(1419)') CLUSTER(Q.SALES) REPLACE
ALTER QLOCAL (SALES) CLUSTER(' ') CLUSNL(CLUSTERS)

chggate.txt


ALTER NAMELIST(ALL) NAMES(SALES, FINANCE, Q.SALES)
ALTER QMGR DEFCLXQ(CHANNEL)
DEFINE CHANNEL(Q.SALES.SALER1) CHLTYPE(CLUSSDR)  CONNAME('localhost(1416)') CLUSTER(Q.SALES) REPLACE
DEFINE CHANNEL(Q.SALES.GATE)  CHLTYPE(CLUSRCVR) CONNAME('localhost(1420)') CLUSTER(Q.SALES) REPLACE
DEFINE QLOCAL (XMITQ.Q.SALES.SALESRV) USAGE(XMITQ) CLCHNAME(Q.SALES.SALESRV) REPLACE
DEFINE QLOCAL (XMITQ.SALES)     USAGE(XMITQ) CLCHNAME(SALES.*)  REPLACE
DEFINE QLOCAL (XMITQ.FINANCE)    USAGE(XMITQ) CLCHNAME(FINANCE.*) REPLACE

Remove the SALES queue from the SALES cluster.
Run the MQSC command in Figure 2:
Figure 2. Remove the sales queue on queue manager SALESRV from the sales cluster
```
ALTER QLOCAL(SALES) CLUSTER('Q.SALES') CLUSNL(' ')
```
Switch the channels to the new transmission queues.

The requirement is to stop and start all the channels that the GATE queue manager is using. To do this with the least number of commands, stop and start the queue manager
```
endmqm -i GATE
strmqm GATE
```

What to do next

Rerun the sample request program to verify the new configuration works; see step 2
Monitor the messages flowing through all the cluster transmission queues on the GATE queue manager:
1. Alter the definition of each of the cluster transmission queues to turn queue monitoring on.
```
ALTER QLOCAL(SYSTEM.CLUSTER.TRANSMIT. 
name) STATQ(ON)
```
2. Check queue manager statistics monitoring is OFF, to minimize output, and set the monitoring interval to a lower value to perform multiple tests conveniently.
```
ALTER QMGR STATINT(60) STATCHL(OFF) STATQ(OFF) STATMQI(OFF) STATACLS(OFF)
```
3. Restart the GATE queue manager.
4. Run the sample request program a few times to verify that an equal number of messages are flowing through SYSTEM.CLUSTER.TRANSMIT.Q.SALES.SALESRV and SYSTEM.CLUSTER.TRANSMIT.QUEUE. Requests flow through SYSTEM.CLUSTER.TRANSMIT.Q.SALES.SALESRV and replies through SYSTEM.CLUSTER.TRANSMIT.QUEUE.
```
amqsmon -m GATE -t statistics
```
5. The results over a couple of intervals are as follows:
  
  C:\Documents and Settings\Admin>amqsmon -m GATE -t statistics MonitoringType: QueueStatistics QueueManager: 'GATE' IntervalStartDate: '2012-02-27' IntervalStartTime: '14.59.20' IntervalEndDate: '2012-02-27' IntervalEndTime: '15.00.20' CommandLevel: 700 ObjectCount: 2 QueueStatistics: 0 QueueName: 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' CreateDate: '2012-02-24' CreateTime: '15.58.15' ... Put1Count: [0, 0] Put1FailCount: 0 PutBytes: [435, 0] GetCount: [1, 0] GetBytes: [435, 0] ... QueueStatistics: 1 QueueName: 'SYSTEM.CLUSTER.TRANSMIT.Q.SALES.SAVESRV' CreateDate: '2012-02-24' CreateTime: '16.37.43' ... PutCount: [1, 0] PutFailCount: 0 Put1Count: [0, 0] Put1FailCount: 0 PutBytes: [435, 0] GetCount: [1, 0] GetBytes: [435, 0] ... MonitoringType: QueueStatistics QueueManager: 'GATE' IntervalStartDate: '2012-02-27' IntervalStartTime: '15.00.20' IntervalEndDate: '2012-02-27' IntervalEndTime: '15.01.20' CommandLevel: 700 ObjectCount: 2 QueueStatistics: 0 QueueName: 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' CreateDate: '2012-02-24' CreateTime: '15.58.15' ... PutCount: [2, 0] PutFailCount: 0 Put1Count: [0, 0] Put1FailCount: 0 PutBytes: [863, 0] GetCount: [2, 0] GetBytes: [863, 0] ... QueueStatistics: 1 QueueName: 'SYSTEM.CLUSTER.TRANSMIT.Q.SALES.SAVESRV' CreateDate: '2012-02-24' CreateTime: '16.37.43' ... PutCount: [2, 0] PutFailCount: 0 Put1Count: [0, 0] Put1FailCount: 0 PutBytes: [863, 0] GetCount: [2, 0] GetBytes: [863, 0] ... 2 Records Processed.
  
  One request and reply message were sent in the first interval and two in the second. You can infer that the request messages were placed on SYSTEM.CLUSTER.TRANSMIT.Q.SALES.SAVESRV, and the reply messages on SYSTEM.CLUSTER.TRANSMIT.QUEUE.