Managed subscriptions shift destination queue housekeeping from your operations team to the IBM MQ queue manager. When an application registers a subscription in managed mode, MQ can create a destination queue with a generated name, apply default attributes, and remove or reuse resources when the subscription ends—behavior familiar to JMS developers using durable subscribers but surprising to mainframe operators who expect every queue in the nightly DISPLAY QLOCAL(*) report. Unmanaged subscriptions—the DEFINE SUB with an explicit DEST you created in MQSC—remain the norm when queue names must appear on backup tapes, capacity plans, and RACF profiles with stable spelling. This tutorial explains managed versus unmanaged semantics, DESTTYPE and related attributes, how to discover managed queues after deploy, authority gaps on auto-created queues, cleanup and orphan prevention, hybrid estates with Java managed and COBOL unmanaged side by side, and monitoring without losing track of system-generated object names.
Unmanaged: you DEFINE QLOCAL('MYAPP.EVENTS.Q') then DEFINE SUB DEST('MYAPP.EVENTS.Q'). Operations owns MAXDEPTH, DEFPSIST, cluster membership, and DLQ. Managed: application calls subscription API; queue manager provisions DEST such as SYSTEM.MQ.SUB.... or similar naming per platform—exact prefix varies by release. You still DISPLAY SUB to learn the mapping; you do not promote the queue name in Git MQSC unless you capture it after first run.
| Aspect | Managed | Unmanaged |
|---|---|---|
| DEST creation | Queue manager | Administrator MQSC |
| Naming | Often system-generated | Business-meaningful names |
| Typical client | JMS, some .NET | MQI, COBOL, batch |
| Change control | Dynamic at runtime | Git MQSC pipeline |
| Cleanup risk | Orphan subs if apps leak | Queues remain until deleted |
IBM MQ subscription attributes include destination type and whether the queue manager manages the destination—consult DEFINE SUB parameter list for your release (DESTTYPE, SUBTYPE, and options related to managed destinations). Administrative subs are usually unmanaged with explicit DEST. Application-created subs trigger managed behavior when the API requests it. Mixing styles on one topic without documentation confuses capacity planning.
12345DEFINE QLOCAL('INVENTORY.EVENTS.Q') REPLACE MAXDEPTH(200000) DEFINE SUB('SUB.INVENTORY.UNMANAGED') TOPICSTR('inventory/#') + DEST('INVENTORY.EVENTS.Q') DESTTYPE(QUEUE) DURSUB(YES) SUBTYPE(ADMIN) DISPLAY SUB('SUB.INVENTORY.UNMANAGED') * Compare: start JMS durable subscriber — DISPLAY SUB(*) — note new DEST
connectionFactory.setClientID must be unique and stable for durable JMS subscribers on a queue manager—duplicate client IDs cause subscription takeover or errors. Each logical service should use one documented client ID in config servers, not random UUID per pod unless you use non-durable consumers. Kubernetes replicas sharing one durable client ID incorrectly is a frequent managed-sub bug.
When MQ creates a managed queue, default authority may deny the application MQGET until you grant +get to the MCAUSER or map users via CHLAUTH. Symptom: subscription exists, publications publish, CURDEPTH stays zero while errors appear in AMQERR01 about not authorized. Fix with setmqaut on the discovered DEST name and template profiles if your site supports queue naming patterns.
Managed is the hotel assigning you a room when you check in—you do not pick room 412 in advance. Unmanaged is reserving suite PAYMENTS.AUDIT.412 in the booking system before arrival.
The school gives you a mailbox the first day you sign up—you did not bring your own box from home. When you leave, they might take the mailbox away.
After JMS start, record DISPLAY SUB output and explain each DEST.
List pros/cons of switching a managed JMS service to unmanaged MQSC DEST.
Two pods, same client ID—predict subscription behavior.
1. Managed subscription DEST is created by:
2. Unmanaged sub requires:
3. JMS durable sub often uses:
4. DISPLAY SUB helps find: