Request/Reply Pattern

Request/reply lets distributed and mainframe programs achieve RPC-style conversations over IBM MQ without a direct TCP connection between client and server. The requester puts a message on a service queue and includes return routing in the message descriptor; the server gets the request, does work, and puts a reply to the named reply queue. Correlation identifiers tie each reply to its request when many conversations share infrastructure. This page walks through ReplyToQ, ReplyToQMgr, MsgId, CorrelId, temporary dynamic queues, timeouts, competing servers, JMS temporary queues, and pitfalls beginners hit when mixing syncpoint with reply puts.

Flow Overview

1. Requester opens or creates a reply queue (often dynamic from a model queue).
2. Requester MQPUT to SERVICE.REQUEST with ReplyToQ set and MsgId established.
3. Server MQGET from SERVICE.REQUEST under syncpoint if required.
4. Server processes and MQPUT reply to ReplyToQ with CorrelId = request MsgId.
5. Requester MQGET on reply queue with correl selector or dedicated dynamic queue.

The pattern decouples address and availability: the server does not open a socket back to the client. Multiple server instances can compete on SERVICE.REQUEST; each reply still returns to the correct ReplyToQ named in that specific request.

Message Descriptor Fields

Temporary Dynamic Queues and Model Queues

DEFINE MODELQ specifies a template for dynamic queues: MAXDEPTH, DEFPSIST, and naming pattern. MQI MQOPEN with object type MQOT creates a unique queue name per connection. When the connection closes, the queue disappears—ideal for reply mailboxes. Administrators must cap resources so runaway clients cannot exhaust the queue manager with thousands of dynamic queues.

JMS TemporaryQueue maps to this mechanism under IBM MQ JMS. Spring clients create temporary destinations for replies in some templates. Operations monitor SYSTEM.ADMIN.* or model queue usage per documentation for your release.

Shared Reply Queue vs Private Dynamic Queue

A private dynamic reply queue avoids correlation selectors: only this client reads the queue. A shared REPLY queue requires every client to get with CorrelId matching its outstanding requests—harder but fewer objects. High-volume RPC gateways often use dynamic queues per session; batch utilities may use a fixed reply queue with strict correl discipline.

Competing Servers and Fairness

Multiple server instances get from one request queue. Each message carries its own ReplyToQ—servers must not confuse replies between requests. Server code should copy ReplyToQ and ReplyToQMgr from the request MD to the reply MD before put. Failure to do so sends answers to the wrong client—a serious production bug that correlation-focused tests catch.

Syncpoint and Failure

If the server gets under syncpoint and fails before commit, the request returns to the queue. If the server commits business work but fails before reply put, the client may timeout while work completed—design idempotency on the server and consider reporting errors on a reply with error payload. Client timeouts should not assume exactly-once processing unless the whole chain is transactional with participating resources.

Cross Queue Manager Reply

ReplyToQMgr names the target queue manager for the reply put. Channels must exist between managers; reply messages may traverse sender/receiver channels like any other put to a remote queue. Latency and authority (MCAUSER, CHLAUTH) apply. Mainframe hubs often host the service queue while clients in distributed regions use dynamic reply queues on local queue managers—architecture varies by estate standards.

Tutorial: Model Queue and Service Queue MQSC

1
2
3
4
5
6
7
8
9
10
DEFINE MODELQ('REPLY.MODEL') REPLACE +
  DESCR('Model for temporary reply queues') +
  DEFPSIST(NO) MAXDEPTH(1000)
DEFINE QLOCAL('CREDIT.CHECK.REQUEST') REPLACE +
  DEFPSIST(YES) MAXDEPTH(100000)
* Application flow (conceptual):
* 1) Open model -> dynamic reply queue name in ReplyToQ
* 2) Put request to CREDIT.CHECK.REQUEST with ReplyToQ set
* 3) Server gets request, puts reply with CorrelId = request MsgId
* 4) Client gets from dynamic queue or with correl selector

Explain Like I'm Five: Request/Reply

You send a note to the office asking, "What is my locker number?" You write on the note, "Put the answer in my tray B-7" (ReplyToQ). You also write a secret code on your note (MsgId). The office worker looks up your locker, writes the answer on a new note with the same secret code (CorrelId), and puts it in tray B-7. You only read tray B-7, so you get your answer—not someone else's.

Practice Exercises

Exercise 1: Trace Fields

Draw a diagram labeling MsgId, CorrelId, ReplyToQ for one request and reply.

Exercise 2: Timeout Design

A client waits 30 seconds for reply; server takes 45 seconds. What does the client see? What might still happen on the server?

Frequently Asked Questions

Test Your Knowledge