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 > can't use a solution that eliminates that > possibility. > > Wayne Shutz on mqseries.net suggested ReplyTo > Aliases, which I suppose will > work (see below), but I wish there was a better way, > i.e. allowing the flow > to easily and quickly check environmental stuff so > that it can act > accordingly. > > *********************** > BROKERA and BROKERB are in CLUSTER1. REPLYQ is the > real reply q. > > I would have to define this: > DEFINE QREMOTE(REPLYQ.ALIAS) RNAME(REPLYQ) > RQMNAME(CLUSTER1) > > And then the flow would specify REPLYQ.ALIAS for the > MQMD.ReplyToQueue. When > the message left, it would be tagged in the MQMD > with ReplyToQueue = REPLYQ > and ReplyToQueueManager = CLUSTER. Cool. > > Hmmmm, yeah, I guess that will work. All it means is > for every reply queue > on my brokers, I would then have to create a replyto > alias. (That's alot of > queues, but what the hay) If the flow wants the > reply to come back to the > cluster, it sets the reply to queue to REPLY.ALIAS, > and if it wants it to > come back to the specific broker, then it just codes > the actual reply queue > (REPLYQ) in that field. > > Man, I wish there was a better way. Someone at work > suggested creating a > queue on each Broker called WHO.AM.I, and putting a > persistent message with > unlimited Expiry that would contain pertinent info, > like the broker name. > Any flow that wanted to know the info would use the > MQGET node to open that > queue, and get the message. Then they would have to > roll it back, or put a > copy of it back on the queue. Probably would perform > like a dog, and if the > message gets eaten for good and not replaced, we are > sunk. > ************************************* > > > -Peter > > > > > -----Original Message----- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf > Of Michael Dag > Sent: Wednesday, July 20, 2005 5:45 PM > To: [email protected] > Subject: Re: What cluster am I in? > > > Peter, > From what I recall you work with Gateway > Queuemanager(s) to access > the cluster, so I assume that your replies get back > to the cluster only > always end up on the same queue manager the broker > sent the message from... > > What you need to do on the Gateway Queuemanager(s) > is define X (=number of > Clustered broker Qmgrs) QMAlias definitions that not > only have a blank RNAME > but also have a blank RQMNAME and XMITQ > > This will make sure the original queuemanager name > that was in the MQMD > get's BLANKED and so you can let clustering do it's > work... > > So if you have 2 broker QMGRS called QMBRK1 and > QMBRK2 > > Define on your gateway(s) (that ARE part of the > cluster) a QMALIAS > definition with blank RNAME, RQMNAME and XMITQ ! > > Michael > > -----Original Message----- > From: MQSeries List > [mailto:[EMAIL PROTECTED] On > Behalf Of > Potkay, Peter M (ISD, IT) > Sent: woensdag 20 juli 2005 23:23 > To: [email protected] > Subject: Re: What cluster am I in? > > It makes sense, and my Reply queues are clustered, > but the Replier could be > inside or outside the cluster. If they are outside, > (95% of the time) they > will need to populate the Destination QM value with > the cluster name so my > QMAliases will catch the reply message and route it > back to the cluster. > > > > -----Original Message----- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf > Of Michael Dag > Sent: Wednesday, July 20, 2005 5:15 PM > To: [email protected] > Subject: Re: What cluster am I in? > > > Peter, > It's not about the cluster it's about the Queue, > Make sure the replyToQueue is clustered and the > Path back to the cluster is known. Make sure to > Set the reply to QM to BLANK. > > Clustering will see which Queue is available and > Put the message there through round robin, your > Broker need not do anything special. > > It's late so I hope this made sense... > > Michael > > -----Original Message----- > === 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 ************************************************************************* PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/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 e-mail, 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://listserv.meduniwien.ac.at/archives/mqser-l.html
