Unmanaged queues are the destination queues you choose by name before IBM MQ links them to a subscription. DEFINE QLOCAL('PAYMENT.EVENTS.SUB') in Tuesday’s MQSC pipeline; DEFINE SUB DESTQL('PAYMENT.EVENTS.SUB') DESTTYPE(UNMANAGED) on Wednesday; payment service MQGET on Thursday—every step visible in change control. This is how most z/OS and distributed MQI estates run production pub/sub: no surprise queues, RACF profiles spelled the same in every environment, and capacity planners see PAYMENT.EVENTS.SUB in the same spreadsheet as PAYMENT.REQUEST. This tutorial covers DEFINE QLOCAL for subscriber use, DESTTYPE UNMANAGED on subscriptions, sizing for durable offline periods, authority layering with PUB and SUB on topics, sharing pitfalls, cluster considerations when DEST is on another queue manager, trigger and monitoring integration, and comparison with managed queues when architects choose a standard for new applications.
The queue is a normal local queue unless your design uses alias or remote indirection—unusual for subscriber DEST. Set DESCR documenting owning application, MAXDEPTH for worst-case backlog, MAXMSGL for largest expected message, DEFPSIST consistent with your persistence standard, and BOQNAME if poison messages need a backout path separate from the main DLQ. SHARE and DEFSOPT affect concurrent getters if multiple instances read the same DEST—many designs use one consumer per DEST queue name.
1234567891011DEFINE QLOCAL('FIN.PAYMENT.SUB') REPLACE + DESCR('Payment events subscriber - unmanaged DEST') + MAXDEPTH(200000) MAXMSGL(4194304) DEFPSIST(YES) + DEFPRTY(0) GET(ENABLED) PUT(ENABLED) DEFINE SUB('FIN.PAYMENT.SUBSCRIBER') REPLACE + TOPICSTR('prod/finance/payment/#') DESTQL('FIN.PAYMENT.SUB') + DESTQMGR('QM1') DESTTYPE(UNMANAGED) DURSUB(YES) SUBSCOPE(QMGR) ALTER AUTHREC OBJTYPE(QUEUE) PROFILE('FIN.PAYMENT.SUB') + PRINCIPAL('paycons') AUTHADD(GET DSP) ALTER AUTHREC OBJTYPE(TOPIC) PROFILE('prod/finance/payment/#') + PRINCIPAL('paycons') AUTHADD(SUB)
| Attribute | Role for DEST | Beginner tip |
|---|---|---|
| MAXDEPTH | Cap messages while consumer slow or down | Size for peak rate × outage window |
| MAXMSGL | Largest single publication copy | Match publisher max message size |
| DEFPSIST | Persistent vs non-persistent copies | YES for durable business events |
| GET | Allow subscriber MQGET | ENABLED unless maintenance lock |
| PUT | Allow queue manager delivery puts | ENABLED for pub/sub engine |
| BOQNAME | Backout queue for bad messages | Pair with app poison handling |
DESTQL must exactly match the QLOCAL name. DESTQMGR is usually the local queue manager name; cross-queue-manager DEST uses advanced proxy patterns beyond this beginner page—verify IBM documentation before pointing DEST to remote QMgr. DESTTYPE(UNMANAGED) is explicit in MQSC; omitting managed semantics defaults toward unmanaged on many administrative DEFINE SUB examples. TOPICSTR or TOPICOBJ defines what arrives; the queue only holds copies that matched.
If the subscriber is down over a weekend and publishers emit continuously, CURDEPTH grows until MAXDEPTH. Calculate: messages per hour × hours offline, add headroom. When full, publish may fail or subscriptions back pressure depending on configuration—incidents look like “publisher broken” when DEST is full. Monitor CURDEPTH and oldest message age. Consider separate DEST per consumer class so one slow team does not share one MAXDEPTH with critical alerting.
SUB on the topic pattern allows registering interest. +get on FIN.PAYMENT.SUB allows reading copies. Missing SUB causes subscription define or MQSUB to fail. Missing GET causes 2035 on MQGET despite messages visible to operators with elevated authority. Queue manager delivery puts require put authority for the putting context—often satisfied by defaults but verify on z/OS RACF. Document both grants in your security standard template per application.
Standard pattern: one DEFINE SUB, one DEST queue, one consumer application cluster reading that queue. Sharing one DEST across multiple SUB objects to different topic patterns merges unrelated events into one FIFO—usually undesirable. Sharing one SUB across multiple consumers on one queue is a work-queue pattern; ensure competing MQGET is intentional and use appropriate syncpoint discipline.
Choose unmanaged when operations owns queue standards, mainframe RACF requires pre-defined profiles, or multiple tools reference fixed queue names. Choose managed when JMS microservices deploy rapidly and queue naming is disposable. Regulated industries often mandate unmanaged for production regardless of client technology.
You rent PO Box 4821 (DEFINE QLOCAL) before telling the post office to forward all “finance magazines” there (DEFINE SUB). Managed mode is “give me any free box” instead—you still need permission to open whichever box you receive.
You pick your mailbox number and put your name on it before signing up for mail. The post office does not invent a new mailbox for you—they use the one you chose.
Write MQSC for QLOCAL plus UNMANAGED SUB with DURSUB YES and auth stubs.
Estimate MAXDEPTH if publish rate is 1200/hour and outage is 48 hours.
List why sharing one DEST between two SUBs is usually a bad idea.
1. DESTTYPE UNMANAGED means:
2. Order of create should be:
3. Subscriber app needs on DEST:
4. Durable offline messages accumulate on: