| Author |
Message
|
| tso0rxp |
 Posted: Fri Aug 30, 2002 5:35 am Post subject: Channel autostart |
 |
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
We currently keep channels active at all times. I'm investigating the ability to start channel on receipt of message in transmission queue. I've gotten that to work on a test channel but have a question...
We currently monitor channels for 'up' status and send a page if one goes down. With the autostart this monitor is unnecessary. What if the channel cannot be autostarted by transmission queue trigger? What can I monitor to alert myself of a serious condition?
Thanks in advance. |
|
| Back to top |
|
 |
| Toronto_MQ |
| Posted: Fri Aug 30, 2002 5:54 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
You could always monitor the xmitq depth...
Steve |
|
| Back to top |
|
|
| tso0rxp |
| Posted: Fri Aug 30, 2002 5:57 am Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
| If I check for depth > 0 I would get a page every time a message was sent. I guess I could check for some unusually high number but what if only 1 interface is running at the time - sending 1 message? It would never reach the high count. |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Fri Aug 30, 2002 6:07 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
Then you have yourself a bit of a problem. In our shop we do the same as you, set discint to 0 and always expect the channels to be running, if not then send an alert... We also have automation to restart the channels if they come down.
Most of our channels process a high volume of messages, so much so that it is not uncommon if the is any slowdown in the network to get queueing on the XMITQ. For this reason, we set a queue depth monitor usually to around 100 messages. I can see your problem with channels that do not process many messages, maybe you want to keep those as running always?
Steve |
|
| Back to top |
|
|
| tso0rxp |
| Posted: Fri Aug 30, 2002 6:27 am Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
I would think that IBM gave this some consideration when building the autostart mechanism. 
I guess I have some more research to do.
Thanks for your suggestions. |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Fri Aug 30, 2002 6:55 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
|
| Back to top |
|
|
| tso0rxp |
| Posted: Fri Aug 30, 2002 7:39 am Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
Jorgen,
I have the channel set to autostart - and it works just fine. My question is really how do I know if the autostart does not work when I send data to the transmission queue? I realize there are times when the remote system is down and the channel won't start. Those situations I'll be aware of. The situation I'm concerned with is Sender QMGR and Receiver QMGR are both up but the autostart of the sender channel does not work for some reason.
Are there reasons why the autostart will fail - other than the remote server being down?
Forgive all of this confusion on my end. I thought I discovered a way to cut down on the overhead of channels being active all the time. I just do not want to cause any other problems in doing so.
btw, this is a great site for MQ Series discussion. Much thanks to Brandon for his work here. |
|
| Back to top |
|
|
| tso0rxp |
| Posted: Fri Aug 30, 2002 7:43 am Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
I just thought of something after my last post.
I notice that when the channel hits the DISCINT it goes to 'inactive' and when it processes a message it goes to 'running'. Would a check for 'stopped' be appropriate for autostart channels? |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Fri Aug 30, 2002 8:03 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Well, what tell my customers is keep track on the SYSTEM.ADMIN.xxx.EVENT queues with a automation tool.
Another thing I allways change is the TRIGINT, typicly I reduce it to 1-10 minutes depending on the situation. 
This is because the qmgr will report failures on the channel this way, nice and easy....
I guess there are even a supportpack that can be used to monitor the EVENT queues. My major customers are using Mainview and similar tools for the monitoring job.
Well the "STOPPED" state for a channel is legal, because it's the only way operation can stop a channel f.ex. there are problems and we want to do something, or our partner is having a problem let's say a upgrade of software and don't want to receive messsages in the same second he's starting the qmgr.....
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| tso0rxp |
| Posted: Fri Aug 30, 2002 8:39 am Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
Great suggestions.
What do you typically set the trigger_type field to - first or every?
Also, TRIGINT. Can you describe this field further? |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Fri Aug 30, 2002 9:34 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
1) A channel will only ever be in a STOPPED state if it is manually stopped by someone or something
2) set triggering to FIRST for xmitqs, otherwise you will have a lot of overhead
Steve |
|
| Back to top |
|
|
| Glen Shubert |
| Posted: Fri Aug 30, 2002 12:37 pm Post subject: |
|
|
Apprentice
Joined: 16 May 2001
Posts: 42
Location: TSYS - Columbus, GA
|
We monitor all of our channels, but only issue an alert on STOPPED, BINDING, RETRY, and INIT. If a channel is INACTIVE or RUNNING, all is well.
_________________
Glen Shubert
Associate Director
MQSeries Technical Support
TSYS |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Aug 31, 2002 12:50 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
|
|
