| Author |
Message
|
| mikegrove |
 Posted: Thu Aug 09, 2007 7:38 am Post subject: get process ID's for InputCount |
 |
|
Novice
Joined: 02 Jul 2007
Posts: 11
|
How do I get the process id's associated with the apps that have a queue open for input. I have found IPPROCS and dis qstatus(local queue name) type(handle) all
But it is all greek to me.
Can this be done from the v5.3 MQ Explorer or a windows command prompt? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Aug 09, 2007 7:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You should be migrating to v6.
In v6 one can do "dis conn".
A bit of searching around here will find you some options for v5.3.
But you should be migrating to v6. v5.3 goes out of support *soon*.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Aug 09, 2007 7:43 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, as a more general note.
If you are having to reverse engineer things like this - then likely you do not have enough process control on your environment as you should.
It should be clearly documented that app A will connect to queue 1 for it's input. And output to queues 2, 3 and 4.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Aug 09, 2007 7:54 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| jefflowrey wrote: |
If you are having to reverse engineer things like this - then likely you do not have enough process control on your environment as you should.
It should be clearly documented that app A will connect to queue 1 for it's input. And output to queues 2, 3 and 4. |
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| mikegrove |
| Posted: Thu Aug 09, 2007 8:56 am Post subject: Process Id's |
|
|
Novice
Joined: 02 Jul 2007
Posts: 11
|
We have a process that shuts down gracefully and is no longer visible in task manager, but we still have an inputcount > 0 and no other processes should be accessing this queue. Consequently the trigger never fires because something has the queue open and we don't know what.
1) We are moving to 6, all 50+ servers, but, in the mean time we have a problem that needs to be addressed that I don't want to bet the farm on v6 automagically fixing.
2) We are not reverse engineering anything, just trying to troubleshoot what is going on. We have clearly documented that we have 1 input queue and 1 process that is started by a First trigger to proces the messages. Our process control is extremely tight, documented verbosely and with diagrams, and audited by SOX 4 times a year.
Unfourtunately every now and then, regardless of our documentation, the messages start backing up, the app that processes the messages is not running and the InputCount is 2. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Aug 09, 2007 9:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well.
Either, mysteriously and miraculously a non-existent process still has an open connection... or some process that is not supposed to be allowed to connect to your queue is in fact connecting to your queue.
Again, there's a post from dgolding that documents a 'backdoor' way to find information about connections in v5.3.... unless I'm remembering it wrong and it has to do with channel connections...
Also, if you know that it's a client connection and not a bindings connection, then you can stop the SVRCONN and see what starts throwing errors.
If it's a bindings connection, then you should be able to figure out what process is running - that shouldn't be - in Task Manager.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mikegrove |
| Posted: Thu Aug 09, 2007 9:27 am Post subject: Processes |
|
|
Novice
Joined: 02 Jul 2007
Posts: 11
|
Thanks much.
I am on an island with the only 3 windows Webshere MQ boxes in the company, no training other than what I have read and sometimes it's faster to get an answer here than from our MQ admins, and then it is 'this is how you do it on Unix or an iSeries'  |
|
| Back to top |
|
|
|
|
