Correlation identifiers are how IBM MQ conversations stay coherent when thousands of requests and replies fly through the same infrastructure. The CorrelId field in the message descriptor is only twenty-four bytes, yet it powers request/reply matching, audit trails, duplicate detection, and cross-program tracing from CICS to Java. Beginners confuse CorrelId with MsgId or with the business primary key in the payload—this page separates those roles, shows the standard request/reply handshake, explains MQGET match options and timeouts, covers JMS interop, and warns about encoding mistakes that leave replies stranded on a queue forever.
CorrelId is a byte array in the MQMD. MQ does not interpret your business meaning—it stores what you set. Default puts often initialize CorrelId to binary zeros unless copied from a prior message. For request/reply, the replier sets CorrelId on the outbound message before MQPUT to the reply queue. The requester waits on MQGET with CorrelId equal to the MsgId it saved from the original request put. Each field is independent: the reply still receives a fresh MsgId for its own identity.
| Message | MsgId | CorrelId |
|---|---|---|
| Request | R1 (generated or set by client) | Often zeros or copy of prior context |
| Reply | R2 (new for reply) | Usually R1 (request MsgId) |
If the client skips saving R1 or the server copies the wrong bytes, the client waits until timeout. Integration tests should assert CorrelId on every reply in CI.
MQGMO_MATCH_CORREL tells the queue manager to return the next message whose CorrelId equals the value in the MQMD used for the get. Combine with MQGMO_WAIT and a suitable interval for blocking clients. Without match options on a shared queue, the first message wins—dangerous on a shared REPLIES queue. Temporary dynamic queues reduce collision: only one client reads that queue, but CorrelId matching still helps when multiple outstanding requests use one dynamic queue incorrectly.
Teams sometimes copy an order number or UUID into CorrelId when not using strict MsgId pairing. Ensure the value fits twenty-four bytes or define a hash. Document endianness and padding for mainframe COBOL and Java interop. COBOL COPYbooks map CorrelId to PIC X(24); Java may use byte arrays. Hex display in support tools must match both sides.
JMSCorrelationID property maps to MQ CorrelId for IBM MQ JMS. Set it on the reply message to the request JMSMessageID bytes as per your client documentation. .NET and Node clients expose similar properties. Mixed estates should publish a correlation cookbook so CICS MQPUT and Spring JmsTemplate agree on byte layout.
Store CorrelId in a processed table with a unique constraint alongside business keys. Duplicate MQ deliveries with the same CorrelId and MsgId pair signal redelivery; same business key with new MsgId may signal a true duplicate business event. Operations grep application logs for CorrelId when tracing a single customer complaint across three queue managers.
123456789101112/* Requester after put */ Save RequestMsgId = MD.MsgId /* Server */ Read RequestMsgId from request MD.MsgId MD.CorrelId = RequestMsgId MD.MsgId = MQMI_NONE /* let MQ generate new MsgId for reply */ PUT ReplyToQ /* Requester wait for reply */ MD.CorrelId = Saved RequestMsgId GET ReplyQ with MQGMO_MATCH_CORREL + MQGMO_WAIT
You send a note asking What is 2+2? and write ticket number 7 on the corner. The answer note says Re: ticket 7 with 4 written inside. You ignore answers for ticket 6 or 8. CorrelId is the ticket number on the answer linking it to your question.
Server sets CorrelId to its own new MsgId by mistake. What does the client see on GET?
Two clients use REPLIES.SHARED without match options. Describe the bug.
List three tools or commands you would use to find a stuck reply by CorrelId.
1. In classic request/reply, reply CorrelId is usually set to:
2. MQGMO_MATCH_CORREL is used to:
3. CorrelId length in MQMD is typically:
4. Shared reply queue with many clients requires: