When a sender channel ships messages to a partner, IBM MQ does not treat the TCP stream as a firehose with no memory. The message channel protocol assigns logical sequence numbers to batches so both queue managers agree what was delivered, what was committed, and what must be retried after a network blip. Without that discipline, a dropped connection could duplicate payroll messages or lose audit records silently. Sequence numbers are why operators sometimes must RESET CHANNEL on both sides after a disaster recovery event—and why that command terrifies architects who understand the duplication risk. This tutorial explains sequence numbers for beginners: how they relate to batching, what happens during RUNNING and RETRY, when RESET is appropriate, and how sequence state differs from message IDs in the MQMD.
Message channels read multiple messages from the transmission queue into a batch subject to BATCHSZ and BATCHLIM. The channel sends the batch as a unit with protocol headers including sequence information. The receiver acknowledges when the batch is safely on disk (persistent messages) according to channel and queue manager rules. Smaller batches mean more frequent acknowledgements and lower exposure per failure; larger batches improve throughput but increase work in flight per batch.
| Concept | Scope |
|---|---|
| Channel sequence number | Sender/receiver pair protocol state |
| Message ID (MsgId) | Per message in MQMD |
| Log sequence (LSN) | Queue manager recovery log |
| Correlation ID | Application request/reply linking |
Each end of a message channel pair maintains logical sequence counters for the conversation. When a batch completes successfully, both sides advance their view of the next expected sequence. If the sender believes batch 42 was sent but the receiver only committed through 41, reconnect logic determines whether to resend 42 or advance—depending on whether the receiver partially received data and what persisted. The implementation details are internal to IBM MQ; operators observe outcomes via XMITQ depth decreasing, target queues receiving messages, and CHSTATUS errors when state diverges.
Network partition during RUNNING is the classic case. The sender may have transmitted bytes the receiver did not fully commit. On RETRY and reconnect, partners exchange sequence information before resuming bulk transfer. Persistent messages on the transmission queue remain available for resend until successfully delivered and removed per protocol rules. Non-persistent messages may be lost on failure depending on configuration—another reason financial traffic uses DEFPSIST(YES).
Imagine a cafeteria line where each tray of food has a number. The sender kitchen stacks tray 7 and tray 8 on the cart. If the cart tips over between buildings, both cafeterias check: did tray 8 arrive? If only half arrived, tray 8 goes back on the cart—tray 7 is not sent twice if the other side already recorded it. Channel sequence numbers are those tray numbers for batches of messages.
Symptoms include channels that never reach stable RUNNING, repeated RETRY with protocol errors, and stuck XMITQ depth despite apparently healthy network. Do not randomly RESET without a runbook.
RESET CHANNEL (with appropriate options per your release documentation) clears instance state so partners can re-establish sequence agreement from a defined starting point. The dangerous case is resetting only one side while messages exist on XMITQ or target queues—risking duplicates or gaps. Standard procedure: agree with partner operations, quiesce traffic, document depths, perform RESET on both sides per IBM guidance, test with non-production traffic, then resume. Some estates use new channel names after major DR to avoid ambiguous state entirely.
123456DISPLAY CHSTATUS('QM1.TO.QM2') ALL * Document CURSHRSEQ, CURLURSEQ or equivalent per release * Coordinate with partner QM before: RESET CHANNEL('QM1.TO.QM2') * Partner admin runs matching RESET on RCVR side START CHANNEL('QM1.TO.QM2')
Sequence negotiation occurs during BINDING and early RUNNING. Sequence errors may flip RUNNING to RETRY. Monitoring should correlate RETRY spikes with sequence-related LASTCHLERR values. After fixing network issues, many channels recover automatically without RESET; reserve RESET for true state divergence.
Each message channel pair has its own sequence context. CLUSSDR to CLUSRCVR pairs maintain separate state from point-to-point SDR/RCVR pairs. Do not assume resetting one cluster channel fixes all cluster paths—identify the specific channel name in CHSTATUS.
In a test environment, start a sender with messages on XMITQ. Allow RUNNING, then STOP CHANNEL abruptly on the receiver side mid-transfer. Restore listener and observe sender enter RETRY then RUNNING; verify message counts on both sides match expectations without manual XMITQ delete.
Sequence numbers are like counting which bag of mail the truck already delivered so after a flat tire you do not deliver the same bag twice or skip a bag.
Explain difference between MsgId and channel sequence to a new developer.
DR scenario: QM1 restored from yesterday backup, QM2 current—why might RESET be discussed?
List steps in a runbook before RESET CHANNEL on a payment route.
1. Sequence numbers primarily protect:
2. RESET CHANNEL should be done:
3. Messages in flight during disconnect may:
4. Sequence numbers apply most to: