When an IBM MQ message channel enters RETRY, the queue manager does not immediately give up—it schedules another connection attempt. SHORTRTY decides how many quick tries to make; SHORTTMR decides how many seconds to wait between those tries. A channel with SHORTRTY(10) and SHORTTMR(60) might spend roughly ten minutes in aggressive reconnect before long retry spacing applies. Operators who only raise SHORTRTY without understanding SHORTTMR accidentally create reconnect storms that overwhelm partner listeners. This tutorial explains SHORTTMR in seconds, how it interacts with SHORTRTY and LONGTMR, when to shorten or lengthen the interval, and how to diagnose RETRY loops that are tuning problems versus broken CONNAME or TLS.
Think of SHORTTMR as the pause between knocks on a door. SHORTRTY is how many knocks in the quick phase. If SHORTTMR is 10 seconds and SHORTRTY is 6, the short phase lasts about one minute of active retry scheduling before long retry backoff—arithmetic is approximate because processing and network time add overhead. Payment routes needing fast recovery after a thirty-second listener bounce might use SHORTTMR 20–60. Bulk routes to a partner under maintenance should not use SHORTTMR 5 with huge SHORTRTY—that punishes the partner network for hours.
| Attribute | Unit | Phase |
|---|---|---|
| SHORTTMR | Seconds | Between short retries |
| SHORTRTY | Count | How many short retries |
| LONGTMR | Seconds | Between long retries |
| LONGRTY | Count | How many long retries |
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) SHORTTMR(60) DISPLAY CHANNEL('QM1.TO.QM2') SHORTRTY SHORTTMR LONGRTY LONGTMR DISPLAY CHSTATUS('QM1.TO.QM2') STATUS LASTCHLERR
ALTER SHORTTMR affects new retry scheduling after the change; a channel already in RETRY may continue prior timing until the instance cycles—verify on your release. Record baseline SHORTRTY and SHORTTMR pairs per route in the operations manual so DR restores do not accidentally deploy lab values to production.
SHORTTMR is how long you wait before redialing when your friend did not answer—short enough to catch them if they just rebooted the phone, not so fast that you block their line with endless rings.
Beginners mix timer attributes because all are numbers on DISPLAY CHANNEL. HBINT is heartbeat interval for liveness on RUNNING channels—seconds between “still alive” checks. BATCHINT is milliseconds waiting to fill a message batch. SHORTTMR is seconds between reconnect attempts in RETRY. Changing HBINT does not fix RETRY caused by wrong CONNAME; lowering SHORTTMR does not fix silent TCP death—that is HBINT and network policy.
Messages keep arriving on the transmission queue while SHORTTMR drives reconnect attempts. Alert on CURDEPTH and RETRY duration together. SHORTTMR does not throttle application puts—it only spaces channel reconnects. Back-pressure belongs in application design or partner coordination, not infinite fast retry.
SHORTTMR is how many seconds MQ waits before trying again to connect when the first tries did not work.
SHORTRTY=12, SHORTTMR=25. Estimate short-phase wall-clock time.
Partner asks you to stop “hammering” port 1414. Which two attributes do you adjust first?
Explain why SHORTTMR is in seconds but BATCHINT is in milliseconds.
1. SHORTTMR is measured in:
2. SHORTTMR pairs with:
3. Very low SHORTTMR during outage may:
4. After short phase, channel uses: