Channel Retries

Networks fail, listeners restart, certificates expire, and firewalls change rules—message channels must not give up on the first refused TCP connection, but they also must not hammer a dead partner forever at full speed. IBM MQ channel retry attributes define how long a channel stays in RETRY status and when it attempts BINDING again. SHORTRTY and SHORTTMR govern the short burst of quick tries; long retry count and interval take over for sustained outages. Beginners see RETRY in DISPLAY CHSTATUS and increase retries randomly; this tutorial explains what each attribute does, how retry interacts with channel states and sequence numbers, how XMITQ depth grows while retries loop, and how to tune retries without masking broken CONNAME or CHLAUTH configuration.

RETRY Status in the Lifecycle

A sender channel in RUNNING loses connectivity. The instance transitions to RETRY—not INACTIVE—because the queue manager intends to reconnect automatically. Messages remain on the transmission queue (for persistent traffic) while retries proceed. Operators fix the partner listener or network; on successful reconnect, BINDING and RUNNING return and transfer resumes. If retries exhaust policy limits, behavior depends on release and configuration—channels may remain in RETRY or require manual intervention; consult your version documentation for MAXRTY and long retry attributes on your platform.

Short Retry Phase

SHORTRTY(10) SHORTTMR(60) means up to ten attempts roughly sixty seconds apart during the short phase—illustrative numbers only. Brief listener restarts often recover within the first few short retries. Setting SHORTTMR too low on many parallel channels can look like a denial-of-service against the partner listener. Setting SHORTRTY to zero skips straight to long retry behavior per attribute interaction—verify on a test queue manager before production changes.

Long Retry Phase

After short retries exhaust, long retry intervals space attempts over minutes or hours. This prevents endless rapid TCP SYN floods to a data center under maintenance. Operations alerts often fire on long RETRY duration plus XMITQ depth thresholds. Change windows should PAUSE or STOP channels deliberately rather than relying on long retry alone to protect partners.

Explainer: Calling Back When Busy

Channel retry is like calling a friend who did not answer: you try again in a minute a few times (short retry), then try every hour (long retry) instead of redialing every second all night. Eventually you leave a voicemail (operations ticket) and stop assuming they are coming to the phone.

Defining and Altering Retry Attributes

1
2
3
4
5
6
DEFINE CHANNEL('QM1.TO.QM2') CHLTYPE(SDR) TRPTYPE(TCP) +
  CONNAME('qm2.example(1414)') XMITQ('XMIT.QM2') +
  SHORTRTY(10) SHORTTMR(30) LONGRTY(999999999) LONGTMR(600)
ALTER CHANNEL('QM1.TO.QM2') CHLTYPE(SDR) SHORTTMR(60)
DISPLAY CHANNEL('QM1.TO.QM2') SHORTRTY SHORTTMR LONGRTY LONGTMR
DISPLAY CHSTATUS('QM1.TO.QM2') STATUS LASTCHLERR

ALTER takes effect for new instances; running instances may need STOP and START to pick up some changes—check IBM documentation for your release. Document baseline values per critical route in your operations manual.

Diagnosing RETRY Loops

1. DISPLAY CHSTATUS — LASTCHLERR, STATUS RETRY, time in state.
2. Test TCP to CONNAME host and port from sending host.
3. DISPLAY LISTENER on receiver — listening and correct port.
4. Verify channel name match SDR/RCVR and TLS/CHLAUTH.
5. Rule out sequence number mismatch after DR (see sequence numbers tutorial).
6. Check partner queue manager running and not in quiesce.

Retry vs Heartbeat

HBINT detects connections that appear up but are dead (silent TCP). RETRY handles explicit failures and refused connections. Both affect perceived availability: heartbeats may trigger reconnect logic internal to the channel; retry timers schedule reconnection after RETRY state. Do not set HBINT to zero to disable heartbeats on production routes without understanding risk.

Client Connection Retries

Remote applications using MQCONNX may specify client reconnect options independent of SHORTRTY on SVRCONN. A message channel can be in RETRY while a client on the same queue manager still connects locally. Teach developers the difference so they do not duplicate conflicting retry policies.

Tuning Guidelines

• Critical low-latency routes — moderate SHORTRTY, SHORTTMR not too aggressive on partner.
• Batch overnight routes — longer SHORTTMR acceptable.
• Maintenance windows — STOP or PAUSE instead of extreme LONGRTY.
• Never use retry tuning alone to fix wrong CONNAME.

Explain Like I'm Five: Channel Retries

Retries mean the MQ truck will come back tomorrow if the dock was closed today—it does not mean the dock moved to a new address; you still need the right address (CONNAME).

Practice Exercises

Exercise 1

Given SHORTRTY=5 and SHORTTMR=20, how long is the short phase at most?

Exercise 2

Channel RETRY 24 hours—list six checks before increasing LONGTMR.

Exercise 3

When is PAUSE CHANNEL better than increasing retries?

Frequently Asked Questions

Test Your Knowledge