| Author |
Message
|
| noman |
 Posted: Thu Jun 24, 2010 1:00 pm Post subject: Missing alert when a channel goes goes straight from inactiv |
 |
|
Newbie
Joined: 24 Jun 2010
Posts: 4
|
well, here is thing.
i got a problem with MQ event monitoring.
When a channel goes straight from an inactive state to a retrying state I do not see any msg in SYSTEM.ADMIN.CHANNEL.EVENT.
Is there any way to fix the issue?
i read about undocumented feature
StopEvent=ALWAYS
but as IBM support said:
"This is issued when a channel instance stops. It will only be issued if the channel instance previously issued a start event "
it's really important for me to be alerted in that case.
Any ideas? thanks for any answer |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jun 24, 2010 1:32 pm Post subject: Re: Missing alert when a channel goes goes straight from ina |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| noman wrote: |
| it's really important for me to be alerted in that case. |
Why? If there's a transitory problem the channel will fix itself before you can react.
If it's important to you that a channel doesn't sit in retry "too long", why not amend the retry intervals to stop the channel & raise an event from that?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Jun 24, 2010 3:48 pm Post subject: Re: Missing alert when a channel goes goes straight from ina |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| noman wrote: |
| it's really important for me to be alerted in that case. |
Why?
| Vitor wrote: |
| If there's a transitory problem the channel will fix itself before you can react. |
Agree. Most channels go into retry status because the remote end is unavailable due to a network or system outage. Assuming these are critical resources for other reasons, they will come back soon. The MQ channel will retry again, becoming running, and all will be good in the world again.
_________________
Glenn |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 24, 2010 7:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And if you are planning for a monitoring application, you might want to consider polling for channel status every so often with a pcf message. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Jun 25, 2010 8:50 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
And updating your stanzas to:
| Code: |
TCP:
KeepAlive=yes
ListenerBacklog=256
#*
Channels:
MaxChannels=2000
MaxActiveChannels=2000
AdoptNewMCA=ALL
AdoptNewMCATimeout=60
AdoptNewMCACheck=ALL
|
Will also help the channels restart faster. Well, not the Max part but I left it there for you to gaze at. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 25, 2010 9:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
There have been many, many discussions here about channel availability. Search for a doc called something like 'Channels: up and running'.
Look at the WMQ Intercommunications manual for channel status.
RUNNING state indicates that the channels is currently transmitting a message, OR that it believes it can transmit a message when one arrives in an xmit queue. It won't know for sure until it next tries to transmit the message. If it can't transmit, it will go into RETRY - and succeed or fail the retry counts/intervals.
So, if you are trying to discover with absolute precision whether a channel can transmit a message, then (attempt to) transmit one. But keep in mind the next attempt might fail; or the next, next attempt might fail.
_________________
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 |
|
|
| zonko |
| Posted: Sun Jun 27, 2010 10:46 pm Post subject: |
|
|
Voyager
Joined: 04 Nov 2009
Posts: 78
|
| Quote: |
Since APAR IC29815, in MQ 5.2 CSD04, no channel stop event is written
for a channel which has not started, i.e. a failure to start a channel
causing the channel to go into RETRYING status does not generate a
channel event.
.
Here is the comment from IC29815:
.
A stop channel event will only be written if the channel program itself
had already written a start channel event. The reason for this is that
the event written by runmqsc signals a change in status of the channel,
and the events written by the channel are concerned with specific
instances of the channel being started and stopped.
.
The effect of this APAR is that the event message is only written when
the channel is successfully started. If the channel fails to start and
a message is logged that the channel is stopped, then the stop event
will not in that case be written. There is no correspondence between
the log entries and the event messages.
.
There is a tuning parameter which will restore the previous behaviour.
Add these lines to the qm.ini file:
.
Channels:
StopEvent=Always
.
The stop event will be generated as required |
|
|
| Back to top |
|
|
|
|
