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 IndexGeneral IBM MQ SupportQuestion about QMGR name and listener

Post new topicReply to topic
Question about QMGR name and listener View previous topic :: View next topic
Author Message
fswarbrick
PostPosted: Wed Jun 03, 2020 4:07 pm Post subject: Question about QMGR name and listener Reply with quote

Apprentice

Joined: 07 Jul 2014
Posts: 42

So...if one uses MQCONNX to connect to a remote queue manager, and also uses the MQCO.MQCD (Connection Options.Channel Definition) to specify the channel name and the "connection name" (hostname(port) for TCP), it seems to be the case that the queue manager name in the MQCONNX call can be a null string. But it also can be the name of the remote queue manager. In the later case, if the connection name connects to a queue manager that has a different name then the connection is rejected with MQRC=2058 (MQRC_Q_MGR_NAME_ERROR). Is this just a "sanity check", or can you actually have two queue manager instances assigned to a single "connection name"?

Sorry that question is so convoluted. I didn't know how to ask it in simpler terms!
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Jun 03, 2020 4:48 pm Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

MQ Clients can connect to a queue manager with the correct queue manger specified, no queue manger specified, an * for the queue manager name or with any queue manager name that starts with an *. Pretty much the only thing you can't do is connect supplying the wrong queue manager name.

