| Author |
Message
|
| spellman |
 Posted: Thu Aug 08, 2002 5:33 pm Post subject: Pros and cons for DISCINT zero ? |
 |
|
Newbie
Joined: 17 Jun 2002
Posts: 3
|
It seems that specifying a DISCINT of zero provides less opportunities for communications mishaps and transmit queue triggers being set to OFF.
Is there any reason to set the disconnect interval for channels to anything but zero? We arre trying to adopt a standard, and any response would be appreciated.
- spellman |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Thu Aug 08, 2002 7:26 pm Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well I have been at companies that have done both and it doesnt seem
to be problem either way
By keeping the channels up you are increasing the chance that any small network glitch will cause a channel to going retry, if the glitch is short it will
recover.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| mgrabinski |
| Posted: Thu Aug 08, 2002 9:47 pm Post subject: |
|
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
If a channel is transfering messages very often, it's no point in closing it and opening again. On the other nand, if there not so many messages, it will be better to start the channel when needed.
I'm using fuzzy logic - it's up to you to define "often" and "many" 
_________________
Marcin Grabinski <>< |
|
| Back to top |
|
|
| spellman |
| Posted: Fri Aug 09, 2002 8:55 am Post subject: |
|
|
Newbie
Joined: 17 Jun 2002
Posts: 3
|
Thank you, Jeff and Marcin.
We will standardize on Allways-running, untill we run into something that makes this choice unwise.
------------ |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Aug 12, 2002 6:36 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
When a channel is running, and you send a message from QM1 to QueueB an QM2,
the MCA on QM2 opens up QueueB to put the message there. It then leaves
QueueB Open-For-Output (puts) until the channel shuts down, correct? If this
is so, now QueueB has a permanent OPROCS count of 1. Soon, all of your
queues on QM2 that take messages from remote QMs now have OPROCS of 1.
Can this pose a problem? I know you can't do some Admin-type things to
queues that are open, like issuing a clear queue command.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Mon Aug 12, 2002 6:48 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Peter, on Z/OS I've seen it work in another way... :
It looks like the channel initiator holds the queue open for a long time, but not as long as channel is running... just about 30 minutes without data... 
So it seems to me that the channel initiator is pretty clever, is optimizes the use of holding the queues open for limited time to avoid spending resources calling SAF and all the other things that are implied in opening a queue.
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 |
|
|
| mrlinux |
| Posted: Mon Aug 12, 2002 6:50 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
The channel has some form of timeout where it will close the queue connection, I have in the passed tried sending messages to a test queue to get it to close the queue I needed close to clear, it did work, but Iam not sure that it still works, I beleive it v5.0 or v5.1 queue manager
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| jc_squire |
| Posted: Wed Aug 14, 2002 4:56 pm Post subject: |
|
|
Centurion
Joined: 14 Apr 2002
Posts: 105
Location: New Zealand
|
Sorry, don't think the channel initiator has got anything to do with closing a queue open for input. A channel initiator is purely a service/daemon that initiates a channel (similar to a trigger monitor but specifically designed for channels).
I have recently come from a client site where they have not had the channel initiator running for years - they could never get it to start (MQ 5.0) and their solution was to set the discint to 0 to stop the channels from timming out .......... 
The point is that during this time MQ worked normally (except channels would not trigger and always require a manual start) without the channel initiator running which indicates that the channel initiator has nothing to do with this process i.e. it is not reliant on the channel initiator at all.
Another potential issue is network bandwidth - is it congested? do you pay for traffic? There is no point in keeping a connection open for a long period of time if there are no messages and the network is congested or you have to pay for the MQ traffic going across the connection to keep the channel alive. And what about weekends when it is possible that no messages will be processed? Yes, there is an overhead in traffic when starting/shutting down a channel so you need to look at how often messages will be processed, take into account your discint and see how many times your chl would stop/start in a day. Compare the cost of this to the cost of keeping chls running and find a centre point here where you can get the best of both worlds.
How many chls are you talking about? What are the max nr of connections for the qmgr? A queue manager has a restriction as to how many connections it can accept. If channels remain active (discint set to 0) and the max nr of connections is reached it will not accept any more new connections.
If you send messages on a regular basis e.g. every 20 minutes just leave discint as default and your channels will always be running anyway.
Not quite sure how you see setting discint to 0 will reduce the risk of comms mishaps - the risk is there irrespective of whether channels are running permanently or triggered.
Regards
_________________
J C Squire
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
|
|
|
