ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » MQRC 2087 not able to resolve based on needs

Post new topic  Reply to topic Goto page 1, 2  Next
 MQRC 2087 not able to resolve based on needs « View previous topic :: View next topic » 
Author Message
smeunier
PostPosted: Fri Jun 23, 2017 8:27 am    Post subject: MQRC 2087 not able to resolve based on needs Reply with quote

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
View user's profile Send private message
RogerLacroix
PostPosted: Fri Jun 23, 2017 8:39 am    Post subject: Re: MQRC 2087 not able to resolve based on needs Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3252
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
View user's profile Send private message Visit poster's website
PaulClarke
PostPosted: Fri Jun 23, 2017 9:07 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
smeunier
PostPosted: Fri Jun 23, 2017 9:52 am    Post subject: Reply with quote

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
View user's profile Send private message
smeunier
PostPosted: Fri Jun 23, 2017 10:02 am    Post subject: Reply with quote

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
View user's profile Send private message
smeunier
PostPosted: Fri Jun 23, 2017 10:37 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Fri Jun 23, 2017 10:48 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
smeunier
PostPosted: Fri Jun 23, 2017 11:56 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Fri Jun 23, 2017 5:27 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Fri Jun 23, 2017 5:33 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

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
View user's profile Send private message
tczielke
PostPosted: Sat Jun 24, 2017 5:00 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
gbaddeley
PostPosted: Sun Jun 25, 2017 7:02 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
smeunier
PostPosted: Mon Jun 26, 2017 7:40 am    Post subject: Reply with quote

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
View user's profile Send private message
smeunier
PostPosted: Mon Jun 26, 2017 8:22 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Mon Jun 26, 2017 9:04 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » General IBM MQ Support » MQRC 2087 not able to resolve based on needs
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.