| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Is there a way to do pub/sub in an unconventional way |
View previous topic :: View next topic |
| Author |
Message
|
| PeterPotkay |
 Posted: Mon Sep 12, 2011 5:48 pm Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| bruce2359 wrote: |
| Of course naming qmgrs and xmitqs QMxxxx would make the xmitqs easy-to-identify. |
Maybe, but certainly not to scripts unless you maintain and feed in a list of your QMs.
| bruce2359 wrote: |
| I seem to recall that MCAs open xmitqs INPUT_EXCLUSIVE - on z/OS, too. |
Good point.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Sep 12, 2011 8:32 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| exerk wrote: |
| bruce2359 wrote: |
| ...Yes, I know naming an xmitq something not == downstream qmgr is possible, but what are the benefits - other than obfuscation? |
Class-of-service, i.e. some messages using the 'proper' XMITQ (same name as the downstream queue manager) and other messages via a differently named XMITQ. I've seen it done, and I neither endorse nor reject it. |
Yes, in the instance where there are multiple paths between qmgrs there is a need for one of the xmitqs to be named something other than == downstream qmgr name.
_________________
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 |
|
|
| mqrules |
| Posted: Wed Sep 14, 2011 5:28 am Post subject: |
|
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
Thank you all for your comments – much appreciated. Looks like I haven’t made my point very clear.
“XMITQ with the same name as the Qmgr” EQUALS “QMGRAlias with the same name as the qmgr –> pointing to an XMITQ” . There is no difference. Let me illustrate:
QMA requesting <---> replying QMB
When Requesting app specifys ReplyToQ =Q1, RepltyoQMgr=QMA ….
On QMA you need: on QMB:
Option:
XMITQ=QMB XMITQ: QMA
Channel sdr: QMA.QMB Channel rcvr: QMA.QMB
Channel rcvr: QMA.QMB Channel sdr: QMB.QMA
QL: Q1 QL: Q2
RemoteQ: You DON’T need one RemoteQ (for the ReplyToWQ): You DON’T need one
Option 2:
XMITQ=QMA.QMB.X XMITQ: QMA.QMB.X
Channel sdr: QMA.QMB Channel rcvr: QMA.QMB
Channel rcvr: QMA.QMB Channel sdr: QMB.QMA
QmgrAlias: QmgrAlias QMA rnmae(‘’)rqmname(QMA) xmitq(QMB.QMA.X)
QMB rnmae(‘’)rqmname(QMB) xmitq(QMA.QMB.X)
QL: Q1 QL: Q2
RemoteQ: You DON’T need one RemoteQ (for the ReplyToWQ): You DON’T need one
In the above 2 options, you don’t even need to define any remote queue as the name resolution will get you across to the other qmgr. I can think of 2 caveats to either one of the approaches (which are inherently the same):
1- When the app starts using a new remote queue in their app, it will work without us (the MQ admins) even knowing about it. When they come and say to us, I am not getting any messages blah blah blah… the usual complaints, especially in a multi-hop environment, it would be really hard to debug to see what is happening as there are no remote queues.
2- Suppose that the RCVR channel of the QMB is NOT secured. It would be so easy , in a hub-spoke architecture, to connect to get to one of the spokes via the hub qmgr (In MQExplorer, you can connect to it via the Intermediate Qmgr) and admitnier it remotely.
That is why we use the:
Option 3:
On QMA: On QMB:
XMITQ=QMA.QMB.X XMITQ: QMB.QMA.X
Channel sdr: QMA.QMB Channel rcvr: QMA.QMB
Channel rcvr: QMA.QMB Channel sdr: QMB.QMA
QL: Q1 QL: Q2
RemoteQ: You must define it RemoteQ (for the ReplyToWQ): You must define it
Benefits to us:
1- Yes, explicitly defined QR will get its Rname RqmName and XMITQ from its definition. App should leave the RqmName blank when using the RemoteQs. Yes, explicitly defined QR will override. I am all familiar with the programming side of MQ as I used to be a developer for many years.
So, tomorrow, if the app starts using a “new” QR without asking us to define it, it won’t work. I can see the downside to this approach but we like the benefits of using this approach. As I said, no app has been using Dynamic queues as replytoQs yet. When they start using them (dynamic Qs) we will have no choice but use optin 1 or 2 above.
2- Our channels are all secured in Prod. In Test/Dev, we leave most of them unsecured. But no one can remote control the QMGR via another QMGR (as name resulition expects to have an XMITQ or QMGRALias-with-an-XMITQ with the same name as the qmgr they are trying to reach).
Thank you all again for taking the time to respond with your valuable input!
Regards,
MR |
|
| Back to top |
|
|
| mqrules |
| Posted: Wed Sep 14, 2011 7:57 am Post subject: |
|
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
Oooops! Very sorry about the doulbe-posting.... I tried to format the second one better but it did not make any difference. ...
MR |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Sep 14, 2011 7:59 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mqrules wrote: |
Oooops! Very sorry about the doulbe-posting.... I tried to format the second one better but it did not make any difference. ...
MR |
No worries. Duplicate deleted.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 14, 2011 8:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
I'm just a bit confused...
Are you saying that your developers specify both qname and qmgrname in the MQOD at MQOPEN?
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
