Peter, Actually, in my design... you don't need a remoteq definition at all (what was I thinking????). As you get the ReplyTo* info from the MQMD of the request message, all you need is a transmit queue called CLUSTER.X (pointing to the gateway Qmgr) on QM3, and you are good to go.
Ruzi --- "Potkay, Peter M (ISD, IT)" <[EMAIL PROTECTED]> wrote: > Ruzi, > Unfortunatly your design calls for defining a remote > queue def for the > replier to use, and I specifically want to avoid > that. The Replying app is > written as a proper MQ Replier, in that it respects > the MQMD_Report options, > the MQMD_ReplyToQ and the MQMD_ReplyToQM. As such, > it would ignore the > remote q def for the reply queue even if I was > inclined to create them. > > Right now my options are: > #1 > Use the IA06 Support Pack (but its Cat 2) > http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg24000599&loc=en_US&cs > =utf-8&lang=en > > > or > #2 > Create a ReplyTo Alias queue for every ReplyTo queue > defined on the broker. > > > Actually, you just gave me an idea Ruzi. > > What if on every QM outside of the cluster, I create > a QMAlias like this: > DEFINE QREMOTE(FASTCLUSTER) RNAME() > RQMNAME(ActualClusterNameHereDependingOnIfItsDEVorQAorPROD) > XMITQ(ToTheGatewayQM). > DEFINE QREMOTE(NORMALCLUSTER) RNAME() > RQMNAME(ActualClusterNameHereDependingOnIfItsDEVorQAorPROD) > XMITQ(ToTheGatewayQM). > > On the Gateway, I do this: > DEFINE QREMOTE(FASTCLUSTER) RNAME() RQMNAME() > XMITQ(). > DEFINE QREMOTE(NORMALCLUSTER) RNAME() RQMNAME() > XMITQ(). > > Then the WB-IMB flows that want this behaviour hard > code FASTCLUSTER or > NORMALCLUSTER as the ReplyToQM on the outgoing > Request message. The Replier > will pick it up, and send it back to REPLYQ at > FASTCLUSTER. The message > finds its way back to the GW, where the QMALias > there wipes the FASTCLUSTER > or NORMALCLUSTER clean, and the message is free to > round robin. That will > work! > > Benefits: > The flow's ESQL does not need to change between DEV, > QA or PROD. > I do not need to rely on a Cat 2 Support Pack > I do not need to make 100s of ReplyTo Aliases for > every Reply Queue. > If the flow is such that it needs the reply to come > back to the specific > Broker, nothing interferes with the flow allowing > the MQMD_ReplyToQM to > default to the local Broker QM name. > > > I like it! > > Any drawbacks that people can see? > > > -Peter > > > > > -----Original Message----- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf > Of Ruzi R > Sent: Thursday, July 21, 2005 9:00 PM > To: [email protected] > Subject: Re: What cluster am I in? > > > Hi Peter, > > So you have QM1 and QM2 in the CLUSTER1, and REPLYQ > exists on both the qmgrs. You have, say, QM3 > outside > the cluster and it will send the reply back to the > cluster (to any qmgr in the cluster for that > matter). > Let's assume you are using QM1 as a gateway. > > on QM1 you need a qmgr-alias like: > > DEFINE QREMOTE(CLUSTER.X) RNAME(' ') RQMNAME(' ') > > As there is no qmgr called CLUSTER.X it will > resolve > to null. It is only a bogus qmgr name.This means > that > an App on the QM3 can use "CLUSTER.X" as a qmgr name > to send a message to your cluster WITHOUT explicitly > specifying any actual qmgr name, or the cluster > name. > So, on the QM3 you will need a remoteq, like: > > DEFINE QREMOTE(REPLYQ) RNAME(REPLYQ) > RQMNAME(CLUSTER.X) XMITQ(QM1). > > Needless to say you need the SDR/RCVR channel pairs > and the associated XMIT queues between QM1 and > QM3... > > Now, when an App on QM3 opens the remoteq REPLYQ to > send a message, the message goes to the gateway QM1; > this is the crucial part. Once the message is in the > cluster it will be routed to any qmgr hosting > REPLYQ. > > Hope this helps. If you have any more questions > regarding this topic I would be more than happy to > respond however I have limited access to my emails > these days:(.. > > Best regards, > > Ruzi > > --- "Potkay, Peter M (ISD, IT)" > <[EMAIL PROTECTED]> wrote: > > > Paul, could you elaborate? I don't understand. > QMA? > > > > If my Broker QMs are called QM1 and QM2, and they > > are in CLUSTER1, and the > > reply queue is REPLYQ, what would I need with your > > design to allow the flows > > to put a request message where the reply2q was > > REPLYQ, and the Reply2QM was > > CLUSTER1, if the flow is not hard coded to output > > CLUSTER1? In the solution, > > a def cannot exist that would preclude any Broker > > from being able to send > > out a request with its name in the Reply2QM > instead > > of the cluster name. > > > > > > > > > > > > -----Original Message----- > > From: MQSeries List > > [mailto:[EMAIL PROTECTED] > Behalf > > Of Paul Sloan > > Sent: Thursday, July 21, 2005 4:45 PM > > To: [email protected] > > Subject: Re: What cluster am I in? > > > > > > Peter, > > > > We have a similar configuration to the one you > > describe as a site we set up > > 3 years ago. We worked through your issue by > > creating logical QMA'a and > > physical QMA's. The remote queues were the same > on > > each environment level > > and just pointed to the physical QMA which then > > pointed to the actual qmgr. > > That alowed us to do routing via remote queue > > definitions and fully > > qualified mesages. With this approach your broker > > just needs to know the > > name of the service it wants (the logical QMA) and > > your physical QMA > > resolves to the actual qmgr. > > > > Hope this helps. > > > > Paul > > > > -----Original Message----- > > From: MQSeries List > > [mailto:[EMAIL PROTECTED] > Behalf > > Of Potkay, Peter M (ISD, IT) > > Sent: Thursday, 21 July 2005 11:14 PM > > To: [email protected] > > Subject: Re: What cluster am I in? > > > > > > But sometimes the reply *MUST* come back to the > > broker that sent it, so I > === message truncated === Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
