writing stream-access files
robert....@oracle.com
sequences
for writing stream-access files. I first saw the code fragment
OPEN(10, FILE='XXX', ACCESS='STREAM',
FORM='UNFORMATTED',
& ACTION='WRITE', POSITION='REWIND', IOSTAT=I)
CLOSE(10, STATUS='DELETE')
OPEN(10, FILE='XXX', ACCESS='STREAM',
FORM='UNFORMATTED',
& ACTION='WRITE', POSITION='REWIND', IOSTAT=I)
The first OPEN and the CLOSE are intended to delete the file XXX
before it
is written. Having seen that sequence, I quickly understood the
reason for the
code fragment
CALL SYSTEM('rm XXX')
OPEN(10, FILE='XXX', ACCESS='STREAM', FORM='UNFORMATTED',
& ACTION='WRITE', POSITION='REWIND')
Code sequences like these ensure that any data in the file to be
written is deleted
before the file is written. Unlike sequential-access files, writing
a record to a stream-
access file connected for unformatted input/output does not cause the
file to be
truncated.
While the sequences presented worked for the people who wrote them,
there is a
better way to get the same effect. The code fragment
OPEN(10, FILE='XXX', ACCESS='STREAM', FORM='UNFORMATTED',
& ACTION='WRITE', POSITION='REWIND')
ENDFILE(10)
causes the file to be truncated after the file is opened. It should
typically be faster
than the two sequences presented above, and it is more portable than
the second.
Unlike an ENDFILE statement for a sequential-access file, an ENDFILE
statement for
a stream-access file does not write an endfile record. Therefore,
there is no need to
backspace over the endfile record after the ENDFILE statement is
executed. A good
thing that, as backspacing is not allowed for stream-access files.
Robert Corbett
robert....@oracle.com
> A good
> thing that, as backspacing is not allowed for stream-access files.
I should have said that backspacing is not allowed for unformatted
stream-access files.
Robert Corbett
robert....@oracle.com
> While the sequences presented worked for the people who wrote them,
> there is a
> better way to get the same effect. The code fragment
>
> OPEN(10, FILE='XXX', ACCESS='STREAM', FORM='UNFORMATTED',
> & ACTION='WRITE', POSITION='REWIND')
> ENDFILE(10)
>
> causes the file to be truncated after the file is opened. It should
> typically be faster
> than the two sequences presented above, and it is more portable than
> the second.
Shortly after posting this, I remembered that there is a better way to
get the same effect, namely to use the STATUS='REPLACE' specifier in
the
OPEN statement.
Bob Corbett
mecej4
basic type of files, using STATUS='REPLACE' is more natural than to use
a record oriented statement such as ENDFILE on a file opened for STREAM
access.
-- mecej4
Richard Maine
> Shortly after posting this, I remembered that there is a better way to
> get the same effect, namely to use the STATUS='REPLACE' specifier in
> the OPEN statement.
Yes. I recall status='replace' as one of the new features that nobody
tended to talk about in f90, but was very useful. Prior to that,there
was just no really portable way to achieve the same thing. The
status='delete' trick required you to be able to sucessfully open the
old file, which could fail if you got properties of the file wrong.
(Stream access is much more likely to be able to open an arbitrary file,
but we didn't have that yet then.)
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
robert....@oracle.com
>
> Furthermore, to those who are used to thinking of streams as the most
> basic type of files, using STATUS='REPLACE' is more natural than to use
> a record oriented statement such as ENDFILE on a file opened for STREAM
> access.
>
> -- mecej4
ENDFILE has its uses for stream-access files, namely, if the file is
to be truncated at any point other than the start of the file.
Bob Corbett