[email protected] (Shmuel Metz , Seymour J.) writes: > We ran more than that, plus TSO, on a 2 MiB machine.
IBM executives were looking at 370/165 ... where typical customer had 1mbyte ... in part because 165 real memory was very expensive ... and typical regions were such that they only got four in 1mbytes (after system real storage requirement) later, newer memory for 370/168 was less expensive ... and started to see four mbytes as much more common ... aka four mbytes as 370/165 would have met that typical MVT customer could have gotten 16 regions ... w/o having to resort to virtual memory ... but the decision had already been made. basical initial transtion os/mvt to os/vs2 svs was MVT laid out in single 16mbyte virtual address space ... and little bit of code to build the segement/page tables and handle page faults. The biggest code hit was adding channel program translation in EXCP ... code initially copied from CP67 CCWTRANS channel program translation. prior reference/discssion to justification for 370 virutal memory http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory later transition to os/vs2 MVS with multiple virtual address spaces ... had other problems. The os/360 MVT heritage was heavily based on pointer passing API paradigm ... and with move to MVS. The first pointer passing ... was put an 8mbyte image of the MVT kernel into every application virtual address space ... leaving only 8mbytes (out of 16) for application use. Then because of subsystems were now in their own (different) virtual address space ... needed a way for passing parameters & data back and forth between applications and subsystems using pointer passing API. The result was "common segment" ... a one mbyte area that also appeared in every virtual address space .... which could be used to pass arguments/data back&forth between applications and subsystems (leaving only 7mbytes for applications). The next issue was demand for common segment was somewhat proportional to number of concurrent applications and subsystems ... so the common segment area became common system area (CSA) as requirements exceeded 1mbytes. Into the 3033 area, larger operations were pushing CSA to 4&5 mbytes and threatening to push it to 8mbytes ... leaving no space at all for application (of course with MVS kernel at 8mbytes and CSA at 8mbytes, there wouldn't be any left for applications ... which drops the demand for CSA to zero). Part of the solution to address the OS/360 MVT pointer passing API problem was included in the original XA architecture (later referred to 811 ... because documents dated Nov1978) were access registers ... and ability to address/access multiple address spaces. To try and alleviate the CSA explosion in 3033 time-frame ... a subset of access registers was retrofitted to 3033 as dual-address space mode ... but it provide only limited help since it still required updating all the subsystems to support dual-address space mode (instead of CSA). trivia: the person responsible for retrofitting dual-access to 3033 ... later leaves IBM for another vendor and later shows up as one of the people behind HP Snake and later Itanium. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
