John,
The other option you could use if you have to leave the message on the queue (if it can't be
processed because of some errors and can't be put away) and to avoid the looping is to use MQSET to disable triggering
just before the MQCLOSE in the case not all MQGETs were completed. You should probably have your
CICS transaction issue an alert since the trigger would then be disabled and would not re-start by itself.
Using the trigger interval as Peter mentioned is a solution to re-start the triggering process (providing the trigger has not
been disabled), unfortunately it tends to mask any underlying problems that need attention.
So basically if a message can't be processed, you probably have the following options:
1. Retry until the message can be processed (loop)
2. Put the message that can't be processed away to be able to keep processing the other messages
(this won't work if message sequencing is important)
3. Stop the process and issue an alert
Oliver.
| "Chase, John" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]> 02/20/2004 03:03 PM
|
To: [EMAIL PROTECTED] cc: Subject: Re: "Trigger-looping" CICS transaction |
-----Original Message-----
From: Potkay, Peter M (PLC, IT)
"In your case, by leaving a message on the queue and terminating your CICS
transaction, the above
condition would never been met again, meaning that the trigger would never
start the CICS transaction again"
You can set the TriggerInterval to a reasonable value, and once that time
expires AND a new message lands, you will get retriggered, even though the
depth is not going from 0 to 1.
================================
Yes, we've done a little experimenting with that and observed that it works
as you describe. Problem is that the newly-triggered transaction has no
"prior knowledge" of the previous transaction's misfortune, nor of the fact
that the message that caused the misfortune is still first in the queue.
Thus, the newly-triggered transaction would encounter the same misfortune,
take the same "early exit" and leave the queue to accumulate new messages
until "the second Tuesday of next week".
I gather from Oliver's reply that the triggered transaction is *obligated*
to remove the message from the "incoming" queue unconditionally, and "do
something" with it even if "something" turns out to be "wrong".
-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
