Ken asks again:
> Why provide a function that returns a value, if that value
> cannot be used.

The value certainly *can* be used for lots of things.  You asked for the
virtual address of the file.  It gave you exactly what you demanded of it.
You can quite safely use the address to *read* the file.  Unfortunately the
semantics for performing mapped *write* operations are more complex, and as
you discovered and pointed out, poorly documented (on a good day).

> Why should the bit which determines the behavior at HPFOPEN
> time not be set when the value is requested after HPFOPEN time?

There is a strong argument that this indeed would be the safest choice.  On
the other hand, the FFILEINFO and AIF[...]GET functions are read only
"getter" type interfaces, and giving them side effects would hardly be good
design.

Setting the "post entire file VA range on close" flag will also incur a fair
amount of overhead at file close time which is unnecessary if the address
was only being retrieved for use in read access or some other unrelated
purpose.

If this functionality *were* added, it would probably only be added to the
FFILEINFO interface and not to the AIF interfaces which are defined to be a
fast low-level privileged interface for use by people who know what they are
doing (i.e. who would go rummage around directly in system tables if the
AIFs were not provided).

Another option would be to prevent the user from retrieving the address
without calling some function (FCONTROL/FSETMODE) to set the "I'm going to
do mapped updates to this file" flag.  Unfortunately the current memory
manager doesn't implement the ability to return "read only" pointers which
could not be used to modify their targets, and we're stuck with programs
that already get the pointer for read access today.

> >Of course mapped access is generally the *slowest* way to access a file,

> Generally you are correct, when it is a byte at a time.  However, if you
> are copying large blocks of data, like the COPY command in the CI, then
> you do want to use memory mapped access.  That is the case here.

IMHO, this is precisely backwards.  Mapped access is excellent when you know
that the data you want is already in memory, but completely inappropriate
when dealing with large volumes of data, and writing a file copier that uses
mapped access is absolutely the slowest way to do it that I can think of
offhand.

The CI's :COPY command does not use simple mapped access.

To get efficient bulk access to data using mapped access, you must manually
manage the I/O for the operation by calling various (privileged) memory
manager interfaces to explicitly manage the prefetching and posting of data
during the copy operation.

Simple mapped access performs very little prefetching of data and results in
many more page faults and other delays than simply using the FREAD and
FWRITE Intrinsics.  An FREAD/FWRITE loop will beat a mapped "memory move"
copy operation in all cases except where the pages to be read/written are
already in memory.

G.