Creating two overlapping clusters with a gateway queue manager

Follow the instructions in the task to construct overlapping clusters with a gateway queue manager. Use the clusters as a starting point for the following examples of isolating messages to one application from messages to other applications in a cluster.

About this task

The example cluster configuration used to illustrate isolating cluster message traffic is shown in Figure 1. The example is described in Clustering: Application isolation using multiple cluster transmission queues.

Figure 1. Client-server application deployed to hub and spoke architecture using IBM® MQ clusters
The diagram shows two overlapping clusters connected by a gateway queue manager QM1. A message flows from an application in one cluster to the other cluster, through the transmission queue, SYSTEM.CLUSTER.TRANSMIT.QUEUE, in the gateway queue manager. The message is routed by an alias queue in the gateway queue manager QM1. 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 QM1 point to the real queue managers in each cluster.

To minimize the number of steps to construct the example, the configuration is kept simple rather than realistic. The example might represent the integration of two clusters created by two separate organizations. For a more realistic scenario, see Clustering: Planning how to configure cluster transmission queues.

Follow the steps to construct the clusters. The clusters are used in the following examples of isolating the message traffic from the client application to the server application.

The instructions add a couple of additional queue managers so that each cluster has two repositories. The gateway queue manager QM1 is not used as a repository for performance reasons.

Procedure

  1. Create and start the gateway queue manager QM1, and queue managers QM2, QM3, QM4, QM5. 
    crtmqm -sax -u SYSTEM.DEAD.LETTER.QUEUE QM n
strmqm QmgrName
    Note: QM4 and QM5 are the backup full repositories for the clusters.
  2. Define and start listeners for each queue manager. 
    *... On QM n
DEFINE LISTENER(TCP141 n) TRPTYPE(TCP) IPADDR(hostname) PORT(141 n) CONTROL(QMGR) REPLACE
START LISTENER(TCP141 n)
  3. Create a cluster name list for all of the clusters. 
    *... On gateway queue manager QM1
DEFINE NAMELIST(ALL) NAMES(CL1, CL2) REPLACE
  4. Make QM2 and QM4 full repositories for CL1, QM3 and QM5 full repositories for CL2.
    1. For CL1: 
      *... On QM2 and QM4
ALTER QMGR REPOS(CL1) DEFCLXQ(SCTQ)
    2. For CL2: 
      *... On QM3 and QM5
ALTER QMGR REPOS(CL2) DEFCLXQ(SCTQ)
  5. Add the cluster-sender and cluster-receiver channels for each queue manager and cluster.
    Run the following commands on QM2, QM3, QM4 and QM5, where c, n, and m take the values shown in Table 1 for each queue manager:
    Table 1. Parameter values for creating clusters 1 and 2
    Queue manager
    Cluster
    c
    Other repository
    n
    This repository
    m
    QM2 1 4 2
    QM4 1 2 4
    QM3 2 5 3
    QM5 2 3 5 
    *... On QMm
DEFINE CHANNEL(CLc.QMn) CHLTYPE(CLUSSDR) CONNAME('localhost(141n)') CLUSTER(CLc) REPLACE
DEFINE CHANNEL(CLc.QMm) CHLTYPE(CLUSRCVR) CONNAME('localhost(141m)') CLUSTER(CLc) REPLACE
  6. Add the gateway queue manager QM1 to each of the clusters. 
    *... On gateway queue manager QM1
DEFINE CHANNEL(CL1.QM2) CHLTYPE(CLUSSDR) CONNAME('localhost(1412)') CLUSTER(CL1) REPLACE
DEFINE CHANNEL(CL1.QM1) CHLTYPE(CLUSRCVR) CONNAME('localhost(1411)') CLUSTER(CL1) REPLACE
DEFINE CHANNEL(CL2.QM3) CHLTYPE(CLUSSDR) CONNAME('localhost(1413)') CLUSTER(CL2) REPLACE
DEFINE CHANNEL(CL2.QM1) CHLTYPE(CLUSRCVR) CONNAME('localhost(1411)') CLUSTER(CL2) REPLACE
  7. Add the local queue Q1 to queue manager QM3 in cluster CL2. 
    *... On QM3
DEFINE QLOCAL(Q1) CLUSTER(CL2) REPLACE
  8. Add a queue alias on the gateway queue manager QM1 for each clustered queue. 
    *... On gateway queue manager QM1
DEFINE QALIAS(Q1A) CLUSNL(ALL) TARGET(Q1) TARGTYPE(QUEUE) DEFBIND(NOTFIXED) REPLACE
  9. Add the cluster queue manager alias definitions, for all the clustered queue managers, to the gateway queue manager QM1.

    A queue manager alias is needed for each Partial Repository to which a response (Reply) will be needed. The purpose of the queue manager alias is this: If an application is processing a request message that includes a ReplyTo attribute (that originated from a queue manager in a different cluster), the application can reply to the request through the queue manager alias.

    Note: In the following example, the queue manager alias names are QM2 and QM3, which are the same as the real queue manager names (RQMNAME) of QM2 and QM3 they refer to. If you want the applications not to know the real queue manager names, you can use different names. For example, the queue manager alias could be named PAYROLLQM, if this is more meaningful to the application than QM2.
    *... On gateway queue manager QM1
DEFINE QREMOTE(QM2) RNAME(' ') RQMNAME(QM2) CLUSNL(ALL) REPLACE
DEFINE QREMOTE(QM3) RNAME(' ') RQMNAME(QM3) CLUSNL(ALL) REPLACE
    Tip: The queue manager alias definitions on the gateway queue manager QM1 transfer messages that refer to a queue manager in another cluster. See Clustered queue manager aliases.

What to do next

  1. Test the queue alias definition by sending a message from QM2 to Q1 on QM3 using 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
  2. Test the queue manager alias definitions by sending a request message and receiving a reply message on a temporary-dynamic reply queue.

    The diagram shows the path taken by the reply message back to a temporary dynamic queue, which is called RQ. The server application, connected to QM3, opens the reply queue using the queue manager name QM2. The queue manager name QM2 is defined as a clustered queue manager alias on gateway queue manager QM1. QM3 routes the reply message to gateway queue manager QM1. QM1 routes the message to QM2.

    Figure 2. Using a queue manager alias to return the reply message to a different cluster
    Path taken by a reply message from the server to the client application through the gateway queue manager.

    The way the routing works is as follows. Every queue manager in each cluster has a queue manager alias definition on gateway queue manager QM1. The aliases are clustered in all the clusters. The grey dashed arrows from each of the aliases to a queue manager show that each queue manager alias is resolved to a real queue manager in at least one of the clusters. In this case, the QM2 alias is clustered in both cluster CL1 and CL2, and is resolved to the real queue manager QM2 in CL1. The server application creates the reply message using the reply to queue name RQ, and reply to queue manager name QM2. The message is routed to gateway queue manager QM1 because the queue manager alias definition QM2 is defined on QM1 in cluster CL2 and queue manager QM2 is not in cluster CL2. As the message cannot be sent to the target queue manager, it is sent to the queue manager that has the alias definition.

    Gateway queue manager QM1 places the message on its cluster transmission queue for transfer to QM2. Gateway queue manager QM1 routes the message to QM2 because the queue manager alias definition on QM1 for QM2 defines QM2 as the real target queue manager. The definition is not circular, because alias definitions can refer only to real definitions; the alias cannot point to itself. The real definition is resolved by gateway queue manager QM1, because both QM1 and QM2 are in the same cluster, CL1. Gateway queue manager QM1 finds out the connection information for QM2 from the repository for CL1, and routes the message to QM2. For the message to be rerouted by QM1, the server application must have opened the reply queue with the option DEFBIND set to MQBND_BIND_NOT_FIXED. If the server application had opened the reply queue with the option MQBND_BIND_ON_OPEN, the message is not rerouted and ends up on a dead letter queue.

    1. Create a clustered request queue with a trigger on QM3. 
      *... On QM3
DEFINE QLOCAL(QR) CLUSTER(CL2) TRIGGER INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE) PROCESS(ECHO) REPLACE
    2. Create a clustered queue alias definition of QR on the gateway queue manager QM1. 
      *... On gateway queue manager QM1
DEFINE QALIAS(QRA) CLUSNL(ALL) TARGET(QR) TARGTYPE(QUEUE) DEFBIND(NOTFIXED) REPLACE
    3. Create a process definition to start the sample echo program amqsech on QM3. 
      *... On QM3
DEFINE PROCESS(ECHO) APPLICID(AMQSECH) REPLACE
    4. Create a model queue on QM2 for the sample program amqsreq to create the temporary-dynamic reply queue. 
      *... On QM2
DEFINE QMODEL(SYSTEM.SAMPLE.REPLY) REPLACE
    5. Test the queue manager alias definition by sending a request from QM2 to QR on QM3 using the queue alias definition QRA.
      1. Run the trigger monitor program on QM3. 
        runmqtrm -m QM3
        The output is

        C:\IBM\MQ>runmqtrm -m QM3
        5724-H72 (C) Copyright IBM Corp. 1994, 2025. ALL RIGHTS RESERVED.
        01/02/2012  16:17:15: IBM MQ trigger monitor started.

        __________________________________________________
        01/02/2012  16:17:15: Waiting for a trigger message
      2. Run the sample program amqsreq on QM2 to put a request and wait for a reply.

        C:\IBM\MQ>amqsreq QRA QM2
        Sample AMQSREQ0 start
        server queue is QRA
        replies to 4F2961C802290020
        A request message from QM2 to QR on QM3

        response <A request message from QM2 to QR on QM3>
        no more replies
        Sample AMQSREQ0 end