From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: flushing in VAXC and DECC
Date: 28 Dec 1992 16:12:46 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1992Dec27.200611.24473@nntpd2.cxo.dec.com>, winalski@adserv.enet.dec.com (Paul S. Winalski) writes:
>The function behaves as documented.  It flushes all of the C RTL's internal
>buffers and it also does an RMS SYS$FLUSH to force the data to be written to
>disk.
>
>You're being caught by the special RMS processing for process-permanent files.

Afraid not.  The same thing happens with the program:
	#include stdio
	main()
	{	FILE *fp;
		fp = fopen("TEST.DAT", "w");
		fprintf(fp, "This is a test.\n");
		fsync(fileno(fp));
		sleep(30);
	}

fsync() *MUST* be preceded by an fflush() if you want to be sure that all stuff
that's already been written using standard I/O calls is flushed to disk.  And,
byt the way, despite the claim by another person, the program:

#include stdio
main()
{	int fd;
	fd = creat("TEST.DAT");
	write(fd, "This is a test.\n", 16);
	fsync(fd);
	sleep(30);
}

Also exhibits exactly the same behavior.  Unfortunately, there doesn't appear
to be any documented way to flush the C I/O buffers if you've been using
write() instead of standard I/O.

>When you do a SPAWN/NOWAIT/OUT=filespec, SYS$OUTPUT (aka stdout) is opened in
>supervisor mode by DCL as a process-permanent file.  This is done so that each
>program run in the subprocess doesn't create its own version of the output file.
>Many user-mode RMS operations on a process-permanent file end up being no-ops.
>Among these are SYS$OPEN, SYS$CLOSE, and SYS$FLUSH.  So what happens here is
>that the DECC RTL does write its buffers and do a SYS$FLUSH, but RMS ignores
>the SYS$FLUSH because stdout is a process-permanent file.

>Note that your second program above (the one with the fflush()) behaves
>identically to the first one--you still don't see "This is a test." until the
>subprocess terminates.  This is because the fsync()'s SYS$FLUSH is still
>being ignored.

Have you actually tried this, or are you just making a wild-assed-guess without
actually testing your claim?  The reason I ask is that your claim is dead wrong
under VMS v5.4-2.  Perhaps it's different under a different version of VMS?

>If you change the first program to read:
>
>	#include stdio
>	#include signal
>        main()
>        {
>        FILE *x;
>        x = fopen ("x.x", "w");
>        fprintf(x, "This is a test.");
>        fsync(fileno(x));
>        sleep(30);
>        }
>
>and then run it using the command SPAWN/NOWAIT/OUT=Y.Y RUN program
>you will find that the fsync() flushes "This is a test." to file X.X as the
>fsync() documentation would lead one to believe.

Again, is this just a wild-assed guess?  I tried that under VMS v5.4-2, and
once again, your claim is dead wrong.  If it's not simply a guess, what version
of VMS are you running?
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.