thanks...
"Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 01/10/2003 05:21:53 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: Remote Queues I always define remote queue defs, except on the replying side of a request/reply scenario. The replying application will always have Reply2Queue and Reply2QueueManager info from the request message. On day one where there is only 1 requestor, I suppose it wouldn't be a big hassle to make the remote queue def to point back to the (permanent) reply queue on the requestor's QM. But the nice thing about not having remote queue defs on the replying side is if the app is coded to dynamically respect the Reply2Queue and Reply2QueueManager info, you can have more and more requestors send messages in, and not have to make any admin or coding changes on the replying side as new requestors come on board. Also, any of the requestors can now use dynamic reply queues. On the requestor's side, I always use the remote defs. The name of the remote queue def is the same from DEV to QA to PROD, so as the app migrates between the testing levels, there is no need to change code or input properties files to simply accommodate the Queue Manager's name changing between the testing environments. Peter Potkay -----Original Message----- From: Tim Armstrong [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 8:22 PM To: [EMAIL PROTECTED] Subject: Re: Remote Queues Except that you can wind up with hundreds of definitions, queue manager aliasing is kind of nice for avoiding that. Someone else mentioned hardcoding of names I would have thought that the actual names of destination queue and queue manager should be in a configuration file read by the program not hard coded. Also if you take proper advantage of MQ's clustering features then you have no need to create remote queue definitions it's all done automatically. I realise that MQ clustering used to have its own problems but its pretty stable now. Regards Tim A Randy J Clark <Randy_Clark@AHM. To: [EMAIL PROTECTED] HONDA.COM> cc: Sent by: MQSeries Subject: Remote Queues List <MQSERIES@AKH-WIE N.AC.AT> 10/01/2003 08:49 Please respond to MQSeries List I am asking for some opinions on sending to remote queues without having a remote queue definition on the sending queue manager just specifying remote qmgr and remote queue name in the MQOPEN. Usig this method. In the ObjectName field of the MQOD structure, specify the name of the remote queue, as known to the remote queue manager. In the ObjectQMgrName field, specify either: The name of the transmission queue that has the same name as the remote queue manager. Note that the name and case (capitals, lower case or a mixture) must match exactly. The name of a queue manager alias object that resolves to the destination queue manager or the transmission queue. This tells the queue manager the destination of the message as well as the transmission queue it needs to be put on to get there. I know there are or maybe times when you "have to" do it this way but overall I am not crazy about the lack of documentation involved using this method. Seems to me even if the sending application is not going to create and use a remote queue def on its own local Qmgr one should or maybe should exist just for documentation purposes. Without this it seems there is no reasonable way to know exactly what is being sent between Qmgrs. Any comments?? As you can tell I think there should be I know an extra object created even if not used just for documentational purposes otherwise when ask what is going between these two qmgrs I have no idea. 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, 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 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
