Re: Why I've Dropped In

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

Yes, but as I have argued before, this was a mistake, and in any event
base registers became obsolete when virtual memory became available
(though, of course, IBM kept it for backwards compatibility).

OS/360 "relocatable" ... included address constants in executable images
that had to be modified when first loaded into real storage (which
continued after move to virtual storage).

The initial decision to add virtual memory to all 370s was based on the
fact that OS/360 "MVT" storage management was so bad that (concurrently
loaded) executable sizes had to be specified four times larger than used
... so typical 1mbyte (real storage) 370/165 only ran four concurrently
executing regions, insufficient to keep 165 busy and justified. Running
MVT in a (single) 16mbyte virtual address space, aka VS2/SVS (sort of
like running MVT in a CP67 16mbyte virtual machine) allowed concurrently
running regions to be increased by a factor of four (modulo 4bit storage
protection keys required for isolating each region) with little or no
paging.

As systems got larger they needed to run more than 15 concurrent regions
(storage protect key=0 for kernel, 1-15 for regions). As a result they
move to VS2/MVS ... a separate 16mbyte virtual address space for each
region (to eliminate storage protect key 15 limit on concurrently
executing regions). However since OS/360 APIs were heavily pointer
passing, they map an 8mbyte kernel image into every virtual address
space (allowing pointer passing kernel calls to use passed pointer
directly) ... leaving 8mbyte for each region.

However kernel subsystems were also mapped into their own, separate
16mbyte virtual address space. For (pointer passing) application calls
to subsystem, a one megabyte "common segment area" ("CSA") was mapped
into every 16mbyte virtual address space for pointer passing API calls
to subsystems ... leaving 7mbytes for every application.

However, by later half of 70s & 3033 processor, since the total common
segment API data space was somewhat proportional to number of subsystems
and number of concurrently executing regions ... the one mbyte "common
SEGMENT area" was becoming 5-6mbyte "common SYSTEM area", leaving only
2-3mbytes for applications ... but frequently threatening to become
8mbyte (leaving zero bytes for applications).

This was part of desperate need to migrate from MVS to 370/XA and MVS/XA
with 31-bit addressing as well as "access registers" ... where call to
subsystem switched the caller's address space pointer to the secondary
address space and loads the called subsystem address space pointer into
the primary address space ... allowing subsystem to directly address
caller's API data in (secondary address space) private area (not needing
to be placed in a "CSA"). The subsystem then returns to the caller
... and the caller's address space pointer is switched back from
secondary to primary.

--
virtualization experience starting Jan1968, online at home since Mar1970