| Author |
Message
|
| KIT_INC |
 Posted: Thu Jun 08, 2017 4:57 am Post subject: channel retry count |
 |
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| This is more for educational purpose. I am reading the channel definitions for sender channel. The channel goes into long retry after the short retry is not successful. I noticed that the SYSTEM.DEF.SENDER has LONGRTY(999999999) LONGTMR(1200). If I understand it correctly, MQ will try to start the channel 999999999 times every 20 minutes and this is a lot of years. A lot of us take the defaults when creating channels, I was wondering if there is any recommendations on changing this long retry parameters or it is better to just to use the default value. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Jun 08, 2017 5:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It's certainly better to change this if you need to know that a channel can't be started without manual effort...
If you have some kind of monitoring that will tell you that the channel is in a retrying state, or not up, however, you can avoid changing this and rely on your monitoring.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Thu Jun 08, 2017 9:11 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Be aware that at the end of the retry sequence, if not successful, the channel will go into STOPPED state. This means it will never get going again without something external to the Queue Manager kicking it into life again. That is why the default is to essentially retry forever.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Thu Jun 08, 2017 9:48 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Thanks for the response. It is probably safer to leave it as default. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Jun 12, 2017 4:10 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Agree, leave the long retry parameters at defaults.
There may be some benefit in altering the short retry parameters to more quickly start a channel if a typical network or server outage exceeds the default short retries. eg. Alter to 50 short retries at 300 second intervals. YMMV.
BTW, if you find a SENDER channel in RETRY status, you can manually issue a START command against it to force an immediate retry. You don't need to wait for the long retry interval to tick over, or STOP then START it.
_________________
Glenn |
|
| Back to top |
|
|
| blorro |
| Posted: Tue Jan 23, 2018 1:46 am Post subject: |
|
|
Acolyte
Joined: 09 Jan 2014
Posts: 57
Location: Sweden
|
Good thread.
Checking some settings in our shop, i discovered that some Retry intervals are ridiculously short.
Upon asking my predecessor he stated it unnecessary to "Waste machine capacity" .
The channels in question are server channels running on z/OS.
Surely i would think to put the retry intervals (Short and long) to summarize up to three days of retries on the Server channels on z/OS.
Or would it result in extensive overhead on Logging , causing CPU and Memory to get strained ?
(I really dont think so , but would love a second, third and fourth opinion .
_________________
"Anything is possible, all the time." |
|
| Back to top |
|
|
|
|
