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 IndexClusteringCluster to Cluster Alias

Post new topicReply to topic Goto page 1, 2  Next
Cluster to Cluster Alias View previous topic :: View next topic
Author Message
Jeff.VT
PostPosted: Fri Oct 05, 2018 11:41 am Post subject: Cluster to Cluster Alias Reply with quote

Apprentice

Joined: 02 Mar 2017
Posts: 25

Queue Manager: SOURCE
QM Cluster: ONE
Has an alias queue (ONE.TO.TWO) going to "ONE.TO.TWO.CLUSTERED"

Queue Manager: MIDDLEMAN
QM Cluster: ONE
QM Cluster: TWO
ONE.TO.TWO.CLUSTERED is an alias queue on the ONE Cluster that points to "TWO.QUEUE" (a queue on the TWO Cluster)

Queue Manager: ENDPOINT
QM Cluster: TWO
Clustered Queue: TWO.QUEUE

-------------

Why doesn't this work?

When I put a message on "ONE.TO.TWO.CLUSTERED" on MIDDLEMAN directly, it sends it to TWO.QUEUE just fine.

But when I put a message on ONE.TO.TWO on SOURCE, it gets an Alias error... whycome?

[/img]
Back to top
View user's profile Send private message
Jeff.VT
PostPosted: Fri Oct 05, 2018 12:01 pm Post subject: Reply with quote

Apprentice

Joined: 02 Mar 2017
Posts: 25

ROFL... Okay... what a weird way to fix this.
I can't understand why this works AT ALL, but it does >_<

I have some other cluster queues and we sort of use this empty remote queue as some kind of a target point to get us to the other cluster. But we've only directly pointed there. If I add it to the "TWO" cluster, everything breaks. But I wondered... what if I put that queue in the "ONE" cluster?

It works... I have zero clue why, but it works >_<

Queue Manager: SOURCE
Remote Queue Name: ONE.TO.TWO
Remote Queue : TO.TWO
Remote Queue Manager: MIDDLEMAN.BOUNCE
XMIT Q: <blank>

Queue Manager: MIDDLEMAN
Remote Queue Name: MIDDLEMAN.BOUNCE
Remote Queue Manager: <blank>
Remote Queue: <blank>
XMIT Q: <blank>
Added to cluster: ONE

------------

WHY on EARTH did that work?!?!

Though I'd say I'd prefer it if the target queue was on MIDDLEMAN - I can live with it being on SOURCE.
Back to top
View user's profile Send private message
tczielke
PostPosted: Fri Oct 05, 2018 12:36 pm Post subject: Reply with quote

Shaman

Joined: 08 Jul 2010
Posts: 744
Location: Illinois, USA

If could be that one of your alias queue definitions has an attribute of DEFBIND(OPEN). If so, changing it to DEFBIND(NOTFIXED) may fix the issue.
_________________
MQ administrator since 2010.
Back to top
View user's profile Send private message
Jeff.VT
PostPosted: Fri Oct 05, 2018 1:46 pm Post subject: Reply with quote

Apprentice

Joined: 02 Mar 2017
Posts: 25

That didn't work.

I think it's some weird interaction between the two clusters.

I'd wonder if I added that alias queue to both clusters if it would work - but I don't control the TWO cluster enough to play with it.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Fri Oct 05, 2018 2:52 pm Post subject: Re: Cluster to Cluster Alias Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7466

Jeff.VT wrote:
Queue Manager: SOURCE
QM Cluster: ONE
Has an alias queue (ONE.TO.TWO) going to "ONE.TO.TWO.CLUSTERED"

Queue Manager: MIDDLEMAN
QM Cluster: ONE
QM Cluster: TWO
ONE.TO.TWO.CLUSTERED is an alias queue on the ONE Cluster that points to "TWO.QUEUE" (a queue on the TWO Cluster)

Queue Manager: ENDPOINT
QM Cluster: TWO
Clustered Queue: TWO.QUEUE

-------------

Why doesn't this work?

When I put a message on "ONE.TO.TWO.CLUSTERED" on MIDDLEMAN directly, it sends it to TWO.QUEUE just fine.

But when I put a message on ONE.TO.TWO on SOURCE, it gets an Alias error... whycome?

