| Author |
Message
|
| dertel |
 Posted: Thu Jul 05, 2007 6:29 am Post subject: Specify which instance of cluster queue on put command. |
 |
|
Novice
Joined: 17 Dec 2003
Posts: 15
|
Is there a way to direct a message to a specific instance of a cluster queue?
I have 2 queue managers (LQ05 and LQ06) which are clones. They are passing messages via the broker to a mainframe qm that processes them through the MQ CICS bridge.
I have knowledge in the return broker flow as to which qm should get the returning message. Clustering round robins the messages, so they alternate between LQ05 and LQ06. I need to be able to direct them. I essentially need to be able to specify the remote qm in a broker flow and override the decision that clustering would make.
Other than the the mainframe, all the qms are running on z/linux (as is the broker). The broker and its qm are both at version 6; the other qms are all at version 5. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jul 05, 2007 6:31 am Post subject: Re: Specify which instance of cluster queue on put command. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dertel wrote: |
I essentially need to be able to specify the remote qm in a broker flow and override the decision that clustering would make.
|
You've answered your own question. Specify a ReplyToQMgr on the original request, or put the reply to a remote queue specific to the queue manager you want to talk to.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dertel |
| Posted: Thu Jul 05, 2007 7:33 am Post subject: |
|
|
Novice
Joined: 17 Dec 2003
Posts: 15
|
We've tried ReplyToQMgr with no luck. The mainframe qm (MQ01) has no knowledge of the originating qm (LQ05 or LQ06), so if either of those are specified, it fails with a 2087 (or 2085?), and MQ01 needs to respond to the broker anyway (the broker needs to transform the returning message).
I can see that setting up remote queues would work, but then the broker flows would need to be coded to handle multiple output queues. The LQ05/LQ06 endpoints are assoiciated with WAS (Websphere Application Server) nodes, and our desire is to be able to add those as needed for workload (we have 2 today, but we might have 10 tomorrow). With the remote queue solution, I would need separate remote queues for each WAS server, and separate logic in each flow for each WAS server. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 05, 2007 7:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Ok, confused now. You've got 2 qmgrs in a cluster called LQ05 & LQ06. These could get more instances as your workload scales. There's a broker on machine X which services these qmgrs, passing the requests onto MQ01, which needs to reply via the broker to the correct instance, i.e. whichever orginated the request. There's no direct MQ link between MQ01 & LQ05/6
Assuming I've got that straight, then LQ05/6 sets their ReplyToQmgr when they request. The request goes through the broker, is processed and the message is sent back to the broker. This transforms it and uses an MQReply node to send it back to the relevant node. If the broker's in the cluster with LQ05/6 it'll find it's own way there, it not you need 1 (and only 1) remote queue for each node and no code changes in broker. So when you add new nodes to the cluster in addition to the administrative changes to achieve that, you add a remote queue def to the broker queue manager.
Simple. 
Unless I've misunderstood what you're doing! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 05, 2007 7:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If the MQ bridge is returing a 2085 or 2087, then you need to create a qmgr alias on the mainframe qmgr.
Or you're sending the wrong thing in the ReplyToQmgr. It should be the name of the broker qmgr, not the name of the original requesting qmgr.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 05, 2007 12:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
We have a flow that's working fine in this regard:
gwy->brk(MQInput + MQOutput)->mfr->brk(MQGet + MQReply)->gwy
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jul 05, 2007 1:44 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)
|
| jefflowrey wrote: |
If the MQ bridge is returing a 2085 or 2087, then you need to create a qmgr alias on the mainframe qmgr.
Or you're sending the wrong thing in the ReplyToQmgr. It should be the name of the broker qmgr, not the name of the original requesting qmgr. |
Like Jeff says you need Qmgr Aliases for LQ05 and LQ05 on your mainframe MQ01 to point to BRK Qmgr, a picture always helps (whipped this up quickly so may not be 100% correct )
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| dertel |
| Posted: Fri Jul 06, 2007 5:10 am Post subject: |
|
|
Novice
Joined: 17 Dec 2003
Posts: 15
|
I appreciate the responses; you understand what I am trying to do. I have more questions.
Why would I create qm aliases on MQ01 (the mainframe) for LQ05 and LQ06? My message needs to return via the broker qm, and the ReplyToQMgr in the message that reachs the mainframe will not have LQ05/6. I don't perceive the requirement for MQ01 to be aware of LQ05/6.
For purposes of asking my subsequent questions, allow me to refer to the separate messages in my process as follows:
leg1 - from WAS to broker
leg2 - from broker to CICS
leg3 - from CICS to broker
leg4 - from broker to WAS
Regarding ReplyToQMgr in leg2 (broker to CICS), it would seem that the broker qm (BQ05) would work there, but wouldn't mainframe qm (MQ01) also work? In our dev environment, where we're not using clustering, the flow is using the mainframe qm (which has a remote queue pointing to the broker queue). In this qa level, with clustering, the ReplyToQueue is a clustered queue, and I would expect that to work the same as the remote queue in dev. Can I use either MQ01 or BQ05?
I'm not understanding how the remote queue solution works without modifying the broker flows. I would need to create remote queues on the broker qm; for example, I might create SOA.LQ05.REPLY and SOA.LQ06.REPLY (which would point to SOA.REPLY on LQ05 and LQ06). Wouldn't I need code in the flow, perhaps even separate output nodes for each of these queues, and wouldn't this code need to adjusted when I add LQ07?
Does the MQREPLY node solve my problem of directing the message to the correct WAS server in leg4? The help information states: 'MQReply is a specialized form of the MQOutput node that puts the output message to the WebSphere MQ queue that is identified by the ReplyToQ field of the input message header.' Is it doing that by simply using the queue name without taking the qm into account? If that is the case, I still have my original problem (the queue names on LQ05 and LQ06 are the same). |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 06, 2007 5:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dertel wrote: |
| I'm not understanding how the remote queue solution works without modifying the broker flows. I would need to create remote queues on the broker qm; for example, I might create SOA.LQ05.REPLY and SOA.LQ06.REPLY (which would point to SOA.REPLY on LQ05 and LQ06). Wouldn't I need code in the flow, perhaps even separate output nodes for each of these queues, and wouldn't this code need to adjusted when I add LQ07? |
No, because you're creating queue manager aliases which are queue agnostic and don't refer to a specific queue on the queue manager they're aliasing. And you don't need separate output node, just one node where the queue manager is set dynamically according to the destination required.
| dertel wrote: |
Does the MQREPLY node solve my problem of directing the message to the correct WAS server in leg4? The help information states: 'MQReply is a specialized form of the MQOutput node that puts the output message to the WebSphere MQ queue that is identified by the ReplyToQ field of the input message header.' Is it doing that by simply using the queue name without taking the qm into account? If that is the case, I still have my original problem (the queue names on LQ05 and LQ06 are the same). |
No, it uses reply to queue and reply to queue manager. This is why you need to alias the queue managers to provide a direct route through the cluster.
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Fri Jul 06, 2007 5:20 am; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 06, 2007 5:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
ReplyToQueues don't need to be shared in the cluster - and it causes confusion if they are. When a Reply message is sent, it is fully addressed to the right queue manager using the ReplyToQueue and ReplyToQueueManager name.
The MQReply node is the same as an MQOutput node, except instead of using a Queue name set on the Node, it uses the queue name in the ReplyToQ (and the ReplyToQmgr) in the Message.
There's nothing here that's specific to any of the pieces you are talking to or from - WAS, CICS, Broker. This is all pure MQ routing/name resolution - and it's all based on the Queue name and the Queue Manager name that a particular message is addressed to when it is put.
You need to think of your Leg1 and Leg4 as one request/reply and Leg 2/Leg 3 as another request/reply. WAS sends a request to broker, and provides a ReplyToQ/ReplyToQmgr. Broker sends a reply to that WAS ReplyToQ/ReplyToQmgr. Broker sends a request to CICS and provides a *different* ReplyToQ/ReplyToQmgr. CICS sends a reply to that ReplyToQ/ReplyToQmgr.
You can configure an MQOutput node to act exactly like an MQReply node - by writing code to indicate the message is a Reply msg, and set the destination based on the messages. But the point of the MQReply is so you don't have to write that code yourself.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 06, 2007 12:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
| Quote: |
Regarding ReplyToQMgr in leg2 (broker to CICS), it would seem that the broker qm (BQ05) would work there, but wouldn't mainframe qm (MQ01) also work? In our dev environment, where we're not using clustering, the flow is using the mainframe qm (which has a remote queue pointing to the broker queue). In this qa level, with clustering, the ReplyToQueue is a clustered queue, and I would expect that to work the same as the remote queue in dev. Can I use either MQ01 or BQ05?
|
The point of the QMGR ALIAS here is to set up only the communications between MQ01 and BQ05. You do not have to define any remote queues on MQ01 (mainframe) to send messages to the broker (BQ05).
This is particularly of interest when your flows start multiplying.... As long as the reply to information is provided correctly by the broker you're fine...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
