Hi Pete ! Long time... After the program processes the Queue named in MQTMC2, does it close the queue ? If not, then MQ will not issue a new trigger message. Is the program multi-threaded? if not, then you're causing a bottle neck for other trigger messages for other queues.
It might be more efficient since MQ doesn't have to load a program to process the queues, but depends upon how frequently it gets scheduled. I assume it's TRIGGER FIRST. Phil "Heggie, Peter" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] NGRID.COM> cc: Sent by: MQSeries Subject: Design Review - custom trigger monitor vs triggered program List <[EMAIL PROTECTED] n.AC.AT> 07/29/2003 11:16 AM Please respond to MQSeries List Hello all - would appreciate your responses on this one. We have someone who wants to use a custom trigger monitor to both read the init queue message and process the application queue message. It would be a long running process, on AIX, that waits forever (loops) on the init queue. When a message arrives there (trigger message), it extracts the queue name from the MQTMC2 and then opens the application queue and processes the message. Then it goes back into the loop. Setup - A trigger monitor is started at MQ startup time, pointing to a specific init queue. The first message coming into the application queue triggers normally - MQ writes a trigger message to the init queue and the native MQ trigger monitor starts program XYZ according to the process definition. The program XYZ is also a trigger monitor, a custom trigger monitor. Program XYZ has been passed the MQTMC2, so it reads it to get the application queue name. It opens the application queue, reads and processes the message and closes the application queue. It then goes back into a loop where it reads the init queue. Because program XYZ has the init queue open, MQ will not invoke another instance of program XYZ. Every time another message arrives on the application queue, program XYZ will get another trigger message. This is not a classic trigger configuration, but are there problems with it? The trigger monitor started at MQ startup time is a long running process that basically feeds program XYZ trigger messages. Program XYZ is also a long running process that monitors the init queue. To shutdown the program, you have to treat it the same way as a trigger monitor - disable the init queue for Get, but that's not a very bad thing. I am used to the simplicity of a trigger monitor that starts an application program, that reads application messages until No-More-Messages, and gets triggered again when needed. That seems more efficient, but is it? Peter Heggie National Grid, Syracuse, NY This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. 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 for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates. 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