Re: Channel Retry Counts/Intervals
Don't forget about Heartbeats. If a RCVR does not get a HB back from the other side in the required time, it assumes an outage and goes into Inactive. When the network comes back up, the SNDR finally gets a successful retry, and finds the RCVR inactive, ready to do business. If the SNDR successfully retries a connection after an outage but before the heartbeat, then the RCVR is still running, and then AdoptMCA steps up to the plate to save the day like Steve explained below. Properly set up, it is very rare that you have to manually interfere to get channels running again after an outage. -Original Message- From: Stephan C. Moen [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 11:08 PM To: [EMAIL PROTECTED] Subject: Re: Channel Retry Counts/Intervals Beware this is a long response but it is technical in nature, which is a welcome relief for those of you who got tired of the "Spiraling downhill" thread. When I referred to the fact that your sender channel LONGRETRY and LONGTMR attributes can be set to ZERO, this would only make sense if your DISCINT interval expires BEFORE your SHORTRTY * SHORTMR interval. Well this ONLY works if there are no messages left on your XMITQ. DUH! In short this was an IDIOTIC statement to make, let alone broadcast to all of you. I thank you all for allowing me to say this versus one of our more assertive personalities on the Listserver. Do I hear chuckles in the background? From this point forward, I will proof read my statements BEFORE hitting the SEND key. To save what dignity I have left, what I was ATTEMPTING to do is explain how channels can be made more reliable by using the DISCINT, ADOPTNEWMCA, and ADOPTNEWMCATIMEOUT attributes in combination with the SHORT* and LONG* attribute values. Allow me to re-explain. The DISCINT interval only works for SENDER type channels. Let's assume this attribute is set to 10 minutes. If no messages go to the XMIT queue for that channel within that time period, the SENDER channel will quiesce, as will the RECEIVER channel (assuming there is connectivity between the two). If the connectivity is broken, then the ADOPNEWMCA and ADOPTNEWMCATIMEOUT attributes take over, since they work on RECEIVER-type channels. With that said... When a network outage occurs, there is no guarantee that both ends of the channel will detect the failure at the same time. Often the sending channel detects the failure first since it is trying to send the message. If the sending channel goes into an inactive state during a network outage (disconnect interval expired), when new messages arrive and the network is back online, the sender channel will try to reconnect to the target queue manager but since the previous receiver channel is still running with the same name, the new inbound connection request is rejected because the receiver is still stuck waiting on the previous socket signature (did not receive the disconnect request from the sender channel due to the network outage). Remember, a sender channel will only connect if it finds the receiver in an INACTIVE state. The ADOPTNEWMCA attribute allows you to control the shutdown of a receiver channel and the startup of a new one. By configuring ADOPTNEWMCA, if a new inbound connection request arrives and there is already a channel with that name running from the same network address and from the same queue manager, then the new channel tries to stop the previous one by requesting it to end. If the previous channel does not respond to this request by the time the ADOPTNEWMCATIMEOUT interval expires (lets assume it is set to 20 seconds), a second attempt is made. If the receiver channel has not ended after the ADOPTNEWMCATIMEOUT wait interval expired for a second time, I believe MQSeries ends the channel with a CHANNEL IN USE error. With all this said, I find this a cleaner, more robust solution to handle system or network interruptions, though maybe some of the issues we have, are cleaned up in V5.3 (we are at an earlier release of V5.2 - cost reasons). This configuration was principally done to resolve issues with remote connections found throughout the United States. Without using the ADOPTNEWMCA* attributes, if the sender channels time-out while there was a network outage or a system crashed, the receiver channels would stay up. Once the incident was resolved (network or system outage), we had to bounce numerous receiver channels to get them to reconnect. Using the ADOPTNEWMCA parameters in conjunction with the DISCINT attribute, channels reconnect on their own free will - no matter what the previous outage was or its time duration. Oh, and DON'T set the LONG* channel attributes to ZERO. Keep the LONGRETRY attribute at its default value (999,999,999) and change the LONGTMR attribute to fit whatever timeout values fits your situation. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Glen Larson Sent: Tuesday,
Re: Channel Retry Counts/Intervals
Beware this is a long response but it is technical in nature, which is a welcome relief for those of you who got tired of the "Spiraling downhill" thread. When I referred to the fact that your sender channel LONGRETRY and LONGTMR attributes can be set to ZERO, this would only make sense if your DISCINT interval expires BEFORE your SHORTRTY * SHORTMR interval. Well this ONLY works if there are no messages left on your XMITQ. DUH! In short this was an IDIOTIC statement to make, let alone broadcast to all of you. I thank you all for allowing me to say this versus one of our more assertive personalities on the Listserver. Do I hear chuckles in the background? From this point forward, I will proof read my statements BEFORE hitting the SEND key. To save what dignity I have left, what I was ATTEMPTING to do is explain how channels can be made more reliable by using the DISCINT, ADOPTNEWMCA, and ADOPTNEWMCATIMEOUT attributes in combination with the SHORT* and LONG* attribute values. Allow me to re-explain. The DISCINT interval only works for SENDER type channels. Let's assume this attribute is set to 10 minutes. If no messages go to the XMIT queue for that channel within that time period, the SENDER channel will quiesce, as will the RECEIVER channel (assuming there is connectivity between the two). If the connectivity is broken, then the ADOPNEWMCA and ADOPTNEWMCATIMEOUT attributes take over, since they work on RECEIVER-type channels. With that said... When a network outage occurs, there is no guarantee that both ends of the channel will detect the failure at the same time. Often the sending channel detects the failure first since it is trying to send the message. If the sending channel goes into an inactive state during a network outage (disconnect interval expired), when new messages arrive and the network is back online, the sender channel will try to reconnect to the target queue manager but since the previous receiver channel is still running with the same name, the new inbound connection request is rejected because the receiver is still stuck waiting on the previous socket signature (did not receive the disconnect request from the sender channel due to the network outage). Remember, a sender channel will only connect if it finds the receiver in an INACTIVE state. The ADOPTNEWMCA attribute allows you to control the shutdown of a receiver channel and the startup of a new one. By configuring ADOPTNEWMCA, if a new inbound connection request arrives and there is already a channel with that name running from the same network address and from the same queue manager, then the new channel tries to stop the previous one by requesting it to end. If the previous channel does not respond to this request by the time the ADOPTNEWMCATIMEOUT interval expires (lets assume it is set to 20 seconds), a second attempt is made. If the receiver channel has not ended after the ADOPTNEWMCATIMEOUT wait interval expired for a second time, I believe MQSeries ends the channel with a CHANNEL IN USE error. With all this said, I find this a cleaner, more robust solution to handle system or network interruptions, though maybe some of the issues we have, are cleaned up in V5.3 (we are at an earlier release of V5.2 - cost reasons). This configuration was principally done to resolve issues with remote connections found throughout the United States. Without using the ADOPTNEWMCA* attributes, if the sender channels time-out while there was a network outage or a system crashed, the receiver channels would stay up. Once the incident was resolved (network or system outage), we had to bounce numerous receiver channels to get them to reconnect. Using the ADOPTNEWMCA parameters in conjunction with the DISCINT attribute, channels reconnect on their own free will - no matter what the previous outage was or its time duration. Oh, and DON'T set the LONG* channel attributes to ZERO. Keep the LONGRETRY attribute at its default value (999,999,999) and change the LONGTMR attribute to fit whatever timeout values fits your situation. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Glen Larson Sent: Tuesday, June 17, 2003 9:15 AM To: [EMAIL PROTECTED] Subject: Re: Channel Retry Counts/Intervals Stephan, when the problem is network related yes, but what about the inevitable outages for hardware/software/power/cooling upgrades that may take 4-12 hours on a weekend. Now some but not all of the servers may be down at this time, either because the are not on the same platform, or maybe not even in the same datacenter. In that case is it not better to let MQ reconnect on its own, rather require an admin to fix something that really isn't a problem? Glen Larson Zurich North America "Stephan C. Moen" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 06/16/2003 11:25:14 PM Please respond to MQSeries List <[EMAIL
Re: Channel Retry Counts/Intervals
Stephan,
when the problem is network related yes, but what about the inevitable
outages for hardware/software/power/cooling upgrades that may take 4-12
hours on a weekend. Now some but not all of the servers may be down at
this time, either because the are not on the same platform, or maybe not
even in the same datacenter. In that case is it not better to let MQ
reconnect on its own, rather require an admin to fix something that really
isn't a problem?
Glen Larson
Zurich North America
"Stephan C. Moen" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 06/16/2003 11:25:14
PM
Please respond to MQSeries List <[EMAIL PROTECTED]>
Sent by:MQSeries List <[EMAIL PROTECTED]>
To:[EMAIL PROTECTED]
cc:
Subject: Re: Channel Retry Counts/Intervals
I know that I am opening myself up to a lot of CONSTRUCTIVE CRITICISM but I
will be more than happy to take the ‘slings and arrows’ to benefit the
entire community as to what these channel attributes should be set to.
From my perspective (‘have yet to implement this scenario in a production
environment’) I would set LongRetryCount and LongRetryInterval to ZERO and
arbitrary values for ShortRetry Count + Interval that are tailored to your
production environment. Once the ShortRetry* attributes have elapsed, the
channel will go into a STOPPED state. If you give the network 10 minutes
(shorretryinterval=30, shorretrycount=20) or 60 minutes
(shortretryinterval=60, shortretrycount=60) to clean itself up, isn’t that
enough? Why do I want to stay in a retrying state FOREVER? A more robust
solution should incorporate the ADOPTNEWMCA, ADOPTNEWMCATIMEOUT and DISCINT
(and optionally HBINT) attributes to break a connection within the window
defined by the ShorRetry* settings. Therefore if the channel DOES go into
a STOPPED state, you really know you have a problem.
OK, I now am wearing my shield of armor and am ready to defend myself, so
let them arrows fly and see what collective decision we can make…
Steve
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Glen
Shubert
Sent: Monday, June 16, 2003 10:22 AM
To: [EMAIL PROTECTED]
Subject: Re: Channel Retry Counts/Intervals
Edward,
We just went through the same thing, and we came up with the following:
Short Retry Count : 60
Short Retry Interval : 60
Long Retry Count : 9
Long Retry Interval : 300
Glen Shubert
[EMAIL PROTECTED]
Associate Director
TSYS - MQSeries Technical Support
Edward Pius
<[EMAIL PROTECTED]
M>To: [EMAIL PROTECTED]
Sent by: MQSeries List cc:
<[EMAIL PROTECTED] Subject: Channel
> Retry Counts/Intervals
06/16/2003 10:31 AM
Please respond to
MQSeries List
Hello,
Are there any preferred values for the sender channel short and long
retry counts and intervals different from the default values?
The defaults I have for a sender channel from an Win 2000 queue
manager to a OS/390 queue manager are :
Short Retry Count : 10
Short Retry Interval : 60
Long Retry Count : 9
Long Retry Interval : 1200
In appreciation,
Edward Pius
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
This message was content-scanned by GatewayDefender.com
6/16/2003 - 12:01:16 PM - BB0395deca.0001.mml
*** PLEASE NOTE ***
This E-Mail/telefax message and any documents accompanying this
transmission may contain privileged and/or confidential information and is
intended solely for the addressee(s) named above. If you are not the
intended addressee/recipient, you are hereby notified that any use of,
disclosure, copying, distribution, or reliance on the contents of this
E-Mail/telefax information is strictly prohibited and may result in legal
action against you. Please reply to the sender advising of the error in
transmission and immediately
Re: Channel Retry Counts/Intervals
Title: Message
The
adopt values are for the case where you have a RCVR that is running, but the
SNDR went away without being able to tell the RCVR bye-bye. So the RCVR is just
sitting there, watching the paint peel, waiting for the long gone SNDR to send
another message (Geez, sounds like the day after my last date). If the SNDR fixes itself and tries to reestablish the connection, he can't, because the RCVR
is still hung up on the old instance. He can't accept the new request from the
new instance. UNLESS you have the Adopt values set, in which case the QM starts
up a new instance of the RCVR, the new SNDR connects to him and life is
good.
This
is not what happens in an IPL. In this case your QM is coming down as well. The
same instance of the SNDR keeps attempting to call the mainframe RCVR. When the
QM comes back up, a new instance, no longer hung up on the old socket signature,
is created, and the next time the SNDR hits its retry interval, the connection
is remade (OLD SNDR to new RCVR). ADOPT does not come into play
here.
We IPL
our mainframes almost every weekend, and never need to do anything to the
distributed channels coming into the mainframes. During the IPL, the remote SNDRs are retrying, and as soon as the IPL is over, within our
LongRertyIntervals, all the channels reestablish themselves. Meanwhile MQSupport
is sleeping soundly.
This
is not to say you should not use ADOPTNEWMCA & ADOPTNEWMCATIMEOUT, and DISCINT. There are many other valid reasons to use them.
-Original Message-From: Heggie, Peter
[mailto:[EMAIL PROTECTED]Sent: Tuesday, June 17, 2003 8:27
AMTo: [EMAIL PROTECTED]Subject: Re: Channel Retry
Counts/Intervals
So
using the ADOPTNEWMCA & ADOPTNEWMCATIMEOUT, and DISCINT, is a better way
to reconnect, for example, to a mainframe that has been IPL'ed over a Saturday
night.. don't have to touch the distributed side at all..
??
Peter Heggie
(315) 428 - 3193
-Original Message-From: Stephan C. Moen
[mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 12:25
AMTo: [EMAIL PROTECTED]Subject: Re: Channel Retry
Counts/Intervals
I
know that I am opening myself up to a lot of CONSTRUCTIVE CRITICISM but I will
be more than happy to take the 'slings and arrows' to benefit the entire community as to what these channel attributes should be set
to.
From
my perspective ('have yet to implement this scenario in a production
environment') I would set LongRetryCount and LongRetryInterval to ZERO and
arbitrary values for ShortRetry Count + Interval that are tailored to your
production environment. Once the
ShortRetry* attributes have elapsed, the channel will go into a STOPPED state. If you give the network 10
minutes (shorretryinterval=30, shorretrycount=20) or 60 minutes
(shortretryinterval=60, shortretrycount=60) to clean itself up, isn't that
enough? Why do I want to stay in
a retrying state FOREVER? A more
robust solution should incorporate the ADOPTNEWMCA, ADOPTNEWMCATIMEOUT and
DISCINT (and optionally HBINT) attributes to break a connection within the
window defined by the ShorRetry* settings. Therefore if the channel DOES go into
a STOPPED state, you really know you have a
problem.
OK,
I now am wearing my shield of armor and am ready to defend myself, so let them
arrows fly and see what collective decision we can
make...
Steve
-Original
Message-From: MQSeries
List [mailto:[EMAIL PROTECTED]On
Behalf Of Glen ShubertSent: Monday, June 16, 2003 10:22 AMTo:
[EMAIL PROTECTED]Subject: Re: Channel Retry
Counts/Intervals
Edward, We just went
through the same thing, and we came up with the following:
Short Retry Count : 60
Short Retry Interval : 60
Long Retry Count : 9
Long Retry Interval : 300Glen
Shubert[EMAIL PROTECTED]Associate DirectorTSYS - MQSeries
Technical Support
Edward
Pius <[EMAIL PROTECTED]> Sent by:
MQSeries List <[EMAIL PROTECTED]>
06/16/2003
10:31 AM
Please
respond to MQSeries List
To:
[EMAIL PROTECTED]
cc:
Subject: Channel Retry
Counts/Intervals
Hello,
Are there any preferred values for the sender channel short and long retry counts and intervals different from the default
values? The defaults I have for a sender channel from an Win 2000 queue manager to a OS/390 queue manager are : Short Retry Count : 10
Short Retry Interval : 60 Long Retry Count : 9 Long Retry
Interval : 1200 In
appreciation,Edward PiusInstructions
Re: Channel Retry Counts/Intervals
The only issue with that is ADOPTNEWMCA and ADOPTNEWMCATIMEOUT only work for TCP/IP based channels. We have a lot of LU62 based channels. What do you do if there is a phone circuit cut, and it takes approximately 24 hours to fix? I would hate to set ShortRetries based on worst case scenarios. Normally, interruptions in channels tend to be short, ie a circuit hit, a system IPL or boot, etc. But, in order to be effective for long-term situations, the LongRetries fills the need.
Glen Shubert
[EMAIL PROTECTED]
Associate Director
TSYS - MQSeries Technical Support
"Stephan C. Moen" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
06/17/2003 12:25 AM
Please respond to MQSeries List
To: [EMAIL PROTECTED]
cc:
Subject: Re: Channel Retry Counts/Intervals
I know that I am opening myself up to a lot of CONSTRUCTIVE CRITICISM but I will be more than happy to take the 'slings and arrows' to benefit the entire community as to what these channel attributes should be set to.
From my perspective ('have yet to implement this scenario in a production environment') I would set LongRetryCount and LongRetryInterval to ZERO and arbitrary values for ShortRetry Count + Interval that are tailored to your production environment. Once the ShortRetry* attributes have elapsed, the channel will go into a STOPPED state. If you give the network 10 minutes (shorretryinterval=30, shorretrycount=20) or 60 minutes (shortretryinterval=60, shortretrycount=60) to clean itself up, isn't that enough? Why do I want to stay in a retrying state FOREVER? A more robust solution should incorporate the ADOPTNEWMCA, ADOPTNEWMCATIMEOUT and DISCINT (and optionally HBINT) attributes to break a connection within the window defined by the ShorRetry* settings. Therefore if the channel DOES go into a STOPPED state, you really know you have a problem.
OK, I now am wearing my shield of armor and am ready to defend myself, so let them arrows fly and see what collective decision we can make…
Steve
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Glen Shubert
Sent: Monday, June 16, 2003 10:22 AM
To: [EMAIL PROTECTED]
Subject: Re: Channel Retry Counts/Intervals
Edward,
We just went through the same thing, and we came up with the following:
Short Retry Count : 60
Short Retry Interval : 60
Long Retry Count : 9
Long Retry Interval : 300
Glen Shubert
[EMAIL PROTECTED]
Associate Director
TSYS - MQSeries Technical Support
Edward Pius <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
06/16/2003 10:31 AM
Please respond to MQSeries List
To: [EMAIL PROTECTED]
cc:
Subject: Channel Retry Counts/Intervals
Hello,
Are there any preferred values for the sender channel short and long retry counts and intervals different from the default values?
The defaults I have for a sender channel from an Win 2000 queue manager to a OS/390 queue manager are :
Short Retry Count : 10
Short Retry Interval : 60
Long Retry Count : 9
Long Retry Interval : 1200
In appreciation,
Edward Pius
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
This message was content-scanned by GatewayDefender.com
6/16/2003 - 12:01:16 PM - BB0395deca.0001.mml
Re: Channel Retry Counts/Intervals
Title: Message So using the ADOPTNEWMCA & ADOPTNEWMCATIMEOUT, and DISCINT, is a better way to reconnect, for example, to a mainframe that has been IPL'ed over a Saturday night.. don't have to touch the distributed side at all.. ?? Peter Heggie (315) 428 - 3193 -Original Message-From: Stephan C. Moen [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 12:25 AMTo: [EMAIL PROTECTED]Subject: Re: Channel Retry Counts/Intervals I know that I am opening myself up to a lot of CONSTRUCTIVE CRITICISM but I will be more than happy to take the ‘slings and arrows’ to benefit the entire community as to what these channel attributes should be set to. From my perspective (‘have yet to implement this scenario in a production environment’) I would set LongRetryCount and LongRetryInterval to ZERO and arbitrary values for ShortRetry Count + Interval that are tailored to your production environment. Once the ShortRetry* attributes have elapsed, the channel will go into a STOPPED state. If you give the network 10 minutes (shorretryinterval=30, shorretrycount=20) or 60 minutes (shortretryinterval=60, shortretrycount=60) to clean itself up, isn’t that enough? Why do I want to stay in a retrying state FOREVER? A more robust solution should incorporate the ADOPTNEWMCA, ADOPTNEWMCATIMEOUT and DISCINT (and optionally HBINT) attributes to break a connection within the window defined by the ShorRetry* settings. Therefore if the channel DOES go into a STOPPED state, you really know you have a problem. OK, I now am wearing my shield of armor and am ready to defend myself, so let them arrows fly and see what collective decision we can make… Steve -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Glen ShubertSent: Monday, June 16, 2003 10:22 AMTo: [EMAIL PROTECTED]Subject: Re: Channel Retry Counts/Intervals Edward, We just went through the same thing, and we came up with the following: Short Retry Count : 60 Short Retry Interval : 60 Long Retry Count : 9 Long Retry Interval : 300Glen Shubert[EMAIL PROTECTED]Associate DirectorTSYS - MQSeries Technical Support Edward Pius <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 06/16/2003 10:31 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Channel Retry Counts/Intervals Hello, Are there any preferred values for the sender channel short and long retry counts and intervals different from the default values? The defaults I have for a sender channel from an Win 2000 queue manager to a OS/390 queue manager are : Short Retry Count : 10 Short Retry Interval : 60 Long Retry Count : 9 Long Retry Interval : 1200 In appreciation,Edward PiusInstructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive This message was content-scanned by GatewayDefender.com6/16/2003 - 12:01:16 PM - BB0395deca.0001.mml This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360.
Re: Channel Retry Counts/Intervals
I know that I am opening myself up to a lot of CONSTRUCTIVE CRITICISM but I will be more than happy to take the ‘slings and arrows’ to benefit the entire community as to what these channel attributes should be set to. From my perspective (‘have yet to implement this scenario in a production environment’) I would set LongRetryCount and LongRetryInterval to ZERO and arbitrary values for ShortRetry Count + Interval that are tailored to your production environment. Once the ShortRetry* attributes have elapsed, the channel will go into a STOPPED state. If you give the network 10 minutes (shorretryinterval=30, shorretrycount=20) or 60 minutes (shortretryinterval=60, shortretrycount=60) to clean itself up, isn’t that enough? Why do I want to stay in a retrying state FOREVER? A more robust solution should incorporate the ADOPTNEWMCA, ADOPTNEWMCATIMEOUT and DISCINT (and optionally HBINT) attributes to break a connection within the window defined by the ShorRetry* settings. Therefore if the channel DOES go into a STOPPED state, you really know you have a problem. OK, I now am wearing my shield of armor and am ready to defend myself, so let them arrows fly and see what collective decision we can make… Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Glen Shubert Sent: Monday, June 16, 2003 10:22 AM To: [EMAIL PROTECTED] Subject: Re: Channel Retry Counts/Intervals Edward, We just went through the same thing, and we came up with the following: Short Retry Count : 60 Short Retry Interval : 60 Long Retry Count : 9 Long Retry Interval : 300 Glen Shubert [EMAIL PROTECTED] Associate Director TSYS - MQSeries Technical Support Edward Pius <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 06/16/2003 10:31 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Channel Retry Counts/Intervals Hello, Are there any preferred values for the sender channel short and long retry counts and intervals different from the default values? The defaults I have for a sender channel from an Win 2000 queue manager to a OS/390 queue manager are : Short Retry Count : 10 Short Retry Interval : 60 Long Retry Count : 9 Long Retry Interval : 1200 In appreciation, Edward Pius Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This message was content-scanned by GatewayDefender.com 6/16/2003 - 12:01:16 PM - BB0395deca.0001.mml
Re: Channel Retry Counts/Intervals
Edward, We just went through the same thing, and we came up with the following: Short Retry Count : 60 Short Retry Interval : 60 Long Retry Count : 9 Long Retry Interval : 300 Glen Shubert [EMAIL PROTECTED] Associate Director TSYS - MQSeries Technical Support Edward Pius <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 06/16/2003 10:31 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Channel Retry Counts/Intervals Hello, Are there any preferred values for the sender channel short and long retry counts and intervals different from the default values? The defaults I have for a sender channel from an Win 2000 queue manager to a OS/390 queue manager are : Short Retry Count : 10 Short Retry Interval : 60 Long Retry Count : 9 Long Retry Interval : 1200 In appreciation, Edward Pius Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Channel Retry Counts/Intervals
Hello, Are there any preferred values for the sender channel short and long retry counts and intervals different from the default values? The defaults I have for a sender channel from an Win 2000 queue manager to a OS/390 queue manager are : Short Retry Count : 10 Short Retry Interval : 60 Long Retry Count : 9 Long Retry Interval : 1200 In appreciation, Edward Pius Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
