richardson_j@seismo.CSS.GOV@summer.su.OZ.AU (12/22/86)
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. Note that when the output device is a terminal, all works fine, as illustrated by the first example in Chap 24 of the C Manual. The problem appears when output is to a disk file, e.g., if the example mentioned is run in a batch job so that stdout is the logfile, or in cases where a disk file is specifically fopened. Has anybody else encountered this problem and found a work-around? We are trying to port a large Unix program to VMS, and this bug seems to be the only significant obstacle. We are running VMS V4.5. Thanks in advance, Jim Richardson, Alec Dunn -- Jim Richardson Department of Pure Mathematics, University of Sydney, NSW 2006, Australia UUCP: ...!seismo!munnari!summer.oz!jimr ARPA: jimr%summer.oz@seismo.arpa ACSNET, CSNET: jimr@summer.oz
rcb@rti-sel.UUCP (Random) (12/29/86)
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.