Managed Queues

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.

When the Queue Manager Creates a Managed Queue

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.

Managed queue lifecycle stages
StageWhat happensOperations action
Subscription createMQ defines QLOCAL DEST with defaultsCapture DESTQL from DISPLAY SUB
Active deliveryCURDEPTH grows with publicationsAlert MAXDEPTH like any app queue
Subscriber connectedApplication MQGET drains DESTMonitor age of oldest message
Subscription deleteQueue may be deleted per rulesVerify no orphan QLOCAL remains
QM restartDurable sub reloads; queue persists if not deletedConfirm authority profiles still apply

Managed Queue Naming

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.

Default Attributes and ALTER Limits

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.

shell
1
2
3
4
5
6
7
DEFINE 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)

Authority on Managed Destinations

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.

Managed vs Unmanaged Queues (DEST)

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.

Monitoring and Housekeeping

  • Include managed DEST in queue depth dashboards—filter by DISPLAY SUB DESTQL list.
  • Alert on subscriptions with no consumer and rising CURDEPTH—stale durable interest.
  • After application version upgrades, compare SUB count and QLOCAL count week over week.
  • Document DELETE SUB procedures so managed queues are not left without owners.

Explainer: Hotel Room Assigned at Check-In

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).

Explain Like I'm Five: Managed Queues

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).

Practice Exercises

Exercise 1

After a JMS app starts, list commands to find DESTQL and check CURDEPTH.

Exercise 2

Why might MAXDEPTH on a managed queue default be dangerous for prod/inventory/#?

Exercise 3

Write three OAM grants needed for delivery and consumption on a managed DEST.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. Managed queues are created by:

  • Queue manager for MANAGED subs
  • Publisher application
  • Cluster repository only
  • JES

2. To read messages the app needs on DEST:

  • +get
  • Only PUB
  • CHLTYPE SDR
  • DEFINE TOPIC

3. DISPLAY SUB shows:

  • DESTQL queue name
  • Only channel names
  • Page set ID
  • JCL class

4. DESTTYPE MANAGED on DEFINE SUB means:

  • QM creates DEST queue
  • No TOPICSTR
  • No durability
  • XMITQ required
Published
Read time17 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation