MQ Triggering

[JEMIAZ]

Hi
I have routing maps that listen for MQ triggers that on occassion fail with MQ input card error of -13 (connection not available). The queue then contains a stuck message that requires a restart of the ES to clear. We can replicate this on many different queues with different maps but the typical trigger command line is

-qmn ROUTER.V15 -qn APP_TO_ROUTER -eqn APP_TO_ROUTER.ERROR -QTY 1 -HDR -REFRESH 60

We have tried the following solutions so far in combination where it makes sense.
- map delay
- map retry
- card retry
- PollWaitTimeMin/Max
- IdleMQS=xxx
- Queue manager open handles

The map has been pared down to just a single MQ trigger input queue which we bombard with messages from another Mctr process. no transformation just post to another queue.
MQ shows no errors, neither do the MQ trace or ES debug logs.
This has been reported to support before but we were on slightly older releases of MQ and Mercator. Now we are as fully up to speed as we can be (sorry but not 8.0 yet). Any ideas would be welcome.

Mercator 6.7.1 on W2k Advanced Server. 8GB memory, 2x processors.
MQ Server 5.3 CSD11

 

[BocaBurger]

PollWaitTimeMin should be in the 20 to 40 range, max does nothing.
Could be a total connections issue, you might try HLimMQS.
IdleMQS is almost never needed. You might look into some other MQ settings: queue depth, etc.
-refresh could be too high, try 10 to 30.

6.7.1 is not supported with 5.3 as far as I know.



BocaBurger
<===========================||////////////////|0
The pen is mightier than the sword, but the sword hurts more!

 

[JEMIAZ]

Thanks BocaBurger I'll give those a try...

A couple of points though...
What would I expect to happen if HLimMQS < the number of MQ source triggers in temrs of performance. We get this problem on servers with 200+ triggers and also on those with 10.

Also could you expand on the usage of PollWaitTimeMin beyond what is in the books please.

Surely MQ 5.3 is supported by 6.7.1 as MQ5.2 is almost out of support by IBM and 6.0 is not yet supported by TX 8. Doesn't leave many options!

Tim

 

[JEMIAZ]

An update
I'll answer one of my questions. If HLimMQS is lower than the number of triggers defined then the ES will not start.
Tim

 

[BocaBurger]

Pollwaitimemin, is the time between the poll of the queue by the "listener" 2000 = 2 seconds and could be too slow for mast systems.

MQ 5.3 was released after 6.7.1.
DSTX 8.0 does support 5.3.

If HLim is less than the number of separate watches, this would need to be tested.

As to your error, turn on verbose trace and check the MQ error logs for anything that occurred at the same time as the adapter error.



BocaBurger
<===========================||////////////////|0
The pen is mightier than the sword, but the sword hurts more!

 

[JEMIAZ]

Ok, I've got the trace information.
This snippet is after a single map had processed 70,000 messages. The 2058 error implies a fault of the queue manager name although this hasn't changed in years. I think these problems originally started with Mq 5.2 and Tx6.7
The map returns a -13 card error.

<724-2016>: | [intm4mqsIsTransactionRequired]
<724-2016>: | [intm4mqsIsTransactionRequired] (rc = 0) OK
<724-2016>: | Syncpoint required
<724-2016>: | Buffer reallocation from 4196 to 100030 bytes
<724-2016>: | Message retrieved:
MID [414D5120524F555445522E56313520200CC6A7432002BE6C]
CID [545249505445535433373600000000000000000000000000]
GRP [000000000000000000000000000000000000000000000000]
SeqNum[1] Offset[0]
<724-2016>: | [intm4mqsAddMessageToErrorQueueList]
<724-2016>: | [intm4mqsAddMessageToErrorQueueList] (rc = 0) OK
<724-2016>: [m4mqsGet] (rc = 0) OK
<724-3580>: TRACE ON
<724-3580>: Adapter command: -qmn ROUTER.V15 -qn APP_TO_ROUTER -eqn APP_TO_ROUTER.ERROR -HDR -REFRESH 10 -t
<724-3580>: [intm4mqsCheckAdapterCommand]
<724-3580>: [intm4mqsCheckAdapterCommand] (rc = 0) OK
<724-4300>: [m4mqsConnect]
<724-4300>: | MQSeries error (ReasonCode = 2058)
<724-4300>: [m4mqsConnect] (rc = -13) *** ERROR ***
<724-3320>: [m4mqsEndTransaction]
<724-3320>: | Committing unit of work
<724-4500>: [m4mqsEndTransaction]
<724-4500>: | Committing unit of work
<724-3320>: [m4mqsEndTransaction] (rc = 0) OK
<724-4500>: [m4mqsEndTransaction] (rc = 0) OK
<724-3320>: [m4mqsOnNotify]
<724-3320>: | OnNotify->GetStop
<724-3320>: [m4mqsOnNotify] (rc = 0) OK
<724-4500>: [m4mqsOnNotify]
<724-4500>: | OnNotify->GetStop
<724-4500>: [m4mqsOnNotify] (rc = 0) OK
<724-4332>: [m4mqsEndTransaction]
<724-4332>: | Committing unit of work
<724-3580>: Destroying trace object in m4mqsDestroyAdapterInstance
<724-4332>: [m4mqsEndTransaction] (rc = 0) OK
<724-4332>: [m4mqsOnNotify]

 

[BocaBurger]

Contact support. I think this is a known issue and there was a PTF for this.



BocaBurger
<===========================||////////////////|0
The pen is mightier than the sword, but the sword hurts more!

 

[JEMIAZ]

As an update I think we have narrowed this down to the number of times the adapter has to issue a command to increase the buffer allocation . The default buffer is 4096 and most messages are in excess of this. By restriciting my message size I can't repeat the error.

Next step is to look at the -mbs command line option and also to contact support as you say in case there is a ptf

Tim

 

[BocaBurger]

What about increasing the buffer size?

There can be more than one cause or solution to a problem.



BocaBurger
<===========================||////////////////|0
The pen is mightier than the sword, but the sword hurts more!

 

[JEMIAZ]

Just an update.

There is a patch available for this MQ triggering issue which is apparently down to network glitches - not an explanation I'm entirely happy with.

Support have confirmed that 6.7.1 and MQ 5.3 is supported and has been tested up to CSD02.

Tim

 

[BocaBurger]

I checked my 7.5.1 documentation and confirmed with IBM support: MQ 5.3 is first supported with DS TX 7.5.



BocaBurger
<===========================||////////////////|0
The pen is mightier than the sword, but the sword hurts more!

 

[JEMIAZ]

Who do I believe?
IBM Support or IBM Support?

I'd like to believe that 5.3 is not supported to justify a move to TX 8 although thats alot of work to add to a crowded schedule.

I'd like to believe IBM Support but they give me different answers.

I'll return to support for a definitive - written in blood - answer!

Thanks for your prompting Boca Burger
Tim

 

[janhes]

The following ecases exist on the Ascential knowledgebase
G51662 G81615 G72997
All to do with random 2058 errors with MQ
The resolution was
Resolution:
This is a 3rd party s/w problem that needs to be addressed by IBM.

My recommendations are as follows:
1.Make sure the customer is running on the latest MQ*Series CSD.

2.Try and use the retry setting on the MQ*Series adapter (e.g. retry 5 or 6 times at a 2 second interval). The retry may prevent (if not reduce) the likelihood of connection failures occurring.

3.If the above steps don't work, then have them follow the guidelines contained in the following URL:

http://www-1.ibm.com/support/docvie...58&uid=swg21144253&loc=en_US&cs=utf-8&lang=en