RESOLVE (MQSC)

RESOLVE is the IBM MQ administrative verb for finishing work the queue manager left in limbo. When a channel fails mid-batch or a transaction coordinator dies before commit, objects can enter indoubt state: the system knows something was in progress but cannot infer the correct outcome without human or policy direction. RESOLVE CHANNEL(channel-name) ACTION(COMMIT) or ACTION(BACKOUT) tells the queue manager which way to break the tie. This is not daily operations—it appears in disaster recovery playbooks, after unclean queue manager shutdown, and when DISPLAY CHSTATUS shows indoubt-related substates or when error logs reference indoubt channels. Beginners sometimes run RESET CHANNEL when RESOLVE is required, or vice versa, creating duplicates or apparent message loss. This tutorial explains indoubt concepts, RESOLVE CHANNEL options, how RESOLVE relates to log replay and recovery processing, DISPLAY evidence to gather, transaction-level RESOLVE overview, and governance so production resolves are auditable.

Understanding Indoubt Channels

Message channels move batches between queue managers. The protocol tracks which batches are fully received and committed on the receiver before the sender discards them from the transmission queue. If the sender crashes after the receiver committed but before the sender acknowledged, or the network fails at the acknowledgment boundary, one side may mark the batch indoubt. The channel will not return to normal RUNNING until resolution. Symptoms include CHSTATUS that does not progress through STOP and START alone, persistent errors referencing indoubt in LASTCHLERR, and XMITQ depth frozen while business teams report partial delivery. Compare timestamps on both queue managers error logs to find the failure second.

1
2
3
4
5
6
7
DISPLAY CHSTATUS('PARIS.TO.LONDON') CHSTATUS SUBSTATE LASTCHLERR
* Look for indoubt-related substate or error text on your release
STOP CHANNEL('PARIS.TO.LONDON')
RESOLVE CHANNEL('PARIS.TO.LONDON') ACTION(COMMIT)
* Or ACTION(BACKOUT) per runbook and application team decision
DISPLAY CHSTATUS('PARIS.TO.LONDON')
START CHANNEL('PARIS.TO.LONDON')

COMMIT Versus BACKOUT: Business Choice

ACTION(COMMIT) tells IBM MQ to complete the indoubt work in the commit direction—messages may become available on the target queue as if delivery succeeded. ACTION(BACKOUT) rolls back the uncertain batch from the channel perspective; messages may remain on XMITQ for retry or require application replay from source. Neither choice is universally correct. Payment systems with idempotent consumers may prefer COMMIT to avoid gaps; audit systems that cannot tolerate duplicates may prefer BACKOUT and controlled replay. The messaging team implements the decision; application owners own the business outcome. Document the ticket number on the RESOLVE command transcript.

RESOLVE Versus RESET Versus STOP/START

• STOP CHANNEL—ends session; may leave indoubt if failure was abrupt.
• RESOLVE CHANNEL—explicit decision on indoubt batches.
• RESET CHANNEL—clears instance and sequence; does not replace indoubt resolution semantics.
• START CHANNEL—begins new session after state is consistent.

Sequence number errors after restore often need coordinated RESET on both sides, not RESOLVE—read the error text. Indoubt after single-queue-manager crash mid-batch often needs RESOLVE—read CHSTATUS and IBM recovery manual for your version. When unsure, open a support case with FDC and DISPLAY output rather than guessing COMMIT.

Transactions and DISPLAY TXN

Client applications using syncpoints or XA can leave indoubt transactions visible through DISPLAY TXN or platform tools. RESOLVE TRANSACTION with COMMIT or BACKOUT completes coordinator recovery when the transaction manager cannot. Mixed failures—database committed, MQ backout needed—require cross-team orchestration. Recovery processing tutorial explains log replay; RESOLVE is the manual knob when automatic replay stops at indoubt. z/OS operators may use different command interfaces; concepts match distributed MQ.

1
2
3
4
DISPLAY TXN
* Shows indoubt transaction IDs where supported
* RESOLVE TRANSACTION syntax — consult IBM MQ 9.x reference for your platform
* Coordinate with DB2 or other RM when XA involved

Evidence Collection Runbook

1. DISPLAY CHSTATUS full attributes for the channel pair.
2. DISPLAY QSTATUS on transmission queue—CURDEPTH and oldest message age.
3. Extract AMQERR and FDC around failure time on both queue managers.
4. Confirm application last successful message ID or business batch ID if available.
5. Obtain written COMMIT or BACKOUT decision from application owner.
6. Run RESOLVE during agreed window; capture runmqsc output.
7. Validate with test put/get and consumer counts after START CHANNEL.

Prevention and Architecture

Graceful STOP CHANNEL before maintenance reduces indoubt incidence. Multi-instance queue managers and monitored networks reduce abrupt failures but do not eliminate them. Persistent messages survive many failures; non-persistent messages may be lost regardless of RESOLVE. Design consumers with idempotency keys. Test RESOLVE procedures in disaster recovery exercises annually—teams that only read documentation panic during real indoubt events.

Explainer: The Bank Transfer Pending Light

You clicked transfer; the screen froze. The bank does not know if money left your account. Indoubt is that pending light. RESOLVE is the supervisor choosing either to complete the transfer or cancel it—after checking both ledgers.

Explain Like I'm Five: RESOLVE

You handed your friend a toy but the lights went out before they said thanks. Nobody knows if they got it. RESOLVE is Mom deciding: yes they have it now, or no give it back and try again.

Practice Exercises

Exercise 1

Find DISPLAY CHSTATUS fields on your lab MQ version that indicate stopped versus indoubt-related states.

Exercise 2

Write a one-page decision tree: when to call application owner before RESOLVE CHANNEL COMMIT.

Exercise 3

Compare your site runbook for sequence number RESET versus indoubt RESOLVE—list three differences.

Frequently Asked Questions

Test Your Knowledge