| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Remote Queue Defs in a cluster |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Fri Feb 15, 2013 10:05 am Post subject: Remote Queue Defs in a cluster |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
This link
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzah.doc/qc10750_.htm
explains that you don’t need Remote Queue Defs inside a cluster when sending messages between QMs inside the cluster. If you want to put a layer of abstraction between the putting app and the clustered queue you can use a locally defined Alias queue. Basic MQ 101.
What I would like to know is are remote queue definitions inside a cluster, that point at local queues defined on other QMs in the cluster, regardless if those local queues are clustered or not, expressly forbidden or allowed.
Here is the scenario:
QM1 and QM2 are not in a cluster. They use regular SNDR/RCVR channels.
Apps connected to QM1 send to QM2 via Remote Q Defs defined on QM1 that aim at QM2.
QM3 and QM4 are in a cluster.
QM1 is then added to that cluster.
QM1 still talks to QM2 the way it always did.
I want to know if I can repoint the existing Remote Q on QM1 (that currently aims at LOCAL.QUEUE.OLD queue on QM2), to LOCAL.QUEUE.NEW on QM3 and QM4.
If yes, what would I put in Remote QM Name of the Remote Q Def? Leave it blank?
If yes, what would I put in the XMITQ parm of the Remote Q Def, SYSTEM.CLUSTER.TRANSMISSION.QUEUE? Or leave it blank?
I know I could delete the Remote queue on QM1 and replace it with a Q Alias on QM1 by the same name, with a TARGQ of LOCAL.QUEUE.NEW. But I’m wondering if its possible to avoid replacing those remote queue defs on QM1 in favor of just altering the remote queue defs?
If anyone has a link to IBM doc that specifically allows are prohibits remote q defs in a cluster from pointing to other local, optionally clustered, queues in a cluster please share that link.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Feb 15, 2013 10:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I would leave both the RQMNAME and the XMITQ blank.
There's no reason it shouldn't work.
There's no specific reason I can think that specifying S.C.T.Q in the XMITQ would cause a problem, either, but it feels safer to not do so. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 15, 2013 10:56 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Hi Peter,
Please only fill in the remote qname (clustered queue name) and leave all other fields blank e.g.
def qr(my.clustered.queue.b) rname(queue.b)
If there is a connection or name resolution problem the message should land on the local DLQ.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
