The file isn't necessarily damaged or corrupt, but the operating system will
ALWAYS flag it that way by putting a marker record in the file at the last known
EOF.  A writer may open the file,and continue appending data to the file
completely unaware that the data can never be read.  The reader will be allowed
to read up to the error marker, and be toast.  The data between the marker
placed by system startup and the real EOF due to the writer is lost, and can't
be recovered.

The FSERR 105 still crops up without any power or system problems.  Not often,
but it still bytes us now and then.

We always use a FLOCK, FWRITE data, FCONTROL 6, FUNLOCK model, and it's entirely
random what application, files, accounts etc. it may bite us on.

What gets me is that the files we have sent HP to analyze are never corrupt,
only marked with these darn marker records.
--
Rick Ingham
"One track minds usually have derailed trains of thought."
John Korb wrote in message ...
|I agree, but compared to doing an FCLOSE followed by an FOPEN, an FCONTROL
|6 (which is a minor code change) is an improvement.   Personally, the only
|valid reason I know of for doing an FCONTROL 6 is to avoid the FSERR 105
|problem and the loss of the data in the message file if there is a power
|failure (longer than the UPS can survive) or a system failure.  A message
|file that is open when the system fails or dies due to a power outage is
|almost 100% sure to be damaged, with at least some data loss.  The FCONTROL
|6 has a definate performance penalty, but in situations where data loss is
|not an option, it is very useful in preventing data loss.
|