Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!mordor!styx!ames!ucbcad!ucbvax!rti-sel.UUCP!rcb
From: rcb@rti-sel.UUCP (Random)
Newsgroups: mod.computers.vax
Subject: Re: Output file sharing by C child processes
Message-ID: <8612291524.AA24109@rti-sel>
Date: Mon, 29-Dec-86 10:24:42 EST
Article-I.D.: rti-sel.8612291524.AA24109
Posted: Mon Dec 29 10:24:42 1986
Date-Received: Wed, 31-Dec-86 00:39:02 EST
References: <8612220638.AA15514@seismo.CSS.GOV>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Random 
Organization: Research Triangle Institute, RTP, NC
Lines: 13
Approved: info-vax@sri-kl.arpa

In article <8612220638.AA15514@seismo.CSS.GOV> richardson_j@seismo.CSS.GOV@summer.su.OZ.AU writes:
>We have a problem with C programs in which a parent and child process both need
>to write to the same file.  RMS now allows multiple writers to all file types
>(since VMS verion 4.4), and DEC C allows extra arguments to fopen() to specify
>file sharing options.  Parent and child execute their fopen() and fprintf()
>calls without error, but the parent's output obliterates anything written by the
>child. 
>

About the only thing I can think of is that you should be using 
"RAB.ROP.EOF := true" The meaning of this was changed with the new 4.4 RMS
so that on a file opened for shared write, each record write is guarenteed
to first seek to the end of the file.