I do not believe so. There have been people monitoring the PC since this started last August.
Regards, Richard Schuh -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dave Jones Sent: Thursday, November 29, 2007 7:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append Hi, Richard. Since it is only one file from one site that is causing the problem, would it be possible that someone, at the remote site, is accessing the PC directly and doing a manual FTP PUT, instead of an APPEND? Could this simply be operator error on somebody's part? Schuh, Richard wrote: > 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 > > > -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
