Checking that the other end of the channel is still available

Heartbeats

You can use the heartbeat-interval channel attribute to specify that flows are to be passed from the sending MCA when there are no messages on the transmission queue. This is described in Heartbeat interval (HBINT).

Keep Alive

In WebSphere MQ for z/OS, if you are using TCP/IP as the transport protocol, you can also specify a value for the KeepAlive Interval channel attribute (KAINT). You are recommended to give the KeepAliveInterval a higher value than the heartbeat interval, and a smaller value than the disconnect value. You can use this attribute to specify a time-out value for each channel. This is described in KeepAlive Interval (KAINT).

In WebSphere MQ for iSeries, UNIX(R) systems, and Windows systems, if you are using TCP as your transport protocol, you can set keepalive=yes. If you specify this option, TCP periodically checks that the other end of the connection is still available, and if it is not, the channel is terminated. This is described in KeepAlive Interval (KAINT).

If you have unreliable channels that are suffering from TCP errors, use of KEEPALIVE will mean that your channels are more likely to recover

You can specify time intervals to control the behavior of the KEEPALIVE option. When you change the time interval, only TCP/IP channels started after the change are affected. The value that you choose for the time interval should be less than the value of the disconnect interval for the channel.

For more information about using the KEEPALIVE option on z/OS, see WebSphere MQ for z/OS Concepts and Planning Guide . For other platforms, see the chapter about setting up communications for your platform in this manual.

Receive Time Out

If you are using TCP as your transport protocol, the receiving end of an idle non-MQI channel connection is also closed if no data is received for a period of time. This period of time is determined according to the HBINT (heartbeat interval) value.

In WebSphere MQ for iSeries, UNIX systems, and Windows systems, the time-out value is set as follows:

  1. For an initial number of flows, before any negotiation has taken place, the timeout is twice the HBINT value from the channel definition.
  2. When the channels have negotiated a HBINT value, if HBINT is set to less than 60 seconds, the timeout is set to twice this value. If HBINT is set to 60 seconds or more, the timeout value is set to 60 seconds greater than the value of HBINT.

In WebSphere MQ for z/OS, the time-out value is set as follows:

  1. For an initial number of flows, before any negotiation has taken place, the timeout is twice the HBINT value from the channel definition.
  2. If RCVTIME is set, the timeout is set to one of depending on the RCVTTYPE parameter, and subject to any limit imposed by RCVTMIN. If you use a constant value of RCVTIME and you use a heartbeat interval, do not specify an RCVTIME less than the heartbeat interval. For details of the RCVTIME, RCVTMIN and RCVTTYPE attributes, see ALTER QMGR in WebSphere MQ Script (MQSC) Command Reference.
Notes:
  1. If either of the above values is zero, there is no timeout.
  2. For connections that do not support heartbeats, the HBINT value is negotiated to zero in step 2 and hence there is no timeout, so you must use TCP/IP KEEPALIVE.
  3. For client connections, heartbeats are only flowed from the server when the client issues an MQGET call with wait; none are flowed during other MQI calls. Therefore, you are not recommended to set the heartbeat interval too small for client channels. For example, if the heartbeat is set to ten seconds, an MQCMIT call will fail (with MQRC_CONNECTION_BROKEN) if it takes longer than twenty seconds to commit because no data will have been flowed during this time. This can happen with large units of work. However, it should not happen if appropriate values are chosen for the heartbeat interval because only MQGET with wait should take significant periods of time.
  4. Aborting the connection after twice the heartbeat interval is valid because a data or hearbeat flow is expected at least every heartbeat interval. Setting the heartbeat interval too small, however, can cause problems, especially if you are using channel exits. For example, if the HBINT value is one second, and a send or receive exit is used, the receiving end will only wait for two seconds before aborting the channel. If the MCA is performing a task such as encrypting the message, this value might be too short.