Determine the remote MQ queue manager accessing our local queue
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?
ibm-mq mainframe zos
asked Dec 28 '18 at 10:52
Steve IvesSteve Ives
5,05321231
add a comment |
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?
ibm-mq mainframe zos
asked Dec 28 '18 at 10:52
Steve IvesSteve Ives
5,05321231
I don't think you can. Very curious to see if there is a way.
– SaggingRufus
Dec 28 '18 at 11:34
@SaggingRufus Does my interpretation seem correct? All the IBM docs & diagrams I find about using remote queues mamagers talk about remote queues and triggering. Putting messages on local queues and waiting for a GET from a remote QMGR seems not to be discussed.
– Steve Ives
Dec 28 '18 at 12:04
What you describe is basically how I have seen things set up where I work. There are 2 queue, so if you were one putting the messages you would have a queue called XXX_TO_YYY and you may be using a queue manager called MQX1. This would be a local queue for you. When I go to get those messages, I would call a queue called YYY_FR_XXX which could be using a queue manager called MQY1. In this case, the queue I issue the GET to is local to me, and the queue you issue the PUT to is local to you, but your queue is remote to me and my queue is remote to you.
– SaggingRufus
Dec 28 '18 at 12:33
In this type of setup, I don't know if it possible to identify the remote queue or manager as this is all set up within the MQS config (as far as I know at least).
– SaggingRufus
Dec 28 '18 at 12:34
add a comment |
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?
ibm-mq mainframe zos
asked Dec 28 '18 at 10:52
Steve IvesSteve Ives
5,05321231
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?
ibm-mq mainframe zos
ibm-mq mainframe zos
asked Dec 28 '18 at 10:52
Steve IvesSteve Ives
5,05321231
asked Dec 28 '18 at 10:52
Steve IvesSteve Ives
5,05321231
edited Jan 2 at 10:53
Steve Ives
asked Dec 28 '18 at 10:52
Steve IvesSteve Ives
5,05321231
asked Dec 28 '18 at 10:52
Steve IvesSteve Ives
5,05321231
asked Dec 28 '18 at 10:52
Steve IvesSteve Ives
5,05321231
5,05321231
I don't think you can. Very curious to see if there is a way.
– SaggingRufus
Dec 28 '18 at 11:34
@SaggingRufus Does my interpretation seem correct? All the IBM docs & diagrams I find about using remote queues mamagers talk about remote queues and triggering. Putting messages on local queues and waiting for a GET from a remote QMGR seems not to be discussed.
– Steve Ives
Dec 28 '18 at 12:04
What you describe is basically how I have seen things set up where I work. There are 2 queue, so if you were one putting the messages you would have a queue called XXX_TO_YYY and you may be using a queue manager called MQX1. This would be a local queue for you. When I go to get those messages, I would call a queue called YYY_FR_XXX which could be using a queue manager called MQY1. In this case, the queue I issue the GET to is local to me, and the queue you issue the PUT to is local to you, but your queue is remote to me and my queue is remote to you.
– SaggingRufus
Dec 28 '18 at 12:33
In this type of setup, I don't know if it possible to identify the remote queue or manager as this is all set up within the MQS config (as far as I know at least).
– SaggingRufus
Dec 28 '18 at 12:34
add a comment |
I don't think you can. Very curious to see if there is a way.
– SaggingRufus
Dec 28 '18 at 11:34
@SaggingRufus Does my interpretation seem correct? All the IBM docs & diagrams I find about using remote queues mamagers talk about remote queues and triggering. Putting messages on local queues and waiting for a GET from a remote QMGR seems not to be discussed.
– Steve Ives
Dec 28 '18 at 12:04
What you describe is basically how I have seen things set up where I work. There are 2 queue, so if you were one putting the messages you would have a queue called XXX_TO_YYY and you may be using a queue manager called MQX1. This would be a local queue for you. When I go to get those messages, I would call a queue called YYY_FR_XXX which could be using a queue manager called MQY1. In this case, the queue I issue the GET to is local to me, and the queue you issue the PUT to is local to you, but your queue is remote to me and my queue is remote to you.
– SaggingRufus
Dec 28 '18 at 12:33
In this type of setup, I don't know if it possible to identify the remote queue or manager as this is all set up within the MQS config (as far as I know at least).
– SaggingRufus
Dec 28 '18 at 12:34
I don't think you can. Very curious to see if there is a way.
– SaggingRufus
Dec 28 '18 at 11:34
I don't think you can. Very curious to see if there is a way.
– SaggingRufus
Dec 28 '18 at 11:34
@SaggingRufus Does my interpretation seem correct? All the IBM docs & diagrams I find about using remote queues mamagers talk about remote queues and triggering. Putting messages on local queues and waiting for a GET from a remote QMGR seems not to be discussed.
– Steve Ives
Dec 28 '18 at 12:04
@SaggingRufus Does my interpretation seem correct? All the IBM docs & diagrams I find about using remote queues mamagers talk about remote queues and triggering. Putting messages on local queues and waiting for a GET from a remote QMGR seems not to be discussed.
– Steve Ives
Dec 28 '18 at 12:04
What you describe is basically how I have seen things set up where I work. There are 2 queue, so if you were one putting the messages you would have a queue called XXX_TO_YYY and you may be using a queue manager called MQX1. This would be a local queue for you. When I go to get those messages, I would call a queue called YYY_FR_XXX which could be using a queue manager called MQY1. In this case, the queue I issue the GET to is local to me, and the queue you issue the PUT to is local to you, but your queue is remote to me and my queue is remote to you.
– SaggingRufus
Dec 28 '18 at 12:33
What you describe is basically how I have seen things set up where I work. There are 2 queue, so if you were one putting the messages you would have a queue called XXX_TO_YYY and you may be using a queue manager called MQX1. This would be a local queue for you. When I go to get those messages, I would call a queue called YYY_FR_XXX which could be using a queue manager called MQY1. In this case, the queue I issue the GET to is local to me, and the queue you issue the PUT to is local to you, but your queue is remote to me and my queue is remote to you.
– SaggingRufus
Dec 28 '18 at 12:33
In this type of setup, I don't know if it possible to identify the remote queue or manager as this is all set up within the MQS config (as far as I know at least).
– SaggingRufus
Dec 28 '18 at 12:34
In this type of setup, I don't know if it possible to identify the remote queue or manager as this is all set up within the MQS config (as far as I know at least).
– SaggingRufus
Dec 28 '18 at 12:34
add a comment |
2 Answers
2
active
oldest
votes
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)
answered Dec 28 '18 at 20:42
Morag HughsonMorag Hughson
4,435531
Morag - thanks. the command response is MPO1 DISPLAY CONN(*) TYPE(ALL) ALL WHERE(OBJNAME EQ PPDAA1.APLUS.DRS.AUTOCASE.UPD) CSQM297I MPO1 CSQMDRTC NO CONN FOUND MATCHING REQUEST CRITERIA. If I look at the 'MQ Request by Object; display in Sysvies (Sorrtty - I don;t know the z/OS command equivalent) the only connection types against that queue are CICS (for the PUTs) and CHIN (for the GETs);
– Steve Ives
Dec 31 '18 at 9:31
Unfortunately, I don't know if any remote machine is involved. I'm trying to find out if there is.
– Steve Ives
Dec 31 '18 at 9:40
Try theDIS CONNcommand many times in a row. Sometimes you will find a client app written that connects, gets, disconnects, repeat. On unix i can run the display in a while true loop and usually catch it, not sure how to do the same on zOS.
– JoshMc
Dec 31 '18 at 15:00
@JoshMc thnks Josh - did try but never got a hit.
– Steve Ives
Jan 3 at 8:14
Another detail you can obtain is last put and get time. The setting on the queue isMONQ. It can be set toQMGRwhich means to take the value of theQMGR MONQsetting, or it can be set toOFFto turn collection off for that specific queue, or it can be set toLOW/MEDIUM/HIGHwhich in the words of the knowledge center "here is no distinction between the values LOW, MEDIUM, and HIGH. These values all turn data collection on, but do not affect the rate of collection."
– JoshMc
Jan 3 at 8:27
|
show 3 more comments
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.
answered Dec 28 '18 at 13:01
Mark TaylorMark Taylor
126112
1
Mark - are you saying that you cannot issue a GET against a QREMOTE? This appears to be a normal QLOCAL - not a XMITQ and no INITQ or PROCESS defined. I can't see how CHSTATUS will help as I don't know which channel is involved. .If I issue QSTATUS for this queue what can I expect to see that will indicate where the messages are going?
– Steve Ives
Dec 28 '18 at 13:10
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53957355%2fdetermine-the-remote-mq-queue-manager-accessing-our-local-queue%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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)
answered Dec 28 '18 at 20:42
Morag HughsonMorag Hughson
4,435531
Morag - thanks. the command response is MPO1 DISPLAY CONN(*) TYPE(ALL) ALL WHERE(OBJNAME EQ PPDAA1.APLUS.DRS.AUTOCASE.UPD) CSQM297I MPO1 CSQMDRTC NO CONN FOUND MATCHING REQUEST CRITERIA. If I look at the 'MQ Request by Object; display in Sysvies (Sorrtty - I don;t know the z/OS command equivalent) the only connection types against that queue are CICS (for the PUTs) and CHIN (for the GETs);
– Steve Ives
Dec 31 '18 at 9:31
Unfortunately, I don't know if any remote machine is involved. I'm trying to find out if there is.
– Steve Ives
Dec 31 '18 at 9:40
Try theDIS CONNcommand many times in a row. Sometimes you will find a client app written that connects, gets, disconnects, repeat. On unix i can run the display in a while true loop and usually catch it, not sure how to do the same on zOS.
– JoshMc
Dec 31 '18 at 15:00
@JoshMc thnks Josh - did try but never got a hit.
– Steve Ives
Jan 3 at 8:14
Another detail you can obtain is last put and get time. The setting on the queue isMONQ. It can be set toQMGRwhich means to take the value of theQMGR MONQsetting, or it can be set toOFFto turn collection off for that specific queue, or it can be set toLOW/MEDIUM/HIGHwhich in the words of the knowledge center "here is no distinction between the values LOW, MEDIUM, and HIGH. These values all turn data collection on, but do not affect the rate of collection."
– JoshMc
Jan 3 at 8:27
|
show 3 more comments
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)
answered Dec 28 '18 at 20:42
Morag HughsonMorag Hughson
4,435531
Morag - thanks. the command response is MPO1 DISPLAY CONN(*) TYPE(ALL) ALL WHERE(OBJNAME EQ PPDAA1.APLUS.DRS.AUTOCASE.UPD) CSQM297I MPO1 CSQMDRTC NO CONN FOUND MATCHING REQUEST CRITERIA. If I look at the 'MQ Request by Object; display in Sysvies (Sorrtty - I don;t know the z/OS command equivalent) the only connection types against that queue are CICS (for the PUTs) and CHIN (for the GETs);
– Steve Ives
Dec 31 '18 at 9:31
Unfortunately, I don't know if any remote machine is involved. I'm trying to find out if there is.
– Steve Ives
Dec 31 '18 at 9:40
Try theDIS CONNcommand many times in a row. Sometimes you will find a client app written that connects, gets, disconnects, repeat. On unix i can run the display in a while true loop and usually catch it, not sure how to do the same on zOS.
– JoshMc
Dec 31 '18 at 15:00
@JoshMc thnks Josh - did try but never got a hit.
– Steve Ives
Jan 3 at 8:14
Another detail you can obtain is last put and get time. The setting on the queue isMONQ. It can be set toQMGRwhich means to take the value of theQMGR MONQsetting, or it can be set toOFFto turn collection off for that specific queue, or it can be set toLOW/MEDIUM/HIGHwhich in the words of the knowledge center "here is no distinction between the values LOW, MEDIUM, and HIGH. These values all turn data collection on, but do not affect the rate of collection."
– JoshMc
Jan 3 at 8:27
|
show 3 more comments
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)
answered Dec 28 '18 at 20:42
Morag HughsonMorag Hughson
4,435531
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)
answered Dec 28 '18 at 20:42
Morag HughsonMorag Hughson
4,435531
answered Dec 28 '18 at 20:42
Morag HughsonMorag Hughson
4,435531
answered Dec 28 '18 at 20:42
Morag HughsonMorag Hughson
4,435531
answered Dec 28 '18 at 20:42
Morag HughsonMorag Hughson
4,435531
4,435531
Morag - thanks. the command response is MPO1 DISPLAY CONN(*) TYPE(ALL) ALL WHERE(OBJNAME EQ PPDAA1.APLUS.DRS.AUTOCASE.UPD) CSQM297I MPO1 CSQMDRTC NO CONN FOUND MATCHING REQUEST CRITERIA. If I look at the 'MQ Request by Object; display in Sysvies (Sorrtty - I don;t know the z/OS command equivalent) the only connection types against that queue are CICS (for the PUTs) and CHIN (for the GETs);
– Steve Ives
Dec 31 '18 at 9:31
Unfortunately, I don't know if any remote machine is involved. I'm trying to find out if there is.
– Steve Ives
Dec 31 '18 at 9:40
Try theDIS CONNcommand many times in a row. Sometimes you will find a client app written that connects, gets, disconnects, repeat. On unix i can run the display in a while true loop and usually catch it, not sure how to do the same on zOS.
– JoshMc
Dec 31 '18 at 15:00
@JoshMc thnks Josh - did try but never got a hit.
– Steve Ives
Jan 3 at 8:14
Another detail you can obtain is last put and get time. The setting on the queue isMONQ. It can be set toQMGRwhich means to take the value of theQMGR MONQsetting, or it can be set toOFFto turn collection off for that specific queue, or it can be set toLOW/MEDIUM/HIGHwhich in the words of the knowledge center "here is no distinction between the values LOW, MEDIUM, and HIGH. These values all turn data collection on, but do not affect the rate of collection."
– JoshMc
Jan 3 at 8:27
|
show 3 more comments
Morag - thanks. the command response is MPO1 DISPLAY CONN(*) TYPE(ALL) ALL WHERE(OBJNAME EQ PPDAA1.APLUS.DRS.AUTOCASE.UPD) CSQM297I MPO1 CSQMDRTC NO CONN FOUND MATCHING REQUEST CRITERIA. If I look at the 'MQ Request by Object; display in Sysvies (Sorrtty - I don;t know the z/OS command equivalent) the only connection types against that queue are CICS (for the PUTs) and CHIN (for the GETs);
– Steve Ives
Dec 31 '18 at 9:31
Unfortunately, I don't know if any remote machine is involved. I'm trying to find out if there is.
– Steve Ives
Dec 31 '18 at 9:40
Try theDIS CONNcommand many times in a row. Sometimes you will find a client app written that connects, gets, disconnects, repeat. On unix i can run the display in a while true loop and usually catch it, not sure how to do the same on zOS.
– JoshMc
Dec 31 '18 at 15:00
@JoshMc thnks Josh - did try but never got a hit.
– Steve Ives
Jan 3 at 8:14
Another detail you can obtain is last put and get time. The setting on the queue isMONQ. It can be set toQMGRwhich means to take the value of theQMGR MONQsetting, or it can be set toOFFto turn collection off for that specific queue, or it can be set toLOW/MEDIUM/HIGHwhich in the words of the knowledge center "here is no distinction between the values LOW, MEDIUM, and HIGH. These values all turn data collection on, but do not affect the rate of collection."
– JoshMc
Jan 3 at 8:27
Morag - thanks. the command response is MPO1 DISPLAY CONN(*) TYPE(ALL) ALL WHERE(OBJNAME EQ PPDAA1.APLUS.DRS.AUTOCASE.UPD) CSQM297I MPO1 CSQMDRTC NO CONN FOUND MATCHING REQUEST CRITERIA. If I look at the 'MQ Request by Object; display in Sysvies (Sorrtty - I don;t know the z/OS command equivalent) the only connection types against that queue are CICS (for the PUTs) and CHIN (for the GETs);
– Steve Ives
Dec 31 '18 at 9:31
Morag - thanks. the command response is MPO1 DISPLAY CONN(*) TYPE(ALL) ALL WHERE(OBJNAME EQ PPDAA1.APLUS.DRS.AUTOCASE.UPD) CSQM297I MPO1 CSQMDRTC NO CONN FOUND MATCHING REQUEST CRITERIA. If I look at the 'MQ Request by Object; display in Sysvies (Sorrtty - I don;t know the z/OS command equivalent) the only connection types against that queue are CICS (for the PUTs) and CHIN (for the GETs);
– Steve Ives
Dec 31 '18 at 9:31
Unfortunately, I don't know if any remote machine is involved. I'm trying to find out if there is.
– Steve Ives
Dec 31 '18 at 9:40
Unfortunately, I don't know if any remote machine is involved. I'm trying to find out if there is.
– Steve Ives
Dec 31 '18 at 9:40
Try the
DIS CONN command many times in a row. Sometimes you will find a client app written that connects, gets, disconnects, repeat. On unix i can run the display in a while true loop and usually catch it, not sure how to do the same on zOS.– JoshMc
Dec 31 '18 at 15:00
Try the
DIS CONN command many times in a row. Sometimes you will find a client app written that connects, gets, disconnects, repeat. On unix i can run the display in a while true loop and usually catch it, not sure how to do the same on zOS.– JoshMc
Dec 31 '18 at 15:00
@JoshMc thnks Josh - did try but never got a hit.
– Steve Ives
Jan 3 at 8:14
@JoshMc thnks Josh - did try but never got a hit.
– Steve Ives
Jan 3 at 8:14
Another detail you can obtain is last put and get time. The setting on the queue is
MONQ. It can be set to QMGR which means to take the value of the QMGR MONQ setting, or it can be set to OFF to turn collection off for that specific queue, or it can be set to LOW/MEDIUM/HIGH which in the words of the knowledge center "here is no distinction between the values LOW, MEDIUM, and HIGH. These values all turn data collection on, but do not affect the rate of collection."– JoshMc
Jan 3 at 8:27
Another detail you can obtain is last put and get time. The setting on the queue is
MONQ. It can be set to QMGR which means to take the value of the QMGR MONQ setting, or it can be set to OFF to turn collection off for that specific queue, or it can be set to LOW/MEDIUM/HIGH which in the words of the knowledge center "here is no distinction between the values LOW, MEDIUM, and HIGH. These values all turn data collection on, but do not affect the rate of collection."– JoshMc
Jan 3 at 8:27
|
show 3 more comments
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.
answered Dec 28 '18 at 13:01
Mark TaylorMark Taylor
126112
1
Mark - are you saying that you cannot issue a GET against a QREMOTE? This appears to be a normal QLOCAL - not a XMITQ and no INITQ or PROCESS defined. I can't see how CHSTATUS will help as I don't know which channel is involved. .If I issue QSTATUS for this queue what can I expect to see that will indicate where the messages are going?
– Steve Ives
Dec 28 '18 at 13:10
add a comment |
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.
answered Dec 28 '18 at 13:01
Mark TaylorMark Taylor
126112
1
Mark - are you saying that you cannot issue a GET against a QREMOTE? This appears to be a normal QLOCAL - not a XMITQ and no INITQ or PROCESS defined. I can't see how CHSTATUS will help as I don't know which channel is involved. .If I issue QSTATUS for this queue what can I expect to see that will indicate where the messages are going?
– Steve Ives
Dec 28 '18 at 13:10
add a comment |
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.
answered Dec 28 '18 at 13:01
Mark TaylorMark Taylor
126112
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.
answered Dec 28 '18 at 13:01
Mark TaylorMark Taylor
126112
answered Dec 28 '18 at 13:01
Mark TaylorMark Taylor
126112
answered Dec 28 '18 at 13:01
Mark TaylorMark Taylor
126112
answered Dec 28 '18 at 13:01
Mark TaylorMark Taylor
126112
126112
1
Mark - are you saying that you cannot issue a GET against a QREMOTE? This appears to be a normal QLOCAL - not a XMITQ and no INITQ or PROCESS defined. I can't see how CHSTATUS will help as I don't know which channel is involved. .If I issue QSTATUS for this queue what can I expect to see that will indicate where the messages are going?
– Steve Ives
Dec 28 '18 at 13:10
add a comment |
1
Mark - are you saying that you cannot issue a GET against a QREMOTE? This appears to be a normal QLOCAL - not a XMITQ and no INITQ or PROCESS defined. I can't see how CHSTATUS will help as I don't know which channel is involved. .If I issue QSTATUS for this queue what can I expect to see that will indicate where the messages are going?
– Steve Ives
Dec 28 '18 at 13:10
1
1
Mark - are you saying that you cannot issue a GET against a QREMOTE? This appears to be a normal QLOCAL - not a XMITQ and no INITQ or PROCESS defined. I can't see how CHSTATUS will help as I don't know which channel is involved. .If I issue QSTATUS for this queue what can I expect to see that will indicate where the messages are going?
– Steve Ives
Dec 28 '18 at 13:10
Mark - are you saying that you cannot issue a GET against a QREMOTE? This appears to be a normal QLOCAL - not a XMITQ and no INITQ or PROCESS defined. I can't see how CHSTATUS will help as I don't know which channel is involved. .If I issue QSTATUS for this queue what can I expect to see that will indicate where the messages are going?
– Steve Ives
Dec 28 '18 at 13:10
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53957355%2fdetermine-the-remote-mq-queue-manager-accessing-our-local-queue%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I don't think you can. Very curious to see if there is a way.
– SaggingRufus
Dec 28 '18 at 11:34
@SaggingRufus Does my interpretation seem correct? All the IBM docs & diagrams I find about using remote queues mamagers talk about remote queues and triggering. Putting messages on local queues and waiting for a GET from a remote QMGR seems not to be discussed.
– Steve Ives
Dec 28 '18 at 12:04
What you describe is basically how I have seen things set up where I work. There are 2 queue, so if you were one putting the messages you would have a queue called XXX_TO_YYY and you may be using a queue manager called MQX1. This would be a local queue for you. When I go to get those messages, I would call a queue called YYY_FR_XXX which could be using a queue manager called MQY1. In this case, the queue I issue the GET to is local to me, and the queue you issue the PUT to is local to you, but your queue is remote to me and my queue is remote to you.
– SaggingRufus
Dec 28 '18 at 12:33
In this type of setup, I don't know if it possible to identify the remote queue or manager as this is all set up within the MQS config (as far as I know at least).
– SaggingRufus
Dec 28 '18 at 12:34