Randy, I think you've answered your own question -- it all depends on your environment and applications.
-----Original Message----- From: Randy J Clark [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 12:42 PM To: [EMAIL PROTECTED] Subject: Re: Remote Queues I should clarify - I was not talking about hardcoding per se but using the replytoqmgr and replytoqueuename and not defining them on the replying side qmanager. I know these are mutually exclusive we have hundreds of flows and only about 3 or 4 have taken this approach and everytime there is a problem it kinda stumps us for a bit because we can not even find the definition for the queue they are talking about - then we say oh ya its not required and they have to go back to their program and find the complete queue name for us. Doing this there is no visibility to the flow inside of MQ when looking at definitions - you know there is a channel and an xmitQ queue but if someone asked you what these are used for other than sending messages all you could do is shrug your shoulders. we also have had to add multiple channels to service some message flows when we did this all we had to do create the channels and xmitQ's and modify the RemoteQdefs and no application changes were required this was a lifesaver. Tim Armstrong <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 01/09/2003 05:21:52 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: 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 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 and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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
