Pavel, could you expand on why you think that defining a default dead letter queue is a "bad thing"?
When I define a QM I always use -u SYSTEM.DEAD.LETTER.QUEUE. I'd agree on all the other things as being "sins", though whether they are "deadly" or merely "venal" is possibly arguable (I'd go for deadly myself). Dave -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Pavel Tolkachev Sent: 30 July 2003 14:18 To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Thanks Don! I thought I was the only one and so was keeping the embarassed silence :-). In my personal list of bad things to do the unfounded use of triggering (and when is it actually well founded?) sits right next to defining default queue managers, dead letter queues and couple of other things like breaking the guarantees of natural order of messages in queues and then using groups to get things together. Just as a side note.. Pavel "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 e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 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
