| Author |
Message
|
| mavey |
 Posted: Fri Apr 15, 2011 9:38 am Post subject: QM1-QM2 to QM1-QM3-QM2 while preserving QM1/2 channel names? |
 |
|
Newbie
Joined: 15 Apr 2011
Posts: 4
|
First, I'd like to say thanks to everybody, because this forum is great for googling around when a problem needs to be fixed ASAP.
I'm competent in performance/security, but advanced MQ intercommunication is not my cup of tea. Let me explain the situation. Typical MQ route for one of our clients is like this:
1) z/OS mainframe with queues: Request = local, Reply = remote.
2) AIX MQ with queues: Request = remote, Reply = local.
I'm at QM2, the mainframe is in WAN across Europe. In reality, HACMP clusters, QM client clusters and redundant cross-QM request/reply connections are involved, but that's irrelevant here. A new dealer is to be connected and they're in a DMZ. They can connect only within the DMZ, so QM2 is inaccessible. The decision is that new MQ servers be placed in the DMZ to allow for this:
1) z/OS mainframe
2) AIX MQ (gateway, just forwarding)
3) DMZ Linux MQ
It's up to me to architect this, turn the QM2 into a gateway (for future templates) and transparently forward messages to a new QM3 in the DMZ (which is also mine and should work like QM2 did on AIX). It has to be done so that MQ object names on the front- and back-end (QM1/3) can stay the same.
This is my fallback setup, it's working fine, but it requires changing channel names on QM1 and QM3:
a) changed QM1 channel names:
SDR: QM1.QM3 -> QM1.QM2
RCVR: QM3.QM1 -> QM2.QM1
b) moved config from QM2 to QM3, but changed channel names and QM1's IP to QM2's IP:
SDR: QM3.QM1 -> QM3.QM2
RCVR: QM1.QM3 -> QM2.QM3
c) new QM2 config:
- 2 XMIT queues "QM1" and "QM3" with...
- 2 SDR channels "QM2.QM1" and "QM2.QM3", respectively.
- 2 RCVR channels "QM1.QM2" and "QM3.QM2"
QM2 XMIT queues are named the same as the target QM's. When QM1 sends a message to QM3 by connecting to QM2 (QM1's SDR channel has QM2's IP), the QM2 sees that it belongs to QM3 and uses the XMIT queue "QM3" to deliver it. Vice versa for QM3 -> QM1.
Alas, channel names on QM1 and QM3 cannot be the same as before. AFAIK, MQ demands that the target RCVR channel has the same name as the source SDR. Because of this, while preserving QM1/3 channel names, I would need RCVR "QM1.QM3" on QM2 to be able to receive messages for QM3 from QM1, but also need SDR "QM1.QM3" on QM2 to be able to send messages from QM1 to QM3. That cannot be done.
I may not be able to make the mainframe people go against their naming standard. They only care about the backend QM1 and the frontend QM3. What's in the middle is unsupported (they never used an indirect route, actually) and they name their channels accordingly, "FRONTEND.BACKEND".
Isn't there some way to define which remote RCVR channel a SDR channel should contact? I just can't come up with anything. Can anybody think of another setup that would make this work under those conditions?
Thanks.[/code] |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Apr 15, 2011 9:49 am Post subject: Re: QM1-QM2 to QM1-QM3-QM2 while preserving QM1/2 channel na |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mavey wrote: |
| Isn't there some way to define which remote RCVR channel a SDR channel should contact? |
| mavey wrote: |
| I may not be able to make the mainframe people go against their naming standard. They only care about the backend QM1 and the frontend QM3. What's in the middle is unsupported (they never used an indirect route, actually) and they name their channels accordingly, "FRONTEND.BACKEND". |
This is hair splitting. If the channels are (in accordance with common practice) named <source queue manager>.<target queue manager> then the fact they don't support the queue manager in the middle doesn't alter the fact their queue manager is connected to it. If instead their channel is named <Application 1>.<Application 2> then this is downright wrong; channels connect queue managers & applications shouldn't know what queues they're using never mind the channels the messages are traversing.
You've done the right thing by hopping the xmitq on the middle box. Everything else is politics.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 15, 2011 9:58 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Nothing says that the names of existing channels have to change.
But you do have to create a new set of channels, and either alter QREMOTES to use a new XMITQ or alter what XMITQ the existing channels use.
So you can do all that you want to do without changing the existing channel names. But the existing channels will just stop being used...  |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 15, 2011 10:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| So you can do all that you want to do without changing the existing channel names. But the existing channels will just stop being used... |
Yes, yes, but the new channels would violate the existing naming convention and hence hit the same problem. But I agree that would avoid changing the names....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 15, 2011 10:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| mqjeff wrote: |
| So you can do all that you want to do without changing the existing channel names. But the existing channels will just stop being used... |
Yes, yes, but the new channels would violate the existing naming convention and hence hit the same problem. But I agree that would avoid changing the names.... |
How would that be true? the names would indicate the points that were being connected, still? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 15, 2011 10:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Vitor wrote: |
| mqjeff wrote: |
| So you can do all that you want to do without changing the existing channel names. But the existing channels will just stop being used... |
Yes, yes, but the new channels would violate the existing naming convention and hence hit the same problem. But I agree that would avoid changing the names.... |
How would that be true? the names would indicate the points that were being connected, still? |
My interpretation of the OP's problem is that the channel existing channels can't be changed / renamed. So they can't reflect the new piggy-in-the-middle queue manager but reflect their final destination (the existing queue manager). And new channels can't be created because whoever's running QM1 doesn't support QM2 & wants no truck with it.
If that's wrong, then my comments are wrong. Obviously enough. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 15, 2011 10:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
My interpretation of the OP's problem is that the channel existing channel QM1.QM3 can't be changed / renamed. So they can't reflect the new piggy-in-the-middle queue manager.
If that's wrong, then my comments are wrong. Obviously enough. |
Yes. But that doesn't preclude creating QM1.QM2 and QM2.QM3 channels on either end.
And all sets of channels (QM1.QM2, QM2.QM3, QM3.QM2, QM2.QM1, QM1.QM3, QM3.QM1) still define the correct endpoints on both sides according to the naming standards. It's just that one set of routes (QM1.QM3, QM3.QM1) is no longer in use. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 15, 2011 10:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
But to return to the first question, can we agree that you can't match a sender channel called QM1.QM3 with a receiver channel called QM1.QM2? But only with a reciever channel called QM1.QM3?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 15, 2011 10:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| But to return to the first question, can we agree that you can't match a sender channel called QM1.QM3 with a receiver channel called QM1.QM2? But only with a reciever channel called QM1.QM3? |
Right.
You can, however, do horrible things like match TWO DIFFERENT QM1.QM3 SDRS to the same QM1.QM3 receiver.
but that way leads to  |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 15, 2011 11:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| You can, however, do horrible things like match TWO DIFFERENT QM1.QM3 SDRS to the same QM1.QM3 receiver. |
Or not use the dotted naming convention and have a channel called QM1. Or FRED.
| mqjeff wrote: |
| but that way leads to |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mavey |
| Posted: Fri Apr 15, 2011 11:19 am Post subject: |
|
|
Newbie
Joined: 15 Apr 2011
Posts: 4
|
Thanks for comments, I hope somebody will have an idea.  Victor you got it right, the problem is to stick the middle MQ in without having to change more than channel IP's on QM1.
It is just politics, but when you're dealing with one of the biggest MQ mainframes in VW and it's dedicated to generating vehicle codes for the whole group, you don't have many options. Their practices are actually OK, it's just they don't want to bring inconsistencies into the configuration. Every production line client of this system in the world is connected to that monster front-end; for them, one exception = trouble.
If they really stuck to their convention "QMa.QMb.n", they'd HAVE to change the channel names to reflect QM2, but they'd sooner force us to avoid the 3rd MQ altogether by port forwarding the two ports on the AIX cluster from the DMZ. I'd hate that, so I'm trying to think of something... |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Apr 15, 2011 3:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mavey wrote: |
Thanks for comments, I hope somebody will have an idea. Victor you got it right, the problem is to stick the middle MQ in without having to change more than channel IP's on QM1.
It is just politics, but when you're dealing with one of the biggest MQ mainframes in VW and it's dedicated to generating vehicle codes for the whole group, you don't have many options. Their practices are actually OK, it's just they don't want to bring inconsistencies into the configuration. Every production line client of this system in the world is connected to that monster front-end; for them, one exception = trouble.
If they really stuck to their convention "QMa.QMb.n", they'd HAVE to change the channel names to reflect QM2, but they'd sooner force us to avoid the 3rd MQ altogether by port forwarding the two ports on the AIX cluster from the DMZ. I'd hate that, so I'm trying to think of something... |
Have you thought at a complete different way of solving your problem.
Like for instance placing an MQIPT server in the DMZ ? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mavey |
| Posted: Fri Apr 15, 2011 3:49 pm Post subject: |
|
|
Newbie
Joined: 15 Apr 2011
Posts: 4
|
| Sure, TCP port forwarding or some higher OSI layer forwarding/proxy is an option. Good tip with MQIPT, didn't know that, looks good, just not exactly what I'd like to use if pure MQ solution could be found. A new product means a lot of extra time and overhead, support issues, etc. But I'll think about it, thank you! |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Apr 15, 2011 3:59 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
IPT is a 'pure' WMQ solution!
_________________
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 |
|
|
| fjb_saper |
| Posted: Fri Apr 15, 2011 7:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| exerk wrote: |
| IPT is a 'pure' WMQ solution! |
We use it, and it requires very little support.
From time to time (once in a quarter?) we bounce the MQIPT server, mainly to clear connections in close_wait state...(netstat -an).
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
