This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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 >