In IBM MQ publish/subscribe, every matching publication becomes a put to a destination queue. Managed queues are those destination queues the queue manager creates for you when a subscription uses DESTTYPE(MANAGED)—the companion object to managed subscriptions, but focused on the queue itself: what appears in the object repository, how it is named, what defaults apply, how operations monitors depth, and how security is granted after auto-provisioning. Mainframe teams accustomed to every QLOCAL existing in change-controlled MQSC before go-live often discover dozens of new queues after a Java deploy because JMS durable subscribers requested managed destinations. This tutorial explains when managed queues appear, how they differ from queues you define explicitly, attribute inheritance and limits, authority after create, capacity and MAXDEPTH surprises, orphan detection, pairing with JMS and MQI, and runbook steps to audit a queue manager without losing track of system-generated names.
Triggers include DEFINE SUB with DESTTYPE(MANAGED), dynamic subscription APIs that request managed destinations, and JMS createDurableSubscriber patterns that map to managed semantics on the wire. The queue manager allocates a QLOCAL, binds it to the subscription, and begins delivering publication copies there. Until the subscription exists, the queue may not exist—your nightly job that only lists queues from Git will miss them until after first connect. Operations should extend monitoring to DISPLAY SUB(*) driven discovery or object inventory tools that scan live repositories.
| Stage | What happens | Operations action |
|---|---|---|
| Subscription create | MQ defines QLOCAL DEST with defaults | Capture DESTQL from DISPLAY SUB |
| Active delivery | CURDEPTH grows with publications | Alert MAXDEPTH like any app queue |
| Subscriber connected | Application MQGET drains DEST | Monitor age of oldest message |
| Subscription delete | Queue may be deleted per rules | Verify no orphan QLOCAL remains |
| QM restart | Durable sub reloads; queue persists if not deleted | Confirm authority profiles still apply |
Names are often generated from subscription identity, topic hash, or platform conventions such as prefixes under SYSTEM or AMQ—not guaranteed across releases or platforms. Do not hard-code managed queue names in application config; resolve via subscription handle or DISPLAY SUB. For documentation, record the mapping subscription name to DESTQL after first run in your application CMDB. Renaming managed queues manually breaks the subscription link—use DELETE SUB and recreate instead of ALTER QLOCAL name where unsupported.
Auto-created queues inherit model or system defaults for MAXDEPTH, MAXMSGL, DEFPSIST, and sharing. High-volume topics can fill shallow MAXDEPTH quickly because every publication copies to the managed DEST. Some attributes can be altered after creation; others are tied to subscription options. Compare with unmanaged queues where you set MAXDEPTH(100000) up front in MQSC. If managed defaults are too small, consider switching to unmanaged DEST with explicit DEFINE QLOCAL, or use ALTER QLOCAL after create with change control documenting the subscription DESTQL affected.
1234567DEFINE SUB('JMS.DURABLE.EXAMPLE') TOPICSTR('prod/inventory/#') + DESTTYPE(MANAGED) DURSUB(YES) SUBSCOPE(QMGR) * After application connects: DISPLAY SUB('JMS.DURABLE.EXAMPLE') DESTQL DESTQMGR DISPLAY QLOCAL('') CURDEPTH MAXDEPTH ALTER AUTHREC OBJTYPE(QUEUE) PROFILE(' ') + PRINCIPAL('invapp') AUTHADD(GET DSP)
Three identities matter: the publisher (PUB on topic), the queue manager delivery path (+put on DEST for the putting context IBM uses), and the subscriber (+get on DEST). Managed create does not imply +get for your application service ID. A common 2035 on MQGET after successful subscription registration means OAM on the new queue was never updated. Automate authority grants in deploy pipelines triggered by DISPLAY SUB output, or standardize on unmanaged queues when RACF profiles must exist before runtime.
Unmanaged queues are QLOCAL objects you define first; DEFINE SUB points DESTQL at them. Managed queues defer QLOCAL creation to the queue manager. Managed reduces application boilerplate; unmanaged maximizes operational control. Hybrid estates use unmanaged for COBOL batch DEST names and managed for microservice JMS clients on the same queue manager—both compete for page set and disk; capacity planning sums all DEST queues regardless of who created them.
An unmanaged queue is reserving a specific room number in advance. A managed queue is the hotel assigning whichever room is free when you check in—you still need a key (+get) to enter, and housekeeping (the queue manager) delivers mail (+put) to that room number printed on your registration (DISPLAY SUB).
When you sign up for a magazine subscription, the post office makes a new mailbox just for you instead of you building one in your yard first. IBM MQ makes that mailbox (queue) when you sign up (managed subscription).
After a JMS app starts, list commands to find DESTQL and check CURDEPTH.
Why might MAXDEPTH on a managed queue default be dangerous for prod/inventory/#?
Write three OAM grants needed for delivery and consumption on a managed DEST.
1. Managed queues are created by:
2. To read messages the app needs on DEST:
3. DISPLAY SUB shows:
4. DESTTYPE MANAGED on DEFINE SUB means: