MQINQ and Clusters and needing to give too much access

[Potkay, Peter M (CTO Architecture + Engineering)]

Before I open an RFE to 'fix' this I wanted to see if any of you knew what the use case was to require MQ to work this way.


http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.dev.doc/q027050_.htm?resultof=%22%4d%51%49%4e%51%22%20%22%6d%71%69%6e%71%22%20%22%63%6c%75%73%74%65%72%22%20


Basically this link says that unless you add the option of Browse, Set, Output or Input to your MQOPEN call for a subsequent MQINQ (where you are specifying the MQOO_INQUIRE option already), "successive MQINQ calls might inquire on different instances of the cluster queue."

Now why in the world would anyone connect to QMx to inquire about a queue on QMx and want to get results from random instances of that queue in the cluster? And only a subset of the attributes you could get if it was the local instance?

I am forced to give the UserID used by my little monitoring app more than I think it needs. All it needs is +inq, but I have to add +put, +set, +get or +browse. This is not good as now this ID, that only needs to execute an occasional MQINQ call, needs the ability to read application data, or consume app data, or insert its own messages, or PUT disable the queue.

My RFE would be for IBM to not require these extra authorizations. If the QM sees an MQOPEN call with only MQOO_INQUIRE come in against queue, assume the user wants information about the local instance of that queue and 'bind' all future MQINQ calls using that handle to the local instance of the queue. If there is no local instance of the queue hosted on that QM, the MQOPEN call should fail.

Is there a legitimate use case for getting a subset of attributes from some random instance of a queue in the cluster? If not, I think an RFE is warrented.


(No, I am not going to rewrite my app to use PCF messages. This question is all about the behavior of the MQINQ call and clustered queues.)


Peter Potkay



************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

Request For Enhancement submitted. Please vote for it if you would like apps that only need MQINQ to be able to run with only +inq and +connect in an MQ Clustered environment.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=40878



Peter Potkay
Application Platform Engineering @ The Hartford
Websphere MQ, Message Broker and DataPower
(W) 860-624-1395 / (M) 860-202-1375

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 24, 2013 11:12 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: MQINQ and Clusters and needing to give too much access

Before I open an RFE to 'fix' this I wanted to see if any of you knew what the use case was to require MQ to work this way.


http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.dev.doc/q027050_.htm?resultof=%22%4d%51%49%4e%51%22%20%22%6d%71%69%6e%71%22%20%22%63%6c%75%73%74%65%72%22%20


Basically this link says that unless you add the option of Browse, Set, Output or Input to your MQOPEN call for a subsequent MQINQ (where you are specifying the MQOO_INQUIRE option already), "successive MQINQ calls might inquire on different instances of the cluster queue."

Now why in the world would anyone connect to QMx to inquire about a queue on QMx and want to get results from random instances of that queue in the cluster? And only a subset of the attributes you could get if it was the local instance?

I am forced to give the UserID used by my little monitoring app more than I think it needs. All it needs is +inq, but I have to add +put, +set, +get or +browse. This is not good as now this ID, that only needs to execute an occasional MQINQ call, needs the ability to read application data, or consume app data, or insert its own messages, or PUT disable the queue.

My RFE would be for IBM to not require these extra authorizations. If the QM sees an MQOPEN call with only MQOO_INQUIRE come in against queue, assume the user wants information about the local instance of that queue and 'bind' all future MQINQ calls using that handle to the local instance of the queue. If there is no local instance of the queue hosted on that QM, the MQOPEN call should fail.

Is there a legitimate use case for getting a subset of attributes from some random instance of a queue in the cluster? If not, I think an RFE is warrented.


(No, I am not going to rewrite my app to use PCF messages. This question is all about the behavior of the MQINQ call and clustered queues.)


Peter Potkay




************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[David Ware]

Hi Peter,

I think I agree that this particular usage of MQINQ does need some
attention, but it may not need an RFE...

In the case where only MQOO_INQUIRE is set on the open and there is a
local instance of the queue the local one will always be returned.
However, it seems that on some platforms (i.e. distributed, not z/OS) the
handle you get back only allows 'clustered' attributes to be inquired on,
not the full set of local attributes. You might want to raise a PMR to
have this investigated further, as platform inconsistencies are rarely
good.

However, it is possible for you to force an MQOPEN with only MQOO_INQUIRE
to open the local instance of the queue and return a handle that allows
all local attributes to be inquired on. This is through setting the
ObjectQMgrName to the local queue manager name on the MQOPEN. This should
allow your application to inquire on the local attributes without needing
further permissions.

When the doc says "If you open a cluster queue without fixing the queue
that MQOPEN has bound to, successive MQINQ calls might inquire on
different instances of the cluster queue. " it doesn't randomly pick one
for each MQINQ. It is trying to say that unless you've explicitly bound to
a specific cluster queue instance (e.g. using MQOO_BIND_ON_OPEN) then the
remote instance of the queue may change under you, for example if the
previously chosen remote instance has been removed from the cluster or a
new one joins.

The reasoning behind this is that you would expect properties of the
cluster queue instances to match across the cluster, e.g. DEFBIND.
However, if they don't match then the queue manager has to pick a default
behaviour to use when applications open and put to that cluster queue.
What you get back from an inquire gives you the same value as you would be
using if opened for output. This means it's possible for an inquiring
application to determine what values would be used when putting messages
to a remote clustered queue.

Thanks
David Ware
WebSphere MQ



From: "Potkay, Peter M (CTO Architecture + Engineering)"
<Peter.Potkay-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 25/10/2013 20:20
Subject: Re: MQINQ and Clusters and needing to give too much access
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>



Request For Enhancement submitted. Please vote for it if you would like
apps that only need MQINQ to be able to run with only +inq and +connect in
an MQ Clustered environment.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=40878



Peter Potkay
Application Platform Engineering @ The Hartford
Websphere MQ, Message Broker and DataPower
(W) 860-624-1395 / (M) 860-202-1375

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 24, 2013 11:12 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: MQINQ and Clusters and needing to give too much access

Before I open an RFE to ?fix? this I wanted to see if any of you knew what
the use case was to require MQ to work this way.


http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.dev.doc/q027050_.htm?resultof=%22%4d%51%49%4e%51%22%20%22%6d%71%69%6e%71%22%20%22%63%6c%75%73%74%65%72%22%20


Basically this link says that unless you add the option of Browse, Set,
Output or Input to your MQOPEN call for a subsequent MQINQ (where you are
specifying the MQOO_INQUIRE option already), ?successive MQINQ calls might
inquire on different instances of the cluster queue.?

Now why in the world would anyone connect to QMx to inquire about a queue
on QMx and want to get results from random instances of that queue in the
cluster? And only a subset of the attributes you could get if it was the
local instance?

I am forced to give the UserID used by my little monitoring app more than
I think it needs. All it needs is +inq, but I have to add +put, +set, +get
or +browse. This is not good as now this ID, that only needs to execute an
occasional MQINQ call, needs the ability to read application data, or
consume app data, or insert its own messages, or PUT disable the queue.

My RFE would be for IBM to not require these extra authorizations. If the
QM sees an MQOPEN call with only MQOO_INQUIRE come in against queue,
assume the user wants information about the local instance of that queue
and ?bind? all future MQINQ calls using that handle to the local instance
of the queue. If there is no local instance of the queue hosted on that
QM, the MQOPEN call should fail.

Is there a legitimate use case for getting a subset of attributes from
some random instance of a queue in the cluster? If not, I think an RFE is
warrented.


(No, I am not going to rewrite my app to use PCF messages. This question
is all about the behavior of the MQINQ call and clustered queues.)


Peter Potkay



************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

Hi David,
I tested with the API Exerciser in MO71 and it does appear that specifying the local QM name in the MQOD and using just MQOO_INQUIRE gives me the local instance of the queue consistently, and allows me to inquire against things like q depth and IPROCS/OPROCS. This allows me to avoid having to add MQOO_BROWSE, MQOO_INPUT_*, or MQOO_SET to the MQOO_INQUIRE, and so I can have the ID run with only +connect and +inq authority (and not also +set or +browse or +get).

When researching this originally I used this page in the InfoCenter:
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.dev.doc/q027050_.htm

This page does not mention the (now) somewhat obvious solution of specifying the QM name on the MQOPEN. And so I went down the path of using OPEN options to fix the queue being opened.

There is another page in the Info Center that does talk about using the Destination QM Name on the MQOPEN to fix the q you open (thanks J.G. for referring me to it)
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.dev.doc/q026010_.htm


I submitted Feedback on the first page saying it should have info added to it, or that it should link to the page, that talks about using the QM name in the MQOD as an alternative to just MQOO_* options.


I'll test with the real app this week, but the MO71 API Exerciser tests are encouraging.



Peter Potkay


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of David Ware
Sent: Monday, October 28, 2013 6:17 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQINQ and Clusters and needing to give too much access

Hi Peter,

I think I agree that this particular usage of MQINQ does need some attention, but it may not need an RFE...

In the case where only MQOO_INQUIRE is set on the open and there is a local instance of the queue the local one will always be returned. However, it seems that on some platforms (i.e. distributed, not z/OS) the handle you get back only allows 'clustered' attributes to be inquired on, not the full set of local attributes. You might want to raise a PMR to have this investigated further, as platform inconsistencies are rarely good.

However, it is possible for you to force an MQOPEN with only MQOO_INQUIRE to open the local instance of the queue and return a handle that allows all local attributes to be inquired on. This is through setting the ObjectQMgrName to the local queue manager name on the MQOPEN. This should allow your application to inquire on the local attributes without needing further permissions.

When the doc says "If you open a cluster queue without fixing the queue that MQOPEN has bound to, successive MQINQ calls might inquire on different instances of the cluster queue. " it doesn't randomly pick one for each MQINQ. It is trying to say that unless you've explicitly bound to a specific cluster queue instance (e.g. using MQOO_BIND_ON_OPEN) then the remote instance of the queue may change under you, for example if the previously chosen remote instance has been removed from the cluster or a new one joins.

The reasoning behind this is that you would expect properties of the cluster queue instances to match across the cluster, e.g. DEFBIND. However, if they don't match then the queue manager has to pick a default behaviour to use when applications open and put to that cluster queue. What you get back from an inquire gives you the same value as you would be using if opened for output. This means it's possible for an inquiring application to determine what values would be used when putting messages to a remote clustered queue.

Thanks
David Ware
WebSphere MQ



From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>,
Date: 25/10/2013 20:20
Subject: Re: MQINQ and Clusters and needing to give too much access
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________



Request For Enhancement submitted. Please vote for it if you would like apps that only need MQINQ to be able to run with only +inq and +connect in an MQ Clustered environment.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=40878



Peter Potkay
Application Platform Engineering @ The Hartford
Websphere MQ, Message Broker and DataPower
(W) 860-624-1395 / (M) 860-202-1375

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 24, 2013 11:12 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: MQINQ and Clusters and needing to give too much access

Before I open an RFE to 'fix' this I wanted to see if any of you knew what the use case was to require MQ to work this way.


http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.dev.doc/q027050_.htm?resultof=%22%4d%51%49%4e%51%22%20%22%6d%71%69%6e%71%22%20%22%63%6c%75%73%74%65%72%22%20


Basically this link says that unless you add the option of Browse, Set, Output or Input to your MQOPEN call for a subsequent MQINQ (where you are specifying the MQOO_INQUIRE option already), "successive MQINQ calls might inquire on different instances of the cluster queue."

Now why in the world would anyone connect to QMx to inquire about a queue on QMx and want to get results from random instances of that queue in the cluster? And only a subset of the attributes you could get if it was the local instance?

I am forced to give the UserID used by my little monitoring app more than I think it needs. All it needs is +inq, but I have to add +put, +set, +get or +browse. This is not good as now this ID, that only needs to execute an occasional MQINQ call, needs the ability to read application data, or consume app data, or insert its own messages, or PUT disable the queue.

My RFE would be for IBM to not require these extra authorizations. If the QM sees an MQOPEN call with only MQOO_INQUIRE come in against queue, assume the user wants information about the local instance of that queue and 'bind' all future MQINQ calls using that handle to the local instance of the queue. If there is no local instance of the queue hosted on that QM, the MQOPEN call should fail.

Is there a legitimate use case for getting a subset of attributes from some random instance of a queue in the cluster? If not, I think an RFE is warrented.


(No, I am not going to rewrite my app to use PCF messages. This question is all about the behavior of the MQINQ call and clustered queues.)


Peter Potkay




************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[David Ware]

Hi Peter,

That's good that you seem to be making progress. I agree that the
documentation could do with improving, I'll see if I can add my two
pence/cent to the feedback.

Thanks
David




From: "Potkay, Peter M (CTO Architecture + Engineering)"
<Peter.Potkay-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 28/10/2013 11:43
Subject: Re: MQINQ and Clusters and needing to give too much access
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>



Hi David,
I tested with the API Exerciser in MO71 and it does appear that specifying
the local QM name in the MQOD and using just MQOO_INQUIRE gives me the
local instance of the queue consistently, and allows me to inquire against
things like q depth and IPROCS/OPROCS. This allows me to avoid having to
add MQOO_BROWSE, MQOO_INPUT_*, or MQOO_SET to the MQOO_INQUIRE, and so I
can have the ID run with only +connect and +inq authority (and not also
+set or +browse or +get).

When researching this originally I used this page in the InfoCenter:
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.dev.doc/q027050_.htm

This page does not mention the (now) somewhat obvious solution of
specifying the QM name on the MQOPEN. And so I went down the path of using
OPEN options to fix the queue being opened.

There is another page in the Info Center that does talk about using the
Destination QM Name on the MQOPEN to fix the q you open (thanks J.G. for
referring me to it)
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.dev.doc/q026010_.htm


I submitted Feedback on the first page saying it should have info added to
it, or that it should link to the page, that talks about using the QM name
in the MQOD as an alternative to just MQOO_* options.


I?ll test with the real app this week, but the MO71 API Exerciser tests
are encouraging.



Peter Potkay


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of David Ware
Sent: Monday, October 28, 2013 6:17 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQINQ and Clusters and needing to give too much access

Hi Peter,

I think I agree that this particular usage of MQINQ does need some
attention, but it may not need an RFE...

In the case where only MQOO_INQUIRE is set on the open and there is a
local instance of the queue the local one will always be returned.
However, it seems that on some platforms (i.e. distributed, not z/OS) the
handle you get back only allows 'clustered' attributes to be inquired on,
not the full set of local attributes. You might want to raise a PMR to
have this investigated further, as platform inconsistencies are rarely
good.

However, it is possible for you to force an MQOPEN with only MQOO_INQUIRE
to open the local instance of the queue and return a handle that allows
all local attributes to be inquired on. This is through setting the
ObjectQMgrName to the local queue manager name on the MQOPEN. This should
allow your application to inquire on the local attributes without needing
further permissions.

When the doc says "If you open a cluster queue without fixing the queue
that MQOPEN has bound to, successive MQINQ calls might inquire on
different instances of the cluster queue. " it doesn't randomly pick one
for each MQINQ. It is trying to say that unless you've explicitly bound to
a specific cluster queue instance (e.g. using MQOO_BIND_ON_OPEN) then the
remote instance of the queue may change under you, for example if the
previously chosen remote instance has been removed from the cluster or a
new one joins.

The reasoning behind this is that you would expect properties of the
cluster queue instances to match across the cluster, e.g. DEFBIND.
However, if they don't match then the queue manager has to pick a default
behaviour to use when applications open and put to that cluster queue.
What you get back from an inquire gives you the same value as you would be
using if opened for output. This means it's possible for an inquiring
application to determine what values would be used when putting messages
to a remote clustered queue.

Thanks
David Ware
WebSphere MQ



From: "Potkay, Peter M (CTO Architecture + Engineering)" <
Peter.Potkay-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 25/10/2013 20:20
Subject: Re: MQINQ and Clusters and needing to give too much access

Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>




Request For Enhancement submitted. Please vote for it if you would like
apps that only need MQINQ to be able to run with only +inq and +connect in
an MQ Clustered environment.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=40878




Peter Potkay
Application Platform Engineering @ The Hartford
Websphere MQ, Message Broker and DataPower
(W) 860-624-1395 / (M) 860-202-1375

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 24, 2013 11:12 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: MQINQ and Clusters and needing to give too much access

Before I open an RFE to ?fix? this I wanted to see if any of you knew what
the use case was to require MQ to work this way.


http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.dev.doc/q027050_.htm?resultof=%22%4d%51%49%4e%51%22%20%22%6d%71%69%6e%71%22%20%22%63%6c%75%73%74%65%72%22%20



Basically this link says that unless you add the option of Browse, Set,
Output or Input to your MQOPEN call for a subsequent MQINQ (where you are
specifying the MQOO_INQUIRE option already), ?successive MQINQ calls might
inquire on different instances of the cluster queue.?

Now why in the world would anyone connect to QMx to inquire about a queue
on QMx and want to get results from random instances of that queue in the
cluster? And only a subset of the attributes you could get if it was the
local instance?

I am forced to give the UserID used by my little monitoring app more than
I think it needs. All it needs is +inq, but I have to add +put, +set, +get
or +browse. This is not good as now this ID, that only needs to execute an
occasional MQINQ call, needs the ability to read application data, or
consume app data, or insert its own messages, or PUT disable the queue.

My RFE would be for IBM to not require these extra authorizations. If the
QM sees an MQOPEN call with only MQOO_INQUIRE come in against queue,
assume the user wants information about the local instance of that queue
and ?bind? all future MQINQ calls using that handle to the local instance
of the queue. If there is no local instance of the queue hosted on that
QM, the MQOPEN call should fail.

Is there a legitimate use case for getting a subset of attributes from
some random instance of a queue in the cluster? If not, I think an RFE is
warrented.


(No, I am not going to rewrite my app to use PCF messages. This question
is all about the behavior of the MQINQ call and clustered queues.)


Peter Potkay



************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************



List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU







List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html