Gavin after me:

>> I first encountered difficulties with the READ and not
>> the write operation.

>I have never heard of anything like this, and would be quite interested in
>hearing more details.

It had to do with certain files, and only under certain strict conditions.

I was able to reproduce it consistently where the READ of the data caused an

invalid memory address in HPFMOVEDATA but did not otherwise cause an error
when
the FAR pointers were passed to memcpy and the contents copied.

>> Then, what would be a valid behavior, is to not return the value, unless
>> it had been supplied already via HPFOPEN.

>Unfortunately we're stuck with the current behavior because existing
>programs depend on it :-(

Really? Can you explain how the FAR pointer is being used?


>...
>You're sure your test file wasn't always in memory?

No, I cannot be sure, but in the cases being tested, I can reasonably assume
that the source was not in memory, and that the destination most likely
stayed
in memory (because it was being hammered, so to speak).
By using memory mapped, for both READ and WRITE access, there was a
significant
improvement.  When analyzed at the file level, there were instances where
certain files took slightly longer with mapped, than with normal access, and

now I understand why.  But overall, using mapped access, under current
conditions,
has improved performance.

Ken.