Store-and-forward is one of IBM MQ's defining strengths: accept a message now, hold it safely, deliver it later when the path or consumer is ready. Branch offices, ships at sea, overnight batch windows, and maintenance outages all rely on this behavior. Unlike synchronous RPC, the sender does not need continuous connectivity to the ultimate receiver—only to its local queue manager. This page explains the pattern at local queues and across queue managers, transmission queues, sender and receiver channels, remote queue definitions, depth monitoring, and how persistence and syncpoint make store-and-forward trustworthy on z/OS and distributed platforms.
The simplest form: a producer MQPUT to a local queue; consumers are down for maintenance. Messages accumulate in the queue (subject to MAXDEPTH). When consumers return, they MQGET the backlog. Persistent messages survive queue manager restart during the outage. This is store-and-forward between producer time and consumer time on one queue manager—foundational asynchronous messaging.
When the receiver lives on another queue manager, the local manager stores messages on a transmission queue tied to a channel. A remote queue definition tells the queue manager: puts to this name actually go to queue RNAME on queue manager RQMNAME via XMITQ. The application still does one put; routing is administrative. If the sender channel cannot connect, depth on the XMITQ grows—visible evidence of store-and-forward in action.
| Object | Role |
|---|---|
| QREMOTE | Logical name apps put to; points at remote target |
| QLOCAL (XMITQ) | Holds messages waiting for channel |
| CHANNEL (SDR) | Moves messages from XMITQ to partner |
| CHANNEL (RCVR) | Partner receives and puts to target queue |
| QLOCAL (target) | Final destination on remote QM |
Sender channels retry connections on schedules defined by channel attributes (retry counts, intervals—see your release documentation for SHORTTMR, LONGTMR, DISCINT). Messages remain on the XMITQ between attempts. Long outages require MAXDEPTH and disk capacity planning so the transmission queue does not fill—puts fail when full. Operations run START CHANNEL after network fixes; message delivery resumes without re-sending from applications.
Spokes put to remote queue names resolving to the hub. During WAN failure, spokes store locally on XMITQ or hold on spoke local queues depending on design. Hub-and-spoke store-and-forward is how retail, banking, and logistics tolerate link loss. Batch consolidation may deliberately forward overnight when bandwidth is cheaper—still store-and-forward, timed by operations schedule rather than failure.
Non-persistent messages on transmission queues may be lost if the queue manager fails hard before delivery completes. Use persistent messages for business-critical cross-site forwarding unless loss is explicitly acceptable. Mixed estates sometimes use non-persistent for status pings and persistent for financial payloads on parallel channels.
123456789* Spoke QM_SPOKE: app puts to ORDERS.TO.HUB DEFINE QREMOTE('ORDERS.TO.HUB') REPLACE + RNAME('ORDERS.IN') RQMNAME('QM_HUB') + XMITQ('QM_HUB.XMIT') DEFINE QLOCAL('QM_HUB.XMIT') REPLACE DEFPSIST(YES) DEFINE CHANNEL('TO.HUB') CHLTYPE(SDR) TRPTYPE(TCP) + CONNAME('hub.example.com(1414)') XMITQ('QM_HUB.XMIT') REPLACE * If channel stopped: DISPLAY QLOCAL('QM_HUB.XMIT') CURDEPTH * After START CHANNEL('TO.HUB'): depth should drain
The mail truck cannot reach the next town because of snow. The post office keeps bags of letters in the back room (stored). When the road opens, the truck takes all waiting bags (forward). You still dropped your letter at your local office—you did not have to wait in the snow for the other town to open.
Transmission queue depth is 50,000 for four hours. List four investigation steps.
Sketch QREMOTE, XMITQ, SDR channel, RCVR, target QLOCAL for one remote put.
1. When a sender channel is inactive, messages to a remote queue typically wait on:
2. Store-and-forward helps when:
3. Remote queue definitions specify:
4. Persistent messages on an XMITQ survive: