On Wednesday, 12/26/2007 at 01:21 EST, "Schuh, Richard" <[EMAIL PROTECTED]> wrote: > The results are coming in and they seem unanimous. Whenever I detect a file > for the center in question having zero records (many occurrences) it is
> invariably corrupted. There have been only two occurrences of zero record > files from one of the other centers. Those two files were not corrupted. There > must be something happening because of timing or some other factor. > > I tried TRACERTE to the MVS systems at each of the centers. In each case, You mean your VM systems? > there were 8 hops. The difference is in time. The center where there is no > failure had almost instantaneous response while there are noticeable delays > when checking the path to the problem center. > > This leaves me with two questions: > > 1. Why am I seeing any instances of zero record files, especially when there > had been thousands of records in some of them in earlier checks? > 2. Why is this OK for one set of files, but not another? "Why" is a question that can only be answered with evidence from the FTP server since it is the thing that creates the files. A while back you indicated that the PC client displays ERROR: Can not Append on VM3. Function = FtpAppend. FtpError = FTPDATACONN immediately before the corruption. In theory, that was because an error was issued on the CONTROL connection in response to a APPE request by the client. If we can't construct a failure scenario in the lab, the difficulty will be to develop a trap that detects an error on an APPE, let the error go back to the client, and only then dump the virtual machine so that we can see the state of the file system. At that time you'd manually investigate the minidisk to look at the file in question. For a minidisk, the APPEND request causes the FTP server to set the file pointer to the end of the file. It doesn't actually "open" the file. When the data connection is established, and the data arrives, the writes are done starting at EOF. In theory, an error on the data connection can't corrupt anything. It would be educational to know if the same problem would occur if you used the SFS server instead of minidisk. > Actually, there is a third question: Which component(s) do I open the PMR(s) > against? Open it against the FTP server; it's the only thing that touches the files. Right? You don't have MW minidisks or something else that sneaks in and steals the minidisk from the FTP server? Alan Altmark z/VM Development IBM Endicott
