Reply queues complete the request-reply conversation in IBM MQ. The client puts a question on a service queue; the server puts the answer on the reply queue named in the request message descriptor. Getting reply queues right prevents responses vanishing to wrong programs, reply queues filling with unmatched messages, or security blocking the server from putting replies. This page covers fixed named reply queues, temporary dynamic queues from model queues, ReplyToQ and ReplyToQMgr, correlation with CorrelId and MsgId, differences from work queues, and MQSC plus API considerations for beginners implementing synchronous-style messaging over asynchronous MQ.
PAYMENTS.REQUEST might be a shared inbound queue for a payment service. Each teller application uses PAYMENTS.REPLY.TELLER42 or a private dynamic queue for answers. The payment service MQGETs from REQUEST, processes, and MQPUTs to ReplyToQ from the incoming MQMD. The teller MQGETs its reply queue (often with a wait interval). Separating directions avoids consumers on the request queue accidentally reading another client's reply and keeps service scaling independent from client count.
| Style | How created | Best for |
|---|---|---|
| Fixed named reply queue | DEFINE QLOCAL per client or pool | Long-lived apps, CICS, batch with known names |
| Shared reply queue + CorrelId | One QLOCAL, many requesters | Few servers, strict correl matching in code |
| Temporary dynamic queue | MQOPEN model queue dynamic | JMS, Java, short RPC-style calls |
On MQPUT of the request, set ReplyToQ to the reply queue name and ReplyToQMgr to blank if local or to the target queue manager name if the reply lives elsewhere. The server copies these fields when putting the reply (or sets CorrelId from MsgId per convention). Wrong ReplyToQMgr sends replies across the network to the wrong host—common in multi-QM estates after DR drills. DISPLAY QLOCAL and test harness puts should verify end-to-end paths in lower environments.
The requester opens a model queue (for example SYSTEM.DEFAULT.MODEL.QUEUE or a custom QMODEL) with dynamic queue options. IBM MQ creates a unique queue name, often prefixed AMQ. on distributed systems. The requester passes that name in ReplyToQ, waits on get with correlation, then closes and deletes the dynamic queue. Model queues should set sensible MAXDEPTH, DEFPSIST (often NO for temp replies), and SHARE(YES). See the temporary dynamic queues tutorial for MQSC on QMODEL and TTL if supported on your release.
12345DEFINE QLOCAL('PAYMENTS.REQUEST') REPLACE MAXDEPTH(100000) DEFINE QLOCAL('PAYMENTS.REPLY.POOL') REPLACE SHARE(YES) MAXDEPTH(50000) DEFINE QMODEL('REPLY.MODEL') REPLACE MAXDEPTH(1000) DEFPSIST(NO) SHARE(YES) * Requester sets ReplyToQ and CorrelId in application code * Server: get from REQUEST, put reply to ReplyToQ with CorrelId
When ten requests are outstanding on one shared reply queue, each reply must carry CorrelId matching the request (often byte copy of request MsgId). The requester MQGET with MQMO_MATCH_CORRELID. Implement wait timeouts: if no reply in 30 seconds, log and cancel—orphan replies may arrive later and need garbage collection or browse-remove. Expiry on messages can prevent infinite growth on abandoned reply queues.
Only the owning application should get from a private reply queue. The service needs put authority to ReplyToQ but not get—prevents the server from stealing another client's replies. Dynamic queues inherit authority from model or default profiles; tighten before production. On z/OS, review profiles and generic names for AMQ.* dynamic queues.
Work queues feed processing pipelines (many messages, competing consumers). Reply queues are usually client-specific or short-lived, lower depth, often one requester getting correlated replies. Do not point batch producers at a reply queue by mistake. Do not use reply queues as dead-letter or backout targets without explicit design.
You mail a question to the help desk mailbox (request queue). You write your home address on the form (ReplyToQ). The helper sends the answer to your home mailbox (reply queue), not back into the help desk inbox.
Draw message flow for two clients, one service, fixed reply queues per client.
Why is CorrelId required on a shared PAYMENTS.REPLY.POOL?
List attributes you would set differently on a reply QMODEL vs a work queue.
1. The server puts the reply to:
2. Temporary dynamic reply queues are created from:
3. Shared reply queue for many clients needs:
4. ReplyToQMgr is used when: