| Author |
Message
|
| 72dolfan |
 Posted: Wed Jan 31, 2007 11:41 am Post subject: SYSTEM.ADMIN.QMGR.EVENT |
 |
|
Acolyte
Joined: 02 May 2006
Posts: 53
|
Hi All,
I've been reading up on Queue Manager Events and this queue. From what I've been able to obtain, it looks like if a queue manager is started, a message will be written to the SYSTEM.ADMIN.QMGR.EVENT queue. If a qmgr is stopped, a mesage will be written to this queue unless it is z/OS.
I have a in house written queue monitor (monitors z/OS & Windows) that checks a DB2 table for the status of a qmgr (up or down). If the qmgr is active, the monitor/collector will collect stats on that qmgr via PCF commands (Inquire_Q_Status) during that collection cycle (a collection cycle starts every 30 seconds). If the DB2 table shows the qmgr as being down, no PCF commands are issued against that qmgr during that collection cycle.
I wanted to try to add code into the monitor/collector to browse the SYSTEM.ADMIN.QMGR.EVENT queue each time it wakes up to collect stats to see if any messages reside on the queue saying a qmgr was stopped or started. What we find on the queue would dictate whether or not we collect stats for a particular queue manager during that collection cycle.
Since were dealing with Windows and z/OS, and z/OS doesn't seem to put a message on this queue if a qmgr is stopped, I'm wondering if this is still doable.
Anyway, any advice on how the QMGR.EVENT queue process works and if it would work with what I'm trying to do would be greatly appreciated.
Also, is it possible to limit the types of messages that are put to the SYSTEM.ADMIN.QMGR.EVENT queue (like only using this queue if a qmgr is stopped or started, and not for authority, inhibit, local, & remote)?
Thanks!!!!
Bill |
|
| Back to top |
|
 |
| EddieA |
| Posted: Wed Jan 31, 2007 1:06 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
If the QM is down, how are you going to read the Event that says it's down. 
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| 72dolfan |
| Posted: Wed Jan 31, 2007 1:21 pm Post subject: |
|
|
Acolyte
Joined: 02 May 2006
Posts: 53
|
| EddieA wrote: |
If the QM is down, how are you going to read the Event that says it's down.
Cheers, |
That's one of the first questions I asked the folks that wanted us to look into using this method as a means to determining the status of a qmgr. They seemed to think there was a way, but I haven't found it yet.  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jan 31, 2007 1:42 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Magic Server Beans?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| 72dolfan |
| Posted: Wed Jan 31, 2007 1:49 pm Post subject: |
|
|
Acolyte
Joined: 02 May 2006
Posts: 53
|
| jefflowrey wrote: |
| Magic Server Beans? |
 |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Jan 31, 2007 2:55 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| 72dolfan wrote: |
| ... wanted us to look into using this method as a means to determining the status of a qmgr. They seemed to think there was a way, but I haven't found it yet. |
IBM wrote a good program to check what's on queues. It's called . . . . . a queue manager.
Seriously, there are other ways of checking. Eg. Try connecting to the queue manager - and if you can't, it must be down. Hope this helps |
|
| Back to top |
|
|
| pathipati |
| Posted: Wed Jan 31, 2007 4:52 pm Post subject: |
|
|
Master
Joined: 03 Mar 2006
Posts: 296
|
| Quote: |
| Eg. Try connecting to the queue manager - and if you can't, it must be down. |
I think this is not allways true.. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jan 31, 2007 5:11 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It is if you use a bindings connection...
At least, for all intents and purposes it's down.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 01, 2007 1:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pathipati wrote: |
| Quote: |
| Eg. Try connecting to the queue manager - and if you can't, it must be down. |
I think this is not allways true.. |
If it doesn't move, the distinction between "dead" and "comatose" becomes irrelevant...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tleichen |
| Posted: Thu Feb 01, 2007 7:05 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| Vitor wrote: |
| ...If it doesn't move, the distinction between "dead" and "comatose" becomes irrelevant... |
So, now down becomes a relative term?
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 01, 2007 7:28 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
IMHO it's shorthand for "not performing the desired function within the timescales required, with no realistic evidence that the situation will improve in the short term".
Easier than "dead", "unresponsive", "timing out", etc, etc.
For instance, the channel processes are running, the status shows "RUNNING" but messages are backing up in the xmitq and there are FDCs at the receiver end. It may be moving but in my world it's gone down and steps need to be taken. Frankly, if it can't run fast enough to get away it's likely to be shot....
Purely a personal view. Other viewpoints on errors and resolution strategies may be valid.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
