| Author |
Message
|
| mqrules |
 Posted: Fri Sep 09, 2011 11:57 am Post subject: Is there a way to do pub/sub in an unconventional way |
 |
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
In our environment, our XMITQs don’t have the same name as the qmgr they are for. They are named like QMA.QMB.X . This way, we force the app to use the explicitly defined remote queues. As a result we have more control over the MQ environment. There has not been any use of dynamic queues for ReplyToQs. We don’t use qmgrAlias – especially the kind with an XMITQ. This has been working just fine up until now. However, we are starting to utilize pub/sub of feature for the first time. MQ is v7 on UNIX.
Here is the scenario:
qmgr: MQA sdr/rcvr<===>srd/rcv qmgr: MQB (child of MQA) sdr/rcvr<====>sdr/rcvr qmgr: MQC (Child of MQB) and PSMODE is enabled on all.
There are channels between them as shown above.
Is there a way to use pub/sub without having to create an xmitq with the same name as the qmgr? In other words, I don’t want to create a qmgrAlias (with an xmitq) or just an xmitq with the same name as the qmgr like below:
On MQA: def ql(QMB) usage (xmitq)….
On MQB: def ql(QMA) usage (xmitq)….
def ql(QMC) usage (xmitq)…
On MQC: def ql(QMB) usage (xmitq)….
You may have comments or questions regarding the standard that we have been using, but I just don’t want to go down that road here… at least not in this thread, please. I just need to know if there is a way to do it without using the xmitq having the same name as the qmgr.
Your input would be much appreciated.
TIA. MR |
|
| Back to top |
|
 |
