| Author |
Message
|
| jfbaro |
 Posted: Mon Feb 01, 2010 9:27 am Post subject: Monitoring if the remote queue is still one |
 |
|
Novice
Joined: 05 Jun 2009
Posts: 10
|
Hi,
We are using MQ to transfer messages to a service provider which is miles from us.
How can we monitor (giving reports through a third party too) when the connection to that service provider is not running?
Can I do that through Java? Or is there anything out-of-the-box to be used?
Cheers |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Feb 01, 2010 9:39 am Post subject: Re: Monitoring if the remote queue is still one |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jfbaro wrote: |
| How can we monitor (giving reports through a third party too) when the connection to that service provider is not running? |
Channel status will tell you if the connection fails.
Channel status can be monitored by any of the usual suspects in terms on monitoring tools (and most WMQ-aware monitoring tools monitor channel status by default), by a Java app issuing PCF commands, a script or a variety of other methods.
The same would be true if the target of the connection was a box physically ajacent to the source, or the other side of the world.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rjl_state |
| Posted: Wed May 19, 2010 11:04 am Post subject: |
|
|
Apprentice
Joined: 04 Oct 2002
Posts: 48
Location: Des Moines, IA
|
You could write a simple program to monitor the queue depth of the transmit queue your remote queue is pointing to. If the progam monitors the sequence number of the mesasges in the queue they shouldn't be the same between runs. It could alert if the depth gets too high, that value will be different depending on how busy the queue is.
It has been my experience that your monitor program will get a "get inhibited" error message when the sending channel goes down. If you are able to send alerts based on getting this error and on getting the queue depth high, you will know when the other side is down before they know it. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 19, 2010 5:49 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| rjl_state wrote: |
| It has been my experience that your monitor program will get a "get inhibited" error message when the sending channel goes down. If you are able to send alerts based on getting this error and on getting the queue depth high, you will know when the other side is down before they know it. |
Any monitoring program that gets a get inhibited error (and then worse yet alerts you on that) when a sending channel goes down is not written properly.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| rjl_state |
| Posted: Tue May 25, 2010 10:26 am Post subject: |
|
|
Apprentice
Joined: 04 Oct 2002
Posts: 48
Location: Des Moines, IA
|
| PeterPotkay wrote: |
Any monitoring program that gets a get inhibited error (and then worse yet alerts you on that) when a sending channel goes down is not written properly. |
I would normally bow to your experience, but that what I am saying is correct for transmit queues. When the channel goes into a RETRY state the corresponding transmit queue is set to GET(DISABLED).
Quoted from a manual:
"For sending channels, the associated transmission queue is set to GET(DISABLED) and triggering is turned off."
 |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue May 25, 2010 11:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| rjl_state wrote: |
| PeterPotkay wrote: |
Any monitoring program that gets a get inhibited error (and then worse yet alerts you on that) when a sending channel goes down is not written properly. |
I would normally bow to your experience, but that what I am saying is correct for transmit queues. When the channel goes into a RETRY state the corresponding transmit queue is set to GET(DISABLED).
Quoted from a manual:
"For sending channels, the associated transmission queue is set to GET(DISABLED) and triggering is turned off."
|
It may be accurate, but it's not a good way to monitor channel status.
You should, you know, be monitoring the status of the channel.
Not making educated guesses about why the xmitq is get-disabled. |
|
| Back to top |
|
|
| wschutz |
| Posted: Tue May 25, 2010 12:47 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
and of course we're all assuming its a qmgr-qmgr connection and not a client connection to your service provider, since you didn't say which type it was.
_________________
-wayne |
|
| Back to top |
|
|
| rjl_state |
| Posted: Wed May 26, 2010 6:56 am Post subject: |
|
|
Apprentice
Joined: 04 Oct 2002
Posts: 48
Location: Des Moines, IA
|
[quote="mqjeff"][quote="rjl_state"][quote="PeterPotkay"]
Any monitoring program that gets a get inhibited error (and then worse yet alerts you on that) when a sending channel goes down is not written properly.[/quote]
I would normally bow to your experience, but that what I am saying is correct for transmit queues. When the channel goes into a RETRY state the corresponding transmit queue is set to GET(DISABLED).
Quoted from a manual:
"For sending channels, the associated transmission queue is set to GET(DISABLED) and triggering is turned off."
[/quote]
It may be accurate, but it's not a good way to monitor channel status.
You should, you know, be monitoring the status of the channel.
Not making educated guesses about why the xmitq is get-disabled.[/quote]
You are correct it is not a good way to monitor a sender channel's status, but it is a simple way to do it. Not everyone has done PCF programming, but everyone knows how to do a GET from a queue.
If you do a periodic GET on the transmit queue, it should be empty or if there are messages in the queue they shouldn't be there the next time you check the queue. Also if you do receive a GET INHIBITED error on the queue you could alert on that error that SOMETHING is wrong. In my experience the SENDER CHANNEL is RETRYING. In both instances the connection you wanted to monitor is not working properly and someone should be notified.
There are multiple ways to attack any problem. This is not the perfect solution, but better than none at all.
If you work on a common platform that has good third party vendor tools for monitoring and reporting consider yourself lucky and purchase those tools.  |
|
| Back to top |
|
|
| mvic |
| Posted: Wed May 26, 2010 8:19 am Post subject: Re: Monitoring if the remote queue is still one |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| jfbaro wrote: |
How can we monitor (giving reports through a third party too) when the connection to that service provider is not running?
Can I do that through Java? Or is there anything out-of-the-box to be used? |
DISPLAY CHSTATUS
This will tell you a moment-in-time status, and a number of messages transferred each time you run it.
You can program PCF to do this programmatically, as long as you have a command server running. Another "simple" approach would be to run the runmqsc program and collect and parse its stdout. It's simple and probably good enough for many people.
How often do you need to measure these items?
Also ensure you have big files under /var/mqm/qmgrs/MYQM/errors and keep backups as those files roll over. They will help you if you need to reconstruct a timeline of what failed, and when, and for what reason, and when it retried, and any failures on retry.
UPDATE: Before anyone mentions it, I know I am not the first to mention using channel status, but IMHO the thread was getting OT, and we had not heard back from the OP what he thought of this most useful suggestion. So I thought, what's the harm in re-stating it.  |
|
| Back to top |
|
|
|
|
