ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexIBM MQ Performance Monitoringdis qstatus(<q name>) - does this add to IPPROCS or OP

Post new topicReply to topic Goto page 1, 2  Next
dis qstatus(<q name>) - does this add to IPPROCS or OP View previous topic :: View next topic
Author Message
mqdev
PostPosted: Wed Jan 27, 2016 10:36 am Post subject: dis qstatus(<q name>) - does this add to IPPROCS or OP Reply with quote

Centurion

Joined: 21 Jan 2003
Posts: 109

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
View user's profile Send private message
mqjeff
PostPosted: Wed Jan 27, 2016 10:41 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

What happens when you try it?
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
mqdev
PostPosted: Wed Jan 27, 2016 10:54 am Post subject: its too short to determine Reply with quote

Centurion

Joined: 21 Jan 2003
Posts: 109

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
View user's profile Send private message
bruce2359
PostPosted: Wed Jan 27, 2016 11:02 am Post subject: Re: dis qstatus(<q name>) - does this add to IPPROCS o Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8032
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 would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Wed Jan 27, 2016 11:10 am Post subject: Re: dis qstatus(<q name>) - does this add to IPPROCS o Reply with quote

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
View user's profile Send private message
mqdev
PostPosted: Wed Jan 27, 2016 11:24 am Post subject: Reply with quote

Centurion

Joined: 21 Jan 2003
Posts: 109

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
View user's profile Send private message
mqjeff
PostPosted: Wed Jan 27, 2016 11:35 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Why do you think MO72 isn't using PCF?
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
mqdev
PostPosted: Wed Jan 27, 2016 11:38 am Post subject: Reply with quote

Centurion

Joined: 21 Jan 2003
Posts: 109

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
View user's profile Send private message
mqjeff
PostPosted: Wed Jan 27, 2016 11:42 am Post subject: Reply with quote

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
View user's profile Send private message
mqdev
PostPosted: Wed Jan 27, 2016 11:55 am Post subject: Reply with quote

Centurion

Joined: 21 Jan 2003
Posts: 109

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
View user's profile Send private message
mqjeff
PostPosted: Wed Jan 27, 2016 12:07 pm Post subject: Reply with quote

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
View user's profile Send private message
mqdev
PostPosted: Wed Jan 27, 2016 12:22 pm Post subject: Reply with quote

Centurion

Joined: 21 Jan 2003
Posts: 109

thanks for the quick responses Jeff and others...much appreciated!
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Fri Jan 29, 2016 11:50 am Post subject: Reply with quote

Guardian

Joined: 17 Nov 2005
Posts: 902
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
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Fri Jan 29, 2016 12:20 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8032
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 would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
tczielke
PostPosted: Fri Jan 29, 2016 2:25 pm Post subject: Reply with quote

Yatiri

Joined: 08 Jul 2010
Posts: 693
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?
_________________
MQ administrator since 2010.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexIBM MQ Performance Monitoringdis qstatus(<q name>) - does this add to IPPROCS or OP
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.