| Author |
Message
|
| carolhara |
 Posted: Sun Aug 22, 2010 7:03 am Post subject: Can I connect two queue managers that has the same name? |
 |
|
Acolyte
Joined: 02 Oct 2007
Posts: 56
|
Hello! =)
I wanna send messages from queue manager A in box 1 to queue manager A in box 2.
I´m not sure if I´m getting this right but my Remote Queue Manager (in remote queue definition) can´t have the same name of my local queue manager? Is that it? =(
How can I manage it?
Thanks! |
|
| Back to top |
|
 |
| carolhara |
| Posted: Sun Aug 22, 2010 7:18 am Post subject: |
|
|
Acolyte
Joined: 02 Oct 2007
Posts: 56
|
The reason code was 2087: MQRC_UNKNOWN_REMOTE_Q_MGR.
I believe I have set the communication all right.
- Transmission queue has the same name as my remote queue manager: A.
- Sender channel using transmission queue A and running. |
|
| Back to top |
|
|
| zpat |
| Posted: Sun Aug 22, 2010 8:11 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
why would you even want to try?
Use different names |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Aug 22, 2010 8:42 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The reason code was 2087: MQRC_UNKNOWN_REMOTE_Q_MGR. |
The ReasonCode from what? What command or application program did you use?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| carolhara |
| Posted: Sun Aug 22, 2010 8:47 am Post subject: |
|
|
Acolyte
Joined: 02 Oct 2007
Posts: 56
|
| Got this reason code from MQ, when i tried to test it using "Put test message" on my remote queue. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Aug 22, 2010 8:59 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
Post your QRemote definition here.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| carolhara |
| Posted: Sun Aug 22, 2010 9:31 am Post subject: |
|
|
Acolyte
Joined: 02 Oct 2007
Posts: 56
|
Ok, Bruce, here it is:
DEFINE QREMOTE ('QR.MAINFRAM.OPEN.01') +
* ALTDATE (2010-08-20) +
* ALTTIME (21.18.30) +
DESCR('PPRO') +
PUT(ENABLED) +
DEFPRTY(0) +
DEFPSIST(NO) +
SCOPE(QMGR) +
XMITQ('CORP') +
RNAME('QL.MAINFRAM.OPEN.01') +
RQMNAME('CORP') +
CLUSTER(' ') +
CLUSNL(' ') +
DEFBIND(OPEN) +
CLWLRANK(0) +
CLWLPRTY(0) +
REPLACE
My queue manager name is CORP
So is my xmitq.
Both queue managers are running in W2k3, MQ 6.0.
Thank you! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Aug 22, 2010 9:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
A solution:
1) alter your QRemote definition RQMNAME(OTHER.CORP)
You should now be able to successfully put a message to the xmit queue. If the channel is running, the message will end up in the DLQ of the other CORP because the XQH that travels with the message will identify an unknown OTHER.CORP qmgr. No problem. Read on.
2) on the other COPR qmgr down the network, create a queue-manager alias
DEFINE QR(OTHER.CORP) +
RQMNAME(CORP)
This will resolve the XQH qmgr name OTHER.CORP back to CORP on the downstream CORP qmgr. The next put should (will) work fine.
IBM strongly recommends that there not be qmgrs with the same name in the network. You can see the complications that arise. Duplicate qmgr names in mq clusters add even more complication.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Aug 22, 2010 9:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It's a really really bad idea to have two queue managers with the same name that are talking to each other.
It's a doubly-bad idea to have two queue managers with the same name in the same MQ Cluster.
You really need to stop right now, and recreate one of the two queue managers with a new name.
Whatever purpose you are trying to achieve with this is solvable in a better way.
That said, you probably can do what you're trying to do, but not with the RQMNAME() property filled in.
ETA: What you're asking is equivalent in a larger respect to asking "Is it possible to drive the wrong way down a one-way street." Yes, it's possible. Yes, it's possible to do so without hitting any other cars or getting a traffic citation. Yes, it's a very very bad idea. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Aug 22, 2010 9:47 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
... completely with mqjeff.
But if you can't delete/redefine a new qmgr name (been there, done that), you can circumvent the name resolution issue as I described above. Keep in mind that no good comes from having duplicate qmgr names; and it only gets worse in clusters, multi-hopping and hub qmgrs.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| carolhara |
| Posted: Sun Aug 22, 2010 10:20 am Post subject: |
|
|
Acolyte
Joined: 02 Oct 2007
Posts: 56
|
| bruce2359 wrote: |
A solution:
1) alter your QRemote definition RQMNAME(OTHER.CORP)
You should now be able to successfully put a message to the xmit queue. If the channel is running, the message will end up in the DLQ of the other CORP because the XQH that travels with the message will identify an unknown OTHER.CORP qmgr. No problem. Read on.
2) on the other COPR qmgr down the network, create a queue-manager alias
DEFINE QR(OTHER.CORP) +
RQMNAME(CORP)
This will resolve the XQH qmgr name OTHER.CORP back to CORP on the downstream CORP qmgr. The next put should (will) work fine.
IBM strongly recommends that there not be qmgrs with the same name in the network. You can see the complications that arise. Duplicate qmgr names in mq clusters add even more complication. |
It worked! 
Thank you!
Well.. I really REALLY cannot recreate my qmgr... But thank you all for replying! |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Aug 22, 2010 1:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| carolhara wrote: |
| It worked! |
I'm glad
| carolhara wrote: |
| Well.. I really REALLY cannot recreate my qmgr... |
Try really, REALLY, REALLY hard. I echo the comments of my most worthy associates. 2 queue managers with the same name is a first class ticket to complication and confusion. Under ideal circumstances. Under less than ideal circumstances (like an application trying to use the set up) it rapidly becomes a pain in the neck.
If your set up ever moves from point to point to a WMQ cluster, it stops being a pain. And turns into a huge pile of just-will-not-work.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Aug 24, 2010 3:20 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqjeff wrote: |
| It's a really really bad idea to have two queue managers with the same name that are talking to each other. |
Add 2 more "really"s from me.
carolhara, you have me wondering, why would anyone want to do this? It's advised against in the MQ manuals (can't find where at the moment) and is widely known to be bad practice. Why do it? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 24, 2010 8:14 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
| If your set up ever moves from point to point to a WMQ cluster, it stops being a pain. And turns into a huge pile of just-will-not-work. |
Worse than just-will-not-work: it may become so bad that the existing part of the cluster stops working. I had been called in one afternoon on an emergency because the cluster was behaving badly...
What had happened is that an existing qmgr back up was used to bring a new qmgr into the cluster, but the cluster receiver definition had not been changed... This creates just the same type of scenario...
You really really really want to make sure that each qmgr in your cluster has a unique name and a unique cluster receiver channel name.
It is just good practice to extend that to the whole qmgr network.
Note: We are speaking here about active qmgrs and not multi-instance qmgrs or disaster recovery qmgrs. In any of the previous cases there is only 1 qmgr with the same name active in the network at any given moment in time....
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
