NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/vms/19976

Text File | 1992-12-29 | 3.7 KB | 82 lines

Newsgroups: comp.os.vms
Path: sparky!uunet!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!dbased.nuo.dec.com!nntpd.lkg.dec.com!nntpd2.cxo.dec.com!adserv.enet.dec.com!winalski
From: [e-mail] (Paul S. Winalski)
Subject: Re: flushing in VAXC and DECC
Message-ID: <[e-mail]>
Lines: 69
Sender: [e-mail] (USENET News System)
Reply-To: [e-mail] (Paul S. Winalski)
Organization: Digital Equipment Corporation, Nashua NH
References: <[e-mail]> <[e-mail]>,<[e-mail]> <[e-mail]>,<[e-mail]> <[e-mail]>
Date: Mon, 28 Dec 1992 23:26:10 GMT


In article <[e-mail]>,
[e-mail] (Carl J Lydick) writes:
|>
|>In article <[e-mail]>,
|>[e-mail] (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?

I was very careful to verify my assertions by experiment using DECC under
AXP OpenVMS V1.0 before I wrote them up in my postings (I did the experiments
on Alpha VMS, BTW, because somebody had asked Ehud about DECC's handling of
this situation, and I happened to have an AXP system handy).  It works as I
described using DECC on Alpha AXP VMS systems:  if the file is a PPF, RMS
ignores the $FLUSH that is done by fsync().  However, in all cases, fsync()
causes the C I/O buffers to be flushed.

I can believe that this is not the case under VAX/VMS V5.4-2.  The C I/O
routines were completely rewritten for the DECC RTL, and many bugs and glitches
such as this one were fixed.

--PSW