Walter, Thanks for pointing out APAR PQ45544. This is not a "code-correcting" APAR but a "new function" APAR - and dating from 2001, meaning that the "new function" is available in z/OS 1.6, the level used by the OP.
In effect what you have done is indicate where this relatively new parameter FTPKEEPALIVE might be particularly useful. The specific circumstances described by the APAR are for when a firewall destroys the FTP control connection. The TCP "keepalive" function is not fully intuitive based on the name. As the APAR text states, left alone a TCP connection is supposed to stay active indefinitely - it stays alive without a "heartbeat". It's the potential non-architected action of the firewall which destroys this happy circumstance. If you want to kill an inactive TCP connection, you need to arrange for a "heartbeat" - sending a null TCP packet typically - which, if not answered by a "heartbeat" from your connection partner, following a number of plaintive "second chances"[1], causes death. Originally I thought that what FTPKEEPALIVE is doing is ensuring that the FTP control connection, which is necessary in order to provide the message which assures that the transfer on the FTP data connection completed successfully, sets the sockets option which allows the TCP "keepalive" to operate. However it may be that from the introduction of the APAR, the "keepalive" option is always set - see later. Despite the presence of the INTERVAL parameter - and the SENDGARBAGE parameter - on the TCPCONFIG statement and the good explanation of the "keepalive" mechanism, *nothing happens* unless the sockets application, in this case the FTP client control connection application, approves the use of the mechanism by setting the sockets option "on" (the setsockopt() SO_KEEPALIVE option) which causes the mechanism to operate. In addition, the "keepalive" interval can be specified using the number following the FTPKEEPALIVE parameter (using the setsockopt() TCP_KEEPALIVE option). Reading what is said about the FTPKEEPALIVE parameter, there's an implication that, from the time the APAR was applied or the following release, the FTP client - and server - *always* operate the "keepalive" mechanism. The default specification is FTPKEEPALIVE 0. The significance of this appears to be not that the "keepalive" mechanism is switched off but merely that the interval is determined by the TCPCONFIG INTERVAL value. By contrast, if the TCPCONFIG INTERVAL value is set to 0 (not the default which is 120 minutes, 2 hours), the "keepalive" mechanism is switched "off" globally and thus cannot by used by any application running with that CS IP, in other words, the "keepalive" mechanism cannot be switched "on" by any application. The APAR text, which I was foolish enough to read initially, implies what I deduced originally, a deduction called into question by the manual text. This is sadly par for IBM authors - even APAR text writers' - course - ambiguity reigns. Perhaps someone with the facilities and energy - and inclination - to check can report what happens when an FTP client connection with FTPKEEPALIVE 0 - or FTPKEEPALIVE not specified together with TCPCONFIG INTERVAL (say) 1 is traced. In case the OP is using defaults, the "keepalive" mechanism may well be operating for the FTP client but, with a default interval of 2 hours, it probably may as well not be. As far as I can tell - "also" - you did not see the need to use the FTPKEEPALIVE parameter - or - you felt that referring to the APAR was the most efficient way to describe FTPKEEPALIVE - curious - 'cos it's not as clear as it might be. Chris Mason [1] "a total of ten probes are then sent at 75-second intervals" CS IP Configuration Reference 1.2.56 TCPCONFIG ----- Original Message ----- From: "Walter Trovijo Jr" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Monday, 10 July, 2006 5:10 PM Subject: Re: FTP - Put Error - EZA2590E > Hi, > > We've had a similar problem here in the past. Different platform, but > similar symptons. In our case, we had problems ftpying to a wintel machine > which in turn was writing data to another > machine thru remote shared folder (MS networking); another thing was that > remote machine was in a different network, so the connection was going > thru routers to the other side. The solution in our > case was to zip files on the mainframe before sending, because we found > that problem just happens with large file. Also, take a look at apar > PQ45544. > > http://www-1.ibm.com/support/docview.wss?uid=isg1PQ45544 > > HTH, > > Walter Trovijo Jr ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
