| Author |
Message
|
| smeunier |
 Posted: Fri Jun 23, 2017 8:27 am Post subject: MQRC 2087 not able to resolve based on needs |
 |
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
This seems like a straight forward issue, but is has wrangle me into submission of this posting.
Operating on Linux Red Hat Enterprise Linux Server release 7.3
MQ Version 8.0.0.4
I'm having name resolution issue for ReplYToQmgr field. The only way I can get it to work, is to either specify the Remote QMGR in the QR definition or to specify it as the xmitQ in the Remote definition. Since I need the reply to fairly independent and use the ReplyToQmgr (the reply to QMGR could be different based on where the message came from). Here are the base definitions:
DEF QR(TEST.REPLY.Q) RQMNAME(' ') RNAME(' ') XMITQ(BTVLMQP01)
DEF QR(MBD1) RQMNAME('MBD1') RNAME(' ') XMITQ('BTVLMQP01')
DEF QL(BTVLMQP01) USAGE(XMITQ) TRIGTYPE(FIRST) TRIGGER
The message header has. ReplyToQmgr= MBD1
ReplyToQueueName= TEST.REPLY.Q
The path of the message is: QMGRA -> BTVLMQP01 -> MBD1
BTVLMQP01 has a QR Alias to MBD1 to forward the message on to the final destination
It is my understanding, that the ReplyToQmgr field from the message would be used for name resolution, from which it should use based on the QR Alias(MBD1). In fact, I have the type of setup working in another instance and it works just fine.
Scratching my head on this one, as I know it should work but doesn't! The MQMD replytoQmgr does not seem to be getting resolved?
Thoughts suggestions? |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Fri Jun 23, 2017 8:39 am Post subject: Re: MQRC 2087 not able to resolve based on needs |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| smeunier wrote: |
It is my understanding, that the ReplyToQmgr field from the message would be used for name resolution, from which it should use based on the QR Alias(MBD1). In fact, I have the type of setup working in another instance and it works just fine.
Scratching my head on this one, as I know it should work but doesn't! The MQMD replytoQmgr does not seem to be getting resolved? |
That would only be true if the application doing the reply issues an MQOPEN (or MQPUT1) against the ReplyToQmgr value.
Note: The MQMD ReplyToQmgr field is not modified or updated as a message traverses an MQ environment.
Did you create a Queue Manager Alias for that particular queue manager name on the queue manager where the replying application is connecting to? If not, then that is the reason for 2087.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Fri Jun 23, 2017 9:07 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
My first question would be, on which Queue Manager are you getting the 2087 ?
Secondly you have three Queue Managers involved, what are the definitions that you have specified on each of the Queue Manager. I assume you've just given us the definitions made on QMGRA.
Lastly why are you doing this ? Do you want the replies to go to a different Queue Manager than the one issuing the request ?
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| smeunier |
| Posted: Fri Jun 23, 2017 9:52 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| Quote: |
| Did you create a Queue Manager Alias for that particular queue manager name on the queue manager where the replying application is connecting to? If not, then that is the reason for 2087. |
Yes, the definition
| Code: |
| DEF QR(MBD1) RQMNAME('MBD1') RNAME(' ') XMITQ('BTVLMQP01') |
is defined on the MQ Server that the application connects to and issues the Open/Put. |
|
| Back to top |
|
|
| smeunier |
| Posted: Fri Jun 23, 2017 10:02 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| Quote: |
My first question would be, on which Queue Manager are you getting the 2087 ?
|
The 2087 is received on QMGRA, the first QMGR in the path. The QMGR, that the application connects to and issues the open against.
| Quote: |
Secondly you have three Queue Managers involved, what are the definitions that you have specified on each of the Queue Manager. I assume you've just given us the definitions made on QMGRA. |
Yes, those are only the definitions for the first QMGR(QMGRA). Since I supply all the values in the Remote Queue definition(RQMNAME,RQNAME,XMITQ) and the message will be sent, the path after the first QMGR is deemed good.
| Quote: |
| Lastly why are you doing this ? Do you want the replies to go to a different Queue Manager than the one issuing the request ? |
This is a request/reply scenario. The request can come from one of two queue managers and be received by one of two queue managers. The reply needs to find it way home to the originating Queue manager. I could cluster this, but the cluster are in two different cluster domains(cross companies) with the middle QMGR being the gate way. The clustering was reserved for only taking advantage of the dual nodes on either side of the gateway. I have a similar request/reply set up in the opposite direction and it works just fine. Hence, I'm a little stymied on why it won't work in this direction. |
|
| Back to top |
|
|
| smeunier |
| Posted: Fri Jun 23, 2017 10:37 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
@ Roger Lacroix. Are you saying that, if the application connected to the local queue manager, the Remote Queuemanager alias is defined and the QRemote did not exist there, but the ReplyT0Qmgr is specified, that it would use the QREMOTE Alias and send the message to its destination? This may be true, as I just performed a test using RFHUTIL(IH03 Support Pac) and issued a put to a queue that did not exist, but the QMGR was specified(for Remote Queues filed) and the message went. I'm not sure what that field in the RFHUTIL does, but it appears to resolve the name resolution problem. If I leave that field blank(Remote Queue Manager Name), then I get a 2085, implying that it defaults to looking in the local Queue Manager. If it is not Blank, then it tries to forward it onto a definition by the name of the QMGR, in this case my QMGR Alias.
Given that, it would seem that the possible solution is to delete the locally defined QREMOTE and rely on the QREMOTE Alias to resolve. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 23, 2017 10:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Lets get back to the basics
QMA request qmgr
QMB service qmgr
on QMA
| Code: |
def ql(to.qmb) usage(xmitq) trigger initq(system.channel.initq)
def qr(request.q) rqmname(QMB) rname(request.q) xmitq(to.qmb)
def qr(reply.q.alias) rqmname(replya) rname(reply.q)
def ql(reply.q)
def qr(replya) rqmname(qma) rname('') xmitq('')
|
on QMB
| Code: |
def ql(request.q)
def ql(to.qma) usage(xmiq) trigger initq(system.channel.initq)
def qr(replya) rqmname(replya) rname('') xmitq(to.qma)
|
Note there is no default routing between QMA and QMB
Note there is use a REPLY to Destination by the app on QMA which is REPLY.Q.ALIAS. This will be put into the REPLY TO information. However the application will read its replies from REPLY.Q.
So the server defines a default routing for the REPLYA qmgr that is in the reply to qmgr information and goes to QMA. In QMA there is a qmgr alias that says QMA will accept any messages for REPLYA and handle them as if their destination is QMA.
I guess that is the set up you were trying to get going. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smeunier |
| Posted: Fri Jun 23, 2017 11:56 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Its a difficult environment to articulate in words, but below sums it up.
QMGR1a ( Possibly Requests Data from QMGR3a/b)
QMGR1b ( Possibly Requests Data from QMGR3a/b)
QMGR2 (Gateway DMZ/passthru between network domains)
QMGR3a ( Possibly Replies to requests from QMGR1a/b)
QMGR3b ( Possibly Replies to requests from QMGR1a/b)
As you can see, requests can come from Either QMGR1 a/b and replies need to go back to either of them, depending who initiated the request. So the reply need to drop a message onto the reply queue on a remote server. Right now I have that queue defined as remote on the local server(QMGR3a/b). The application has the replyToQmgr and ReplyToQ specified in it MQOD. How to get that response over to the correct QMGR1a/b is the problem. QMGR2 acts as a cluster gateway to QMGR1a/b), but I wanted to stay away from the cluster an just let it be a Load Balancer between the different domains and not used as the delivery for replies. I don't want to get tied to the cluster in that manner, as this may be temporary. Long story short. I want to go old school. All the Qremote alias are in place and deliver does occur if i specify the RQMGR in the Qremote definition, but I need it to use the RemoteQmgr from the replyToQmgr as that has the source and target for the reply. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 23, 2017 5:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| smeunier wrote: |
Its a difficult environment to articulate in words, but below sums it up.
QMGR1a ( Possibly Requests Data from QMGR3a/b)
QMGR1b ( Possibly Requests Data from QMGR3a/b)
QMGR2 (Gateway DMZ/passthru between network domains)
QMGR3a ( Possibly Replies to requests from QMGR1a/b)
QMGR3b ( Possibly Replies to requests from QMGR1a/b)
As you can see, requests can come from Either QMGR1 a/b and replies need to go back to either of them, depending who initiated the request. So the reply need to drop a message onto the reply queue on a remote server. Right now I have that queue defined as remote on the local server(QMGR3a/b). The application has the replyToQmgr and ReplyToQ specified in it MQOD. How to get that response over to the correct QMGR1a/b is the problem. QMGR2 acts as a cluster gateway to QMGR1a/b), but I wanted to stay away from the cluster an just let it be a Load Balancer between the different domains and not used as the delivery for replies. I don't want to get tied to the cluster in that manner, as this may be temporary. Long story short. I want to go old school. All the Qremote alias are in place and deliver does occur if i specify the RQMGR in the Qremote definition, but I need it to use the RemoteQmgr from the replyToQmgr as that has the source and target for the reply. |
So this is relatively easy
Assumption 1 messages will have QMGR1a/b in their reply to qmgr field
Assumption 2 in the cluster gateway QM2 you are not using a default routing to QMGR1a/b....
Assumption 3 there exists an xmitq TO.QMGR1A / TO.QMGR1B on the gateway QM2 and they are plugged into the respective channels to get the messages delivered where they need to go.
So you are going to set a default routing up and it will be valid in the cluster
in QM2
| Code: |
DEF QR(QMGR1A) RQMNAME(QMGR1A) RNAME('') XMITQ (TO.QMGR1A) CLUSTER(CLUS1) REPLACE
DEF QR(QMGR1B) RQMNAME(QMGR1B) RNAME('') XMITQ(TO.QMGR1B) CLUSTER(CLUS1) REPLACE |
With this setup the requests arriving at QMGR3a/b, (members of CLUS1), will be routable (through QM2) to QMGR1a/b... with the correct and corresponding permissions ... to put to those queues.
Hope this helps
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 23, 2017 5:33 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Can QMGR3a and QMGR3b talk directly with QMGR1a and QMGR1b?
Or must they go thru QMGR2 only?
Are the "1" queue managers in one cluster, the "3" queue managers in another cluster, and QMGR2 in both clusters?
Don't lose sight of this critical fact: When an application provides a QM name on the MQOPEN/MQPUT1 call, and that QM name is not the name of the QM the app is connected to, the connected to QM ignores the queue name used on MQOPEN/MQPUT1 call. The connected to QM focuses 100% on the value provided in the MQOD's Object Queue Manager Name field and MQ Name Resolution rules are followed.
Meaning if you are connected to QMA, and do an MQOPEN / MQPUT1 to ThatReplyQueue on QMB, QMA completely ignores "ThatReplyQueue". Even if you define a Remote Queue Definition or Alias Queue on QMA called "ThatReplyQueue", QMA ignores it, and focuses solely on getting that message shipped to QMB, and letting QMB deal with the queue name. The value QMB could itself be a QM Alias or XMITQ that resolves to who-knows-what, but QMA does not care - ship it to whatever is advertising as knowing how to get to "QMB" and let it deal with the queue name.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| tczielke |
| Posted: Sat Jun 24, 2017 5:00 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Have you tried recreating the 2087 error with the Application Activity Trace? The verbose output in amqsact will give you data like what was the actual ObjectQmgrName and ObjectName passed into the OPEN, what was the resolved QmgrName, QueueName, etc. It could be helpful in diagnosing why the 2087 is being issued.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Jun 25, 2017 7:02 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Qmgr / Queue routing can also be tested using amqsput, eg.
echo This is a test message | amqsput DEST.QL QMGRLOCAL1 16 0 QMGRDEST2
This connects to local qmgr QMGRLOCAL1, opens qmgr QMGRDEST2 / queue DEST.QL, and puts a test message.
HTH, Glenn
_________________
Glenn |
|
| Back to top |
|
|
| smeunier |
| Posted: Mon Jun 26, 2017 7:40 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| Quote: |
| Are the "1" queue managers in one cluster, the "3" queue managers in another cluster, and QMGR2 in both clusters? |
Yes, the "1" Queue managers are in one cluster and the "3" Queue managers are in another cluster. QMGR2 is a member of both clusters. So QMGR2 is in overlapping clusters. I think the easy solution is somewhere embedded in that fact. there are two clusters on either side of QMGR2, one for test environment and one for PROD environment. So in reality, there are 4 cluster that QMGR2 is involved in. The Queue names are the same for all qmgrs. So message affinity(to the reply2qmgr) must be maintained through the cluster.
| Quote: |
Don't lose sight of this critical fact: When an application provides a QM name on the MQOPEN/MQPUT1 call, and that QM name is not the name of the QM the app is connected to, the connected to QM ignores the queue name used on MQOPEN/MQPUT1 call. The connected to QM focuses 100% on the value provided in the MQOD's Object Queue Manager Name field and MQ Name Resolution rules are followed.
Meaning if you are connected to QMA, and do an MQOPEN / MQPUT1 to ThatReplyQueue on QMB, QMA completely ignores "ThatReplyQueue". Even if you define a Remote Queue Definition or Alias Queue on QMA called "ThatReplyQueue", QMA ignores it, and focuses solely on getting that message shipped to QMB, and letting QMB deal with the queue name. The value QMB could itself be a QM Alias or XMITQ that resolves to who-knows-what, but QMA does not care - ship it to whatever is advertising as knowing how to get to "QMB" and let it deal with the queue name.
|
This implies, that because it is not a local queue, the local QMGR looks for a way to get it to the remote QMGR. Because I left the RQMName and XMIT Queue blanlk I figured, if would look for a RQM ALias, which I had defined and take that path to delivery. Maybe that RQM Alias needs to be a XMITQ?! How else would it resolve to get it to some other QMGR? |
|
| Back to top |
|
|
| smeunier |
| Posted: Mon Jun 26, 2017 8:22 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| Quote: |
| Assumption 2 in the cluster gateway QM2 you are not using a default routing to QMGR1a/b.... |
There are Remote QMGR aliases defined on QMGR2 to facilitate message hopping, if this is what your assumption 2 is implies |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jun 26, 2017 9:04 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| smeunier wrote: |
| Quote: |
| Assumption 2 in the cluster gateway QM2 you are not using a default routing to QMGR1a/b.... |
There are Remote QMGR aliases defined on QMGR2 to facilitate message hopping, if this is what your assumption 2 is implies |
If those aliases are shared in the cluster QMGRC1/2 can then route messages through QM2 to QMGRA1/2
See my setup from above.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
