A message channel can show RUNNING in DISPLAY CHSTATUS while no messages flow for hours—that is normal for low-volume routes. It becomes dangerous when the TCP session is actually dead: a firewall dropped the connection, a router failed, or the partner process hung without closing the socket. IBM MQ uses heartbeat flows on active channels to prove the link is still alive. HBINT sets how often those heartbeats are sent. When heartbeats fail, the queue manager can tear down the session and enter recovery or RETRY so messages on the transmission queue are not stranded behind a ghost connection. Beginners often confuse HBINT with retry timers or with client KAINT; this tutorial separates those roles, shows how to set HBINT in MQSC, explains firewall interactions, and gives tuning guidance for batch versus real-time routes.
During RUNNING, channel agents at both ends exchange protocol data. Heartbeats are small flows that say “I am still here.” If the expected interval passes without successful heartbeat exchange, the channel instance treats the connection as failed, logs errors, and transitions according to type—often toward INACTIVE or RETRY on message channels. Applications do not send heartbeats; the channel agents do. That is why a healthy application on a client can still lose SVRCONN when network middleboxes kill idle TCP—the channel layer must detect it.
| Attribute | Purpose |
|---|---|
| HBINT | Detect dead partner during active channel |
| SHORTRTY / SHORTTMR | Reconnect schedule after RETRY |
| DISCINT | Disconnect idle channel when no messages |
| KAINT | TCP keepalive tuning on some transports |
123456DEFINE CHANNEL('QM1.TO.QM2') CHLTYPE(SDR) TRPTYPE(TCP) + CONNAME('qm2.corp(1414)') XMITQ('XMIT.QM2') HBINT(300) DEFINE CHANNEL('QM1.TO.QM2') CHLTYPE(RCVR) TRPTYPE(TCP) HBINT(300) ALTER CHANNEL('PAYMENTS.APP') CHLTYPE(SVRCONN) HBINT(60) DISPLAY CHANNEL('QM1.TO.QM2') HBINT DISPLAY CHSTATUS('QM1.TO.QM2') STATUS HBINT
HBINT(300) means roughly five minutes between heartbeats—illustrative only. Low-latency client SVRCONN routes may use 30–120 seconds; long-haul batch links sometimes use higher values to reduce overhead. Both sides of SDR/RCVR should use similar values. After ALTER, cycle the channel if running instances do not pick up changes immediately on your release.
Heartbeat is saying “are you still there?” every few minutes during a long call. If nobody answers after several checks, you hang up and call back (channel recovery) instead of talking into a dead line forever.
Corporate firewalls often drop TCP sessions with no traffic for thirty to sixty minutes—or less. If HBINT is 300 seconds but the firewall idle timer is 600 seconds, you are usually safe. If the firewall drops at 300 seconds and HBINT is 600, the channel may show RUNNING while packets no longer flow. Coordinate with network teams: either lower HBINT below the firewall timeout or enable TCP keepalive via KAINT where appropriate. Load balancers in front of listeners need health checks compatible with MQ long-lived connections—not HTTP-only probes.
Routes with one message per day still need liveness detection—that is exactly when silent failures hide longest. DISCINT disconnects idle channels to save resources; HBINT monitors channels that remain active. Understand both: a channel disconnected by DISCINT will restart when new XMITQ work appears; a dead RUNNING channel without heartbeats may block forwarding until detected.
HBINT is how often the MQ computers poke each other to make sure the string between them is not broken.
Firewall drops idle TCP at 900 seconds. Suggest HBINT values and explain why.
Channel RUNNING, XMITQ depth 5000, no MSGS increase—list checks including HBINT and firewall.
Explain difference between HBINT and DISCINT in one paragraph.
1. HBINT controls:
2. HBINT helps detect:
3. HBINT is not:
4. Firewall idle timeout vs HBINT—HBINT should be: