RESET is the IBM MQ administrative verb you reach for when runtime state is wrong but the object definition should stay. Operators use RESET CHANNEL after sequence number mismatches, when CHSTATUS shows a zombie instance that STOP did not clear, or when a channel pair will not bind despite correct CONNAME and TLS. Developers rarely run RESET in application code—it belongs in operations runbooks next to STOP, START, and DISPLAY. Unlike ALTER, RESET does not change MAXDEPTH or MCAUSER; unlike DELETE, it does not remove the channel from the catalog. Beginners must learn that RESET CHANNEL on one queue manager without telling the partner is a common cause of production incidents: the protocol counters on each side must make sense together. This tutorial explains RESET CHANNEL step by step, RESET QSTATS for monitoring baselines, authority requirements, coordination with remote teams, comparison to PING and RESOLVE, and how RESET fits into disaster recovery after backup restore.
RESET CHANNEL('PARIS.TO.LONDON') tells the queue manager to discard the current channel instance state for that definition name on this queue manager. The channel must typically be stopped or inactive; exact prerequisites vary slightly by platform and channel type (sender, receiver, server, requester, cluster sender). After RESET, you usually START CHANNEL again and watch DISPLAY CHSTATUS until CHSTATUS shows RUNNING or the expected retry if the root cause is still unfixed. RESET does not fix wrong certificates, CHLAUTH blocks, or firewall rules—it only clears local protocol bookkeeping so a fresh bind can be attempted.
12345678DISPLAY CHSTATUS('PARIS.TO.LONDON') STOP CHANNEL('PARIS.TO.LONDON') RESET CHANNEL('PARIS.TO.LONDON') START CHANNEL('PARIS.TO.LONDON') DISPLAY CHSTATUS('PARIS.TO.LONDON') CHSTATUS SUBSTATE LASTCHLERR * CHSTATUS — RUNNING, RETRYING, BINDING, STOPPED, etc. * SUBSTATE — extra detail on some states * LASTCHLERR — last channel error text; read before blaming RESET
| Command | Effect | Typical use |
|---|---|---|
| STOP CHANNEL | Ends session | Maintenance window |
| RESET CHANNEL | Clears instance / sequence state locally | After DR or stuck instance |
| START CHANNEL | Initiates new session | After fix or RESET |
| PING CHANNEL | Connectivity test without app traffic | Before blaming RESET |
| DELETE CHANNEL | Removes definition | Decommission only |
When sender and receiver disagree about batch sequence after restore or split-brain, the channel may loop in RETRY with errors referencing sequence or protocol in the error log. Increasing SHORTRTY or LONGRTY does not repair counters—only coordinated recovery does. The standard pattern is: agree a window with the partner operations team, STOP the channel on both queue managers, RESET CHANNEL on both sides with the same channel name convention, then START from the sending side (or per your runbook). Messages on the transmission queue remain unless administratively cleared; RESET does not delete them. Business owners decide whether to drain XMITQ to a holding queue before RESET when duplicate delivery is unacceptable. Financial and payroll interfaces often require written approval before RESET on production pairs.
Read LASTCHLERR and AMQERR on both queue managers before RESET. If the error is SSL handshake or connection refused, fix security and network first. If the error mentions sequence or batch after a restore event, RESET may be appropriate after STOP on both sides.
RESET QSTATS('ORDERS.IN') resets queue statistics for that queue—useful before a load test so Prometheus or accounting displays show only the test window. It does not change CURDEPTH, does not remove messages, and does not alter MAXDEPTH. Pair RESET QSTATS with DISPLAY QSTATUS before and after benchmarks. Channel statistics have analogous reset options on your MQ version; consult IBM documentation for RESET CHLSTATS or channel statistics reset syntax if your monitoring team requires zeroed channel counters after maintenance.
1234DISPLAY QSTATUS('ORDERS.IN') CURDEPTH RESET QSTATS('ORDERS.IN') * Resets statistical counters for the queue * CURDEPTH unchanged — messages still on queue
RESET CHANNEL requires sufficient authority on the channel object—often mqm group on distributed MQ or equivalent on z/OS via RACF. Every RESET should appear in your change ticket with timestamp, operator ID, partner ticket reference, and DISPLAY CHSTATUS before and after. Automated scripts that RESET channels must include guards: only run when CHSTATUS matches expected failure pattern, never in a loop. Security auditors sometimes ask whether RESET can bypass CHLAUTH—it cannot; CHLAUTH still applies on the next bind.
On Linux and Windows queue managers, run RESET through runmqsc or MQ Explorer with the same syntax. On z/OS, operators may use CSQUTIL or the operations console equivalent; channel names and coordination rules are identical in concept. Shared transmission queues in queue sharing groups add complexity: ensure you RESET the channel instance on the queue manager that owns the active channel session, which DISPLAY CHSTATUS identifies.
STOP is asking everyone to step out of the turnstile. RESET is the maintenance worker clearing the jammed counter inside the gate so the next person can swipe a card from a known starting position. START is opening the gate again for new traffic.
You and a friend were playing catch and lost count of whose turn it is. RESET is when you both agree to put the ball down, forget the old count, and start counting turns again from the beginning—only safe if you both do it at the same time.
In a lab pair, STOP a channel, RESET on one side only, and document the error on the partner. Then repeat with coordinated RESET on both sides.
Capture DISPLAY CHSTATUS before and after RESET CHANNEL; note which fields changed.
Write a production runbook section: when RESET is allowed, who approves, and what evidence to attach.
1. RESET CHANNEL is mainly used to:
2. RESET versus DELETE:
3. Before RESET CHANNEL in production you should:
4. RESET QSTATS affects: