Gavin writes:

>Mapped access (using the pointer to access the file contents) bypasses the
>MPE file system and relies on the memory manager to page in bits of the
file
>when you need them.  There is no automatic mechanism in the memory manager
>to ensure that at some point all of your changes to this particular range
of
>the Virtual Address Space get posted to disk as a group.

SHORT_MAPPED, and LONG_MAPPED, have worked fine, on all of the systems
tested,
and when discussing the FAR_MAPPED issues mentioned earlier, my description
of
how it appeared to work for them, was not countered.

This(your comments as well as Jerry Fochtmans) is the first I have heard of
SHORT_MAPPED,
and LONG_MAPPED, having the same issue.

If that is the case, then again I ask the same question.  Why provide a
function that
returns a value, if that value cannot be used.  Why should the bit which
determines the
behavior at HPFOPEN time not be set when the value is requested after
HPFOPEN time?  What
value is there in this functionality except to create problems?

>Of course mapped access is generally the *slowest* way to access a file,
>which is another reason why it's not very well documented since almost
>nobody uses mapped access.  Lack of support for mapped files in NetBase was
>never a significant issue, which indicates that few, if any, applications
>used it for access to actual user data files.

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.
NetBase was not the issue.

>As far as the C compiler support for hybrid long-pointer segmented address
>arithmetic goes, I suspect it was felt that the large cost to enhance all
>the compilers to support this new data type was not justified due to the
>fact that very few people use mapped access, that such fundamental compiler
>changes would likely result in new bugs that would be difficult and
>expensive to track down and fix, and that it would further "fork" the
>compiler development work between MPE and HP-UX, since the HP-UX people did
>not want this stuff cluttering up their compilers and their fancy
>optimization stuff.

(I would agree except that what was suggested via pragma, is the removal of
MPE specific code, which overrides the default behavior for a 64 bit value.
When given 'char ^fcp', and one does a '*fcp++', the emitted code is
altered for MPE.  The suggested change would have made it consistent, and
is very simple to implement.)

You also make my point when you say "the HP-UX people did not want this
stuff
cluttering up their compilers".  The HP-UX is a priority platform for HP and

the MPE is not.

Thanks for the info Gavin, and Jerry, about LONG_MAPPED and SHORT_MAPPED
having
the same problem.


Ken Graham.