Jim, there are 2 ways to handle this. 1. Set the MaxMessageLength parameter of the queue to the size of the buffer in your app. Anything bigger will either go to the DLQ if its a RCVR MCA trying to put it, or in the case of a local app, it will get the error on the put saying the message is 2 big.
2. Change you wrapper to handle this specific error, and to reissue the get with the larger buffer. But if it can simply reissue the MQGET with a bigger buffer, why didn't it just issue the GET with the biggest possible buffer it can handle in the first place? And sooner or later, a message will land thats bigger than that, unless your app can eat a 100 megger. -----Original Message----- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Monday, February 23, 2004 4:04 PM To: [EMAIL PROTECTED] Subject: Re: "Trigger-looping" CICS transaction We follow those same rules, and have written a wrapper to enforce them. It *almost* always does the trick, but not always. The problem is when the application encounters a message that is bigger than the buffer length that was specified in the MQGET. In that case, a a reason code of 2080 (MQRC_TRUNCATED_MSG_FAILED) is returned. But since the MQGET was unsuccessful, the message's backout counter isn't incremented. If the application decides to terminate due to the error, it will be retriggered only to hit the same message. It almost never happens in production, but in development it's more frequent. I'm thinking about enhancing our wrapper, but I don't exactly know what to do about it. "Adiraju, Rao" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .CO.NZ> cc: Sent by: MQSeries Subject: Re: "Trigger-looping" CICS transaction List <[EMAIL PROTECTED] n.ac.at> 02/23/2004 02:42 PM Please respond to MQSeries List As a design principle, we set the following standard to our developers: Every GET should check the back-out count and if it is greater than BOTHRESH (threshold counter) or hardcoded no.of tries (some cases), application should check for BOQNAME and put the message in that queue if specified else put the message in dead-letter queue. This will prevent the never ending retries / triggering. Cheers Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Wellington - New Zealand Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 -----Original Message----- From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: 24 February 2004 8:45 AM To: [EMAIL PROTECTED] Subject: Re: "Trigger-looping" CICS transaction I have to step back and re-think what you are really asking. I can hardly imagine a scenario that makes sense to just skip over a bad message. You can either use CICS abend/error handlers to detect errors proactively or catch them after a rollback by checking the backout count (as others have mentioned). But in either case, you usually should shuttle the message off to an error queue. Otherwise, you eventually read all the good messages and end up with the bad message right back at the top of the queue again. Since the triggering mechanism goes to great lengths to re-trigger as long as there are messages still on the queue, you really haven't solved the looping problem until the bad message has been removed. Sometimes a transient condition can cause a message to fail. In other words--the right message at the wrong time. The message has a reasonable chance to work if given another chance later. In that case, it may make sense to put the message back to the triggered queue so it has a chance to try again later. But generally speaking, when you encounter a bad message, consider yourself fortunate to have recognized the error while under program control and do something proactive with the message. I hesitate to even bring this up, but you can browse past a bad message. Your main program could browse through the queue, consuming messages only after they have passed muster and leaving the rest for later. But should your program ever close the queue, it would immediately re-trigger and try to re-work the bad messages. Regards, Dennis -----Original Message----- From: Chase, John [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 10:19 AM To: [EMAIL PROTECTED] Subject: "Trigger-looping" CICS transaction Hi, All, No response from thw Web archives server, so apologies if this has been answered recently. Our application folks are testing a program that processes incoming messages, and they are working thru their error-handling routines. In certain circumstances the error routines terminate the CICS transaction without "physically removing" the incoming message from the application queue. Whenever this "early exit" occurs, the same transaction is immediately re-triggered, and since one test situation involved "hard-coding" an error into the program, the same transaction is continually invoked to process the same message as soon as the "previous" transaction terminates. The message queue is defined with trigger-on-first and triggering enabled. Environment is z/OS 1.4, WMQ 5.3.1 and CICS TS 2.2. Anybody have any ideas how we can prevent this "looping" behavior without removing the message from the incoming queue? TIA, -jc- 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 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 communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails. Thank you. 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 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 communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. 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
