| Author |
Message
|
| mqer |
 Posted: Mon Mar 22, 2004 10:05 am Post subject: MQ Channel Parms - Best Practices |
 |
|
Newbie
Joined: 22 Mar 2004
Posts: 5
Location: Virginia
|
I'm looking for documentation on best practices for MQ Channel parameters. In particular DISCINT, HBINT, BATCHHB, BATCHINT, SHORTRTY, SHORTTMR, LONGTMR, and LONGRTY and any others that may affect channel recovery after a brief glitch in the network. I'm reviewing my MQ environment to make sure it's configured as best as possible to recover from network problems. Sometimes we experience short glitches in the network and there's concern that MQ is not recovering as fast as we would like. Any good doc out there?
Thanks. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Mar 22, 2004 2:30 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
No doc that I know of.
If you use the Search function on this site for those terms, you can see what other people set them to.
IBM choose the defaults for a reason. In other words, the IBM defaults are a good "Best Practices document" themselves.
Read the Intercommunication Guide to understand these attributes, and then you will be able to determine on you own whether it is worth switching the IBM defaults. If you have a specific question about a specific attribute, we may be able to help.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kman |
| Posted: Tue Mar 23, 2004 2:03 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
| Quote: |
| IBM choose the defaults for a reason. In other words, the IBM defaults are a good "Best Practices document" themselves. |
Thank you Peter. At least there are someone out there believes that the values provided by IBM are good enough for a general installation.
For specific requirements, you then need to change those values accordingly and each specific scenario is different from the others. Maybe you have to read the manuals to understand the effect of each values. And sometimes, a combination of values would return something totally unexpected.
Bottomline, you need to play with. That's why it is called 'fine tuning'.  |
|
| Back to top |
|
|
| JLRowe |
| Posted: Tue Mar 23, 2004 2:14 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
| The one parameter that makes the most difference is AdoptNewMCA=ALL in the queue manager config. This allows orphaned receivers (i.e. sender socket has ended in error, receiver socket is unaware and still waiting) to be ended immediately when the new sender socket connects. |
|
| Back to top |
|
|
| mqer |
| Posted: Tue Mar 23, 2004 1:12 pm Post subject: |
|
|
Newbie
Joined: 22 Mar 2004
Posts: 5
Location: Virginia
|
Thanks. Speaking of AdoptNewMCA. We do use this in our environment, however I've noticed recently where it did not work as expected. We use Requester/Server channel combinations. I had a Requester channel throw the following error for 260 seconds after a blip in the network.
AMQ9514: Channel 'QM1.QM2' is in use.
Then after 260 seconds a TCPIP error was thrown and the channel corrected itself.
AMQ9213: A communications error for TCP/IP occurred.
EXPLANATION:
An unexpected error occurred in communications.
ACTION:
The return code from the TCP/IP(select) [TIMEOUT] 260 seconds call was 11
(X'B'). Record these values and tell the systems administrator.
The HBINT is set at 200. Which shows that the HBINT did what it's supposed to do. After HBINT 200 + 60, the Requester channel timed out and then the connection was ok. Any idea why AdoptNewMCA did not immediately correct the issue? Does AdoptNewMCA work with Requester channels? I have it set in the qm.ini file as AdoptNewMCA=ALL. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 23, 2004 2:06 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
What version of MQ are you running? AdoptNewMCA was not always supported.
If you are running a version that does support it, what value do you have for AdoptNewMCATimeout? Because that will delay the adoption of the new channel.
And what about AdoptNewMCACheck? If this is turned on to ALL or ADDRESS, it will verify that the sending side's ip address is the same as the one from the previous instance. If different, the adoption will fail.
(If you use ADOPTNEWMCA, make sure you use AdoptNewMCACheck=ALL, to lessen (but not eliminate) the security risks associated with AdoptNewMCA).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqer |
| Posted: Tue Mar 23, 2004 3:19 pm Post subject: |
|
|
Newbie
Joined: 22 Mar 2004
Posts: 5
Location: Virginia
|
| It's running MQ V5.3, CSD05. We do have AdoptNewMCACheck=ALL and AdoptNewMCATimeout=60 set. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 23, 2004 3:39 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Was the SRVR channel RETRYING during this time period?
If yes, was it retrying from the same IP address?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| offshore |
| Posted: Wed Mar 24, 2004 4:10 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
Acutually, there is a good doc out on IBM's site about channels and the parms for each channel.
Support Pac MD0C - Its an adobe acrobat reader file entitled "Keeping Channels Up and Running" I would highly recommend taking the time to read it.
As for the Server/Requester channel issue. This is just my opinion, but would AdoptMCA work for these pair of channel types? I can't find any real evidence saying no, but......
Unlike RCVR channels Requester channels can actually initiate communication with a Server channel. So if there was a communications blip, would a SVR/RQSTR channel actually need to use the AdoptMCA parms or could/would it reinititate the communications?  |
|
| Back to top |
|
|
| mqer |
| Posted: Wed Mar 24, 2004 6:56 am Post subject: |
|
|
Newbie
Joined: 22 Mar 2004
Posts: 5
Location: Virginia
|
| Unfortuately, I was unable to tell if the SVR side was in retying because of an MQ error log security problem. MQ didn't have permission to write to it's log at that time, though we have corrected that issue since then. However, if it were in retying, it would have had the same IP. |
|
| Back to top |
|
|
|
|
