Subscription durability answers how long the queue manager remembers that your application wants events after the application stops. It is not the same as message persistence, retained publications, or durable queues in the point-to-point sense—it is the lifetime of the subscription registration itself. When durability is on (DURSUB YES or administrative permanent subscriptions), IBM MQ continues matching publications to your destination queue while the consumer is offline, on vacation, or mid-deploy. When durability is off, disconnect often removes interest and publications go nowhere for that consumer—a correct choice for UI sessions, dangerous choice for overnight batch that must not miss accrual events. This tutorial explains DURSUB, SUBTYPE ADMIN versus API-created subs, pairing durability with DEFPSIST on DEST, cluster SUBSCOPE interaction, JMS durable subscriber mapping, restart behavior, capacity when offline, and operational runbooks for durable versus non-durable decisions.
| Setting | After app disconnect | While consumer down |
|---|---|---|
| DURSUB(YES) | Kept in repository | |
| DURSUB(NO) | Removed when session ends | |
| Administrative SUB | Survives until DELETE SUB | |
| Durable + non-persistent msgs | Still kept |
Choose YES for business consumers that must not miss events during maintenance windows. Choose NO for temporary tap-in monitoring tools and most interactive dashboards that should not accumulate backlog when nobody is watching.
DEFINE SUB in MQSC creates a subscription object in the queue manager repository—durable by nature until you DELETE SUB. SUBTYPE(ADMIN) marks administrative subscriptions as opposed to application-created API subscriptions in DISPLAY output. Operations owns the lifecycle: deploy via pipeline, audit with DISPLAY SUB(*), remove in decommission. Batch jobs that only run at 02:00 still need administrative durable subs if publishers emit 24×7—otherwise events published at 14:00 are lost before the batch connects with a non-durable session sub.
12345DEFINE SUB('ACCRUAL.LEDGER.SUB') TOPICSTR('prod/finance/accrual/#') + DESTQL('ACCRUAL.LEDGER.Q') DESTQMGR('QM1') DESTTYPE(UNMANAGED) + DURSUB(YES) SUBTYPE(ADMIN) SUBSCOPE(QMGR) + DESCR('Durable admin sub - survives batch disconnect') * Batch connects with MQGET only; sub already exists
MQI MQSUB and JMS durable subscribers request durable registration at runtime. DISPLAY SUB after deploy shows new entries—capture DESTQL for managed patterns. Non-durable JMS subscribers disappear on connection close; durable ones remain. Client reconnect logic must use the same client ID and subscription name where JMS requires it, or a new durable sub may be created alongside the old one, leaving duplicate DEST queues and confused consumers.
Durable subscription plus DEFPSIST(NO) on DEST means interest survives disconnect but message copies might not survive queue manager restart. For financial or compliance events, use DURSUB(YES), DEFPSIST(YES) on DEST, and persistent publications from publishers. Non-persistent publish to durable DEST is valid for performance-sensitive telemetry where loss on restart is acceptable—document the trade-off explicitly in your integration standard.
Topic objects may carry model durability hints (MDUR) affecting default behavior for subscriptions under a branch—consult IBM MQ DEFINE TOPIC attribute documentation for your release. Administrative topic parents with consistent MDUR reduce teams accidentally creating mixed durable and non-durable subs under the same domain prefix.
Durability does not replace SUBSCOPE. A durable subscription with SUBSCOPE(QMGR) still only receives publications that routing rules deliver to that queue manager. Durable SUBSCOPE(ALL) on multiple members can multiply retained interest—govern who may define cluster-wide durable subs.
Durability shifts responsibility to DEST queue depth. A durable subscriber down for a week during peak season can fill MAXDEPTH and block publishers or trigger backout. Run capacity exercises: publish rate × outage hours < MAXDEPTH with safety margin. Alert on depth growth rate, not only absolute depth.
Durable is a standing newspaper subscription—issues pile on your porch while you travel. Non-durable is buying one paper at the stand when you happen to walk by—no papers saved for you when you skip a day.
Durability means the mail carrier still saves your magazines when you are on vacation. Without durability, they stop delivering as soon as you close the door and forget you wanted them.
When should a monitoring dashboard use DURSUB(NO)?
List three settings for reliable overnight batch consumption of events.
Publish succeeds, durable sub exists, DEST empty—name four checks excluding durability.
1. DURSUB(YES) primarily affects:
2. Offline durable subscriber messages wait on:
3. Non-durable sub after disconnect:
4. DEFPSIST(YES) on DEST affects: