[email protected] (Shiminsky, Gary) writes: > If my memory serves me right, back in the 1970s there was OS/MFT, OS/MVT, > OS/VS1, and OS/VS2. > > OS/VS2 morphed to OS/SVS and then OS/MVS(? Or maybe just MVS) starting in > the 1980s.
OS/VS2 started out as single virtual address space (svs ... single virtual storage) ... a little bit of code for setting up page tables, handle page faults, do page i/o, basically faking MVT into thinking it was running in 16mbyte machine. the biggest problem/effort was channel program translation ... i.e. nearly identical problem as MVT running in 16mbyte virtual machine under cp67. In CP67, the routine to translate channel programs from virtual addresses to real addresses was CCWTRANS ... it made a copy of the passed channel program, replacing virtual addresses with real addresses, fixing up crossing page boundaries, etc. In fact, when Ludlow was doing the work, he actually cribbed a copy of CP67's CCWTRANS into the side of EXCP processing to do the channel program translation. Later OS/VS2 morphs into MVS ... each application getting their own 16mbyte virtual address space ... however OS/360 API heritage is extremely pointer passing intensive ... so they had to stick a 8mbyte image of the MVS kernel into each 16mbyte virtual address space ... so that the pointer passing API paradigm works (aka call the kernel passing virtual address pointer to parameters in application space ... mvs needing direct access to those addresses). Further complicating things were the subsystems were also pointer passing API intensive ... but they each now residing in their own, separate virtual address space. To address this, they started out with the "common segment" (1mbytes), an image of which occupied every virtual address space. applications could reserve space in the common segment, lay down the parameters, and then make call to the subsystem, passing an address pointer to the parameters in the common segment. This left applications with 7mbytes (out of the original 16mbytes). However, the requirement for common segment space is somewhat proportional to the number of different subsystems and the number of concurrent applications. By the 3033 timeframes many datacenters were running with 4-5mbyte common area (leaving only 3-4mbytes for applications our of the original 16mbytes) and verging on increasing to 5-6mbytes ... leaving only 2mbytes for applications. Some particular large internal VLSI chip development fortran programs were constantly threatening to exceed 7mbytes running for hours at a time on several of the largest MVS mainframes ... all requiring a carefully constructed MVS systems that didn't use more than 9mbytes. In order to address the problems they were on the verge to moving to vm370/cms ... since a CMS application could get nearly the whole 16mbytes ... solving a slew of constant applications problems trying to stay within the MVS limitations. for other drift ... part of a Future System discussion where original MVS was supposedly on the glide path to the Future System operating system (FS was going to completely replace 370 ... and the machines were nothing like 370 machines): http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory past posts mentioning (failed, w/o even being announced) FS http://www.garlic.com/~lynn/submain.html#futuresys -- 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
