since last December we have been getting ASOD abends in certain CICS transactions, which indicates that a premature 'RST' instead of a 'FIN' was being issued, so CICS issued an abend in response to it. the abends were documented as being in response to insufficient keep-alive values and I reported the problem to CICS support, who said to look into the use of 'port scanners', which were software packages that Internet security might be running to scan the ports. And Internet security also runs firewalls with a default timeout of 1 hour. our TCP/IP is set to the default of 2 hours. the users were asked to check the server software and did not find that it itself was setting keep-alive values, but after 6 months, we finally found that the application itself running on a windows server and which invokes the url to the CICS application was setting connection timeout values. And someone from the CICS list also showed me a way to set the keep-alive directly from the CICS web applications.
So, just knowing what the default TCP/IP values are might be meaningless, since they can easily be overridden by user applications. -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Mason Sent: Tuesday, June 02, 2009 11:37 AM To: IBM-MAIN@bama.ua.edu Subject: Re: TCPIP Default keep alive question Eileen Did you mean to alert us to the possibility that the *partner* TCP application may be using its own TCP keepalive service? Also that a "firewall" could be operating its own keepalive mechanism so that either partner could be subject to a keepalive regime although neither had actually requested one? All that is certainly handy to know. Since Vic is talking about a "programming interface", he is posting in the IBM- MAIN list and he refers to TSO NETSTAT it's certain he is talking about the Communications Server IP component. That being so, I have pointed out how he can control - through the sockets API - the TCP keepalive service in the IP node with about which he would appear to be most concerned. However, it's true we haven't been told what he really wants to do and we can only guess based on the detailed query. Chris Mason On Tue, 2 Jun 2009 08:40:12 -0400, Barkow, Eileen <ebar...@doitt.nyc.gov> wrote: >Note that applications can set and override the keep-alive values. >We just spent 6 months resolving a problem with keep-alive timeouts and >it turned out that an application running on a Windows server was >setting the values and overriding TCP/IP and firewall settings (another >place where they set keep-alive). Mainframe applications can also set >the value. > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On >Behalf Of Chris Mason >Sent: Tuesday, June 02, 2009 7:32 AM >To: IBM-MAIN@bama.ua.edu >Subject: Re: TCPIP Default keep alive question > >Vic > >The best list to use for questions concerning the Communications Server >IP >component (even the Communications Server SNA component given that >Enterprise Extender is so often the subject) is the IBMTCP-L list: > >For IBMTCP-L subscribe / signoff / archive access instructions, >send email to lists...@vm.marist.edu with the message: INFO IBMTCP-L > >- > >Your precise answer is at the end of the post. > >If there were such an API, it would be one of the options of either the >getsockopt() call or the getibmsockopt() call and the equivalent in >languages >other than C. > >You may be aware that the matter of TCP keep-alive is not quite as >straightforward as it might be. To be sure I cover the topic correctly - >as best >I can - I'll quote what is said in the CS IP Configuration Reference >regarding >the value in which you are interested, the one that shows up in the >NETSTAT >CONFIG output as DefaultKeepALive specified by the PROFILE TCPCONFIG >statement INTERVAL parameter: > ><quote> > >INTERVAL default_keepalive_interval > >The default TCP keepalive interval for applications that enable the >SO_KEEPALIVE socket option and do not override the interval using the >TCP_KEEPALIVE socket option. The range is 0 - 35 791 minutes, and the >default is 120. A value of 0 disables the keepalive function, so that >sockets >for which SO_KEEPALIVE is specified do not perform TCP keepalive. In >this >case, sockets specifying a specific interval using TCP_KEEPALIVE >continue to >send keepalive probes. > >TCP keepalive probes end TCP connections after a period of inactivity. >TCP >keepalive is disabled by default for a connection, but can be enabled by > >issuing the SO_KEEPALIVE or TCP_KEEPALIVE socket options. The >TCP_KEEPALIVE socket option enables the application to specify the >keepalive >probe interval, while the SO_KEEPALIVE socket option uses >default_keepalive_interval as the interval. > >After the interval has expired, TCP sends a single keepalive probe to >the peer. >If the TCP_KEEPALIVE socket option is not used to specify the probe >interval, >a total of ten probes are then sent at 75-second intervals if no >response is >received from the peer. If no response has been received 75 seconds >after >the last probe, the connection is reset. If TCP_KEEPALIVE is used to >specify >the keepalive probe interval, the number of probes and the interval >between >the probes might differ depending on the interval specified. > ></quote> > >It was only after I read the last sentence that I realised the topic was >even >more complicated than I had initially supposed! > >OK, INTERVAL sets a node-wide "keepalive" interval for those TCP sockets > >which have decided to call upon the "keepalive" service by requesting it >by >means of the setsockopt() SO_KEEPALIVE option. The default is for the >service to be disabled. The value of the SO_KEEPALIVE option can be >obtained >by means of the getsockopt() call. > >Note that, even if the program requests that the service is enabled, it >can >effectively be disabled on a node-wide basis, by setting "0" as the >value for >the INTERVAL parameter. > >But there is also the TCP_KEEPALIVE option of the setsockopt() and >getsockopt() calls. This requests the service and sets a value for the >interval. >Moreover it sets up a regime for conducting the keepalive testing should >it be >called upon - that's the unexpected complication in that last sentence! > ><quote> > >TCP_KEEPALIVE > >Use this option to set or determine whether a socket-specific timeout >value >(in seconds) is to be used in place of a configuration-specific value >whenever >keep alive timing is active for that socket. When activated, the socket- >specified timer value remains in effect until respecified by SETSOCKOPT >or >until the socket is closed. See the z/OS Communications Server: IP >Programmer's Guide and Reference for more information about the socket >option parameters. > ></quote> > >The "configuration-specific value" is the value of the INTERVAL >parameter >when the service is enabled using the SO_KEEPALIVE option rather than >the >TCP_KEEPALIVE option. > >For reasons best known to the manual authors the section you need now to > >consult for the specifics of how the TCP_KEEPALIVE option works is >tucked >away as the last section of the last chapter of the CS IP Programmer's >Guide >and Reference manual! > >When you have read this section you may decide that the TCP_KEEPALIVE >option better satisfies your needs that the mechanism associated with >the >PROFILE TCPCONFIG statement INTERVAL parameter and the SO_KEEPALIVE >option. > >- > >Finally, to answer your question, I am not aware of an easy-to-use API >which >yields the value configured on the PROFILE TCPCONFIG statement INTERVAL >parameter. It is possible to extract the value as an SNMP manager >accessing >the MIB variable ibmMvsTcpKeepAliveTimer, 1.3.6.1.4.1.2.6.19.2.2.2.4. If > >there's an easier way, I hope someone will jump in with the answer. I >suspect >some technique able to extract the value from the output of the NETSTAT >CONFIG output might be the easiest. > >Chris Mason > >On Mon, 1 Jun 2009 12:16:28 -0500, Vic Petrone <v...@bell.net> wrote: > >>Is there a programming interface to extract the DefaultKeepALive value >that >is >>stored the TCP Configuration Table? >> >>This is the same value that the TSO NETSTAT CONFIG command displays. >> >>Thanks, >>Vic ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
