HBINT (Heartbeat Interval)

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.

How Heartbeats Work on a Channel

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.

HBINT vs related timers
AttributePurpose
HBINTDetect dead partner during active channel
SHORTRTY / SHORTTMRReconnect schedule after RETRY
DISCINTDisconnect idle channel when no messages
KAINTTCP keepalive tuning on some transports

Defining and Altering HBINT

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

Explainer: Checking Your Friend Is Still on the Phone

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.

Firewalls, Load Balancers, and NAT

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.

HBINT and Low Message Volume

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.

Symptoms of Wrong HBINT

  • Channel RUNNING, XMITQ depth growing, no recent MSGS on CHSTATUS—possible dead session.
  • Frequent disconnects every HBINT period—partner or network rejecting heartbeats, TLS middlebox issue.
  • HBINT zero on production—silent failures until operator notices backlog.
  • Mismatched HBINT across data centers after clone from template—intermittent one-way failures.

Tuning Guidelines

  1. Set HBINT lower than firewall/NAT idle timeout on the path.
  2. Document standard HBINT per route class (client, inter-QM, cluster).
  3. Do not disable heartbeats to “reduce traffic” without network analysis.
  4. After DR failover, verify HBINT on restored channel definitions matches standards.
  5. Correlate heartbeat errors in AMQ logs with network change tickets.

Explain Like I'm Five: HBINT

HBINT is how often the MQ computers poke each other to make sure the string between them is not broken.

Practice Exercises

Exercise 1

Firewall drops idle TCP at 900 seconds. Suggest HBINT values and explain why.

Exercise 2

Channel RUNNING, XMITQ depth 5000, no MSGS increase—list checks including HBINT and firewall.

Exercise 3

Explain difference between HBINT and DISCINT in one paragraph.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. HBINT controls:

  • Heartbeat interval in seconds
  • Batch byte size
  • MAXDEPTH
  • SSL cipher

2. HBINT helps detect:

  • Silent dead TCP connections
  • Queue full only
  • Wrong queue name
  • COBOL compile errors

3. HBINT is not:

  • SHORTTMR retry timer
  • Message size
  • Channel name
  • DLQ name

4. Firewall idle timeout vs HBINT—HBINT should be:

  • Less than firewall idle drop
  • Always zero
  • Equal to MAXDEPTH
  • Ignored
Published
Read time17 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation