7. Verify and test the cluster

Issue some DISPLAY commands to verify the cluster that you have set up. The responses you see should be similar to those shown in the examples that follow.

     1 : dis clusqmgr(*)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(NEWYORK)             CLUSTER(INVENTORY)
   CHANNEL(TO.NEWYORK)
AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(LONDON)              CLUSTER(INVENTORY)
   CHANNEL(TO.LONDON)

Now issue the corresponding DISPLAY CHANNEL STATUS command:

dis chstatus(*)

     1 : dis chstatus(*)
AMQ8417: Display Channel Status details.
   CHANNEL(TO.NEWYORK)           XMITQ( )
   CONNAME(9.20.40.24)           CURRENT
   CHLTYPE(CLUSRCVR)             STATUS(RUNNING)
   RQMNAME(LONDON)
AMQ8417: Display Channel Status details.
   CHANNEL(TO.LONDON)            XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
   CONNAME(9.20.51.25)           CURRENT
   CHLTYPE(CLUSSDR)              STATUS(RUNNING)
   RQMNAME(LONDON)

For more details on troubleshooting see Troubleshooting.

Because the INVENTQ queue has been advertised to the cluster there is no need for remote-queue definitions. Applications running on NEWYORK and applications running on LONDON can put messages to the INVENTQ queue. They can receive responses to their messages by providing a reply-to queue and specifying its name when they put messages.

The definition for the local queue LONDON_reply does not need the CLUSTER attribute. NEWYORK replies to this queue by explicitly specifying the queue manager name. Another way of doing is to use a temporary dynamic queue. See the WebSphere MQ Application Programming Guide for more information.

If you are converting an existing network into a cluster like this, in step 7, we need to alter the existing queue definition. You also need to delete the remote queue definition at LONDON for the INVENTQ queue. See Task 6: Converting an existing network into a cluster for an example of this.

Parent topic:

Procedure

qc10550_

Home