Subscribers are the consumers of IBM MQ pub/sub—and paradoxically they still program against queues. After you create a subscription, the queue manager delivers matching publications to the destination queue (DEST); your COBOL, Java, or Node program MQGETs from DEST exactly like a point-to-point reader. The topic is only how messages arrived there. That model lets operations add a new fraud-detection subscriber by defining SUB and a queue without touching publisher code, provided the event schema is stable. Beginners forget SUB authority separate from +get, or create one DEST shared by competing consumers when the business wanted parallel independent copies. This tutorial explains subscription registration, durable versus non-durable subscriber behavior, managed destination queues, GET options and backout, scaling with multiple instances, correlation for request/reply, monitoring lag on DEST depth, and troubleshooting “publish works, subscriber silent” scenarios.
Step one: existence of a subscription linking TOPICSTR pattern to DEST—via DEFINE SUB MQSC, administrative console, JMS durable subscriber API, or runtime dynamic sub. Step two: subscriber application connects and MQGET loops on DEST. Publications never skip the subscription table; if no sub matches, the message is not queued anywhere except retain scenarios documented by IBM. Adding a subscriber means adding a row to that routing table plus a queue to read.
| Pattern | DEST queues | Copies per publish |
|---|---|---|
| One sub, one app | 1 | 1 message on 1 DEST |
| One sub, competing consumers | 1 | 1 message shared by N apps |
| N subs, N apps | N | N messages (fan-out) |
| Wildcard sub audit | 1 | All events under branch |
Administrative subscriptions survive in the repository. DEST must exist for unmanaged subs (DEFINE QLOCAL first). DESTTYPE and DESTQM handle local versus remote destinations in advanced configs. SUBUSER and PUBUSER attributes on subscriptions can narrow identity per IBM rules—check release docs before relying on them for security instead of OAM.
123456DEFINE QLOCAL('FRAUD.ORDERS.Q') REPLACE MAXDEPTH(500000) DEFINE SUB('SUB.FRAUD.ORDERS') TOPICSTR('retail/order/#') + DEST('FRAUD.ORDERS.Q') DURABLE(YES) setmqaut -m QM1 -t topic -n 'retail/order/#' -p FRAUDSVC +sub setmqaut -m QM1 -n FRAUD.ORDERS.Q -p FRAUDSVC +get +dsp +inq * FRAUDSVC application MQGETs FRAUD.ORDERS.Q
Durable: subscription remains when the app disconnects; messages accumulate on DEST (watch MAXDEPTH). Non-durable: subscription ends on disconnect—suitable for ephemeral UI sessions. Choose durability in architecture reviews, not only at coding time. JMS createDurableSubscriber maps to this behavior; MQI shops use DEFINE SUB DURABLE(YES).
Managed mode lets the queue manager create and manage DEST queues—common in JMS where destination names are opaque. Unmanaged gives operations full control of queue attributes (persistence, depth, cluster placement). Mainframe MQI estates often prefer unmanaged with explicit QLOCAL definitions promoted through MQSC Git pipelines.
Subscribers use GMO options: wait, syncpoint, mark browse if applicable. Failed processing should use backout threshold and BOQNAME on DEST like point-to-point queues—pub/sub does not remove poison handling. Multiple subscribers competing on one DEST share backout count—design separate DEST if isolation is required.
Horizontal scale: multiple instances MQGET from same DEST with competing consumer pattern—each message to one instance. Vertical scale: raise MAXDEPTH and tune GET batching. Fan-out scale: separate subscriptions per downstream system—publisher unchanged. Monitor CURDEPTH and age of oldest message; lag indicates subscriber cannot keep pace, not publisher failure.
Grant SUB only to identities that may register listeners. Audit DISPLAY SUB(*) for unknown DEST queues pointing at sensitive topic patterns. Remove test subs before production cutover—orphan subs copy production events to forgotten queues (data leak risk).
The subscriber signs up for “all sports headlines” (subscription). The post office puts copies in your mailbox (DEST). You only check your mailbox—you never read from the headline board directly (topic).
A subscriber is a kid who asked the school to deliver every lunch announcement to their desk—when the announcement happens, a copy appears on their desk and they read it.
Create SUB and QLOCAL for analytics on logistics/# with durable YES and grants.
Three services need the same event independently—design DEST layout.
DEST depth grows—list publisher rate, subscriber rate, and MAXDEPTH checks.
1. Subscribers read messages from:
2. SUB authority allows:
3. Competing consumers on one DEST:
4. Offline durable sub messages: