[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010402: Flushing file buffers with FORTRAN . . .

Stonie,

I have a manual on DEC fortran... 
There are 2 keywords, BUFFERCOUNT and BLOCKSIZE. Both are in blue print
which mean that they are non-standard extensions to fortran 77.

The documentation states that if BUFFERCOUNT is not specified, or
if it is zero, then the value defaults to 1.

If BLOCKSIZE is not specified, or is zero, then the default is the
filesystem default.

That seems to imply that the example below will still create 1 buffer.
Anything in blue print is generally a portability problem.

The obvious work around for dcgrib2 is to have a separate file action for
the HAXA00 product with -close in pqact.

The best platform independent solution is probably to use alarm() to 
close file handles that haven't been written to recently, or make the 
application
multi threaded.

Steve Chiswell
Unidata User Support


>From: "Stonie R. Cooper" <address@hidden>
>Organization: Planetary Data, Incorporated
>Keywords: 200104021539.f32FdDL02001

>Steve,
>
>A problem you addressed some time back on gembud, and one that we had also 
>noticed, was the decoding of RCM data via the dcgrib2 decoder - and the fact 
>that there is no obvious "fflush()" equivalent in FORTRAN.  At least I 
>thought there wasn't . . .
>
>I found a very old reference - for VME/VAX FORTRAN 77 - that says one can get 
>continuous file I/O to disk by specifying the BUFFERCOUNT in the OPEN 
>statement.  Essentially, the author indicated a typical line would be:
>
>      OPEN (UNIT=10, FILE=TEMP.FIL;1, BUFFERCOUNT=0)
>
>I haven't tried this yet - and not even sure if g77 has this rule allowed, 
>but wanted to see if you knew of this trick, and if it worked.  I guess the 
>logic is that if there is no buffer, it has to go to disk.
>-- 
>Stonie R. Cooper,
>Science Officer
>Planetary Data, Incorporated
>3495 Liberty Road
>Villa Rica, Georgia  30180
>ph. (770) 456-0700; pg. (888) 974-5017; fx. (770) 459-0016
>