Understanding CLUSQMGR output

Body

For some types of cluster issues, the output from the DISPLAY CLUSQMGR command goes a long way towards understanding what's wrong and how to fix it. Let's take a look at the following output to focus on some important fields. CSQM293I indicates, for a partial repository, the number of queue managers it has an interest in. A full repository would return every queue manager in the cluster TEST. Since DEFTYPE is CLUSSDRB and QMTYPE is REPOS this means RTP9 has a manually defined channel to the full repository, RTP8, which has been merged with the CLUSRCVR defined on RTP8. You can tell the date when RTP8 was created using the time-of-day value in the QMID field which equates to (2012/05/07 19:38:55.280960) and can be converted using TSO's time of day service, or the IPCS LISTTOD command. CLUSDATE and CLUSTIME tell when this definition became available to RTP9 based on GMT.

+RTP9 DIS CLUSQMGR(*) ALL
CSQM293I +RTP9 CSQMDRTC 2 CLUSQMGR FOUND MATCHING REQUEST
CSQM201I +RTP9 CSQMDRTC  DIS CLUSQMGR DETAILS 815
CLUSQMGR(RTP8)
CLUSTER(TEST)
CHANNEL(TO.RTP8)
QMID(RTP8.C9887B4687B4021B)
DEFTYPE(CLUSSDRB)
QMTYPE(REPOS)
CLUSDATE(2013-09-05)
CLUSTIME(05.49.53)
SUSPEND(NO)
STATUS(RETRYING)
TRPTYPE(TCP)
CONNAME(WINMVS3C.HURSLEY.IBM.COM(1719))

RTP8 is available for inbound cluster activity, shown by SUSPEND(NO) otherwise this would be displayed as SUSPEND(YES) and traffic that can be routed elsewhere will be. Note that the channel STATUS is RETRYING so connectivity to the listed CONNAME should be checked using a TSO PING. After stopping the channel an MQ PING can also be done. If the former completes successfully, but the latter fails, then this would isolate the issue to a problem with MQ and not the network. Perhaps the listener on RTP8 is not active or the connection name is incorrect.

So this explains how RTP9 views RTP8, but how does it view itself. This self view is shown by the one channel per cluster which has a DEFTTYPE of CLUSRCVR.

CSQM201I +RTP9 CSQMDRTC DIS CLUSQMGR DETAILS
CLUSQMGR(RTP9)
CLUSTER(TEST)
CHANNEL(TO.RTP9)
QMID(RTP9.C90E8C8825558CAC)
DEFTYPE(CLUSRCVR)
QMTYPE(NORMAL)
CLUSDATE(2013-09-10)
CLUSTIME(20.28.22)
SUSPEND(YES)
TRPTYPE(TCP)
CONNAME(9.20.5.158(1720))

Although this is truncated output, using the QMID value it tells me that RTP9 was instantiated on 2012/01/31 at 20:06:31.325016. A QMTYPE of NORMAL represents a partial repository and RTP9 sees itself as suspended from the TEST cluster.

For me, CLUSQMGR is always the first piece of information that I look at before going too deep into a cluster problem. If it's as simple as having configured a channel type improperly, then it's the best way to go. I plan to show how to quickly move through this output in a live test environment in an upcoming YouTube video on our ⇒IBM SupportTV channel, so look for that soon. Stay tuned because we've definitely got a lot more to tell you about.