| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ BIND on OPEN with QSG |
« View previous topic :: View next topic » |
| Author |
Message
|
| aravindtk |
 Posted: Mon Jun 05, 2023 5:57 am Post subject: MQ BIND on OPEN with QSG |
 |
|
Novice
Joined: 05 Jun 2023
Posts: 17
|
Hi,
I am wondering about a general design flaw that might arise if using MQ
BIND-On-Open option from an application on a distributed platform , that eventually
has a target to be a z/OS QMGR hosting a Shared queue.
The BIND option here would only be relevant as far as delivering the message through the QMGR on which it is bound.
Once it reaches the target queue (which is on a QSG) there is no control as to which qmgr actually processes it? It doesn't necessarily have to be the QMGR that delivered the message. Is this correct?
Any thoughts please?
Thanks much |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Jun 05, 2023 12:57 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
What design flaw?
_________________
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 |
|
|
| aravindtk |
| Posted: Mon Jun 05, 2023 2:18 pm Post subject: |
|
|
Novice
Joined: 05 Jun 2023
Posts: 17
|
| If I were to use MQ Bind on Open on a cluster queue that ultimately leads to a shared queue on z/OS, the bind to the queue manager is not guaranteed, as any qmgr on the QSG can pick it. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Jun 05, 2023 4:41 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
|
| Back to top |
|
|
| hughson |
| Posted: Tue Jun 06, 2023 1:35 am Post subject: Re: MQ BIND on OPEN with QSG |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| aravindtk wrote: |
| Once it reaches the target queue (which is on a QSG) there is no control as to which qmgr actually processes it? It doesn't necessarily have to be the QMGR that delivered the message. Is this correct? |
You are quite correct - Bind Options play no part at all once the message resides on the target queue. If the target is a QSGDISP(SHARED) queue, any member of the QSG may server that message up to a getter regardless of the route the message took to get there. This is the design goal of a QSGDISP(SHARED) queue. If you don't want other members of the QSG to be able to retrieve the messages, you would use a QSGDISP(QMGR) queue.
Another way to think about the BIND options is that they are BINDING the messages TOGETHER rather than binding the messages to a specific queue manager. You should use this option when a set of messages must all go to the same instance of the target queue. It's about the affinity the messages have to each other that is really at stake here.
You're welcome.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 06, 2023 6:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| aravindtk wrote: |
| If I were to use MQ Bind on Open on a cluster queue that ultimately leads to a shared queue on z/OS, the bind to the queue manager is not guaranteed, as any qmgr on the QSG can pick it. |
For an application to bind to a particular qmgr, your app would specify the qmgr name in the MQOD. As Glenn points out, an architectural design to be avoided.
MQ clusters and z/OS QSG's offer opprtunities to improve workload distribution, and some greater or lesser high-availability and continuous operation. Binding to a specific queue manager effectively disables these opportunities.
Every time MQ internals encounter a name, the name-resolution process is invoked. I would suggest that you become familiar with Name Resolution https://www.ibm.com/docs/en/ibm-mq/9.3?topic=call-name-resolution
_________________
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: Tue Jun 06, 2023 11:01 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| bruce2359 wrote: |
| aravindtk wrote: |
| If I were to use MQ Bind on Open on a cluster queue that ultimately leads to a shared queue on z/OS, the bind to the queue manager is not guaranteed, as any qmgr on the QSG can pick it. |
For an application to bind to a particular qmgr, your app would specify the qmgr name in the MQOD. |
To be completely clear, this would still not stop another member of the QSG retrieving the message from the QSGDISP(SHARED) queue though. The only way that I can think of to do so is to not use a QSGDISP(SHARED) queue and to use a QSGDISP(QMGR) queue instead. Can you think of another way?
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 07, 2023 7:54 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| hughson wrote: |
| bruce2359 wrote: |
| aravindtk wrote: |
| If I were to use MQ Bind on Open on a cluster queue that ultimately leads to a shared queue on z/OS, the bind to the queue manager is not guaranteed, as any qmgr on the QSG can pick it. |
For an application to bind to a particular qmgr, your app would specify the qmgr name in the MQOD. |
To be completely clear, this would still not stop another member of the QSG retrieving the message from the QSGDISP(SHARED) queue though. The only way that I can think of to do so is to not use a QSGDISP(SHARED) queue and to use a QSGDISP(QMGR) queue instead. Can you think of another way? |
The OP's restatement of the issue ...
| aravindtk wrote: |
| If I were to use MQ Bind on Open on a cluster queue that ultimately leads to a shared queue on z/OS, the bind to the queue manager is not guaranteed, as any qmgr on the QSG can pick it. |
... reaffirms that once the message leaves the originating qmgr, there is no guarantee as to where a message will ultimately be delivered.
As Glenn mentioned earlier in this post: You should avoid any design that requires application affinity with qmgrs.
_________________
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: Wed Jun 07, 2023 3:57 pm Post subject: Re: MQ BIND on OPEN with QSG |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| aravindtk wrote: |
| Hi, I am wondering about a general design flaw that might arise if using MQ BIND-On-Open option from an application on a distributed platform , that eventually has a target to be a z/OS QMGR hosting a Shared queue. |
The discussion on this topic has indicated that a design could not effectively use this particular method if there was a requirement to target a particular z/OS qmgr via a cluster and shared queue. Its not a "flaw" as such, its just a method that should not be used in this case.
A design could be considered "flawed" if it has an tight affinity with one qmgr, when it was operating in a MQ Cluster and MQ Shared Queue environment, where multiple servicing qmgrs is the norm, for very good reasons.
Have a great weekend ahead.
_________________
Glenn |
|
| Back to top |
|
|
| jasonn |
| Posted: Tue Sep 19, 2023 12:22 am Post subject: Re: MQ BIND on OPEN with QSG |
|
|
Newbie
Joined: 22 Dec 2022
Posts: 6
|
| aravindtk wrote: |
Hi,
I am wondering about a general design flaw that might arise if using MQ
BIND-On-Open option from an application on a distributed platform , that eventually
has a target to be a z/OS QMGR hosting a Shared queue.
The BIND option here would only be relevant as far as delivering the message through the QMGR on which it is bound.
Once it reaches the target queue (which is on a QSG) there is no control as to which qmgr actually processes it? It doesn't necessarily have to be the QMGR that delivered the message. Is this correct?
Any thoughts please?
Thanks much |
You've made an astute observation regarding the use of MQ's BIND-On-Open option in a distributed platform scenario targeting a z/OS QMGR with a Shared queue. Indeed, the BIND option primarily governs message delivery through the initially bound QMGR. Once the message reaches the target queue within a Queue Sharing Group (QSG), there's a lack of direct control over which QMGR processes it, as this depends on the load balancing and routing mechanisms inherent to the QSG's design. In QSG setups, the focus is on achieving high availability and efficient message processing across multiple QMGRs, making the precise processing QMGR less deterministic but more resilient. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
