Those messages occur over and over in the logs. Of the 10 listed messages, 2 were one-time messages; the no such connection message occurred about 10 times. There were 12 of the shut down messages, the last being in July of this year. The rest occur thousands of times, each.
One interesting note: In 2004, I asked essentially the same question about the same message. At that time, we were seeing a null file in SFS. This is probably the same problem, except we have not seen the null file. That is probably a matter of timing - if we look before the next addition is appended, we would probably see it. There were no answers posted to my query back then. The problem was self-healing; it went away for over 3.5 years. We do have a circumvention. When the PC posts the DATACONN message, the whole file is sent using PUT instead of APPEND, insuring that no corrupted file lasts for a measurable period. This will increase the amount of data on the network, but it will prevent confusion and manual intervention. As for leaving a partial or corrupted files, isn't SFS supposed to handle that? Something about a commit, perhaps? If FTPSERVE is committing a corrupted file, I would hope that it does not have a way to tell SFS to abandon the rename process in the middle. Speaking of SFS, the last occurrence of this problem was about midway between two control data backups that were 10 hours apart, so that is not the source of the problem. There were no messages, as in none at all, on the file pool server's console log between the two backups. Regards, Richard Schuh -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, November 29, 2007 6:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) > Foreign host aborted the connection > No such connection > Foreign host is no longer responding > TCP/IP service is being shut down > Destination network is unreachable These messages could occur during transfer, which might leave a partial file or a corrupted block, but there would have to be a very tight race to get it committed. If this were minidisks (I think you said this is SFS), then you could conceivably get the server to think a partial file was successfully written and have it replace the original (the old "write a new copy, close, delete old, rename new" method), but that would require some very tricky timing.
