Troubleshooting
Problem
TN3270 clients are being disconnected after being idle longer than some period of time, even after being connected to an application. However, the TN3270 server still shows the session as being active. This occurs even if the TCP/IP stack is configured with a KeepAlive timer (the INTERVAL keyword on the TCPCONFIG statement) that is shorter than a known firewall idle timeout.
Symptom
Users at the client workstation do not get a response when attempting to use the session again, requiring them to reconnect. The TN3270 server's log will eventually have one of the following messages (depending on system configurations):
EZZ6035I TELNET DEBUG DETAIL CLIENT
IP..PORT: xx.xx.xx.xx..yyyy
CONN: nnnnnnnn LU: llllllll MOD: EZBTTRCV
RCODE: 1027-02 Last send not ACKed. Stack drops connection.
PARM1: FFFFFFFF PARM2: 00000460 PARM3: 00000000
EZZ6035I TELNET DEBUG DETAIL CLIENT
IP..PORT: xx.xx.xx.xx..yyyy
CONN: nnnnnnnn LU: llllllll MOD: EZBTTSND
RCODE: 1006-00 A TCP/IP send data request failed.
PARM1: FFFFFFFF PARM2: 0000008C PARM3: 76697242
EZZ6034I TELNET CONN nnnnnnnn LU llllllll SESS DROP ERR 1027
IP..PORT: xx.xx.xx.xx..yyyy
EZZ6034I TELNET CONN nnnnnnnn LU llllllll CONN DROP ERR 1027
IP..PORT: xx.xx.xx.xx..yyyy
EZZ6035I TELNET TN3270 DEBUG CONN DETAIL
IP..PORT: xx.xx.xx.xx..yyyy
CONN: nnnnnnnn LU: llllllll MOD: EZBTTRCV
RCODE: 1001-02 Client disconnected from the connection.
PARM1: FFFFFFFF PARM2: 00000461 PARM3: 76650446
EZZ6034I TELNET CONN nnnnnnnn LU llllllll SESS DROP CLNTDISC
IP..PORT: xx.xx.xx.xx..yyyy
EZZ6034I TELNET CONN nnnnnnnn LU llllllll CONN DROP CLNTDISC
IP..PORT: xx.xx.xx.xx..yyyy
EZZ6035I TELNET DEBUG CONN DETAIL
IP..PORT: xx.xx.xx.xx..yyyy
CONN: nnnnnnnn LU: MOD: EZBTPGLU
RCODE: 3003-00 LUs are all in use.
PARM1: 00000000 PARM2: *DEFLUS* PARM3: 00000000
Cause
A firewall (or possibly some other network device) is dropping the session since there has been no traffic over it for the configured idle timeout interval. The TN3270 server does not use TCP KeepAlive packets on its connections. Instead, it relies on the configured TIMEMARK interval to generate periodic traffic with the client. The server needs to be configured so that this TIMEMARK process occurs before any firewall timeouts.
The last case (RCODE 3003) can occur if the current TIMEMARK setting is significantly longer than the network's idle timeout. What can then happen is that clients continually reconnect until the pool of available LUs is exhausted.
Resolving The Problem
Adjust both the TIMEMARK and SCANINTERVAL values so that the overall interval is shorter than the idle timeout for any intervening firewall. SCANINTERVAL defines how often the server scans the current connections for activity. During this scan, if a session is found that has been idle for the TIMEMARK interval (or longer), the TIMEMARK processing is initiated. This normally consists of the following exchange between the server and the client:
DO TIMEMARK (x'FFFD06') to client
WILL TIMEMARK (x'FFFB06') from client
DONT TIMEMARK (x'FFFE06') to client
WONT TIMEMARK (x'FFFC06') from client
Possible scenarios at this time are:
- If the network connection is still established and the client system (including the emulator) is still responsive, this exchange completes successfully. The server starts the next TIMEMARK interval and the idle timer on any intermediate firewalls is reset.
- If the client system sends a TCP acknowledgement for receipt of the DO TIMEMARK packet but the WILL TIMEMARK response is not received before the next SCANINTERVAL, this means that emulator on the client system is no longer responsive. The session will be then be dropped and an EZZ6034I message with reason TIMEMARK is issued.
- If the network between the two systems is broken (including having a firewall that silently discards packets for sessions that have exceeded its idle timer), normal TCP protocol retransmissions are performed until the limit on retransmissions is reached. If this occurs the server will issue the EZZ6034I message with reason ERR 1027.
- Many firewalls will respond with a RESET packet if they have dropped the session for inactivity. In this case the the EZZ6034I message will occur immediately with no retransmissions.
Note that the time between the last data exchange for a session and the TIMEMARK sequence can range from the TIMEMARK value to TIMEMARK+SCANINTERVAL. With the default settings, this would be between 3 to 3.5 hours. This is because the SCANINTERVAL may have just occurred when a session exceeds the TIMEMARK setting. In this case, the exchange will not occur until the next SCANINTERVAL.
Also note that low SCANINTERVAL settings can result in excessive CPU usage for systems with many open connections. And that TIMEMARK processing is independent of the various inactivity timers (INACTIVE, KEEPINACTIVE, PRTINACTIVE, and PROFILEINACTIVE), see the IP Configuration Guide for a further description of these timers.
Related Information
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21269806