Hi Bill,
the existing design works for both the common case, and for directing a
response to some other queue manager.
It is important to have the queue manager fill in its own ReplyToQMgr
field. Imagine a network with >1000 windows queue managers connected to a
hub. With the current implementation, the queue managers can all be clones,
and the replies go to the correct place because of ReplyToQMgr. With the
alternative proposal, each queue manager would have to have unique reply
queue names defined, and there would also have to be Remote Queue
Definitions of each of these reply queues at the hub. When I have 4 or 5
applications on each of the windows servers, each with its own reply queue,
it becomes unwieldy very quickly. This also shows that the additional
administration is not just at the hub. I would have to custom tailor every
queue manager, instead of cloning them.
On the other hand, you can use the existing design and get your hub to
route responses as well, simply by specifying the target hub queue manager
in your ReplyToQMgr. This will cause the hub to route responses using its
own definitions, thus achieving your goal.
You also have the third mechanism, where the name of an QR is put into
ReplyToQ, and the sending queue manager substitutes the Q and QMgr from
that definition into the MD.
Regards,
Neil Casey.
|---------+---------------------------->
| | "Beinert, |
| | William" |
| | <[EMAIL PROTECTED]|
| | OM> |
| | Sent by: MQSeries|
| | List |
| | <[EMAIL PROTECTED]|
| | n.AC.AT> |
| | |
| | |
| | 04/07/2003 06:38 |
| | Please respond to|
| | MQSeries List |
| | |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: md.ReplyTo.. processing - why?
|
>--------------------------------------------------------------------------------------------------------------|
I think we both understand what is happening.
Probably 99% of applications want the reply to come back to the sending QM
(the word reply kind of implies that...).
But if the sender QM did NOT fill his own name in, then the hub would have
to get the QM name from the remote q definition on the hub. So all your
adminstration is at the hub.
Just as a sample application, suppose my Windows QM sends a message
updating a DB on OS/390. He specifies a ReplyToQ over on a Unix box where
the auditors watch with beady eyes...
Bill
-----Original Message-----
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 03, 2003 3:41 PM
To: [EMAIL PROTECTED]
Subject: Re: md.ReplyTo.. processing - why?
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
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
