+

Search Tips | Advanced Search

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 Create 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.

Figure 1. Example of specific transmission queues for different departmental IBM MQ clusters

The steps to modify the clusters are as follows; see Figure 3 for the definitions.


Procedure

  1. 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.
  2. 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 we 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 Figure 3. 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 4.

    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

  3. 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, we can stop and start the gateway queue manager.

  1. Stop the following channels on the gateway queue manager: 
    SALES. Qmgr
DEVELOP. Qmgr
FINANCE. Qmgr
  2. 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 4.

Parent topic: Clustering: Planning how to configure cluster transmission queues


Related concepts


Related tasks


Create 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 Figure 2, Figure 3, and Figure 4. The definitions for the basic clusters are in Figure 2. The definitions in Figure 3 modify the basic clusters to isolate the SALES queue, and to separate cluster messages to FINANCE and SALES. Finally, to remove the SALES queue from the SALES cluster; see Figure 4. The DEVELOP cluster is omitted from the definitions, to keep the definitions shorter.


Procedure

  1. Create the SALES and FINANCE clusters, and the gateway queue manager.
    1. 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.

      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
    2. Start all the queue managers Run the command: strmqm QmgrName for each of the queue manager names in Table 1.
    3. Create the definitions for each of the queue managers Run the command: runmqsc QmgrName < filename where the files are listed in Figure 2, and the file name matches the queue manager name.
      Figure 2. 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

  2. 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.

  3. 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 Figure 3, and the file name almost matches the queue manager name.
    Figure 3. 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

  4. Remove the SALES queue from the SALES cluster.

    Run the MQSC command in Figure 4:

    Figure 4. Remove the sales queue on queue manager SALESRV from the sales cluster
    ALTER QLOCAL(SALES) CLUSTER('Q.SALES') CLUSNL(' ')
  5. 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

  1. Rerun the sample request program to verify the new configuration works; see step 2
  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. We can infer that the request messages were placed on SYSTEM.CLUSTER.TRANSMIT.Q.SALES.SAVESRV, and the reply messages on SYSTEM.CLUSTER.TRANSMIT.QUEUE.

Last updated: 2020-10-04