From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: VAX c
Date: 27 Dec 1992 08:17:32 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 <1992Dec26.211521.4768@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry
Kennedy, Operations Mgr.) writes:
>In article <Bzt6EF.Est@dale.cts.com>, glippert@dale.cts.com (George Lippert) writes:
>> So how do I make sure that the buffer gets onto disk? (in my case), I asked.
>> They told me that there is an "unsupported and undocumented" function that I
>> could call.  Thanks, but no thanks, I said.
>
>  At the risk of adding some useful information to this discussion 8-), I
>think they were talking about the VAX C fsync() function.

Not that I doubt your claim, but under VMS v4.4-2, there's no documentation for
this function.  Now, if you:
	$ ANAL/IMAGE/OUT=TMP.TMP SYS$SHARE:VAXCRTL
	$ SEARCH TMP.TMP "Symbol: ""FSYNC"""
you'll find that there *IS* such a routine.  But that doesn't help a whole lot. 
What argument does FSYNC take?  Is it the file descriptor or the file pointer?
Really, I'd like to know, since it's there but undocumented?  How do I *USE*
it?  (see:  I've clearly stated what I *don't* know, and have asked for
clarification;  I admit that, since we're talking about VAX C, I've assumed the
argument is either a file descriptor or a file pointer;  but if it's neither of
the above, I'd still like to know).

>2694 ;++ [095]
>2695 ; fsync - force a synchronization of file with user I/O
>2696 ;
>2697 ;	This function simply calls SYS$FLUSH for the file indicated to
>2698 ;	make sure that the physical I/O happens NOW for any logical I/O
>2699 ;	calls that the user has made.
>2700 ;
>2701 ; input:
>2702 ;	4(ap)	file descriptor number

OK. Never mind.  If I want to flush stdout, I should:
	fflush(stdout);
	fsync(fileno(stdout));
Please note:  You need to do both the fflush() AND the fsync()!

Why?  Well the fsync flushes the RMS buffers.  But unless you've done the
fflush, the data might not've made it that far!  So you've got to fflush() to
get the data to RMS, then the fsync() to get it to disk.

Please note that this particular butthead (me) has taken the time (about 5
minutes) to test the solution given and add a rather critical caveat (i.e.,
that you've got to do an fflush() before the fsync()).  Why?  Because I want to
understand what's going on.  I'd *STILL* rather have the whole thing documented
and supported, though!

Now, ask yourself:  Would the dickheads in this group even have wondered about
whether you had to do an fflush() first (this last comment is *NOT* intended as
a dig at Terry Kennedy, who's provided some very useful information; it's
directed at those dickheads who'd try Terry's solution and then say "But it
doesn't work," without bothering to consider that there are two levels of I/O
here).
--------------------------------------------------------------------------------
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.
Newsgroups: comp.os.vms