There can only ever be one queue manager listening at a particular IP address and port number, so if you provide those 2 details, the queue manager name is not needed (just don't give the wrong name as that will be rejected).
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
fswarbrick
PostPosted: Wed Jun 03, 2020 5:06 pm Post subject: Reply with quote

Apprentice

Joined: 07 Jul 2014
Posts: 42

So in other words: no.

Thanks. Just wanted to make sure I wasn't missing something.
Back to top
View user's profile Send private message
hughson
PostPosted: Wed Jun 03, 2020 5:09 pm Post subject: Re: Question about QMGR name and listener Reply with quote

Padawan

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

fswarbrick wrote:
Is this just a "sanity check"

Yes
fswarbrick wrote:
or can you actually have two queue manager instances assigned to a single "connection name"?

No

fswarbrick wrote:
Sorry that question is so convoluted.

To be fair to Peter in his answer - it wasn't simple enough to answer either Yes or No
_________________
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
fswarbrick
PostPosted: Wed Jun 03, 2020 5:40 pm Post subject: Reply with quote

Apprentice

Joined: 07 Jul 2014
Posts: 42

Indeed, I shouldn't have been snarky in my response. He's detailed response was quite helpful.
Back to top
View user's profile Send private message
hughson
PostPosted: Wed Jun 03, 2020 5:46 pm Post subject: Reply with quote

Padawan

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

fswarbrick wrote:
His detailed response was quite helpful.

That is something I love about this community. You will get the answer to your question with some helpful detail which explains why and not just what. The experience out there that you can tap into is incredible.
_________________
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
zpat
PostPosted: Sun Jun 07, 2020 12:17 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

PeterPotkay wrote:


There can only ever be one queue manager listening at a particular IP address and port number, so if you provide those 2 details, the queue manager name is not needed (just don't give the wrong name as that will be rejected).


What about Group listeners in Sysplex? We have one IP address/port that have four z/OS QMs hiding behind the VIPA load balancer.

Also on one quite strange LPAR we have four z/OS QMs listening on the same port (I kid you not). This seems to work without a network load balancer to distribute connections over the four.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
hughson
PostPosted: Sun Jun 07, 2020 1:49 am Post subject: Reply with quote

Padawan

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

zpat wrote:
PeterPotkay wrote:


There can only ever be one queue manager listening at a particular IP address and port number, so if you provide those 2 details, the queue manager name is not needed (just don't give the wrong name as that will be rejected).


What about Group listeners in Sysplex? We have one IP address/port that have four z/OS QMs hiding behind the VIPA load balancer.


In this instance, the groups listeners are still listening on a particular IP address - they don't listen on the VIPA address they listen on the LPAR address. So the IP address + port combination is still unique. The Sysplex Distributor VIPA is balancing the connections to one of the four listeners.

Also, you could argue that there is one big Queue manager which is actually a QSG represented by the VIPA + Port combination.

zpat wrote:
Also on one quite strange LPAR we have four z/OS QMs listening on the same port (I kid you not). This seems to work without a network load balancer to distribute connections over the four.


This one is presumably using SHAREPORT - in order to connect to these listeners you'd HAVE TO supply a blank or asterisked queue manager name as you cannot guess which one your connection will be sent to!

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
bruce2359
PostPosted: Sun Jun 07, 2020 4:57 am Post subject: Reply with quote

Poobah

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

hughson wrote:

Also, you could argue that there is one big Queue manager which is actually a QSG represented by the VIPA + Port combination.

Poetically, maybe, but technically imprecise. Whichever local port listener services the shared group port listener first determines the actual connection to a single queue manager which is a member of the same z/OS QSG.
_________________
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
hughson
PostPosted: Sun Jun 07, 2020 9:01 pm Post subject: Reply with quote

Padawan

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

bruce2359 wrote:
hughson wrote:

Also, you could argue that there is one big Queue manager which is actually a QSG represented by the VIPA + Port combination.

Poetically, maybe, but technically imprecise. Whichever local port listener services the shared group port listener first determines the actual connection to a single queue manager which is a member of the same z/OS QSG.


I was thinking that your application could use the QSG Name instead of the queue manager name on their MQCONN, and therefore treat the VIPA+Port connection as a single queue manager even though it might be serviced by a different actual queue manager each time a re(connect) happened. After all, isn't that sort of the point? Applications not needing to really know which queue manager is servicing them?

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
bruce2359
PostPosted: Mon Jun 08, 2020 4:43 am Post subject: Reply with quote

Poobah

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

hughson wrote:
bruce2359 wrote:
hughson wrote:

Also, you could argue that there is one big Queue manager which is actually a QSG represented by the VIPA + Port combination.

Poetically, maybe, but technically imprecise. Whichever local port listener services the shared group port listener first determines the actual connection to a single queue manager which is a member of the same z/OS QSG.


I was thinking that your application could use the QSG Name instead of the queue manager name on their MQCONN, and therefore treat the VIPA+Port connection as a single queue manager even though it might be serviced by a different actual queue manager each time a re(connect) happened. After all, isn't that sort of the point? Applications not needing to really know which queue manager is servicing them?

Cheers,
Morag

OK, pedantic, but In pursuit of clarity and precision...

There are occasional posts here that begin with "... my application MQCONNected to an MQ cluster ...", or " ... my app connected to an queue ...".

Apps connect to a queue manager.
_________________
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
zpat
PostPosted: Tue Jun 09, 2020 4:30 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

With regard to v9.1.5.uniform clusters and MQ clients -IBM say z/OS does not play in this game, but QSGs provide much of the same function.

Suppressing the urge to laugh at this statement; is this true or just another example of z/OS being left out in the cold?

What features of uniform clustering can you emulate with z/OS and QSGs and how? (in terms of balancing MQ clients etc).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Jun 09, 2020 5:00 am Post subject: Reply with quote

Poobah

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

z/OS left out? z/OS’s Parallel Sysplex and QSG’s implemented high-availability, workload Importance-based workload management, and dynamic pull workload balancing across up to 32 z/OS images decades ago.

Despite the “mainframes are dead” mantra from the mid-1990’s, all of the Bigs still rely heavily on mainframes for transactional and data base workload including MQ.
_________________
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: Tue Jun 09, 2020 3:59 pm Post subject: Reply with quote

Jedi

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

bruce2359 wrote:
z/OS left out? z/OS’s Parallel Sysplex and QSG’s implemented high-availability, workload Importance-based workload management, and dynamic pull workload balancing across up to 32 z/OS images decades ago.
Despite the “mainframes are dead” mantra from the mid-1990’s, all of the Bigs still rely heavily on mainframes for transactional and data base workload including MQ.


Possibly because they have done so from the 1970's (or 1960's) and can afford the high cost for high reliability and are well and truly locked in. Outside of the Bigs, there are plenty of other technology solutions in use that satisfy these types of requirements. Good on IBM for attempting to mold their z product line (aka 360 heritage) into more modern usage.
_________________
Glenn
Back to top
View user's profile Send private message
zpat
PostPosted: Tue Jun 09, 2020 10:05 pm Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

Suppose you have a four LPAR QSG (one QM per LPAR) and a VIPA load-balancer for MQ clients.

If all QMs are up - the MQ clients will be evenly balanced. But if you stop two of the QMs (or they fail) the other two will end up with all the MQ clients (assuming they reconnect in some fashion after disconnection).

Then you restart the QMs that were stopped - and all the MQ clients are still on the two QMs that did not go down. They won't rebalance unless the MQ client application is designed to periodically reconnect.

That is hardly the same as a uniform cluster although of course shared queues are very useful.

We've had some challenges of this nature, not helped by CHIN storage running low due to too many MQ connections on one QM.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportQuestion about QMGR name and listener
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.