| Author |
Message
|
| fswarbrick |
 Posted: Wed Jun 03, 2020 4:07 pm Post subject: Question about QMGR name and listener |
 |
|
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 |
|
 |
| PeterPotkay |
| Posted: Wed Jun 03, 2020 4:48 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
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 |
|
|
| fswarbrick |
| Posted: Wed Jun 03, 2020 5:06 pm Post subject: |
|
|
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 |
|
|
| hughson |
| Posted: Wed Jun 03, 2020 5:09 pm Post subject: Re: Question about QMGR name and listener |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| fswarbrick |
| Posted: Wed Jun 03, 2020 5:40 pm Post subject: |
|
|
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 |
|
|
| hughson |
| Posted: Wed Jun 03, 2020 5:46 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| zpat |
| Posted: Sun Jun 07, 2020 12:17 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
|
| hughson |
| Posted: Sun Jun 07, 2020 1:49 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| bruce2359 |
| Posted: Sun Jun 07, 2020 4:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| hughson |
| Posted: Sun Jun 07, 2020 9:01 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| bruce2359 |
| Posted: Mon Jun 08, 2020 4:43 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| zpat |
| Posted: Tue Jun 09, 2020 4:30 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
|
| bruce2359 |
| Posted: Tue Jun 09, 2020 5:00 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| gbaddeley |
| Posted: Tue Jun 09, 2020 3:59 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
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 |
|
|
| zpat |
| Posted: Tue Jun 09, 2020 10:05 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
|
|
|
