Rather than close and reopen the message file, try using FCONTROL 6.  It
updates the file label (posts the current EOF) with far less overhead.
Also, should there be a system failure (I know, they happen only once very
few years, but they do happen), the fact that the EOF has been updated on
the file label makes the message files much more likely to survive.  There
is also non-destructive read capability with message files, and using
FCONTROL 6 after a destructive read not only updates the EOF, but helps
avoid the dreaded "Bad variable block structure (FSERR 105)".

John


At 8/24/99 09:51 AM , Jim Alton wrote:
<snip>

>I've not experienced any problems with message file data being corrupted.
>There are some tricks to working with them, but no actual corruption.
>
>For example:
>
>- The message file is empty
>- Process A opens the message file and writes 2 records to it.
>- Process B asks for an FINFO('EOF',) on the message file and gets 0.
>
>Resolution of this problem is to force Process A to close the message file
>after each write.  This is additional overhead but I know of no other
>alternative.
>
>
>Jim Alton
>eSystem Solutions
>[log in to unmask]


--------------------------------------------------------------
John Korb                            email: [log in to unmask]
Innovative Software Solutions, Inc.

The thoughts, comments, and opinions expressed herein are mine
and do not reflect those of my employer(s), or anyone else.