| mqrules |
| Posted: Sat Sep 10, 2011 3:49 pm Post subject: |
|
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
I would appreciate your response, please...
Thanks,
MR |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Sep 10, 2011 5:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqrules wrote: |
I would appreciate your response, please...
|
Speaking personally, I didn't respond because I don't think there's a way. IMHO the queue managers will need a way to resolve the routes to the subscribers, and that requires something named for the queue manager.
The other important point is we're not a support desk with an SLA or any requirement to respond. Don't bump posts if you feel ignored, especially when you post late on a Friday. We all have day jobs, social commitments and lives outside WMQ & the forum.
Well, not me clearly, but most of us.
If you want a fast, guaranteed response raise a PMR. You have that right, it comes with your license fee; it's not just for when the software crashes.
I think IBM's view on this would be informative. It's an interesting problem you have; I think your desperately controlling standard just bit you (no dynamic reply queues???) and I'd like to know if there is a solution for you.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqrules |
| Posted: Sat Sep 10, 2011 6:36 pm Post subject: |
|
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
Thank you, Vitor.
And have a great weekend!
MR |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Sep 10, 2011 7:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Well you can either have a cluster or define a qmgr alias.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Sep 10, 2011 8:55 pm Post subject: Re: Is there a way to do pub/sub in an unconventional way |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| mqrules wrote: |
| In our environment, our XMITQs don’t have the same name as the qmgr they are for. |
There is no requirement that xmit queues be named the name of the qmgr at the receiving end of the channel. This is a recommended practice.
| mqrules wrote: |
| They are named like QMA.QMB.X. |
This is not an unreasonable name for an xmit queue.
[edit]
But, why did you decide not to follow the recommended practice of naming the xmit queue the same name as the downstream qmgr?
[/edit]
| mqrules wrote: |
| This way, we force the app to use the explicitly defined remote queues. |
This way? vs. what other way? The app explicitly opening the xmitq?
| mqrules wrote: |
| As a result we have more control over the MQ environment. |
More control is usually achieved with security rules that restrict apps to specific QRemote definitions.
[edit]
I don't understand the points you are making here.
An application only needs to know a queue name for MQOPEN - and for distributed queuing this name can be a QAlias or QRremote definition. Applications do not need to know the name of a transmission queue, or the name of the qmgr, or the local queue name at the receiving end of a channel.
[/edit]
_________________
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 |
|
|
| Vitor |
| Posted: Sun Sep 11, 2011 6:44 am Post subject: Re: Is there a way to do pub/sub in an unconventional way |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
I don't understand the points you are making here.
|
My reading of the OP's OP is that:
a) He knows it's non-standard and not recommended, and doesn't want to get into that
b) Now there's a requirement for pub/sub (where there's no application that can be compelled to open a given object) he's trying to work round it without creating qmgr alias queues (which were specifically mentioned in the OP as a considered and not wanted option) or a cluster.
Which is not only the mother of all queue manager aliases (!), but a serious effort in a large point to point as described here, but given the obsessive control built into their existing system would probably make their management foam at the mouth.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Sep 11, 2011 7:02 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
I agree with your read of the OP, Vitor. But I remain skeptical of the OPs position that security and management control is increased by naming xmitqs something other than the name of the downstream qmgr. And that xmitq naming somehow forces apps to specific QRemote definitions.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Sun Sep 11, 2011 7:40 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| bruce2359 wrote: |
| And that xmitq naming somehow forces apps to specific QRemote definitions. |
If the XMITQs are named something other than the remote QM, and there is no QM Alias definition, then the only way the app on the sending QM can send a message to the remote QM is via a predefined remote q definition. If that's the goal (apps only use predefined remote queues to get to a remote QM), this accomplishes that. There are other, and arguably better, ways of accomplishes the same thing, but this does do the trick. But you take the good with the bad, the bad being the OP's dilemma, not being able to use dynamic reply queues, having to pre define a remote q pointing back at every predefined reply queue, etc. Personally I don't like "crippling" your MQ infrastructure like this and not allowing MQ name resolution to work its magic. They should use security to insure apps use MQ objects they way they are intended.
If the OP will not or can not use typically named XMITQs, or QM Aliases, then I can't think of any other way besides putting all the QMs into one MQ cluster (like FJ said) and get busy defining Alias queues for everything, because you will need to restrict app access to the SYSTEM.CLUSTER.TRANSMIT.QUEUE to prevent them from being able to put to any queue on any QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Sep 11, 2011 11:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Sep 11, 2011 1:14 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| I remain skeptical of the OPs position that security and management control is increased by naming xmitqs something other than the name of the downstream qmgr. |
So do I. And even the OP seems skeptical. But he's trying to get it to work in the constraints he has, not discuss the existing architecture.
Which as I indicated above is IMHO not going to work out for him. For the reasons so ably outlined here.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Sep 11, 2011 1:21 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
As of this date, I've yet to hear a good reason to name an xmitq something other than the == name of the downstream qmgr.
And when I say 'good reason,' this does not encompass 'established naming standards.' A naming standard that doesn't offer anything net new is pointless.
Yes, I know naming an xmitq something not == downstream qmgr is possible, but what are the benefits - other than obfuscation?
_________________
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 |
|
|
| exerk |
| Posted: Sun Sep 11, 2011 1:40 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| 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.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Sun Sep 11, 2011 5:44 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
By fronting the XMITQ (named something other than the remote QM name) with an Alias queue (that is named after the remote QM), you get some of the same benefits you get when you front any other queue with an Alias. For example, on z/OS, it allows you to allow apps to put to the XMITQ but not get from the XMITQ. If you are dealing with dynamic reply queues you need to allow apps access to resolve to the XMITQs directly (not via a predefined remote q).
If all your xmitqs have a similar name, like QM1.XMITQ, QM2.XMITQ, QM3.XMITQ, etc, it allows you to set up generic monitors (alert on all the *.XMITQ queues). If all the XMITQs end in .XMITQ it makes it easier to identify all your XMITQs when looking at a list of queue names. (Yes, I know there is a parameter that can tell you if a queue is set up as an XMITQ.)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Sep 12, 2011 4:31 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Of course naming qmgrs and xmitqs QMxxxx would make the xmitqs easy-to-identify.
I seem to recall that MCAs open xmitqs INPUT_EXCLUSIVE - on z/OS, too.
_________________
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 |
|
|
|
|
