From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: Re: flushing in VAXC and DECC
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Mon, 28 Dec 92 23:36:40 GMT


In article <1hn91uINNnna@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
|>Path: eco.twg.com!uunet!utcsri!torn!spool.mu.edu!darwin.sura.net!gatech!emory!swrinde!elroy.jpl.nasa.gov!news.claremont.edu!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
|>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
|>Lines: 79
|>Distribution: world
|>Message-ID: <1hn91uINNnna@gap.caltech.edu>
|>References: <1992Dec26.211521.4768@spcvxb.spc.edu> <6813@npri6.npri.com>,<1992Dec27.055031.24162@eco.twg.com> <1hjtr9INN34t@gap.caltech.edu>,<1992Dec27.200611.24473@nntpd2.cxo.dec.com>
|>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.
|>

Hello ???.. maybe you need to follow the thread of this discussion a little 
closer.. Sorry if things are moving too fast, but this thread has switched to
AXP.. not VAX/VMS v5.4-2.. it works fine on ALPHA as Mr. Winalski has 
indicated..

-Larry.