| Author |
Message
|
| mqdev |
 Posted: Wed Jan 27, 2016 10:36 am Post subject: dis qstatus(<q name>) - does this add to IPPROCS or OP |
 |
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
Hello,
If there is a monitoring App periodically pulling IPPROCS and OPPROCS on each Q hosted by a QM, would the monitoring App's PID (process ID) figure in the Qs IPPROCS or OPPROCS?
Since the Monitor is just getting the qstatus, its PID should not be either in IPPROCS (open for GET) or OPPROCS (open for PUT)..but just wanted to confirm and hence the question.
Thanks
-mqdev |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Jan 27, 2016 10:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
What happens when you try it?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| mqdev |
| Posted: Wed Jan 27, 2016 10:54 am Post subject: its too short to determine |
|
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
I am unable to determine definitively as the App is connected only for a fraction of a second to the Q to poll the qstatus and the rest of the time, nothing is connected. One other complication is that my monitor is remotely running - it is not local on the server running QM.
(My App wakes up once a minute, pulls qstats and sleeps until the turn of next minute. Also my monitor is remote to the QM - connects to the QM using MQSC interface, runs the "dis qstatus" command and disconnects - if I were to look for PID on the server running the QM - am not sure what PID to look for - it certainly will not be the PID on the remote server which is running the Monitor)...thoughts? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jan 27, 2016 11:02 am Post subject: Re: dis qstatus(<q name>) - does this add to IPPROCS o |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqdev wrote: |
Hello,
If there is a monitoring App periodically pulling IPPROCS and OPPROCS on each Q hosted by a QM, would the monitoring App's PID (process ID) figure in the Qs IPPROCS or OPPROCS?
Since the Monitor is just getting the qstatus, its PID should not be either in IPPROCS (open for GET) or OPPROCS (open for PUT)..but just wanted to confirm and hence the question.
Thanks
-mqdev |
I should think that qstatus IPPROCS and OPPROCS values are obtained by an MQINQuire call, which is neither an open-for-input (IPPROCS) nor open-for-output (OPPROCS).
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 27, 2016 11:10 am Post subject: Re: dis qstatus(<q name>) - does this add to IPPROCS o |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| mqdev wrote: |
Hello,
If there is a monitoring App periodically pulling IPPROCS and OPPROCS on each Q hosted by a QM, would the monitoring App's PID (process ID) figure in the Qs IPPROCS or OPPROCS?
Since the Monitor is just getting the qstatus, its PID should not be either in IPPROCS (open for GET) or OPPROCS (open for PUT)..but just wanted to confirm and hence the question.
Thanks
-mqdev |
I should think that qstatus IPPROCS and OPPROCS values are obtained by an MQINQuire call, which is neither an open-for-input (IPPROCS) nor open-for-output (OPPROCS). |
That depends on what is being used to get the qstatus.
If it's a PCF message based inquiry, then almost certainly it's not done through an MQInquire call, but through the lower level code that would pass information to an MQInquire code.
Regardless, a second application that does a more frequent qstatus operation should be able to see what happens when the first one gets the qstatus.
Secondarily, I would be horrified to learn that any impact on IPPROCs and OPPROCS occured.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| mqdev |
| Posted: Wed Jan 27, 2016 11:24 am Post subject: |
|
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
| mine is a python script that uses MO72 Supportpac (MQSC interface) to connect to the QM via a MQClient connection and issues a "dis qstatus" command against all Qs on the QM..so it is not using PCF. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 27, 2016 11:35 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Why do you think MO72 isn't using PCF?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| mqdev |
| Posted: Wed Jan 27, 2016 11:38 am Post subject: |
|
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
| Nothing in PCF gives the commandline interface that MQSC provides - so was thinking it maybe PCF-less- but I could be wrong! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 27, 2016 11:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The UI presented has nothing to do with how the program acts.
There isn't a way to send MQSC commands to a non-zos qmgr from a client application.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| mqdev |
| Posted: Wed Jan 27, 2016 11:55 am Post subject: |
|
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
2 questions Jeff:
1. In my situation where the Monitor is remote and connecting through MQClient to QM, the PID of which process on the server running QM, will show in IPPRPOCS or OPPROCS (assuming it does, that is). In other words, what process will be kicked off on the MQ Server for a MQClient connection from a remote App?
2. How can I "continuously" run "dis qstatus" command to catch the fleeting interaction between the Monitor and Qs on the QM? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 27, 2016 12:07 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you want "continuous" statistics about the queue manager or it's objects, you need to use performance events.
You don't want *continuous* though. Generating events or otherwise getting qstatus imposes a performance penalty.
There isn't likely going to be a "new" process kicked off when an MQ client application starts. The listener process will manage establishing the connection and then pass it off to an amqrmma process for work.
As I said, if you really want to see if the monitor task is adding to the IPPROCS or OPPROCS, you need a second task that asks for qstatus - or to look at the event messages. If the time interval of the second task overlaps the first task, then you'll see.
But I find it almost impossible to believe that any reading of qstatus will actually open the queue in question. A very badly written app that does an mqinquire would need to open the queue, unless I've forgotten. But no real tool should.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| mqdev |
| Posted: Wed Jan 27, 2016 12:22 pm Post subject: |
|
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
| thanks for the quick responses Jeff and others...much appreciated! |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Fri Jan 29, 2016 11:50 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Just for completeness since I've only just seen this thread.
MO72 does use PCF messages but it uses a sort of command-line/PCF message hybrid called ESCAPE PCF messages. These PCF messages allow you to put a PCF message which contains essentially one string which contains the MQSC command you want to issue...eg DIS Q(*)
As was discussed already a program getting queue data in this way will not add to the IPPROCS/OPPROCS values. Issuing a DIS Q(*) command does not affect the data returned. If that were the case then it would be impossible to ever get back a zero value for IPPROCS which would not be very useful.
ESCAPE PCF messages are a very handy, and easy, way of issuing remote MQSC commands without all the hassle of pointer arithmetic normally associated with PCF messages. However. parsing the responses to these commands is still tricky!
Regards,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 29, 2016 12:20 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
| A very badly written app that does an mqinquire would need to open the queue, unless I've forgotten. But no real tool should. |
A program that wants to inquire need only MQOPEN the object with MQOO_INQUIRE, which is neither input nor output.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Jan 29, 2016 2:25 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| PaulClarke wrote: |
Just for completeness since I've only just seen this thread.
MO72 does use PCF messages but it uses a sort of command-line/PCF message hybrid called ESCAPE PCF messages. These PCF messages allow you to put a PCF message which contains essentially one string which contains the MQSC command you want to issue...eg DIS Q(*)
As was discussed already a program getting queue data in this way will not add to the IPPROCS/OPPROCS values. Issuing a DIS Q(*) command does not affect the data returned. If that were the case then it would be impossible to ever get back a zero value for IPPROCS which would not be very useful.
ESCAPE PCF messages are a very handy, and easy, way of issuing remote MQSC commands without all the hassle of pointer arithmetic normally associated with PCF messages. However. parsing the responses to these commands is still tricky!
Regards,
Paul. |
Just curious. When I was writing my own PCF inquire program, I first wanted to use the ESCAPE PCF functionality. However, I had to abandon it because it looked like ESCAPE was not supported on z/OS (which we have) and I wanted something I could use against all our queue managers. So I assume MO72 is using something else than ESCAPE PCF for z/OS?
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
|
|
