Interesting thought...but then we're not triggering applications any more and we really don't want the native trigger monitor in the fray. The original design amounts to an attempt to trigger-start a trigger monitor. Cannot do.
> -----Original Message----- > From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] > Sent: Wednesday, July 30, 2003 7:46 AM > To: [EMAIL PROTECTED] > Subject: Re: Design Review - custom trigger monitor vs triggered program > > Don, > > Well it's one way for an application to process any number of unknown named > queues... > > > > > > "Thomas, Don" > <[EMAIL PROTECTED] To: [EMAIL PROTECTED] > OM> cc: > Sent by: MQSeries Subject: Re: Design Review - custom > trigger monitor vs triggered program > List > <[EMAIL PROTECTED] > n.AC.AT> > > > 07/30/2003 08:43 > AM > Please respond to > MQSeries List > > > > > > > Peter, > If program XYZ is going to be continuously running, why wouldn't it > be designed to simply do a Get with wait or just periodically check the > queue? I mean triggering is designed to start an application or process, if > it is already running then triggering is redundant. Instead of trying to > tell the consultant why he/she shouldn't do it that way, ask him/her why > they feel the need to essentially waste the resources by triggering an > application that is already running. > > Don Thomas > EDS - PASC > * Phone: +01-412-893-1659 > Fax: 412-893-1844 > * mailto:[EMAIL PROTECTED] > > > > -----Original Message----- > From: Heggie, Peter [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 29, 2003 11:17 AM > To: [EMAIL PROTECTED] > Subject: Design Review - custom trigger monitor vs triggered program > > > 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 > > 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 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
