One Telnet Parameter Does All

Believe it or not, both of these problems can be solved using the same parameter on the Change Telnet Attribute (CHGTELNA) command. The parameter is called Session Keep Alive Timeout (TIMMRKTIMO). So what does the Session Keep Alive Timeout do? According to the IBM Help documentation, "It sets the amount of idle time that the TCP/IP protocol will allow before sending a probe to test an inactive session." Got that? No? Then, let's step back a bit.

TCP/IP Keepalive

When you start up a PC5250 session, your PC and your iSeries communicate back and forth. While you are actively using the PC5250 session, PC5250 is sending data to and receiving data from the iSeries when you press interrupt keys, such as Enter or Function keys. In this case, the iSeries knows the PC5250 session is active because it is receiving data from the PC. However, when that activity stops, the iSeries needs to know if the PC5250 session is still there or if it has been dropped. So it sends what is called in TCP/IP architecture a "keepalive"--or what I like to call an "Are you there?" request. If the PC5250 is still there but just waiting for someone to press an interrupt key, it responds to the "keepalive" request with an "I'm still here" response. The iSeries will continue to periodically send "Are you there?" queries as long as it keeps getting the "I'm here" responses and there is no active communication (i.e., interrupt data) being sent from the PC5250 session.

When the iSeries sends a keepalive (Are you there?) query, it waits for a period of time, and if it does not receive a response from the PC5250 session, it ends the PC5250 session. For specifically named PC5250 sessions (i.e., not QPADEVnnnn), it performs the action set in the Device Recovery Action (QDEVRCYACN) system value such as end or disconnect the interactive job running "in" the PC5250 session. For QPADEVnnnn, TCP/IP will always end the job.

Session Keep Alive (TIMMRKTIMO)

The TIMMRKTIMO parameter on the CHGTELNA command sets the amount of time the iSeries waits to query the status of the PC5250 session. You will need to end and restart the TCP/IP server in order for a change to the TIMMRKTIMO to take effect. The larger you make this value, the longer it will take to detect that a PC5250 session has dropped, thus the longer it will be before the iSeries will clean up the disconnected job. The length of time you could wait for this cleanup to occur could be up to twice the TIMMRKTIMO value. The smaller you make it, the more network traffic you will have and the shorter time a remote user (i.e., PC5250 connection via the Internet) has to make a connection. The default is 600 seconds (10 minutes). A value of zero (0) means there is no timeout, which means cleanup will never occur.

So what value should you use for TIMMRKTIMO? First, find out what your current TIMMRKTIMO is. If you are having trouble connecting, increase the value. If you are having trouble getting reconnected, decrease the value. You will need to find your comfort level between how much traffic you want to tolerate (lower setting means more network traffic) versus how fast you need to have your lost PC5250 session detected.

Help Spread the News

I hope this will help many of you who have experienced these problems. And if so, please spread the word. There is no need to be frustrated by connection problems. The solution is just a TIMMRKTIMO away.

Becky Schmieding is an IBM Certified Senior Project Manager at IBM Rochester. She is a noted speaker and author on PC5250, iSeries Navigator, and the iSeries Access family of products. She can be contacted at This email address is being protected from spambots. You need JavaScript enabled to view it..