"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"
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.
-----Original Message-----
From: Oliver S Fisse [mailto:[EMAIL PROTECTED]
Sent: Friday, February 20, 2004 1:47 PM
To: [EMAIL PROTECTED]
Subject: Re: "Trigger-looping" CICS transaction
John,
My guess is that you triggering your CICS transaction on FIRST ?
If that's the case then, you need to be aware that MQ on the MQCLOSE from the CICS transaction
will check the queue depth to make sure the queue is empty. If the queue is not empty it will re-trigger
the transaction. This is done to prevent that the triggering mechanism on FIRST stops.
Remember that the main condition to trigger on FIRST is when the queue depth goes from 0 to 1.
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.
It is the CICS transaction responsability to process all messages on queue once it is triggered on FIRST.
If a message cannot be processed, it must either be put on the DLQ or on a backout queue so the
remaining messages on the queue can be processed and the queue emptied.
Hope this helps.
Oliver Fisse.
"Chase, John" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>02/20/2004 01:19 PM
Please respond to MQSeries List
To: [EMAIL PROTECTED]
cc:
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
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.
