Thanks Jonathan for your msg about 512mb Is Ample Right Now, on
05 10-05-1994

JP> DR>
JP>   > JdeBP>   You cannot have it both ways in two consecutive sentences.
JP> DR>
JP> 
JP>   I said this, and in your reply you *still* try to have it both ways in
JP>   two consecutive sentences, viz. :
JP> 
JP> DR>
JP>   > The 2Gig size was chosen because thats the biggest file you can
JP>   > have anyway under OS/2 so the mapping of a single large file in a
JP>   > process could always be done [...]. That leaves plenty for the
JP>   > operating system and user code to map into.
JP> DR>
JP> 
JP>   Mapping a 2Gb file into a 2Gb address space *doesn't* leave
"plenty" for
JP>   the O/S and user code/data.
JP> 
JP>   Choose one or the other.  You cannot have both.
JP> 

I think you're confused about the virtual space. The 'potential'
virtual address space for OS/2 (had they chose to use it) is 4Gig.
That DOES leave a lot of room after mapping a 2 Gig file (the
largest that OS/2 supports.)

JP>  Buffer management has to be done for partial file mapping,
JP> which
JP>   leaves the resultant code no simpler.  Think about how access to a
JP>   record that is not currently within the "window" must have to be
JP>   implemented at application level.
JP> 

It's at the 'application level' in the sense that it is not in
the operating system. However it is NOT at the application level
in that it is A) fully separated from the accessing code and B) it
would be in the database system API not in 'user' level code.
Under Workplace OS/2 (as I mentioned before), it would not even be
necessarily even directly connected to the application at all,
since such a clean separation of access code from caching code
would allow a relatvely easy port to personality neutral base
database server system.

---
 X KWQ/2 1.2b X Look Ma, I'm a *Beta Tester*: KWQ Mail/2 for OS/2 v2.0!

--- Maximus/2 2.01wb