I agree, this should work.

https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.ref.adm.doc/q085700_.html
Quote:
If the alias refers to a queue, it must be another local or remote queue, defined at this queue manager, or a clustered alias queue defined on another queue manager.


Using this for some ideas:
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.tro.doc/q041470_.html

Quote:

This reason code can also occur when BaseQName is the name of a cluster queue that cannot be resolved successfully.


Connect to Queue Manager "SOURCE" and do an MQOPEN of queue name "ONE.TO.TWO.CLUSTERED ". Does that work?

If no, work the problem here. You have a (relatively) basic MQ Name resolution problem to solve and have gotten one step closer to the actual failure point.

If it does work, see next point:
Quote:


MQRC_UNKNOWN_ALIAS_BASE_Q might indicate that the application is specifying the ObjectQmgrName of the queue manager that it is connecting to, and the queue manager that is hosting the alias queue. This means that the queue manager looks for the alias target queue on the specified queue manager and fails because the alias target queue is not on the local queue manager. Leave the ObjectQmgrName parameter blank so that the clustering decides which queue manager to route to.

_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Oct 05, 2018 3:15 pm Post subject: Re: Cluster to Cluster Alias Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8185
Location: US: west coast, almost. Otherwise, enroute.

Jeff.VT wrote:


Why doesn't this work?

When I put a message on "ONE.TO.TWO.CLUSTERED" on MIDDLEMAN directly, it sends it to TWO.QUEUE just fine.

But when I put a message on ONE.TO.TWO on SOURCE, it gets an Alias error... whycome?

Exactly and precisely how did you put a message?

Did you use the IBM-supplied utility amqsput or amqsputc? If so, re-run the commands (the one that worked and the one that resulted in the error), and post the command and results here.
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
tczielke
PostPosted: Fri Oct 05, 2018 5:51 pm Post subject: Reply with quote

Shaman

Joined: 08 Jul 2010
Posts: 744
Location: Illinois, USA

Jeff.VT wrote:
That didn't work.

I think it's some weird interaction between the two clusters.

I'd wonder if I added that alias queue to both clusters if it would work - but I don't control the TWO cluster enough to play with it.


To confirm, did you check the DEFBIND on the ONE.TO.TWO qalias queue definition?
_________________
MQ administrator since 2010.
Back to top
View user's profile Send private message
Jeff.VT
PostPosted: Mon Oct 08, 2018 8:43 am Post subject: Reply with quote

Apprentice

Joined: 02 Mar 2017
Posts: 25

The way I checked it was with a MS0P MQ Explorer tools trace of the alias queue on SOURCE.

So I wouldn't think binding should matter there.

Doing the same trace on the MIDDLEMAN queue works fine.
Back to top
View user's profile Send private message
Jeff.VT
PostPosted: Mon Oct 08, 2018 9:07 am Post subject: Reply with quote

Apprentice

Joined: 02 Mar 2017
Posts: 25

tczielke wrote:
Jeff.VT wrote:
That didn't work.

I think it's some weird interaction between the two clusters.

I'd wonder if I added that alias queue to both clusters if it would work - but I don't control the TWO cluster enough to play with it.


To confirm, did you check the DEFBIND on the ONE.TO.TWO qalias queue definition?


I tried NOTFIXED, ON Open, and On Group (ON group is what i'd want) on both. No combination of default bind types seemed to make a difference.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Oct 08, 2018 9:25 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8185
Location: US: west coast, almost. Otherwise, enroute.

Jeff.VT wrote:
The way I checked it was with a MS0P MQ Explorer tools trace of the alias queue on SOURCE.

Sorry if I wasn't clear in my question. I asked how you tested, not what tool did you use to test.

Did your test explicitly specify the queue name AND qmgr name where the message should go? Or did you let clustering software decide to which qmgr the message should go?
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
Jeff.VT
PostPosted: Mon Oct 08, 2018 9:39 am Post subject: Reply with quote

Apprentice

Joined: 02 Mar 2017
Posts: 25

bruce2359 wrote:
Jeff.VT wrote:
The way I checked it was with a MS0P MQ Explorer tools trace of the alias queue on SOURCE.

Sorry if I wasn't clear in my question. I asked how you tested, not what tool did you use to test.

Did your test explicitly specify the queue name AND qmgr name where the message should go? Or did you let clustering software decide to which qmgr the message should go?


Ooooooooooh Good question... Interesting. So I tried to set up a remote queue on SOURCE that points to the alias queue on MIDDLEMAN, and I got that same error... Even when I removed that alias queue on MIDDLEMAN from the cluster.

So it's not a cluster>cluster issue as much as I thought it was.
Back to top
View user's profile Send private message
Jeff.VT
PostPosted: Mon Oct 08, 2018 9:49 am Post subject: Reply with quote

Apprentice

Joined: 02 Mar 2017
Posts: 25

So If I have a remote queue on SOURCE that uses the weird Cluster pass-through empty remote queue trick thing on the MIDDLEMAN queue manager, then it works.

But I can't get to it any other way. So that makes sense, I guess...

The work-around way I got it to work, by making an empty remote queue on MIDDLEMAN and sharing that to the cluster, then using that as the Queue Manager name, with a blank xmit queue name on SOURCE, that'll get there.

It sucks, but it's not unexpected.

----------

As a quick FYI - I can't control how my apps put messages to queues. They basically always do it a similar way. So I can't have them specify that blank remote queue in for the queue manager trick. It has to be straightforward.

I've never seen an instance where a queue traces correctly or incorrectly but my applications work differently. So I'd presume they use a similar method.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Oct 08, 2018 11:15 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8185
Location: US: west coast, almost. Otherwise, enroute.

Jeff.VT wrote:
Ooooooooooh Good question...

We try.

Jeff.VT wrote:
Interesting. So I tried to set up a remote queue on SOURCE that points to the alias queue on MIDDLEMAN, and I got that same error... Even when I removed that alias queue on MIDDLEMAN from the cluster.


Please use mq script command to display the complete qremote def your test app MQOPENS. Post the results here.

Jeff.VT wrote:
So it's not a cluster>cluster issue as much as I thought it was.

Too soon to tell.

Ask your developers if they explicitly specify the qmgrname in the MQOD (object descriptor) for the MQOPEN call.
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Mon Oct 08, 2018 3:25 pm Post subject: Re: Cluster to Cluster Alias Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1898
Location: Melbourne, Australia

Jeff.VT wrote:
Queue Manager: SOURCE
QM Cluster: ONE
Has an alias queue (ONE.TO.TWO) going to "ONE.TO.TWO.CLUSTERED"

Queue Manager: MIDDLEMAN
QM Cluster: ONE
QM Cluster: TWO
ONE.TO.TWO.CLUSTERED is an alias queue on the ONE Cluster that points to "TWO.QUEUE" (a queue on the TWO Cluster)

Queue Manager: ENDPOINT
QM Cluster: TWO
Clustered Queue: TWO.QUEUE

-------------

Why doesn't this work?

When I put a message on "ONE.TO.TWO.CLUSTERED" on MIDDLEMAN directly, it sends it to TWO.QUEUE just fine.

But when I put a message on ONE.TO.TWO on SOURCE, it gets an Alias error... whycome?

This is a standard technique to provide "cluster cross-over". It should work. We use it often.
qalias "ONE.TO.TWO" should just have a target queue name of "ONE.TO.TWO.CLUSTERED", with no target qmgr or cluster settings. Queue Manager SOURCE will resolve the target name, and find that "ONE.TO.TWO.CLUSTERED" it a clustered object in ONE cluster on MIDDLMAN.
The message will be transported to MIDDLEMAN, which will then resolve the target of qalias "ONE.TO.TWO.CLUSTERED".
_________________
Glenn
Back to top
View user's profile Send private message
tczielke
PostPosted: Mon Oct 08, 2018 4:29 pm Post subject: Reply with quote

Shaman

Joined: 08 Jul 2010
Posts: 744
Location: Illinois, USA

The Application Activity Trace would be helpful here to see what is happening. It shows the name resolution that is happening with the MQOPEN calls, and I am pretty sure it should show you the name resolution that is causing the 2082 error.
_________________
MQ administrator since 2010.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexClusteringCluster to Cluster Alias
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.