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 MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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
