KAINT (Keepalive Interval)

IBM MQ channels ride on TCP sockets through corporate networks that silently discard idle connections. DISPLAY CHSTATUS may show RUNNING while packets no longer flow—a nightmare for transmission queues that stop draining. HBINT provides Message Channel Agent heartbeats at the MQ protocol layer; KAINT influences TCP keepalive behavior so the operating system and network stack also probe the connection. Beginners confuse the two or set neither, then blame MQ for firewall timeouts. This tutorial explains KAINT in seconds, how it complements HBINT and DISCINT, when to set explicit values versus zero for OS defaults, and troubleshooting patterns on long-idle links and VPN paths.

Two Layers of Liveness

At the application protocol layer, HBINT causes channel agents to exchange heartbeat flows during RUNNING. At the TCP layer, keepalive probes verify the socket path. A firewall might allow small MQ heartbeat traffic but still expire NAT mappings; TCP keepalive can refresh those mappings on some paths. Conversely, TCP keepalive without adequate HBINT might leave MQ unaware of partial failures in edge cases—use both per standards, not one alone.

Setting KAINT

1
2
3
4
5
6
7
DEFINE CHANNEL('QM1.TO.QM2') CHLTYPE(SDR) TRPTYPE(TCP) +
  CONNAME('qm2.corp(1414)') XMITQ('XMIT.QM2') +
  HBINT(300) KAINT(60)
DEFINE CHANNEL('PAYMENTS.APP') CHLTYPE(SVRCONN) TRPTYPE(TCP) +
  HBINT(120) KAINT(30)
ALTER CHANNEL('QM1.TO.QM2') CHLTYPE(SDR) KAINT(120)
DISPLAY CHANNEL('QM1.TO.QM2') KAINT HBINT

KAINT(60) with HBINT(300) illustrates layered timing—values are examples only. Coordinate KAINT with firewall idle timeout: keepalive should fire before the firewall drops the session. On Linux queue managers, also verify OS-level tcp_keepalive_time sysctl if KAINT is zero.

Explainer: Tap the Pipe While Water Is Still

HBINT is the two MQ buildings shouting “still here?” across the bridge. KAINT is tapping the physical bridge cables so the road crew (network) does not remove the bridge as abandoned while traffic is quiet.

Firewalls, NAT, and Cloud Load Balancers

• Document firewall idle TCP timeout for each MQ path class.
• Set KAINT and HBINT below the smallest timeout in the path.
• Load balancers may need MQ-aware idle settings, not only HTTP health checks.
• VPN reconnect may kill TCP without telling MQ—heartbeats and keepalive help detection.

KAINT Zero and Platform Defaults

KAINT(0) typically delegates to system TCP keepalive defaults, which may be two hours on some Linux installs—far longer than a sixty-minute firewall idle timer. Never assume zero is “good enough” without measuring. z/OS and Windows have their own defaults; read platform guides alongside MQ channel attributes.

Symptoms and Fixes

1. RUNNING channel, zero throughput, no RETRY—suspect dead TCP; review KAINT/HBINT/firewall.
2. Frequent disconnects after exactly N minutes idle—match timers to firewall.
3. After enabling TLS, idle behavior changes—retest KAINT/HBINT pair.
4. Compare with DISCINT—intentional idle disconnect versus silent failure.

Explain Like I'm Five: KAINT

KAINT tells the computer network to poke the connection so nobody thinks the line is abandoned and throws it away.

Practice Exercises

Exercise 1

Firewall idle 900s. Suggest HBINT and KAINT starting points and why.

Exercise 2

Explain KAINT vs HBINT to a network engineer in three sentences.

Exercise 3

When is DISCINT(0) with explicit KAINT reasonable?

Frequently Asked Questions

Test Your Knowledge