Ok, we finally got this squared away. To recap: tn3270 sessions were getting
dropped with S522s. First it seemed to be JWT, but once that was fixed, they
were still getting dropped, but with S622s.
We had an old 2.4 system that did not exhibit the problem, and once we thought
to compare, we found these differences in the TCP/IP setup:
3.1
INACTIVE 0 * 0
TIMEMARK 14400 * 4 hours
SCANINTERVAL 3600 * 1 hour
2.4
INACTIVE 28800 * 8 hours
TIMEMARK 180 * 3 minutes
SCANINTERVAL 120 * 2 minutes
Changing these to match (so 3.1 is like 2.4) fixes 3.1's behavior.
After way too much Googling (not sure what IBM has done to make stuff hard to
find--I expected
"z/os" "tcp/ip" inactive timemark scaninterval
to find the manual that discussed these, but no) I found SC27-3651-03, but I'm
afraid the discussion of TIMEMARK and SCANINTERVAL doesn't make it clear to my
wee brain why this fixed it. Doc:
======
SCANINTERVAL and TIMEMARK statements
Use the SCANINTERVAL parameter statement to define the interval at which Telnet
checks connections for inbound TCP/IP activity. It is used in conjunction with
the TIMEMARK parameter statement, which defines the elapsed time Telnet uses to
determine whether a connection to the client is considered broken. During
SCANINTERVAL processing, if the elapsed time since the last inbound activity is
greater than the TIMEMARK value, the connection is considered possibly broken
and a TIMEMARK request is sent to the client. At the next interval, if neither
a TIMEMARK request nor data is received, the connection is considered broken.
Telnet drops the connection.
SCANINTERVAL and TIMEMARK can be coded in TELNETGLOBALS, TELNETPARMS, or
PARMSGROUP. See “Rules for Telnet parameter statements and security parameters”
on page 593 for more information about the hierarchy of parameter values.
If for any reason the TIMEMARK cannot be sent immediately on five consecutive
tries and no data or TIMEMARK response is received, the connection is dropped.
When TIMEMARK cannot be sent immediately, Telnet tries again at the next
SCANINTERVAL time. If the SCANINTERVAL is greater than the TIMEMARK value, it
is reset to the TIMEMARK value.
======
Seems like it should have wound up the same, just less chatty. Unless the
longer 3.1 intervals caused something ELSE in the loop--firewall/VPN--to allow
timeout, maybe? But I swear I frequently saw drops after as little as ten
minutes, which doesn't make any sense. Of course those could have been my
network connection--there are a lot of unknowns still.
But maybe I'm missing something wrt how those two parameters interact? Pretty
sure INACTIVE wasn't coming into play since it was 0 on 3.1.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
