| Author |
Message
|
| PeterPotkay |
 Posted: Mon Apr 21, 2003 5:19 am Post subject: Channel Status after QM is bounced |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I have some SNDR/RCVR channels that needed to have a very large disconnect interval set. As a result, 99.9% of the time they are in RUNNING status. I am trying to configure some monitoring tools that watch the channel status and was wondering about the following. If a channel is in RUNNING, and one of the QMs is shutdown and then brought back up, what will the status of the channel be once the QM is back up?
My testing seems to show that if the receiving QM is the one bounced, the SNDR channel goes to RETRYING during the outage (no surprises there), and automatically goes right back into RUNNING status when the RCVR comes back. Nice. But if the SNDR QM is the one bounced, then the previously RUNNING channel comes back up as INACTIVE.
Is this behavior documented anywhere?
Is it consistent among all platforms (distributed and mainframe)?
And so even if I really want my channel status as RUNNING, my monitor needs to accept a status of RUNNING and INACTIVE as OK, to handle the case where the SNDR gets bounced.
We do not want to have to "prime" the channel with a dummy message by the app to get it back to RUNNING after an outage. Also, we do not want MQ support to have to get involved by manually changing the channel from INACTIVE to RUNNING. This is why I am considering allowing INACTIVE. (I understand INACTIVE is a "good" state for a channel to be in. The problem was that an application area originally requested this monitoring in this fashion and I think I need to allow INACTIVE, even though the requirement is to have the channel in RUNNING always).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| MichaelR |
| Posted: Mon Apr 21, 2003 5:44 am Post subject: RE: Channel status after QM is bounced.... |
|
|
Apprentice
Joined: 20 May 2002
Posts: 37
Location: Tampa
|
Peter,
Don't think the scenario is "documented" anywhere but the scenario you describe makes complete sense (to me at least).
In the first scenario:
The SDR channel reflects "retrying" because its retry limits have not yet "expired". As such, when the remote MQM becomes available, the SDR automatically connects.
In the second scenario:
The SDR channel is in fact INACTIVE as no activity exists or has been "triggered". This would be the same state if the DSCINT value have been satisfied as well.
In our environment we also treat INACTIVE as a "normal" channel state. Does it make sense for your monitor to execute an instruction to start "inactive" channels? Not sure what redeaming value this provides beyond a trigger other than satisfying your users requirements.
MichaelR
 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Apr 21, 2003 6:23 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I agree with scenario 1.
For scenario 2, I would say that the DISCINT was never reached, irrespective of the QM bounce. So when the QM comes back up, the SNDR should go right back to decrementing its DISCINT from where it was prior to the bounce. Just my logic; I understand that this is probably not coded that way unfortunatly.
fyi
The reason for the always running channel is that these channels are
dedicated for a multi-hop application (z/OS to MQSI/Windows to Java/Solaris and back) that needs its request/reply in less than a second. Triggering and starting the channels puts us over that time limit usually.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MichaelR |
| Posted: Mon Apr 21, 2003 6:53 am Post subject: Channel status after reboot.... |
|
|
Apprentice
Joined: 20 May 2002
Posts: 37
Location: Tampa
|
Interesting view regarding scenario #2. Not a bad idea. Would be nice if IBM added some sort of "autostart" option for SDR channels at MQM "boot" time. This could probably be done (easily?) for those SDR channels with a DSCINT of "0".
 |
|
| Back to top |
|
|
| tillywern |
| Posted: Mon Apr 21, 2003 9:20 am Post subject: UNIX? |
|
|
Centurion
Joined: 28 Jan 2003
Posts: 109
Location: Colorado
|
If your systems are UNIX/LINUX then creating a script to autostart channels is easy. Actually it sounds to me that you need a better monitoring tool... At least one that knows what state channels are in and attempts to resolve simple issues before notifying a central console.
If you want to script this in UNIX you can use simple ksh facilities.
I would would "dis chs(*)" into runmqsc and pipe to grep for not(-v) RUNNING. Then you have a list of channels that are not running. Pipe to SED to get the names of the channels only...
Embed this logic in a ksh "for" loop wiith logic for RESET and RESOLVE situations.
Doing ths on NT or 390 is a bit more trickey... Easy with Perl on NT but on 390 I don't have a solutione. |
|
| Back to top |
|
|
| MichaelR |
| Posted: Mon Apr 21, 2003 9:50 am Post subject: |
|
|
Apprentice
Joined: 20 May 2002
Posts: 37
Location: Tampa
|
Thanks for the info...I would prefer to use PCF commands to resolve such a need as this provides a more platform agnostic solution.
Incidently, while I'm sure there are many other ways to automate channel start up, I think the original "post" was more about the behavior of SDR channels after an MQM re-boot. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Apr 21, 2003 9:54 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
thanks for the thoughts tillwern. Actually our monitoring tool can kick of a script (to perhaps drop a PCF message). That may be worth exploring. Anything to save a page in the middle of the night for no good reason!!!
But it would be nice if MQ could do this out of the box (SNDR channel picks up where it left off). Seems reasonable unless I am missing something.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 01, 2003 11:41 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
To start channels on Windows as a service, which means that whenever the QM is bounced, the channel comes up in RUNNING, and then starts counting down its DISCINT from scratch, if you had it set:
1.) Open MQ Services (Start --> Programs --> MQ --> MQSeries Services)
2.) Right click on the queue manager where the sender channels are configured.
3.) Go to New, then select Channel.
4.) On the Parameters tab enter the sender channel name. On the General tab, for startup type select automatic.
The neat thing I noticed here is that if you stop the service, it puts the channel into INACTIVE mode. I know of no other way to force a channel into this mode short of waiting until DISCINT expires.
Still researching Solaris and z/OS, but looks like scripts are the way for Solaris and Started Tasks (?) for z/OS will work.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
