What it means
The queue manager checked whether the user ID may do what was asked and the answer was no. This can happen on connect (no connect authority, or wrong user ID, password or token), on open (the open options need more access than the user has), on subscribe, on commands, and on close of a permanent dynamic queue. Nothing was put or got.
On z/OS, checks go to the external security manager, such as RACF, with classes like MQCONN, MQQUEUE and MQADMIN. CICS programs get MQRC_CONNECTION_NOT_AUTHORIZED instead on connect. On distributed platforms, the object authority manager and, for clients, channel authentication rules and connection authentication decide.
Typical causes
- The user ID has no access, or too little, for example only browse when MQPUT needs put authority.
- The program runs under a different user ID than expected, such as a batch ID, the CICS task user, or the channel's MCAUSER.
- A client sent a wrong or missing user ID or password, or a channel authentication rule blocks the address or user.
- A new queue was created without a matching security profile or authority record.
- Security was changed but the queue manager's cached view was not refreshed.
How to fix it
- Find which call failed (MQCONN, MQOPEN, MQSUB and so on), on which object, with which open options.
- Find the real user ID used. On z/OS read the ICH408I message; on distributed look in the queue manager error log.
- Grant the missing access (RACF profile on z/OS, setmqaut or SET AUTHREC on distributed), then run REFRESH SECURITY if needed.
- For clients, check credentials and DISPLAY CHLAUTH rules for the channel.
- Do not fix it by widening access for everyone; grant only what the program needs.
Example
Illustrative only; names and values are invented.
MQOPEN failed CompCode=2 Reason=2035 Queue=APP.REQUEST.QUEUE QMgr=QM01
ICH408I USER(LEARNER ) GROUP(APPGRP ) NAME(BATCH USER)
QM01.APP.REQUEST.QUEUE CL(MQQUEUE )
INSUFFICIENT ACCESS AUTHORITY