On Friday, 1994-10-07  Jonathan de Boyne Pollard wrote to Dean Roddey
about "512mb Is Ample Right Now" as follows:

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.

Hi Dean & Jonathan,

Firstly, I thought a 32-bit flat memory model would offer a 4GB
address space. ... ;-)

Anyhow, you blokes are talking about a subject that was very dear to
the hearts of mainframers about 8 or 9 years ago. Indeed, MVS gained
an additional assembler macro called DIV (Data In Virtual) to address
[almost a pun!] this very issue. However, since MVS uses 31-bit
addressing (some turkey in the early 1960's used the MSB of OS/360
pointers as a flag, so it isn't available for addressing) it genuinely
is limited to a 2GB address space with additional data spaces of 2GB
each.

Since the MVS disk datasets that back DIV can grow to 4GB each, this
forces partial mapping into a single address space or data space, or
mapping the file across multiple data sapces. This is the way DB2 does
its buffering under MVS. Indeed, partial mapping works better than
complete file mapping simply because the buffer lookasides on a full
file mapping scheme would cause excessive page faults. Even with sparse
page-frame allocation, as soon as a page-frame is referenced it must be
committed. If this can cause problems on a 10GB mainframe with 500TB of
DASD, it will hammer into the ground a 128MB machine running OS/2.

[Dean, as I said to you on the IBM BBS: Welcome to FidoNet. Just
remember that thousands of people can read this, so keep the insults
very personal. :-) ]

Regards

Dave

 * KWQ/2 1.2g * If love is blind, lingerie makes great braille.
--- Maximus/2 2.01wb