SHORTRTY (Short Retry Count)

When a message channel cannot complete BINDING or loses RUNNING, operators see RETRY in DISPLAY CHSTATUS and watch the transmission queue depth climb. SHORTRTY controls how many quick reconnect attempts IBM MQ makes before backing off to long retry. It is the “try again soon” phase of channel recovery—not a substitute for correct CONNAME, listeners, TLS, or CHLAUTH, but a buffer against brief network blips and partner restarts. This dedicated tutorial complements the channel retries overview by focusing on SHORTRTY semantics, pairing with SHORTTMR, comparing to LONGRTY, and giving tuning examples for batch hubs versus always-on payment links.

Two-Phase Retry Model

IBM MQ channel recovery is intentionally staged. Phase one: SHORTRTY attempts at SHORTTMR second intervals—fast enough to catch a listener that restarted in thirty seconds. Phase two: after short count exhausts, LONGRTY attempts spaced by LONGTMR—slow enough to avoid SYN-flooding a data center under multi-hour maintenance. Understanding SHORTRTY is understanding how many times phase one runs before phase two begins.

Defining SHORTRTY

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

SHORTRTY(10) with SHORTTMR(30) allows up to ten reconnects roughly thirty seconds apart in the short phase—about five minutes total before long retry dominates, arithmetic approximate. Increasing SHORTRTY without increasing SHORTTMR extends short phase duration linearly. Document baselines per critical channel in your operations wiki.

Explainer: Knocking on the Door Several Times

SHORTRTY is how many times you knock on your friend's door every minute before you decide to try once an hour instead—they might have been in the shower the first few times.

When to Increase or Decrease SHORTRTY

Increase moderately when partners have brief rolling listener restarts and you have evidence failures recover within the short window. Decrease when partner operations complains about connection storms from your queue manager during their outages—your SHORTRTY times SHORTTMR may be too aggressive. Never increase SHORTRTY to fix wrong channel name or certificate—RETRY will continue until you fix configuration.

SHORTRTY and XMITQ Backlog

Persistent messages accumulate on the XMITQ while RETRY loops. SHORTRTY does not limit queue depth—it limits reconnect scheduling. Capacity planning for outages must include maximum expected RETRY duration times inbound message rate. Alert on XMITQ CURDEPTH and channel RETRY duration together.

Interaction with HBINT and DISCINT

• HBINT—detects silent failure during RUNNING; may trigger recovery separate from retry counters.
• DISCINT—idle disconnect when no messages; different from failure RETRY.
• Sequence numbers—after reconnect, protocol may require partner alignment; see sequence numbers tutorial.

Operational Playbook

1. DISPLAY CHSTATUS — confirm RETRY and read LASTCHLERR.
2. Fix listener, network, TLS, CHLAUTH before altering SHORTRTY.
3. During planned maintenance, PAUSE or STOP channel instead of relying on retries.
4. After fix, channel should reach RUNNING; watch XMITQ drain.
5. Post-incident: compare SHORTRTY to actual outage duration—tune if needed.

Explain Like I'm Five: SHORTRTY

SHORTRTY is how many quick tries MQ makes to call your friend back before waiting longer between calls.

Practice Exercises

Exercise 1

SHORTRTY=8, SHORTTMR=45. Estimate maximum short-phase wall time.

Exercise 2

Partner down 4 hours. Will SHORTRTY alone deliver messages? Explain.

Exercise 3

Write MQSC to set SHORTRTY 15 and SHORTTMR 60 on SDR QM1.TO.QM2.

Frequently Asked Questions

Test Your Knowledge