IBM MQ long retry is the slow drumbeat of recovery: after quick SHORTRTY attempts at SHORTTMR spacing fail, the channel waits LONGTMR seconds between each long-phase try. LONGRTY counts how many such slow tries occur. Together they prevent a dead partner from receiving a reconnect every few seconds for days while still giving the route a path back without manual DEFINE. This tutorial focuses on LONGTMR—why it is measured in seconds, how to choose values against maintenance windows, how it differs from SHORTTMR and HBINT, and what operators should do when the partner is fixed but LONGTMR means the next try is still forty minutes away.
LONGTMR(600) is ten minutes between long attempts. LONGRTY(144) at that spacing is roughly twenty-four hours of long-phase schedule if every attempt runs—illustrative arithmetic for capacity planning. Operators use this math for “how long until we must intervene” during incidents. If LONGTMR is 3600 and the partner fixed the listener five minutes ago, waiting for automatic retry may waste hours—START CHANNEL after verified fix is standard practice.
| LONGTMR | Typical use |
|---|---|
| 300 (5 min) | Faster recovery after extended blip |
| 600 (10 min) | Common default on many routes |
| 3600 (1 hr) | Partner-sensitive; very long outages |
123456DEFINE 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) LONGTMR(1800) DISPLAY CHANNEL('QM1.TO.QM2') LONGRTY LONGTMR DISPLAY CHSTATUS('QM1.TO.QM2') STATUS
Document why each critical route uses its LONGTMR. Partners under change control may request minimum reconnect interval during maintenance—honor that in LONGTMR rather than fighting with aggressive SHORTTMR alone.
After quick tries failed, LONGTMR is deciding to check the mailbox once an hour instead of every minute—you still check, but you do not walk to the mailbox constantly.
Four-hour maintenance with LONGTMR(600) means roughly four automatic long attempts during the window—may still trigger monitoring alerts. Prefer PAUSE CHANNEL on both sides during coordinated maintenance. Resume after verification; do not rely on LONGTMR to “stay quiet” if SHORTTMR is still aggressive before long phase begins.
LONGTMR is the long wait between slow tries to connect again after the quick tries did not work.
Partner fixed outage. LONGTMR=3600. What should operator do to restore traffic now?
Compare SHORTTMR 30 and LONGTMR 600 in one paragraph for operations.
LONGRTY unlimited, LONGTMR 600—what monitoring do you add?
1. LONGTMR is measured in:
2. LONGTMR applies in:
3. LONGTMR usually compared to SHORTTMR is:
4. After fixing listener, operator can: