This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.

Many of us are familiar with the MQ reason code 2035. Some of us have seen it so often we know off by heart that it means MQRC_NOT_AUTHORIZED. So what do you do when you get one of those 2035s and you need to rectify it. You know you need to grant authority to someone for something, but what exactly, and who exactly? Often the application suffering the 2035 will tell you it needs access to a specific queue (after all they should know what they were trying to do when they got the failure) but sometimes the user id that needs the access granted to it is not so easy to figure out, especially when it’s a client connected application - after all the MCAUSER can be set from lots of different places (see "All the ways to set MCAUSER" for more on that subject).

This post is going to discuss the ways the queue manager outputs more information to you, the system administrator, to figure out what authority is missing and for who.

In modern versions of IBM MQ, the error log contains a message something like this:-

AMQ8077: Entity 'mqguser' has insufficient authority to access object 'Q1'.
EXPLANATION:
The specified entity is not authorized to access the required object. The following requested permissions are unauthorized: put
ACTION:
Ensure that the correct level of authority has been set for this entity against the required object, or ensure that the entity is a member of a privileged group.

This error message gives you most of the information you need to put an authority record in place to allow the application to get it's required access to the resource in question. It gives you the entity, which can be a user id or a group, the object name and the missing authority. In most cases you'll recognise the object from it's name and know what it is, in this example it's a queue, although the message doesn't actually tell you that. The missing authority can also be a clue to this, if it says "put" authority is missing you know it is likely a queue or a topic, where's if it says "connect" authority is missing you know it is the queue manager object. Not so easy if the missing authority is "dsp" because that can apply to any object. Hopefully though, the context will be enough for you to tell.

Remember that there are some cases where a queue and a topic are mapped onto each other, especially when using Queued Pub/Sub. If you are sure the user has already been granted the correct access and yet it is still reporting missing access to that name, maybe it's the topic and not the queue of the same name that is the issue.

If you're on an earlier version of MQ, for example WebSphere MQ V6, then you don't have these error messages; or if you want some more information to figure out what the object in question is; or if you want to know what application is making these attempts at unauthorised MQ calls; then there is another reporting mechanism that you can turn on and that is authority events.

These are enabled by the following command:-

ALTER QMGR AUTHOREV(ENABLED)

and cause the queue manager to write an event message to the SYSTEM.ADMIN.QMGR.EVENT queue each time an application causes an MQRC_NOT_AUTHORIZED (2035) reason code due to a lack of authority. Here's an example event message.

[  640 bytes] Message Content
[  640 bytes] Event Header (MQCFH)
Version      :1
Command      :44 (QMgr Event)
Sequence No. :1
Reason       :2035 (Not authorized.)
Parm Count   :10
[  604 bytes] String (MQCFST)
Parameter Id :2015 (QMgr Name)
String Length:48
Value        :'MQ804                                           '
[  536 bytes] Integer (MQCFIN)
Parameter Id :1020 (Reason Qualifier)
Value        :2 [0x'2'] MQRQ_OPEN_NOT_AUTHORIZED
[  520 bytes] Integer (MQCFIN)
Parameter Id :1022 (Open Options)
Value        :00000010
              00000010 Output
[  504 bytes] String (MQCFST)
Parameter Id :3025 (User Identifier)
String Length:12
Value        :'mqguser     '
[  472 bytes] String (MQCFST)
Parameter Id :2016 (Q Name)
String Length:48
Value        :'Q1                                              '
[  404 bytes] Integer (MQCFIN)
Parameter Id :1016 (Object Type)
Value        :1 [0x'1']
[  388 bytes] Integer (MQCFIN)
Parameter Id :1 (Appl Type)
Value        :7 [0x'7'] MQAT_QMGR
[  372 bytes] String (MQCFST)
Parameter Id :3024 (Appl Name)
String Length:20
Value        :'D:\nttools\mqscx.exe'
[  324 bytes] String (MQCFST)
Parameter Id :3501 (Channel Name)
String Length:20
Value        :'APP1.SVRCONN        '
[  284 bytes] String (MQCFST)
Parameter Id :3506 (Connection Name)
String Length:264
Value        :'127.0.0.1

As you can see it gives you slightly different information from the error message. You can see the user id and the resource in question, and this time you also know the object type. You also see details about the application that made the failing request which can be handy if you're trying to track down who's using the wrong queue, or trying to gain access to something they're not allowed to use.

Also instead of being told what authority is missing, instead you are shown the options used (Open Options in this case where an MQOPEN failed).

The combination of both the error message, which is useful when your main goal is to rectify the missing authority, and the event message, which is useful when you main goal is to track down the perpetrator, gives you a complete picture of the failure.