Durable Subscriptions

Durable subscriptions are how IBM MQ remembers that an application cares about a topic even when that application is not connected. Batch reconciliation that runs at 02:00 still needs every order event published at 14:00; the compliance archive must not lose audit publications because the listener pod restarted; the mainframe bridge may be down for maintenance while events keep arriving from cloud publishers. With DURSUB(YES), the subscription row stays in the queue manager, publications continue to match, and copies land on the destination queue until something consumes them or MAXDEPTH stops delivery. Without durability, disconnect often deletes the subscription and everything published while away is gone forever. This tutorial explains administrative versus API-created durable subs, interaction with persistent messages, capacity on DEST queues, restart and migration, JMS durable subscriber mapping, and operations commands to audit and clean up forgotten durable interest.

What Durability Stores

Durability does not mean messages live on the topic—it means the subscription definition (pattern, DEST, identity, scope) persists. Each publish still creates queue messages on DEST. Think of durability as keeping your place in line at the ticket office overnight; the show announcements (publications) still pile into your mailbox (DEST) while you sleep.

Administrative Durable Subscriptions

DEFINE SUB with SUBTYPE(ADMIN) and DURSUB(YES) is the pattern operations teams promote through Git-managed MQSC. The subscription name becomes a configuration item reviewed in change advisory boards. DEST queue attributes—MAXDEPTH, MAXMSGL, DEFPSIST, BOQNAME—belong in the same change ticket because durability without queue capacity only helps until the queue fills. DISPLAY SUB shows the definition; DISPLAY SUBSTATUS shows whether a consumer is currently attached for dynamic runtime subs.

1
2
3
4
5
6
7
DEFINE QLOCAL('COMPLIANCE.EVENTS.Q') REPLACE MAXDEPTH(1000000) DEFPSIST(YES)
DEFINE SUB('SUB.COMPLIANCE.ALL') REPLACE TOPICSTR('finance/#') +
  DEST('COMPLIANCE.EVENTS.Q') DURSUB(YES) SUBTYPE(ADMIN) +
  DESTTYPE(QUEUE) DESCR('Durable audit fan-in')
DISPLAY SUB('SUB.COMPLIANCE.ALL')
* Stop consumer — publish to finance/payment/posted — CURDEPTH rises
* Restart consumer — MQGET drains backlog

API and JMS Durable Subscribers

JMS createDurableSubscriber(clientId, topic) creates a durable registration tied to a connection factory client ID. The queue manager may assign a managed DEST name you did not choose—document client IDs in your application catalog. MQI applications use MQ subscription APIs per IBM documentation for your release. Duplicate client IDs across instances can cause confusing subscription ownership—standardize one durable sub per logical consumer service, not per JVM unless you understand the semantics.

Message Persistence and Durability Together

A durable sub with non-persistent publications loses in-flight copies if the queue manager stops before consumers drain them—durability of the subscription does not make non-persistent messages survive restart. Production event pipelines usually pair DURSUB(YES) with DEFPSIST(YES) on DEST and persistent publish from producers. Calculate disk: publish rate times subscriber count times message size times retention hours offline.

Capacity and Backlog Management

• Alert on DEST CURDEPTH and oldest message age.
• Size MAXDEPTH for planned outage windows plus peak publish rate.
• Use BOQNAME and backout threshold if poison messages block drain.
• Consider separate durable subs per priority so critical consumers are not blocked by bulk analytics.

Restart, Failover, and Clustering

After strmqm, administrative durable subs reload from the object repository. Messages on persistent DEST queues reload from queue files. In multi-instance queue manager or cluster failover, verify SUBSCOPE and cluster topic routing so the same durable sub name does not exist twice with conflicting DEST on different members. Document whether your DR site restores subscription definitions with the same SUB name—collisions prevent expected routing.

Explainer: Saved Seat at the Theater

A durable subscription saves your seat (interest in the topic) even when you leave the theater (disconnect). Usher still delivers programs (messages) to your seat row mailbox (DEST) until you return to collect them.

Migration: Non-Durable to Durable

1. Define new durable SUB and DEST (or alter with care during maintenance).
2. Drain old non-durable path if any messages remain.
3. Deploy consumer to new DEST; verify DISPLAY SUB.
4. Remove old dynamic sub creation from application code.
5. Monitor backlog after cutover weekend.

Explain Like I'm Five: Durable Subscriptions

You told the mail carrier to keep bringing copies of sports news to your box even when you are on vacation—the carrier remembers because you signed up for durable delivery.

Practice Exercises

Exercise 1

Size MAXDEPTH for 4 hours offline at 50 msgs/sec, 2 KB each, one durable sub.

Exercise 2

Write MQSC for durable SUB on logistics/shipment/# to LOGISTICS.DUR.Q.

Exercise 3

List monitoring metrics for a durable sub nearing capacity.

Frequently Asked Questions

Test Your Knowledge