Queue permissions are the Object Authority Manager grants that control who may put, get, browse, inquire, clear, or alter each queue object on a queue manager. Every business message flowing through IBM MQ eventually touches a QLOCAL, or passes through a QALIAS or QREMOTE definition that resolves to one. Applications see 2035 when the effective principal lacks a required bit; operators sometimes spend hours on network traces when dspmqaut would show missing +put on a three-letter service account. Queue permissions are separate from authentication—you can authenticate successfully and still fail to open PAYMENT.IN. They are also separate from queue attributes: PUT(ENABLED) with no +put grant still fails. This tutorial covers permission bits for each queue operation, patterns for producers and consumers, alias and remote queue nuances, transmission queues for channels, model and dynamic queues, pairing with MCAUSER, inhibit attributes, cluster queue aliases, and audit templates for high-value queues.
QLOCAL is the primary application queue. QALIAS provides an alternate name that may point to a QLOCAL. QREMOTE describes a queue on another queue manager and references a transmission queue. OAM stores grants per object name—the string your application passes to MQOPEN. If developers open ORDERS.ALIAS but grants exist only on ORDERS.IN, you get 2035 until setmqaut targets the opened name or you standardize on one name in code and documentation.
| Permission | Operation | Who needs it |
|---|---|---|
| +put | MQPUT, non-persistent and persistent writes | Producer applications, inbound channels |
| +get | Destructive MQGET | Consumer applications |
| +browse | Browse without removing | Support, monitors, poison-msg inspection |
| +inq +dsp | DISPLAY depth and attributes | Monitoring, Grafana, operations dashboards |
| +clr | CLEAR QUEUE | Controlled purge jobs only |
| +chg +dlt +alt | ALTER, DELETE definitions | MQ administrators, deployment automation |
123456* Producer writes ORDERS.IN: setmqaut -m QM1 -n ORDERS.IN -t queue -p order_prod +put +connect * Consumer reads ORDERS.OUT: setmqaut -m QM1 -n ORDERS.OUT -t queue -p order_cons +get +browse +connect * Verify: dspmqaut -m QM1 -n ORDERS.IN -t queue -p order_prod
Request/reply designs grant +put on the request queue and +get on the reply queue to the same client ID, or split producer and consumer IDs for stronger separation. Reply-to headers do not bypass OAM—the opener still needs +put on the queue it writes to. Bridge programs need both sides if they read and write multiple queues.
DEFINE QLOCAL with PUT(ENABLED) and GET(ENABLED) is the default for application queues. PUT(DISABLED) blocks all puts regardless of +put until an operator ALTERs the queue—useful during maintenance. GET(INHIBITED) blocks destructive gets. Security hardening sometimes sets INHIBIT on administrative queues. Always DISPLAY QLOCAL and dspmqaut together when debugging 2035.
Applications opening a QALIAS name need grants on that alias unless IBM documentation for your release states authority checks pass through to the base queue. Test with the exact open name in a lab. QREMOTE permissions apply to the remote queue object; the channel MCAUSER performing the put to XMITQ needs +put on the transmission queue and appropriate rights on the receiving queue manager for the ultimate target. Cluster queue aliases add routing complexity—grant on the name cluster workloads open locally.
Sender channels use XMITQ; MCAUSER or the sending mechanism needs +put on XMITQ. System queues such as dead-letter queues should not grant +put to general applications—only error handlers and administrators. Amqzmurc and similar processes run under privileged IDs; do not copy their grants to application service accounts.
Opening a model queue for dynamic creation requires +crt on the model or parent profile per platform rules, plus subsequent rights on the dynamic queue name created. Managed subscription queues appear at runtime—grant +get on naming patterns or use template authority documented for your estate. Missing dynamic queue grants surfaces as 2035 on first message, not at deploy time.
The queue is a mailbox slot. Queue permissions are which keys open which slot—deposit mail (+put), take mail (+get), peek through the window (+browse). The building manager can still lock the slot (PUT DISABLED) even if you hold a key.
Remote puts arrive under MCAUSER on the receiver. Grant +put on target QLOCAL to mqbridge, not to the remote operator personal ID. SVRCONN with ADOPTCTX(NO) uses MCAUSER for all client puts—every application sharing that channel shares one permission footprint unless CHLAUTH maps users individually.
Each mailbox has rules about who may drop letters in, who may take letters out, and who may only look through the window. Queue permissions are those rules.
Write setmqaut for request/reply pair with separate producer and consumer IDs.
List checks when PUT(ENABLED) yes but MQPUT returns 2035.
Design read-only monitor grants on ten payment queues without +get.
1. MQPUT requires OAM:
2. PUT(DISABLED) with +put grant:
3. Destructive read needs:
4. setmqaut -t for queues: