ReplyToQ is an MQMD field naming the queue where a service should send its reply message. The requester sets it on the request put. The server reads it from the request descriptor and puts the response there without hard-coding client queue names in server code.

ReplyToQMgr names the queue manager that owns ReplyToQ when the reply queue is on a different queue manager than the server. If blank, the reply queue is on the same queue manager as the request (typical for local dynamic queues).

What is a temporary dynamic reply queue?

Created from a model queue definition, a temporary dynamic queue exists for the life of the connection (or until deleted). Each client instance gets a unique queue name for private replies without administrators defining thousands of static queues.

Can ReplyToQ be a remote queue?

The reply put targets the queue named in ReplyToQ on the queue manager named in ReplyToQMgr. Cross-queue-manager reply requires channel and authorization paths from server QM to reply QM. Firewall and listener planning must include reply direction, not only request direction.

What happens if ReplyToQ is wrong or missing?

The server may put to an invalid name and fail, or put to a default that does not reach the client. Validation on the server should reject requests with missing ReplyToQ when a reply is required. Clients time out waiting on an empty reply queue.

MainframeMaster

Reply-to Queues

Reply-to queues are how IBM MQ answers the question where should the response go without coupling server code to every client installation. The requester encodes return routing in ReplyToQ and optionally ReplyToQMgr on the message descriptor; the service reads those fields and puts the reply there. Enterprise request/reply, CICS clients talking to Linux services, and Java microservices on the mainframe all use the same mechanism. This page explains static versus dynamic reply queues, model queue definitions, remote reply across queue managers, security and authorization on reply puts, common misconfigurations, timeouts, and how ReplyToQ works with CorrelId and MsgId from the correlation and message ID tutorials.

ReplyToQ and ReplyToQMgr Fields

ReplyToQ is a 48-character queue name (platform rules apply for name length and characters). ReplyToQMgr is a 48-character queue manager name. When the server processes a request on QM_SERVER and ReplyToQ is APP01.REPLY on QM_APP01, the server put must reach QM_APP01—often via a remote queue definition or default reply queue manager handling depending on API and channel setup. When both client and server share one queue manager, ReplyToQMgr is often blank and the reply is local. Always verify PUT authority on the reply queue for the server connection id.

Reply routing patterns
Pattern	ReplyToQ	ReplyToQMgr
Local dynamic	SYSTEM.MQ*.generated name	Blank (same QM)
Local static	CLIENT.REPLIES	Blank
Remote reply	CLIENT.REPLIES	QM_CLIENT
Invalid	Blank or deleted queue	Wrong name

Temporary Dynamic Queues

The requester opens a model queue such as REPLY.MODEL with MQOPEN options that create a dynamic queue. MQ returns a name like AMQ85942.REPLY.MODEL. That name becomes ReplyToQ on the request put. Only the creating connection typically reads it until shared—by design private. When the connection closes, the dynamic queue disappears unless retained by options—check your client. Model queues set DEFTYPE(TEMPDYN) or similar and attributes like MAXDEPTH, SHARE, and DEFPSIST that dynamic queues inherit.

Static Shared Reply Queues

Older designs use one queue REPLIES.ALL for many clients. Each request must set CorrelId/MQGET match so clients do not steal each other replies. Prefer dynamic queues or per-application static queues for clarity. Shared queues still appear in legacy CICS regions—document correlation rules strictly.

Server Implementation Checklist

MQGET request; read ReplyToQ and ReplyToQMgr from request MD.
Validate names are non-blank and authorized.
Build reply MD: CorrelId = request MsgId, new MsgId.
MQPUT to named reply queue (open queue or put to resolved name).
Commit under syncpoint if request get was syncpointed.

Remote Reply and Channels

Server on QM_A puts reply to QM_B requires either ReplyToQMgr open on QM_A with channels to QM_B, or putting to a QREMOTE that resolves to the client reply queue. Asymmetric firewalls often block reply path even when requests flow in. Network diagrams must show bidirectional channel or independent reply channels. Test reply puts in lower environments with the same CONNAME and TLS as production.

JMS Temporary Queues

JMSQueueSession.createTemporaryQueue() maps to MQ dynamic reply infrastructure. ReplyToQ in underlying MQMD is set when using JMSReplyTo. Ensure requestor consumes with the same session or saves destination. MQI and JMS mixed flows need a mapping document for operations.

Tutorial: Model Queue MQSC

shell

1
2
3
4
5
6
7
DEFINE QMODEL('REPLY.MODEL') REPLACE +
  DEFTYPE(TEMPDYN) MAXDEPTH(1000) SHARE +
  DEFPSIST(NO)
* Application: MQOPEN model with options to create dynamic queue
* Use returned name as ReplyToQ on request put
* Server: PUT reply using ReplyToQ from request MD
DISPLAY QLOCAL('REPLY.MODEL') DEFTYPE

Explain Like I'm Five: Reply-to Queue

You hand the teacher a question paper with a sticky note saying put the answer in my locker number 12. The teacher does not guess your locker—you told them where to deliver. ReplyToQ is the locker number; ReplyToQMgr is which school building if your locker is in another building.

Practice Exercises

Exercise 1: Firewall

Requests flow A→B but ReplyToQ is on A. List channel/auth checks for reply puts from B.

Exercise 2: Dynamic vs Static

Compare operational cost of 500 static reply queues vs dynamic from one model.

Exercise 3: Debug

Client times out; reply depth on ReplyToQ is 1. List five causes including CorrelId mismatch.