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 » IBM MQ Installation/Configuration Support » Proper naming of transmission queues

Post new topic  Reply to topic
 Proper naming of transmission queues « View previous topic :: View next topic » 
Author Message
fswarbrick
PostPosted: Mon May 18, 2020 2:43 pm    Post subject: Proper naming of transmission queues Reply with quote

Apprentice

Joined: 07 Jul 2014
Posts: 42

Is it best practice to give the transmission queue for a sender channel the name of the peer queue manager?

Take the following example for communication between MQD1 and MQP1.

Code:
QMGR(MQD1)
CHANNEL(MQP1.MQD1) CHLTYPE(RCVR) TRPTYPE(TCP)           
CHANNEL(MQD1.MQP1) CHLTYPE(SDR) XMITQ(MQP1) TRPTYPE(TCP) CONNAME(mqp1.host(1414))
QUEUE(MQP1) TYPE(QLOCAL) USAGE(XMITQ)


On the other side, however, we've given the XMITQ a name that is not the name of the peer queue manager:

Code:
QMGR(MQP1)
CHANNEL(MQD1.MQP1) CHLTYPE(RCVR) TRPTYPE(TCP)
CHANNEL(MQP1.MQD1) CHLTYPE(SDR) XMITQ(MQP1.XMITQ.MQD1) TRPTYPE(TCP) CONNAME(mqd1.host(1414))
QUEUE(MQP1.XMITQ.MQD1) TYPE(QLOCAL) USAGE(XMITQ)


As long as there are remote queue definitions are configured with the appropriate RNAME, RQMNAME, and XMITQ values this works for "most" situations. However, it appears that if an application connecting to MQD1 wants to receive report messages from MQP1 this setup does not work because there is no object named MQD1 defined to MQP1. Rather than changing the XMITQ name on MQP1, which would require updating any remote queue definitions to use this new XMITQ, you can instead create what appears to be named a "queue manager alias". For this example:
Code:
QUEUE(MQD1) TYPE(QREMOTE) RNAME() RQMNAME(MQD1) XMITQ(MQP1.XMITQ.MQD1)


While this is all documented it was not, to me anyway, very clear to me as someone who didn't previously know about it.

Anyway, is there truly any advantage to the second setup over the first?
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Mon May 18, 2020 3:31 pm    Post subject: Reply with quote

Jedi

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

Our site naming standard for distributed channels is "FromQmgr.ToQmgr".
Transmission queues are always "ToQmgr.XMITQ".
When required, qmgr aliases are defined with the qmgr name, and refer to the xmit queue name.

This provides better control over who can send messages via the channel than naming the xmitq as "ToQmgr". Multiple qmgr aliases can be used to provide an app abstraction of the qmgr name, or provide routing to other qmgrs via a hub qmgr.

We also use the qmgr attribute DEFXMITQ to provide a default routing mechanism for other qmgrs that dont have direct distribute channel connections to the local qmgr.
_________________
Glenn
Back to top
View user's profile Send private message
hughson
PostPosted: Tue May 19, 2020 1:46 am    Post subject: Re: Proper naming of transmission queues Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

fswarbrick wrote:
Anyway, is there truly any advantage to the second setup over the first?

If you have more than one channel, say a channel for big messages and one for small messages, or a secure one and an insecure one, or whatever 101 other reasons, then of course you cannot have both of them using a transmission queue with the name of the target queue manager.

Simplicity is good when things are small and fit into the simple world, but sometimes you have to use the more complicated setup when you hit the real world.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
RogerLacroix
PostPosted: Tue May 19, 2020 2:11 pm    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3252
Location: London, ON Canada

I've always gone with {ToQMgrName}.XMIT

When I have needed to have more than one sender channel to the same queue manager then I have gone with: {ToQMgrName}.{BATCH/FAST/QUERY/AUTH}.XMIT

The second qualifier of the XMITQ name tells me the purpose of the particular XMITQ.

There is always different ways to bake a cake.

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
fswarbrick
PostPosted: Wed May 20, 2020 8:04 am    Post subject: Reply with quote

Apprentice

Joined: 07 Jul 2014
Posts: 42

I can definitely see why one might have multiple channels with multiple transmission queues, and thus some XMITQs would not have the same name as the receiving queue manager. But it still seems to me that having at least one XMITQ with the name of the receiving QMGR makes sense.

I guess my biggest issue is that as far as I've seen, while the documentation notes that you can have an XMITQ or a remote queue pointing to an XMITQ for the receiving queue manager, it doesn't seem to stress very clearly why this is desirable. Until I changed it recently we (in our little MQ shop) didn't have it set up this way between our two queue managers, and as far as I can tell none of our "peers" have this set up between us either. Specifically, if I attempt to request report messages when sending to a remote queue I don't get any back.
Back to top
View user's profile Send private message
RogerLacroix
PostPosted: Wed May 20, 2020 8:42 am    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3252
Location: London, ON Canada

fswarbrick wrote:
I guess my biggest issue is that as far as I've seen, while the documentation notes that you can have an XMITQ or a remote queue pointing to an XMITQ for the receiving queue manager, it doesn't seem to stress very clearly why this is desirable. Until I changed it recently we (in our little MQ shop) didn't have it set up this way between our two queue managers, and as far as I can tell none of our "peers" have this set up between us either. Specifically, if I attempt to request report messages when sending to a remote queue I don't get any back.

It sounds like you are confused about the difference between a remote queue and a queue manager alias. If not then can you elaborate.

IMHO, the hack IBM did 20+ years ago to create a queue manager alias was a bad idea. I have hated it since the beginning. I used to be a travelling MQ consultant. This is the one topic 95% of the people got confused about.

IBM's hack was to have 1 command (DEFINE QREMOTE) to be able to do 2 different things: create remote queue and create queue manager alias.

If the command includes a value for the RNAME attribute then it is a queue remote. If the RNAME attribute is blank then it is a queue manager alias. Just weird thinking on IBM's part.

This is such a bad hack. And I have spent countless hours explaining this bad hack to so many customers, it is mind numbing. It would have been so much better to simply create a new keyword called QMALIAS.
i.e.
Code:
DEFINE QMALIAS() CLUSNL( ) CLUSTER( ) CLWLPRTY() CLWLRANK() CUSTOM( ) +
                 DEFBIND() DEFPRTY() DEFPSIST() DEFPRESP() DESCR( ) +
                 PUT() RQMNAME() SCOPE() XMITQ()


But it doesn't exist, so we have to live with the hack.

Anyway, that's my 2 cents.

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
fswarbrick
PostPosted: Wed May 20, 2020 10:29 am    Post subject: Reply with quote

Apprentice

Joined: 07 Jul 2014
Posts: 42

All I am saying is if an application on, for example, MQD1 does an MQPUT to a queue on MQP1 and requests a COA and/or COD report (and supplies the name of a reply to queue), if MQP1 does not have either:
    1) a transmission queue named MQD1 that is associated with a sender channel going back to MQD1, or
    2) a "remote queue" (queue manager alias) definition named MQD1 that has RMQNAME(MQD1) and XMITQ of the actual transmission queue associated with the sender channel back to MQD1.
Then when MQP1 attempts to send the COA/COD reports back to MQD1 it fails with MQCC=2 MQRC=2087 (MQRC_UNKNOWN_REMOTE_Q_MGR).

This also occurs, even without report messages, if the remote side attempts to use the ReplyToQ and ReplyToQMgr values for its response.

In the end I don't think I am disagreeing with anything anyone has said. I am only stating that the documentation doesn't make it all that clear that one of these two options should be implemented.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed May 20, 2020 11:39 am    Post subject: Reply with quote

Poobah

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

The explanation I was given for using the queue-manager-alias hack (QRemote without an Rname attribute) instead of a new QMA object type was that a new object type would involve substantial renovation of MQ internals.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Wed May 20, 2020 3:26 pm    Post subject: Reply with quote

Jedi

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

bruce2359 wrote:
The explanation I was given for using the queue-manager-alias hack (QRemote without an Rname attribute) instead of a new QMA object type was that a new object type would involve substantial renovation of MQ internals.

Interesting, as a few new MQ object types have appeared over the years.


Is anyone aware of the special case of qmgr alias where the RQMNAME attribute is set to blank!

This means the destination qmgr name is not definitely specified. The qmgr (where the qmgr alias object is defined) will resolve the destination queue name using its normal name resolution logic, without any constraint on the destination qmgr name. We call this a "NULL" qmgr alias, and give them names like "MQNULL.APP1", "MQNULL.APP2".

The most common resolution made are:

1/ The destination resolves to a clustered QLOCAL or clustered QALIAS that exists on one or more other qmgrs in a MQ cluster. The message will be round-robin balanced and sent over cluster channels to one of the qmgrs.

2/ Does not resolve to an object name that is known to the qmgr where the null qmgr alias object is defined. The message will be forwarded via the qmgr's default transmission queue to another qmgr, where queue name resolution is attempted again. If the second resolution fails, the message goes to its dead letter queue.
_________________
Glenn
Back to top
View user's profile Send private message
RogerLacroix
PostPosted: Thu May 21, 2020 8:44 am    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3252
Location: London, ON Canada

gbaddeley wrote:
2/ Does not resolve to an object name that is known to the qmgr where the null qmgr alias object is defined. The message will be forwarded via the qmgr's default transmission queue to another qmgr, where queue name resolution is attempted again. If the second resolution fails, the message goes to its dead letter queue.

To the newbies out there reading/searching about MQ's default transmission queue - please be very, very careful in using it.

From a past issue at a customer site that I helped resolve: if you have 3 queue managers in QA called MQQA01, MQQA02 and MQQA03 then make sure one of the queue managers is the final destination (i.e. blank default transmission queue).

This is fine:
- MQQA01 with a default transmission queue of MQQA03
- MQQA02 with a default transmission queue of MQQA03
- MQQA03 with a blank default transmission queue

Be careful NOT to point MQQA03's default transmission queue to either MQQA01 or MQQA02, otherwise, messages can be "lost"!! Technically, they are not lost but rather travelling a million miles an hour in a circle between queue managers.

It was interesting watching the CPU spike and the channels' messages count constantly increase like it was on fire.

Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter


Last edited by RogerLacroix on Thu May 21, 2020 9:28 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
tczielke
PostPosted: Thu May 21, 2020 9:17 am    Post subject: Reply with quote

Guardian

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

RogerLacroix wrote:
gbaddeley wrote:
2/ Does not resolve to an object name that is known to the qmgr where the null qmgr alias object is defined. The message will be forwarded via the qmgr's default transmission queue to another qmgr, where queue name resolution is attempted again. If the second resolution fails, the message goes to its dead letter queue.

To the newbies out there reading/searching about MQ's default transmission queue - please be very, very careful in using it.

From a past issue at a customer site that I helped resolve: if you have 3 queue managers in QA called MQQA01, MQQA02 and MQQA03 then make sure one of the queue managers is the final destination (i.e. blank transmission queue).

This is fine:
- MQQA01 with a default transmission queue of MQQA03
- MQQA02 with a default transmission queue of MQQA03
- MQQA03 with a blank default transmission queue

Be careful NOT to point MQQA03's default transmission queue to either MQQA01 or MQQA02, otherwise, messages can be "lost"!! Technically, they are not lost but rather travelling a million miles an hour in a circle between queue managers.

It was interesting watching the CPU spike and the channels' messages count constantly increase like it was on fire.

Regards,
Roger Lacroix
Capitalware Inc.


We had something similar to that happen with some missing cluster resource set up, too. MQ's version of hot potato.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Thu May 21, 2020 3:56 pm    Post subject: Reply with quote

Jedi

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

RogerLacroix wrote:
..Be careful NOT to point MQQA03's default transmission queue to either MQQA01 or MQQA02, otherwise, messages can be "lost"!! Technically, they are not lost but rather travelling a million miles an hour in a circle between queue managers.
It was interesting watching the CPU spike and the channels' messages count constantly increase like it was on fire...


Hi Roger,

We have had that happen, and call it "message looping". Not because MQQA03 had a default xmitq, but because it received a message that it resolved and routed back to the qmgr it came from. This was due to a qmgr alias (eg. MYQA01) that existed on 03 (resolving to MQQA01), but the qmgr alias didn't exist on 01.

Fortunately I've only seen it twice in 8 years at current employer.
_________________
Glenn
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu May 21, 2020 9:00 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Let me say this for all the newbies out there.
If you have not a hub spoke topology, you have no good reason to define a default transmission queue.
If you do have a hub spoke topology the only default transmission queues should be on the spokes towards the hub. The hub itself should not have a default transmission queue.

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
mqrules
PostPosted: Sat May 23, 2020 2:53 pm    Post subject: Reply with quote

Centurion

Joined: 01 Jun 2005
Posts: 100
Location: US

Our naming standard is (for Qmgrs QM1, QM2):

On QM1:
Channel: QM1.C1.QM2 (rcvr: QM2.C1.QM1)
XmitQ: QM1.X1.QM2

dis chl(QM1.C*) would give you all the sender channels on QM1
dis ql(QM1.X*) would five you all the XMITQs on QM1

For request-reply messaging qmgrALias with the same name as the receving qmgr pointing to an XMITQ conforming to the above mentioned standard. The same approach is used in a pub-sub topology as well.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Proper naming of transmission queues
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.