| Author |
Message
|
| jcv |
 Posted: Mon Jul 23, 2007 4:51 am Post subject: SHORTRTY count number elapsed |
 |
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Jul 23, 2007 6:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Potentially valuable as an early warning I suppose.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 23, 2007 1:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I don't see the advantage of it.
Whenever a channel is in "RETRY" you have to investigate anyway. If you don't want to see it in retry you can stop it and restart it once the situation is resolved...
We investigate and leave it in retry until resolved....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jcv |
| Posted: Tue Jul 24, 2007 12:06 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| The question implies you don't have a channel event to notify you about channel going into retrying state, as well, meaning that without a monitoring tool based on Real-time monitoring features, MQ admin cannot be initiator of such investigations (performed by network crew) unless he limits retry attempts. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Jul 24, 2007 12:35 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
| you don't have a channel event to notify you about channel going into retrying state |
The stop channel event is written when a RUNNING channel goes into RETRYING status. If a channel fails to start and goes to RETRYING immediately, the event is not now written, since APAR IC29815 introduced in MQ 5.2 CSD04.
The stop event will be written if the line StopEvent=ALWAYS is added to the Channels stanza of qm.ini.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 24, 2007 2:03 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
One of the nice features in MQSC in v6 is the ability to say "dis chs(*) where(status ne RUNNING)".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Jul 25, 2007 4:42 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| Nigelg wrote: |
| The stop channel event is written when a RUNNING channel goes into RETRYING status. |
That's absolutely counterintuitive. Why reporting the occurrence of one status, by writing the event message named after occurrence of another status? Such a naming convention doesn't sound like a sound practice. Is this behaviour documented somewhere in Information center for v6?
From the list of channel events:
| Quote: |
Channel Activated
Channel Auto-definition Error
Channel Auto-definition OK
Channel Conversion Error
Channel Not Activated
Channel Started
Channel Stopped
Channel Stopped By User
|
I would never guess which event is written when a RUNNING channel goes to RETRYING status, if I didn't receive this reply.
I couldn't conclude it also from detailed description of "Channel Stopped" event (which is I assume the same as Nigelg's "The stop channel event"):
| Quote: |
Reason code in MQCFH: MQRC_CHANNEL_STOPPED (2283, X'8EB').
Channel stopped.
Event description: This is issued when a channel instance stops.
It will only be issued if the channel instance previously issued a channel started event. |
Other people already performed tests in order to get clean picture about how it works:
http://www.mqseries.net/phpBB2/viewtopic.php?p=164385
I have learned here, that at least two event messages may be written with the same reason code MQRC_CHANNEL_STOPPED: when channel goes from RUNNING to RETRYING status, and when channel goes to STOPPED status. How shall I distinguish between them? I will reach that conclusion by performing my own test, but I would appreciate the answer anyway.
Search for StopEvent (introduced in v5.2) in Information center for v6, gave me "Nothing found". Why is that?
Someone even called it "hidden parameter":
http://www.mail-archive.com/mqseries@akh-wien.ac.at/msg18309.html |
|
| Back to top |
|
|
| jcv |
| Posted: Thu Jul 26, 2007 2:12 pm Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| jcv wrote: |
| That's absolutely counterintuitive. |
Actually, that's an understatement. It's logically wrong. RETRYING and STOPPED are defined as two distinct statuses at the same level, why mixing them?
| jcv wrote: |
| How shall I distinguish between them? |
Obviously, with ReasonQualifier.
| Quote: |
MQRQ_CHANNEL_STOPPED_OK
Channel has been closed with either a zero return code or a warning return code.
MQRQ_CHANNEL_STOPPED_ERROR
Channel has been closed but there is an error reported and the channel is not in stopped or retry state.
MQRQ_CHANNEL_STOPPED_RETRY
Channel has been closed and it is in retry state.
MQRQ_CHANNEL_STOPPED_DISABLED
Channel has been closed and it is in a stopped state.
|
If there is only one thing common for all 4 cases, I would call the event CHANNEL_CLOSED. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 26, 2007 3:37 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jcv wrote: |
| If there is only one thing common for all 4 cases, I would call the event CHANNEL_CLOSED. |
And can you explain the difference between a "closed" channel, and a "stopped" channel?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jcv |
| Posted: Fri Jul 27, 2007 9:06 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
I suggest you to ask that the author of ReasonQualifier descriptions. I hope he knows it. I have just lexically recognized the common token.
I'm reasoning now in purely abstract manner.
Just looking at the names of ReasonQualifiers, without knowing their descriptions, and knowing from the abstract model of channel states (presented by certain hierarchy and flow diagramms) nothing but the fact that STOPPED is defined as a certain channel state, I would suppose that OK, ERROR, RETRY and DISABLED are some substates of STOPPED state.
Knowing both this model (that such substates are not defined) and ReasonQualifier descriptions, I know that's not true.
Does this model describe that channel is always in some known state? I believe that would be logical.
How come is that state in first case totaly irrelevant in order to describe what does the event actually mean, in second case it is less irrelevant, to that extent that certain states are mentioned in which channel doesn't end up, and in the rest of cases we know precisely in which state channel ends up?
And when such an effort is already made to build this model, I'd say that one of its crucial parts is: the exact terms which are chosen to be assigned to each and every one state and substate, as their names. You don't give names to things in such context, just to say afterwards that some name be replaced with some other, or maybe with dozen others, you give this names in order to stick to them strictly and precisely.
Now you tell me, are "closed" channel and "stopped" channel, the same thing? You understand that details of channel implementations are hidden from me, that would be another reason for you to explain that to me.
On the other hand, if you consider channel state model totaly irrelevant to describe the behaviour of the product, why presenting it at all?
And finally, consider these two sentences:
"I have received an event message with reason code MQRC_CHANNEL_STOPPED, with reason qualifier MQRQ_CHANNEL_STOPPED_OK, now I know that my channel is in BINDING state."
or
"I have received an event message with reason code MQRC_CHANNEL_STOPPED, with reason qualifier MQRQ_CHANNEL_STOPPED_ERROR, now I know that my channel is in REQUESTING state."
I realize that given the ReasonQualifiers descriptions, even this statements may be true. It just don't make any sense to me. But, I'm obviously missing something again.  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 27, 2007 9:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I don't have any privileged or special knowledge on channels. I don't know who wrote the ReasonQualifier descriptions. I don't know that they/it were written by a "he".
I don't know that the author would choose to converse with me, nor do I believe that the author would choose to discuss this with me.
Everything I know about channels, I know from reading the Info Center.
My main point is, the event is "channel stopped". The channel is stopped - regardless of why. It's not running any more. So the event is correct. The channel is, actually, stopped.
It might not be in the STOPPED channel state. But, in pure abstract reasoning, it's stopped.
Is it really worth your time and effort to concern yourself with this? Having once learned that the event is not what you thought it was, isn't it easier to go back to getting stuff done?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jcv |
| Posted: Fri Jul 27, 2007 9:57 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Gender of the author is totaly irrelevant detail in the whole story. I don't know it either, so it was mistake to write "he".
I have spoted something I didn't find logical, and I said that. No harm done. It was just out of pure intelectual curiosity, and I still hope to get some explanation.
Of course that my main (vital) concern is to choose proper (most suitable) monitoring tool for my site.
As for this topic, now that I have learned basic facts about events, the question still stands. Vitor said it might be reasonable to fit in this schema another reason qualifier, because, if I understand Vitor correctly they don't utilize this event when channel goes from running to retrying state, because they don't want to react to every network short term problem.
fjb_saper said they do utilize something which notifies them immediately of channel being in retry state, so that fjb_saper does not consider this idea especially usefull. If noone else has anything to add, I guess that's it. |
|
| Back to top |
|
|
| jcv |
| Posted: Tue Jul 31, 2007 10:00 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Nigelg, would you mind telling me please, in which state is channel exactly, when it's stopped, and is not in stopped or retry state. I guess, perhaps INACTIVE? But why guessing when there is someone who knows. Another unanswered question remained:
| Quote: |
And can you explain the difference between a "closed" channel, and a "stopped" channel? |
Where is this difference documented? It must be somewhere, because new expressions shouldn't be introduced into documentation, without describing their precise meaning. Thanks. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 31, 2007 11:02 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You're the one that introduced the phrase "closed" channel.
I'm saying that if a channel has changed from "Running" to any other state, then it's reasonable to call the event that notifies of this a "stop" event - as the channel is now "stopped" in the sense that no more messages are flowing.
It would likewise be reasonable if there were Events thrown for each actual channel state - that when a channel went into "Retrying", then a "Channel Retry" event was created. But that's not what is being done.
I don't have anything more to say on this subject.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jcv |
| Posted: Thu Aug 02, 2007 7:51 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| jefflowrey wrote: |
You're the one that introduced the phrase "closed" channel.
|
IBM introduced the phrase "has been closed". There is no reason to insist now on the difference between phrases "closed" and "has been closed", and at the same time alow saying that channel is "stopped" whenever messages are not flowing.
| jefflowrey wrote: |
I'm saying that if a channel has changed from "Running" to any other state, then it's reasonable to call the event that notifies of this a "stop" event - as the channel is now "stopped" in the sense that no more messages are flowing.
|
I have understood what you're saying when you said that for the first time. It was clear to me even before you started to defend this logic.
And you have understood I don't agree with that, because in that case:
a) reasonable name for event would be "Channel not running" to avoid confusion with channel "stopped" state
b) event description should explicitly state so, instead of what it actually says
There is no reason to repeat this, ever again.
| jefflowrey wrote: |
It would likewise be reasonable if there were Events thrown for each actual channel state - that when a channel went into "Retrying", then a "Channel Retry" event was created. But that's not what is being done.
|
On the contrary, this argument of yours is now introduced here for the first time. I don't see why would Events throwing for each actual state be neccessary to justify the fact, that when a channel goes into "Retrying" state, "Channel Retry" event could have been created instead of "Channel stopped". Absence of "Channel Binding" event doesn't mind, and has nothing to do with that fact. As well as the existence of events which are not thrown as a result of changing states. If the whole point is to understand and accept what's being done, let's never repeat it again.
| jefflowrey wrote: |
I don't have anything more to say on this subject. |
I could add several more points to this discussion, but noone seems to care. I can't let you to convince me of something which is not logical. |
|
| Back to top |
|
|
|
|
