After IBM MQ exhausts the short retry phase—SHORTRTY attempts spaced by SHORTTMR—the channel enters long retry. LONGRTY defines how many reconnect attempts occur in that slower phase, each separated by LONGTMR seconds. Enterprises often set LONGRTY very high so a weekend data-center outage does not permanently stop a critical SDR; the transmission queue holds persistent messages until Monday when the partner listener returns. This tutorial explains LONGRTY semantics, typical values, interaction with operations playbooks, and why increasing LONGRTY never fixes a wrong certificate or channel name.
Phase one: many quick tries (SHORTRTY × SHORTTMR scale). Phase two: fewer attempts per wall-clock hour but continued persistence (LONGRTY × LONGTMR scale). LONGRTY is the “how many times in slow mode” knob. When partners are down for planned maintenance longer than the short phase, long retry keeps the integration logically alive from MQ perspective—operators still see RETRY and growing XMITQ until service restores.
| Phase | Count attr | Timer attr |
|---|---|---|
| Short | SHORTRTY | SHORTTMR |
| Long | LONGRTY | LONGTMR |
12345DEFINE CHANNEL('CORE.TO.HUB') CHLTYPE(SDR) TRPTYPE(TCP) + CONNAME('hub.corp(1414)') XMITQ('XMIT.HUB') + SHORTRTY(10) SHORTTMR(30) LONGRTY(999999999) LONGTMR(600) ALTER CHANNEL('CORE.TO.HUB') CHLTYPE(SDR) LONGRTY(500) DISPLAY CHANNEL('CORE.TO.HUB') SHORTRTY SHORTTMR LONGRTY LONGTMR
LONGRTY(999999999) is a common pattern meaning “essentially unlimited long attempts” on many sites—not a magic guarantee on every platform release. LONGRTY(500) with LONGTMR(600) caps long-phase attempts at five hundred tries ten minutes apart—roughly multi-day coverage before policy stops retry. Choose explicitly; do not copy values without arithmetic.
SHORTRTY is knocking every minute today. LONGRTY is deciding to try once every hour for many days because your friend is on vacation—not giving up forever after three knocks, but not ringing every second either.
Consult IBM MQ documentation for your version when LONGRTY exhausts a finite count—channel may require manual START, remain in RETRY, or transition to INACTIVE. Infinite-style LONGRTY values avoid that edge case for critical routes. Document expected behavior in runbooks so overnight operators know whether to intervene after forty-eight hours of RETRY.
Persistent messages on XMITQ consume disk. Long RETRY with continuing application puts can fill disk and logs. LONGRTY keeps trying; it does not throttle senders. Coordinate with application teams on hold queues or circuit breakers during known extended outages.
LONGRTY is how many slow tries MQ makes after the fast tries did not work.
LONGRTY=100, LONGTMR=300. How long is maximum long-phase schedule if all attempts run?
When is finite LONGRTY better than 999999999?
Channel RETRY 72 hours—list five checks before raising LONGRTY.
1. LONGRTY controls:
2. LONGRTY works with:
3. Before long retry, channel exhausts:
4. LONGRTY does not stop: