MQSeries.net :: View topic - Trigger On First not a good idea for Batch?

PeterPotkay · Posted: Wed Sep 24, 2003 8:27 am Post subject:

MQSeries 5.3 on z/OS 1.4
A batch application is triggered on first. A message lands on the queue,
causing the depth to go from 0 to 1. The queue manager generates a
trigger message to the init queue. The batch trigger monitor picks up
the trigger message, and starts the application.
The application connects to the queue manager, opens the queue, but the
get fails. It fails in such a way that the message was never removed
from the queue. Truncated message, or perhaps the get call itself
specified invalid options. Either way, the message was never removed
from the queue, so the backout count is not incremented. The app closes
the queue and disconnects.
When the app closed the queue, the QM saw that the queue depth was
greater than zero, and since the queue is triggered on first, the QM
generates another trigger message. As soon as the app ends, the trigger
monitor simply restarts it, and the app will simply error again.
We are in an endless loop, and I can't think of anyway around it.

Actually, I got a problem even if the backout count
is incremented for cases where the message is
pulled off of the queue, but the program abends for
reasons not related to the content of the message.
Even if the program is smart enough to put the
message with a backout count of greater than 0 off
to an exception queue, the next message will also
cause the program to continue to execute where it
will abend again. And not because of the content of
the message. If this is a batch queue, with
thousands of messages landing, than this can
happen thousands of times very quickly, spawning thousands of batch jobs.

What if I used Trigger by Depth? If I set trigger
control to on, and set the Trigger Depth to 1, the
first time a message lands on the queue, the app
would start up. Immediately, MQ turns trigger
control to off on this queue. Now, if the app bombs
before completing successfully, it will not get
retriggered, preventing the endless loop.
But if it does complete successfully, the last thing it
does is set the trigger control back to on.
At the same time we monitor the queue depth. If it
ever rises to depth n, we get alerted and we can
investigate.
Basically a trigger on first app but without the
possibility of an endless loop?
_________________
Peter Potkay
Keep Calm and MQ On