Unmanaged Queues

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.

Define the Queue Before the Subscription

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.

shell
1
2
3
4
5
6
7
8
9
10
11
DEFINE 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)
Key QLOCAL attributes for subscriber DEST
AttributeRole for DESTBeginner tip
MAXDEPTHCap messages while consumer slow or downSize for peak rate × outage window
MAXMSGLLargest single publication copyMatch publisher max message size
DEFPSISTPersistent vs non-persistent copiesYES for durable business events
GETAllow subscriber MQGETENABLED unless maintenance lock
PUTAllow queue manager delivery putsENABLED for pub/sub engine
BOQNAMEBackout queue for bad messagesPair with app poison handling

Linking DEFINE SUB to Your Queue

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.

Sizing for Durable Subscribers

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.

Authority: Topic SUB Plus Queue GET

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.

One Subscription per DEST Pattern

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.

Operations Integration

  • Include DEST queues in nightly DISPLAY QLOCAL reports and backup.
  • Map queue name to application in CMDB; DESCR field is first line of defense.
  • Trigger MONITOR or event messages on CURDEPTH thresholds for subscriber lag.
  • DELETE SUB does not delete unmanaged QLOCAL—clean up queues in decommission runbooks.

Unmanaged vs Managed Decision Guide

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.

Explainer: Named PO Box

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.

Explain Like I'm Five: Unmanaged Queues

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.

Practice Exercises

Exercise 1

Write MQSC for QLOCAL plus UNMANAGED SUB with DURSUB YES and auth stubs.

Exercise 2

Estimate MAXDEPTH if publish rate is 1200/hour and outage is 48 hours.

Exercise 3

List why sharing one DEST between two SUBs is usually a bad idea.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. DESTTYPE UNMANAGED means:

  • You define DESTQL queue first
  • QM hides queue name
  • No subscription needed
  • Only for channels

2. Order of create should be:

  • QLOCAL then SUB
  • SUB then channel
  • Listener then topic only
  • DLQ then XMITQ only

3. Subscriber app needs on DEST:

  • GET and usually DSP
  • Only PUB on topic
  • CLR only
  • CHG on channel

4. Durable offline messages accumulate on:

  • DEST QLOCAL
  • Topic object
  • Cluster repository
  • Listener
Published
Read time18 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation