| Author |
Message
|
| mqjeff |
 Posted: Tue Nov 13, 2012 4:18 am Post subject: |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| exerk wrote: |
| I know it's basic intercommunication but the question is whether you have an XMITQ explicitly named QMA or something like QMA.XMITQ - one will work, one will not; you've not really made clear in your posts which it is. |
I think I covered that one!
| Blomman wrote: |
Yes i have xmitq QmA on QmB.
Yes i have told MQ explorer to use QmA. |
|
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Nov 13, 2012 5:13 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mqjeff wrote: |
| exerk wrote: |
| I know it's basic intercommunication but the question is whether you have an XMITQ explicitly named QMA or something like QMA.XMITQ - one will work, one will not; you've not really made clear in your posts which it is. |
I think I covered that one! |
You did, I just echoed it...
| mqjeff wrote: |
| Blomman wrote: |
Yes i have xmitq QmA on QmB.
Yes i have told MQ explorer to use QmA. |
|
"...My real queue manager name is PQM1234 and I qualify all my XMITQs with .XMITQ.TO.PQMnnnn, but for the purposes of posting I'll call it QmA..."  I make no assumptions.
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Nov 13, 2012 5:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| exerk wrote: |
| ...My real queue manager name is PQM1234 and I qualify all my XMITQs with .XMITQ.TO.PQMnnnn, but for the purposes of posting I'll call it QmA..." I make no assumptions. |
Yarh. That's why I suggested stopping the sender and looking at the replytoqmgr. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Nov 13, 2012 5:22 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mqjeff wrote: |
| exerk wrote: |
| ...My real queue manager name is PQM1234 and I qualify all my XMITQs with .XMITQ.TO.PQMnnnn, but for the purposes of posting I'll call it QmA..." I make no assumptions. |
Yarh. That's why I suggested stopping the sender and looking at the replytoqmgr. |
Or DLQ...
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Nov 13, 2012 5:28 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| exerk wrote: |
| mqjeff wrote: |
| exerk wrote: |
| ...My real queue manager name is PQM1234 and I qualify all my XMITQs with .XMITQ.TO.PQMnnnn, but for the purposes of posting I'll call it QmA..." I make no assumptions. |
Yarh. That's why I suggested stopping the sender and looking at the replytoqmgr. |
Or DLQ... |
I think both MQ Explorer and runmqsc will send non-persistent messages. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Nov 13, 2012 5:31 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mqjeff wrote: |
| exerk wrote: |
| mqjeff wrote: |
| exerk wrote: |
| ...My real queue manager name is PQM1234 and I qualify all my XMITQs with .XMITQ.TO.PQMnnnn, but for the purposes of posting I'll call it QmA..." I make no assumptions. |
Yarh. That's why I suggested stopping the sender and looking at the replytoqmgr. |
Or DLQ... |
I think both MQ Explorer and runmqsc will send non-persistent messages. |
I was thinking along the lines of if the XMITQ is not correctly named...
_________________
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 |
|
|
| zpat |
| Posted: Tue Nov 13, 2012 5:43 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
| Blomman wrote: |
| zpat wrote: |
| It's easy to do with MO71. |
Ok, and how is MO71 gonna help me throught the firewall...?
//Blomman |
I didn't say it would. I said that administering one queue manager via another is easy to do with MO71.
Obviously the two queue managers need a MQ channel between them.
Once set up, you can use nearly all the features of MO71 as per normal. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Nov 13, 2012 5:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| exerk wrote: |
| mqjeff wrote: |
| I think both MQ Explorer and runmqsc will send non-persistent messages. |
I was thinking along the lines of if the XMITQ is not correctly named... |
Yes, and what happens when the command server at the remote end tries to send a non-persistent reply message to an xmitq that doesn't exist? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Nov 13, 2012 5:49 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mqjeff wrote: |
| exerk wrote: |
| mqjeff wrote: |
| I think both MQ Explorer and runmqsc will send non-persistent messages. |
I was thinking along the lines of if the XMITQ is not correctly named... |
Yes, and what happens when the command server at the remote end tries to send a non-persistent reply message to an xmitq that doesn't exist? |
I suspect that (yet again) I've learned a lesson here, because I get the feeling that it won't land on a DLQ at the sending end...
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Nov 13, 2012 6:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| exerk wrote: |
| mqjeff wrote: |
| exerk wrote: |
| mqjeff wrote: |
| I think both MQ Explorer and runmqsc will send non-persistent messages. |
I was thinking along the lines of if the XMITQ is not correctly named... |
Yes, and what happens when the command server at the remote end tries to send a non-persistent reply message to an xmitq that doesn't exist? |
I suspect that (yet again) I've learned a lesson here, because I get the feeling that it won't land on a DLQ at the sending end... |
Well, don't take my word for it. My immediate sense is that the command server will get an MQRC !=0 and throw the message away.
but i find that my memory for this level of detail is fuzzier than it should be. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 13, 2012 6:01 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
@mqjeff... Sorry missed the QMA part...
Not enough OJ in the morning... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Blomman |
| Posted: Tue Nov 13, 2012 6:05 am Post subject: |
|
|
Master
Joined: 31 Oct 2006
Posts: 230
|
| bruce2359 wrote: |
| If qma has already punched through the firewall, why can't you get the same firewall access for an admin tool? |
Well its on the the box where QmA is that access through the firewall is allowed...
If my admin tool had access, the no intermediate qmgr administration would be needed. |
|
| Back to top |
|
|
| Blomman |
| Posted: Tue Nov 13, 2012 6:10 am Post subject: |
|
|
Master
Joined: 31 Oct 2006
Posts: 230
|
| exerk wrote: |
| Blomman wrote: |
| exerk wrote: |
| Blomman wrote: |
| Probably what im missing is that the source queuemanger has to be the default queue manager... |
The source queue manager does not have to be a default queue manager but you do need a 'default' path back from the target queue manager:
| Code: |
Queue Manager QMA -
SDR: QMA.TO.QMB
RCVR: QMB.TO.QMA
XMITQ: QMB
Queue Manager QMB -
SDR: QMB.TO.QMA
RCVR: QMA.TO.QMB
XMITQ: QMA |
|
This is basic intercommunication..
| Quote: |
Note: If you are using runmqsc with the -w option, source.queue.manager must be the default queue manager.
|
I dont want to put mqsc commands in a file all the time, not if it is necessary. |
I know it's basic intercommunication but the question is whether you have an XMITQ explicitly named QMA or something like QMA.XMITQ - one will work, one will not; you've not really made clear in your posts which it is. |
I think it is common sense to always name the xmtiq the same name as the qmgr.
It is my sense anyway, may be wrong.
But this what i always do.
Not expecting you to know my sense... |
|
| Back to top |
|
|
| Blomman |
| Posted: Tue Nov 13, 2012 6:16 am Post subject: |
|
|
Master
Joined: 31 Oct 2006
Posts: 230
|
| zpat wrote: |
| Blomman wrote: |
| zpat wrote: |
| It's easy to do with MO71. |
Ok, and how is MO71 gonna help me throught the firewall...?
//Blomman |
I didn't say it would. I said that administering one queue manager via another is easy to do with MO71.
Obviously the two queue managers need a MQ channel between them.
Once set up, you can use nearly all the features of MO71 as per normal. |
Nice, i will look into this, i use MO71 alot but didnt really look if i could use it to solve this.
Maybe i put my question wrong, maybe i should have asked.
Can i use MO71 to admin a qmgr throught a intermediate qmgr?
Or
Can i use MO71 to penetrate FireWalls...
//Blomman |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Nov 13, 2012 6:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MO71 isn't going to use any different method than MQ Explorer or runmqsc to connect and talk to the remote queue manager.
Presumably you've already determined that you can't use a client connection to talk to QmB.
That leaves you with talking to QmB via an intermediate queue manager, regardless of what program you use to support it.
As we said, the only way to make this work is to make sure that the reply messages can be routed back to QmA.
As we've said, in order for this to work, the remote xmitq must be *exactly* the same name as the value put in the replytoqmgr field of the request message.
The easiest way to find out what is in the replytoqmgr field is to stop the sender and look at the outgoing request messages on the xmitq on QmA. |
|
| Back to top |
|
|
|
|
