We have a Hub and Spoke here including IMS bridges, and we rely heavily on the fact that the QM that is putting a message will fill in its own name in the Reply2QM field if it is blank.
Any QM that has an app that is doing an MQPUT fills this value in. If SPOKE1QM puts a request message with a blank Reply2QM, SPOKEQM1 fills his own name in. If the request goes over to SPOKEQM2, and the app their puts a reply, and leaves the Reply2QM of the reply message blank, then SPOKEQM2 fills in his own name. The replying queue manager DOES fill in this value, provided that that the replying app does muddle things up by filling in some garbage there. A favorite "shortcut" of programmers coding replying apps is to populate the MQMD of the reply message with the MQMD of the request message. Ugh. It cause messes like this. Always init your MQMD before any MQGET or MQPUT. Does this answer your question, or I am missing something? -----Original Message----- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2003 2:05 PM To: [EMAIL PROTECTED] Subject: md.ReplyTo.. processing - why? I was testing my IMS Bridge code on another platform and discovered that my understanding of how MQ processes the md.ReplyToQMgr and ReplyToQ fields was deficient. I naively assumed that if I left the ReplyToQMgr field blank, and specified the ReplyToQ, the target queue manager would resolve the ReplyToQ and send the reply message along it's merry way. I discovered that, in fact, the local queue manager processes these fields. If I specify the ReplyToQ, the local QM looks for a definition, and if he can't find it, he fills in his own name in the ReplyToQMgr field. If he does find a remote queue definition, he not only fills in the ReplyToQMgr field with the Remote Queue Manager name from that definition, he also REPLACES the ReplyToQ field with the Remote Queue Name from that definition. It strikes me that this design increases the administrative burden if I am designing a 'hub-and-spoke' application where I might want reply messages to be processed on some 3rd queue manager. If I want to be able to change the system processing the reply messages, I don't want to have to touch the other spokes. (I understand that defining the ReplyToQ on QMSpoke1 as a Remote Queue pointing to the QMHub system and it's associated transmission queue is a one-time step - the hub will then find that the ReplyToQ is a remote queue on QMSpoke2, and send it along). It just seems to me that it's a better design to have the ReplyTo fields resolved by the queue manager that actually has to send the replies. "Late binding" provides more flexibilty, IMHO and reduces administrative work. I don't expect this behavior to change. Change would probably break some existing applications... Anybody have any thoughts on this? Bill Beinert Systems Programming Con Edison (212) 460-4853 When they took the fourth amendment, I was quiet because I didn't deal drugs! When they took the sixth amendment, I was quiet because, I was innocent. When they took the second amendment, I was quiet because I didn't own a gun! Now they've taken the first amendment, and I can say (or do) nothing about it. The Second Amendment is in place in case they ignore the others. MODWN DAbE 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