The GET attribute on an IBM MQ queue answers whether consumers may read messages from that queue. GET(ENABLED) is the normal setting for work queues, reply queues, and dead-letter handlers. GET(DISABLED) turns off consumer access at the object level—stronger than a misconfigured app because even privileged code cannot open for get until operations ALTER the queue. GET works together with PUT (can you add messages?), SHARE (can multiple apps get concurrently?), and OAM authority (is this user allowed?). Beginners debugging MQGET failures should check GET before chasing code bugs. This tutorial covers ENABLED and DISABLED, browse versus destructive get, channel behavior, maintenance patterns, and how GET interacts with open options and reason codes.
| Value | Application MQGET | Typical use |
|---|---|---|
| ENABLED | Allowed (with authority) | Consumer applications |
| DISABLED | Blocked at object level | Maintenance, ingest-only |
IBM MQ also accepts YES/NO synonyms on some platforms for historical compatibility—ENABLED/DISABLED are preferred in modern MQSC. DISPLAY QLOCAL shows the stored value. Consistency across your script library avoids surprise ALTER failures between environments.
Common reason codes: 2035 not authorized (GET enabled but no permission), 2042 object not open for get, 2085 unknown object. GET disabled produces object-specific errors—consult your client reason code list.
12345DEFINE QLOCAL('ORDERS.IN') REPLACE GET(ENABLED) PUT(ENABLED) ALTER QLOCAL('ORDERS.IN') GET(DISABLED) * Consumers fail MQOPEN until: ALTER QLOCAL('ORDERS.IN') GET(ENABLED) DISPLAY QLOCAL('ORDERS.IN') GET PUT
Destructive get removes the message from the queue—standard competing consumer pattern. Browse lets operators or programs inspect without removal—useful for support, dangerous if left uncommitted browse locks messages on some options. Both need GET(ENABLED). Browse does not replace monitoring tools but helps incident triage. Applications should not browse production queues in tight loops—use DISPLAY or event monitoring where possible.
SHARE(ENABLED) allows multiple applications to open for get concurrently with compatible options—horizontal scaling of consumers. SHARE(DISABLED) forces exclusive access patterns. GET disabled blocks everyone; SHARE disabled blocks only shared opens. See the SHARE tutorial for competing consumers and exclusive readers.
Before application upgrade, some teams ALTER GET(DISABLED) to drain existing consumers after graceful shutdown, then deploy, then GET(ENABLED). Coordinate with load balancers and trigger monitors. Safer than killing processes mid-get. Document rollback—forgetting to re-enable GET leaves messages aging until MAXDEPTH or alert.
Object-level GET and OAM work together. Grant +get on queue to consumer group. Deny get on production queues to developers while allowing put to test queues. DISPLAY AUTHREC or security commands on your platform show effective access. Cluster puts to remote queues check authority at destination for the get side on the remote application.
GET is whether anyone is allowed to take letters out of the mailbox. ENABLED means yes, with a key (authority). DISABLED means the mailbox is sealed for taking mail out—letters can still be dropped in if PUT is enabled.
Consumer gets 2035. List order of checks: GET, PUT, authority, name typo.
When would you run a queue with PUT(ENABLED) GET(DISABLED)?
Does GET(DISABLED) stop DISPLAY QSTATUS CURDEPTH? Explain.
1. GET(DISABLED) prevents:
2. Browse requires:
3. GET(ENABLED) alone is not enough—you also need:
4. Ingest-only queue pattern often uses: