MQ

Hello,

I've got colleagues willing to connect dynatrace agent to some queue managers. Dynatrace documentation indicates that it needs get permission on SYSTEM.DEFAULT.MODEL queue. We usually never grant that permission, all applications including administration tools seem happy without it.

I have a hard time finding in IBM MQ documentation what get, inq and put permission actually allow to do 

Can someone point me to the right place in the documentation or explain?

Thanks & Regards;

Laurent

Hello,

I've got colleagues willing to connect dynatrace agent to some queue managers. Dynatrace documentation indicates that it needs get permission on SYSTEM.DEFAULT.MODEL queue. We usually never grant that permission, all applications including administration tools seem happy without it.

I have a hard time finding in IBM MQ documentation what get, inq and put permission actually allow to do 

Can someone point me to the right place in the documentation or explain?

Thanks & Regards;

Laurent

We use Dynatrace to monitor MQ with LDAP as the authenticator.  These are the permissions given to our Dynatrace LDAP group (mq_dynatrace):

Hello,

I've got colleagues willing to connect dynatrace agent to some queue managers. Dynatrace documentation indicates that it needs get permission on SYSTEM.DEFAULT.MODEL queue. We usually never grant that permission, all applications including administration tools seem happy without it.

I have a hard time finding in IBM MQ documentation what get, inq and put permission actually allow to do 

Can someone point me to the right place in the documentation or explain?

Thanks & Regards;

Laurent

Hello,

I've got colleagues willing to connect dynatrace agent to some queue managers. Dynatrace documentation indicates that it needs get permission on SYSTEM.DEFAULT.MODEL queue. We usually never grant that permission, all applications including administration tools seem happy without it.

I have a hard time finding in IBM MQ documentation what get, inq and put permission actually allow to do 

Can someone point me to the right place in the documentation or explain?

Thanks & Regards;

Laurent

Hi Laurent,

A MODEL queue, as its name suggests, is used as a template to create another queue. The most common use of MODEL queues is to create dynamic reply queues for applications that send REQUEST messages and expect to get REPLY messages in return. They need a queue name to put into the REQUEST message so that the REPLY messages have a target to come back to.

If you are not granting authority to the SYSTEM.DEFAULT.MODEL.QUEUE then the creation of dynamic queues will not be able to be successful. If your Dynatrace application is not complaining is issues as a result, this suggests one of the following things is happening (to me - guessing from afar):

• The application opening the SYSTEM.DEFAULT.MODEL.QUEUE is running with mqm privileges and does not need you to grant it authority because it has authority to everything already
• The application needing a ReplyToQ has the ability to be configured to use a QLOCAL directly instead of making a dynamic queue from a QMODEL. Thus the SYSTEM.DEFAULT.MODEL.QUEUE is not in use in your environment.
• As @Francois Brandelik suggested in another answer, a different QMODEL could be in use, and so again, the SYSTEM.DEFAULT.MODEL.QUEUE is not in use in your environment.

No doubt there could be other possibilities that have not occurred to me.

To answer your explicit question:

• get authority enables an application to MQOPEN a queue using the MQOO_INPUT_* options, that is to open a queue to use for getting.
• inq authority enables an application to MQOPEN a queue using the MQOO_INQUIRE option, that is to open a queue to use for inquiring via MQINQ.
• put authority enables an application to MQOPEN a queue using the MQOO_OUTPUT option, that is to open a queue to use for putting.

Cheers,
Morag

Hello,

I've got colleagues willing to connect dynatrace agent to some queue managers. Dynatrace documentation indicates that it needs get permission on SYSTEM.DEFAULT.MODEL queue. We usually never grant that permission, all applications including administration tools seem happy without it.

I have a hard time finding in IBM MQ documentation what get, inq and put permission actually allow to do 

Can someone point me to the right place in the documentation or explain?

Thanks & Regards;

Laurent

Hello @Morag Hughson,

Thanks for your response. I realize now my poor wording in my initial post. Let me rephrase in light of your comments.

I'm well aware of what the put, get and inquire permissions allow to do on a regular queue. What I don't understand is what these permissions allow to do when granted on SYSTEM.DEFAULT.MODEL.QUEUE (or any model queue). For example, put and get do not make sense IMO because this queue is just a template not meant to hold actual messages. Instead, there must be a queue profile matching the name of the actual dynamic queue to which you grant put and get permission.

Moreover, I'm glad you replied here because we can use MO71 as an example. I'm pretty sure that users who have access to a queue manager via MO71 do not need get permission on SYSTEM.DEFAULT.MODEL.QUEUE to get messages from the dynamic reply queue that MO71 creates.

Thanks in advance for your time.

Regards,

Laurent

Hi Laurent,

A MODEL queue, as its name suggests, is used as a template to create another queue. The most common use of MODEL queues is to create dynamic reply queues for applications that send REQUEST messages and expect to get REPLY messages in return. They need a queue name to put into the REQUEST message so that the REPLY messages have a target to come back to.

If you are not granting authority to the SYSTEM.DEFAULT.MODEL.QUEUE then the creation of dynamic queues will not be able to be successful. If your Dynatrace application is not complaining is issues as a result, this suggests one of the following things is happening (to me - guessing from afar):

• The application opening the SYSTEM.DEFAULT.MODEL.QUEUE is running with mqm privileges and does not need you to grant it authority because it has authority to everything already
• The application needing a ReplyToQ has the ability to be configured to use a QLOCAL directly instead of making a dynamic queue from a QMODEL. Thus the SYSTEM.DEFAULT.MODEL.QUEUE is not in use in your environment.
• As @Francois Brandelik suggested in another answer, a different QMODEL could be in use, and so again, the SYSTEM.DEFAULT.MODEL.QUEUE is not in use in your environment.

No doubt there could be other possibilities that have not occurred to me.

To answer your explicit question:

• get authority enables an application to MQOPEN a queue using the MQOO_INPUT_* options, that is to open a queue to use for getting.
• inq authority enables an application to MQOPEN a queue using the MQOO_INQUIRE option, that is to open a queue to use for inquiring via MQINQ.
• put authority enables an application to MQOPEN a queue using the MQOO_OUTPUT option, that is to open a queue to use for putting.

Cheers,
Morag

Hello,

I've got colleagues willing to connect dynatrace agent to some queue managers. Dynatrace documentation indicates that it needs get permission on SYSTEM.DEFAULT.MODEL queue. We usually never grant that permission, all applications including administration tools seem happy without it.

I have a hard time finding in IBM MQ documentation what get, inq and put permission actually allow to do 

Can someone point me to the right place in the documentation or explain?

Thanks & Regards;

Laurent

Hi Laurent,

Authority checks are done at MQOPEN time. An MQOPEN call provides the usage intent for the object being opened. For example, if you intend to use the opened queue for putting messages, you make an MQOPEN call with the MQOO_OUTPUT option. This (on distributed) causes the queue manager to check if you have +put authority before allowing the MQOPEN to work. If you then take the resultant object handle and pass it into an MQPUT call, it will allow that to work.

The same pattern is true for a MODELQ, even though the object handle that is returned from the MQOPEN does not refer to the QMODEL but instead to the created dynamic queue. The object handle has only been opened for those uses.

For a dynamic queue, on distributed, the owner, that is the user ID that caused it to be created, actually is granted +all authority. So, if you take the full name of the dynamic queue and do another MQOPEN call on that queue name, you can ask for ANY open options you want, and all will work on this new object handle. Only those that you were allowed on the MQOPEN of the QMODEL work on the original object handle. MO71 runs with two threads, and the second thread does exactly this. You may be running without +get authority as a result of this, but you must have SOME permissions on the QMODEL or the first MQOPEN would fail.

If your MO71 users are not in the mqm group, and do not have ANY permissions on the SYSTEM.DEFAULT.MODEL.QUEUE then you are either using a different QMODEL for MO71 reply queues, or you are using a QLOCAL for each MO71 user and not making use of any QMODEL. Check what is filled in in the "Reply Queue" field on the "Connection" tab of the location dialog to be certain what is in use.

Cheers,
Morag

Hello @Morag Hughson,

Thanks for your response. I realize now my poor wording in my initial post. Let me rephrase in light of your comments.

I'm well aware of what the put, get and inquire permissions allow to do on a regular queue. What I don't understand is what these permissions allow to do when granted on SYSTEM.DEFAULT.MODEL.QUEUE (or any model queue). For example, put and get do not make sense IMO because this queue is just a template not meant to hold actual messages. Instead, there must be a queue profile matching the name of the actual dynamic queue to which you grant put and get permission.

Moreover, I'm glad you replied here because we can use MO71 as an example. I'm pretty sure that users who have access to a queue manager via MO71 do not need get permission on SYSTEM.DEFAULT.MODEL.QUEUE to get messages from the dynamic reply queue that MO71 creates.

Thanks in advance for your time.

Regards,

Laurent

Hi Laurent,

A MODEL queue, as its name suggests, is used as a template to create another queue. The most common use of MODEL queues is to create dynamic reply queues for applications that send REQUEST messages and expect to get REPLY messages in return. They need a queue name to put into the REQUEST message so that the REPLY messages have a target to come back to.

If you are not granting authority to the SYSTEM.DEFAULT.MODEL.QUEUE then the creation of dynamic queues will not be able to be successful. If your Dynatrace application is not complaining is issues as a result, this suggests one of the following things is happening (to me - guessing from afar):

• The application opening the SYSTEM.DEFAULT.MODEL.QUEUE is running with mqm privileges and does not need you to grant it authority because it has authority to everything already
• The application needing a ReplyToQ has the ability to be configured to use a QLOCAL directly instead of making a dynamic queue from a QMODEL. Thus the SYSTEM.DEFAULT.MODEL.QUEUE is not in use in your environment.
• As @Francois Brandelik suggested in another answer, a different QMODEL could be in use, and so again, the SYSTEM.DEFAULT.MODEL.QUEUE is not in use in your environment.

No doubt there could be other possibilities that have not occurred to me.

To answer your explicit question:

• get authority enables an application to MQOPEN a queue using the MQOO_INPUT_* options, that is to open a queue to use for getting.
• inq authority enables an application to MQOPEN a queue using the MQOO_INQUIRE option, that is to open a queue to use for inquiring via MQINQ.
• put authority enables an application to MQOPEN a queue using the MQOO_OUTPUT option, that is to open a queue to use for putting.

Cheers,
Morag

Hello,

I've got colleagues willing to connect dynatrace agent to some queue managers. Dynatrace documentation indicates that it needs get permission on SYSTEM.DEFAULT.MODEL queue. We usually never grant that permission, all applications including administration tools seem happy without it.

I have a hard time finding in IBM MQ documentation what get, inq and put permission actually allow to do 

Can someone point me to the right place in the documentation or explain?

Thanks & Regards;

Laurent