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

Text File | 1992-12-28 | 3.9 KB | 93 lines

Path: sparky!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: [e-mail] (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: <[e-mail]>
References: <[e-mail]> <[e-mail]>,<[e-mail]> <[e-mail]>,<[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: sol1.gps.caltech.edu

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?

>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: [e-mail] | 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.