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: RandomOrganization: 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.