Reputation: 8134
i am trying to write a script that will - when passed an MQ queue name - indicate either 'end' of the queue i.e. who puts messages on and who takes them off.
To establish the manual method of doing this (before I automate it) I picked a QLOCAL at random and using CA-Sysview, I used the MQROBJ screen to see that one of our CICS regions PUTs messages on the queue and our MQ CHIN started task GETs messages off the queue.
But I can't see where the messages go. As this is a QLOCAL but it's the CHIN job taking messages off it, then I assume that some remote queue manager has this queue defined as a QREMOTE and is issuing GETs against the queue.
We have access to normal z/OS MQ commands and CA-Sysview
Can I establish the remote queue manager taking messages off the queue?
Upvotes: 2
Views: 1364
Reputation: 7527
In order to determine either end of the queue usage diagram, try the following command on your QLOCAL.
DISPLAY CONN(*) TYPE(ALL) ALL WHERE(OBJNAME EQ local-q-name)
and look for the following fields; APPLTYPE
, APPLTAG
, OPENOPTS
, CHANNEL
, CONNAME
You can tell whether the application is a putter or a getter by looking at the OPENOPTS
field in the output. If it says MQOO_OUTPUT
then it is a putter, and if it says MQOO_INPUT_*
then it is a getter.
If the application has a CHANNEL
name filled in, then the connection that is using that queue came down a channel. You must go to the machine described by the CONNAME
and investigate further from there. You should be able to tell the difference between a client application and a sender/receiver channel by using the channel name.
If you are tracking a path across a sender/receiver channel, then on the remote machine you must take a look at QREMOTE definitions. Try a command like the following:-
DISPLAY QREMOTE(*) ALL WHERE(RNAME EQ local-q-name)
Upvotes: 3
Reputation: 1017
A remote queue manager does not "take messages off the queue". That's simply impossible. Since you mention z/OS, then there are patterns where shared queues may be involved, but that's more like a different local qmgr than a remote one.
The local CHIN will take messages off a queue to SEND it to a remote queue manager if it's defined as a transmission queue (USAGE=XMITQ) and there's an associated channel. And at that point you know what the remote qmgr is.
If the queue is not a transmission queue, then the only way a channel is involved is if there's a CLIENT application connected to your queue manager. And then, looking at QSTATUS and CHSTATUS ought to give information about what's doing the work.
More generally, there are ways to work out the path a message would take through an MQ network - research the dspmqrte command. Even if it is not part of the MQ on z/OS product, you can run it as a client application from another platform.
Upvotes: 0