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
