Moving buttembler programs above the line 509

virtual storage constraint (way back in 70s) was the 16mbyte addressing was being totally eaten up by system stuff. seperate address spaces can help with fault isolation and recovery strategies.

the basic (virtual storage constraint) issue then was the convention of pbutting pointers and the convention (inherited from os-360) of everything being in the same address space.

initially, SVS was essentially MVT laid out in a single 24-bit virtual address space. MVS enhanced that so there was a virtual address space per application ... but the kernel (and subsystems) still occupied-shared (each) address space ... essentially as it had in os-360 days.

with the proliferation of kernel and subsystem code ... there was starting to not be enuf space left (in 16megs) for application code ... and there was starting to be a migration of subsystems into their own virtual address space (to free up space for application code). this created a problem with preserving the pointer pbutting paradigm ... and so you got the common "segment" (place to stash data that was available to all virtual address spaces). Even with the migration of subsystems into their private spaces ... a typical late '70s shop had each 16mbyte virtual address space taken up with 8mbyte MVS kernel and 4mbyte common "segment" (and some were being forced to 5mbyte common "segment") ... leaving only maximum of 4mbytes (or 3mbytes) in each virtual address space for application.

the hardware started to be designed specially for the MVS implementation. the 168 & 3033 table look aside buffer used the virtual "8 mbyte" bit as one of the indexes; the result being that half of the TLB entries were used for the MVS kernel and the other half of the TLB entries were used for "application" space. If you had a different virtual memory paradigm ... say starting at virtual zero and only increasing as needed ... (at least) half of the TLB entries would likely be unused.

--