Subscription Durability

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.

DURSUB YES Versus DURSUB NO

Durability comparison
SettingAfter app disconnectWhile consumer down
DURSUB(YES)Kept in repository
DURSUB(NO)Removed when session ends
Administrative SUBSurvives until DELETE SUB
Durable + non-persistent msgsStill 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.

Administrative Durability (MQSC DEFINE SUB)

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.

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

API and JMS Durability

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.

Pairing Durability With Message Persistence

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.

MDUR and Topic-Level Hints

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.

Cluster and SUBSCOPE

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.

Capacity While Offline

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.

Explainer: Newspaper Subscription vs Single Issue

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.

Explain Like I'm Five: Subscription Durability

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.

Practice Exercises

Exercise 1

When should a monitoring dashboard use DURSUB(NO)?

Exercise 2

List three settings for reliable overnight batch consumption of events.

Exercise 3

Publish succeeds, durable sub exists, DEST empty—name four checks excluding durability.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. DURSUB(YES) primarily affects:

  • Subscription registration lifetime
  • Channel SSL cipher
  • Listener port
  • XMITQ name

2. Offline durable subscriber messages wait on:

  • DEST queue
  • Topic object
  • Cluster repo
  • CCDT

3. Non-durable sub after disconnect:

  • Subscription removed
  • All topics deleted
  • QM shuts down
  • Channels invert

4. DEFPSIST(YES) on DEST affects:

  • Message copy persistence
  • SUBSCOPE
  • CHLTYPE
  • TOPTYPE only
Published
Read time17 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation