The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[email protected] (Charles Mills) writes: > It also might be mentioned that there was an incentive to develop a > quick-and-dirty DOS/360 that came from the shortage of machine time on the > 7094 simulators (being used to develop OS/360) versus the amount of 360 > hardware that was coming out of the factory but unusable due to the lack of > an operating system. there was less difference between 360/370 w/o virtual memory and 370 with virtual memory. for 370 virtual memory there was (distributed) development project between the science center and endicott to modify cp67 to support 370 virtual machines with virtual memory (i.e. 370 had some new instructions and the format of the virtual memory tables and definition of control registers were different). since the cp67 service had non-employee users (students and others from various institutions in boston area, BU, MIT, Harvard, etc), the project went on with virtual cp67 in a virtual machine (to help keep information about virtual memory to leaking to the unauthorized). then to test the virtual 370 operation, another version of cp67 was modified to conform to the 370 architecture (instead of 360/67 architecture). A year before first engineering 370, the following was in general use 360/67 real machine "cp67l" running on real hardware "cp67h" running in 360/67 virtual machine w/virtual memory "cp67i" running in 370 virtual machine w/virtual memroy "cms" when first engineering 370 with virtual memory hardware became operation, a version of "cp67i" was booted on the machine to test its operation. The first boot failed, and after some diagnostic, it turned out that the engineers had reversed the definition of two of the new opcodes; the cp67i kernel was quickly patched (for the incorrect opcodes) and cp67i came up and ran. things were a little different for MVT->SVS. There were minimal changes to MVT to build a single virtual address table ... and handle page faults and paging operations (not a whole lot of difference between running MVT in a large virtual machine ... with a minimum amount of "native" virtual memory support). The biggest change for MVT->SVS was that the application channel programs passed via EXCP/svc0 had to be translated, aka a shadow copy of the CCWs built that had real addresses in place of the virtual addresses (along with the associated pinning/unpinning of the virtual pages to real addresses). To do this, a copy of the the corresponding code from CP67 was borrowed (i.e. when cp67 does virtual machine channel programs it had to scan the virtual channel program, creating a "shadow" copy with real address in place of virtual addresses). When 370s with virtual memory hardware started being deployed internally, "cp67i" was the standard system that ran on them for a long time (or "cp67sj" ... which was "cp67i" with 3330 & 2305 device support done by a couple engineers from san jose). something different was done for 3081 and TPF. Originally 308x was never going to have non-multiprocessor machine ... however, at the time, TPF didn't have multiprocessor support. The mechanism to run TPF on 3081 was to run vm370 with TPF in a virtual machine. In some number of TPF 3081, that tended to leave the 2nd 3081 processor idle. The next release of vm then had some special modifications to improve TPF thruput ... it added a bunch of multiprocessor chatter overhead that allowed parts of vm kernel execution to be run asynchronous with TPF operation ... this drove up virtual machine overhead by about 10% ... but increased overall TPF thruput ... by having the overhead being executed on the otherwise idle processor. The problem was that (additional multiprocessor overhead chatter) change degraded the thruput of all the other 3081 multiprocessor customers (that normally ran with all processors fully loaded). Finally, the company started to offer 3083 (a 3081 w/o the 2nd processor frame), in large part for TPF. As mentioned in this post http://www.garlic.com/~lynn/2010d.html#79 LPARs: More or Less? the straight-forward would be to leave out the "processor 1" frame ... but the "processor 0" was built at the top of the box ... and there was some concern that the straight-forward solution would leave the box top-heavy. -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
