This just in. The people overseas have found a message that gets displayed before the error.
ERROR: Can not Append on VM3. Function = FtpAppend. FtpError = FTPDATACONN It appears that the overwrite happens on the next attempt to do the FTP APPEND after this error, whatever it is. There is no mention of "FTPDATACONN" in the 5.2 TCP/IP bookshelf. ---------------------------------------------------- Original Message ------------------------------------------------------------------------ We have been using FTP to append to daily files from our centers around the world for eight years now. The way that we have been doing it is that data is accumulated by a PC at each center. When a threshold is reached, the PC initiates an FTP session with our VM system and appends the data to a file whose name and type reflect the location of the originating system, the type of log file and the date of the collection. These files reside in the same SFS directory. Lately, the files from one of the centers intermittently get corrupted by overwriting the already written data. For example, data, which is timestamped, might be collected for three hours and after the next transmission, the start of the file will bear the timestamp of 03:00:01. Sometimes, it happens early; other times late (20:39:00 is one recent example). The people who are in charge of this process have checked and rechecked to verify (1) that all centers are running the same level of software, (2) that there is nowhere that the PUT command is used in place of APPEND, and (3) any non-zero return code from any command terminates the transmission and the error is logged on the PC. So far, no non-zero return code has been reported; no error log created. Has anyone seen this sort of behavior? What might cause it? We have nearly 20 log files being created on VM using this method and software. Why is only one file being victimized? I have tried FTP to a test file that is locked in XEDIT by a user other than the owner of the directory. The result was a meaningful error message accompanied by a non-zero return code. Doing the same from the owning user gives the expected bad results. The updates of whichever user ends first get wiped out by the last to do the FINIS. It is only the update that gets wiped out, not the entire file. The latter test was just done for completeness of the experiment. In real life, (a) the owner is a service machine that runs disconnected and never manipulates these files until they are at least a day old, and (b) the only ones who can write into the directory are the owner, the PCs doing the FTPs, which act under the auspices of the only user explicitly authorized to write in the directory, and file pool administrators. We are running z/VM 5.2.0 at service level 701 (CP, CMS22, and TCP/IP all at the same service level.) Regards, Richard Schuh