On Dec 15, 2004, at 8:39 AM, Paul Suckling wrote:

> I imagine loads of people must have wanted/attempted to do what I did.
> I
> don't want to use formatted io, and I was hoping not to have to use
> direct access because I know little about it and because my records are
> a lot more complicated that a single integer and I realized it would
> probably involve a lot of counting/bookwork on my part. Would that be
> the simplest way to achieve what I was trying though?

That's pretty much the only standard-conforming way.  There are "tricks"
that might be simpler, depending on other details, but they definitely
fall
into the category of tricks that make nonstandard assumptions about
implementation.  One such trick is to write the file as sequential, then
close it and reopen as direct access for the rewrite; you need to know
how the implementation forms records in the different cases to make
this work.  That's not actually difficult at all, but it is nonportable.

Just as a side note.  Sequential really means that you have to write
the records in sequence.  Any attempt to write them out of sequence
is going to be a battle against the fundamental design.  Also,
sequential
was originally designed around tape drives.  Trying to rewrite the
first record on a tape drive, while leaving the others untouched just
physically would not work.

As Steve mentioned, formatted vs unformatted has nothing to do
with direct vs sequential. You sound like you think that direct access
implies formatted.  It doesn't.  All 4 combinations exist.  In fact, of
the
4, formatted direct access is rarest. Most direct access is unformatted
(in fact, unformatted is the default is you specify direct access,
though
I recommend making it explicit to lessen confusion if nothing else).
You probably want unformatted direct access.

Steve mentioned one issue of direct access, but I consider that one
pretty simple.  You do need to know about it, but it is simple to handle
and not a big enough problem to be much of a deciding factor in the
choice of file structure. There is one big issue which can majorly
complicate direct access so much that it is a deciding factor.

That issue is that all the records in a direct access file are the same
length.  If your records happen to all be the same length already,
then that's perfect.  Doesn't matter how complicated they are - just
that their lengths be the same.  If you can accept padding out the
shorter records to the length of the longest (and you can figure out
ahead of time a suitable length), then that's ok.

But if padding all records to the same length is unacceptable, then
the bookkeeping gets significantly complicated - more so that just
keeping track of a current record number.  You end up needing to
do your own record management in essence.  You have to repackage
the records as known to the application into fixed size blocks, which
are the records as known to the system.  This can be done.  I've done
it.  But it is quite a bit of bookkeeping overhead.  And it can be a lot
of work to change an existing program because you have to go in
and redo every I/O statement to instead call your intermediary
routines.  Works better if you plan for it from the start than if you
are trying to convert existing code.  That's the kind of complication
that might make me consider nonstandard solutions like reopening
as direct access to patch the file.

In f2003, stream access becomes a possibility.  Almost all compilers
currently implement something like stream access as an extension,
but the details are different.  And rewriting in the middle of the file
might
be one of the subtle points of difference - I haven't researched that
bit,
but it strikes me as an area I'd worry about.

--
Richard Maine                |  Good judgment comes from experience;
[log in to unmask]       |  experience comes from bad judgment.
                             |        -- Mark Twain