Troubleshooting
Problem
Higher than expected levels of CPU (MIPS) are being used by the Telnet server address space.
Cause
A common cause of elevated CPU usage in TN3270 is higher than expected levels of connection activity, especially if encrypted sessions (SSL, TLS) are configured. This, in turn, can be caused by multiple sessions being disconnected and the client systems immediately reconnecting.
Diagnosing The Problem
Examine the SYSLOG or the TN3270 JOBLOG for EZZ6034I (or EZZ6035I) messages with SESS DROP or CONN DROP actions. Multiple connection drops will likely occur in batches with the same reason listed; and if there are more than two in a 15 second interval, only two messages where the second has a LUNAME MULTIPLE will be generated. The same IP address will probably show up at regular intervals. These messages will not show up if DEBUG CONN OFF has been configured in the PROFILE for the affected ports.
If SMFTERM is configured, you can examine the resulting 118 or 119 records to see reasons for past session drops, or to get a complete list of affected client addresses. Collecting a TELNET CTRACE will also show the complete set of client addresses.
Resolving The Problem
- If you have control over all the client systems, consider changing their configuration to disable Auto-Reconnect or reduce the number of retries (if available).
- If the drop reason is INACT-K, consider disabling the KEEPINACTIVE timer (set to 0).
- If the drop reason is INACT-S, consider disabling the INACTIVE timer (set to 0).
- If the drop reason is INACT-P, consider disabling the PRTINACTIVE timer (set to 0).
- If the drop reason is INACT-PF, this is typically a one time event (per client). However, this situation can occur often if an OBEYFILE command is being regularly performed on the server; review the reasons for why these OBEYFILEs are being performed.
- If the drop reason is ERR 1001, 1006, or 1027, or there are many with TKOVER, the cause might be that an intermediate firewall has an idle session timer. See TechNote 1269806 for recommendations on how to configure the TIMEMARK and SCANINTERVAL values to avoid this problem.
- If TKOSPECLU is configured, there may be two (or more) client systems configured to request the same LU name. If they are both configured for immediate reconnect and a short takeover interval is specified (especially if it is 0), then there will be constant activity between these two.
- If this is a z/OS 1.9 (or higher) system and the server is using SSL/TLS encryption for these sessions (SECUREPORT), then consider converting to use AT-TLS (TTLSPORT and associated policies) to perform this encryption. The result can be lower CPU overhead for the SSL handshake and the encryption and decryption processes. Further reductions can be achieved by ensuring that System SSL is configured to use the Cryptographic Coprocessors (if available on this system).
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21473179