LONGRTY (Long Retry Count)

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.

Two-Speed Recovery Recap

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.

Short vs long retry phase
PhaseCount attrTimer attr
ShortSHORTRTYSHORTTMR
LongLONGRTYLONGTMR

Defining LONGRTY

shell
1
2
3
4
5
DEFINE 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.

Explainer: Calling Back Tomorrow

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.

When Long Retry Stops

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.

LONGRTY and Operations

  • Planned outage: PAUSE or STOP beats relying on LONGRTY alone.
  • Alert on RETRY duration and XMITQ depth, not only channel INACTIVE.
  • DR tests: verify LONGRTY on restored definitions matches standards.
  • Finite LONGRTY: calculate coverage = LONGRTY × LONGTMR for outage windows.

Capacity During Long 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.

Explain Like I'm Five: LONGRTY

LONGRTY is how many slow tries MQ makes after the fast tries did not work.

Practice Exercises

Exercise 1

LONGRTY=100, LONGTMR=300. How long is maximum long-phase schedule if all attempts run?

Exercise 2

When is finite LONGRTY better than 999999999?

Exercise 3

Channel RETRY 72 hours—list five checks before raising LONGRTY.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. LONGRTY controls:

  • Long-phase retry count
  • Heartbeat
  • Batch size
  • SSL cipher

2. LONGRTY works with:

  • LONGTMR
  • BATCHINT only
  • MAXDEPTH
  • INITQ

3. Before long retry, channel exhausts:

  • SHORTRTY short phase
  • DLQ
  • Topic
  • Browse only

4. LONGRTY does not stop:

  • Applications putting to XMITQ routes
  • Channel naming
  • TLS existing
  • Queue creation
Published
Read time15 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation