[email protected] (Charles Mills) writes: > independently of z/VM, but that is no longer true. > > I'm quite familiar architecturally with CMS. Yes, it is in one sense > an operating system. If I drew a picture of z/VM with a bunch of > guests, CMS would be a peer to VSE, z/OS and Linux, all of which are > no-doubt-about-it operating systems. So yes, it must be an OS. It's a > funny beast of an OS: a single-user operating system for a mainframe! > OTOH, the way people use it it is more like a single TSO session than > an operating system. It is more of a single-user terminal session than > an OS. And yes, it no longer can be IPLed on the hardware, so a purist > might say that disqualifies it as an operating system right > there. What kind of operating system requires an operating system in > order to run? > > Would not the proper phrase be "run independently of CP"? CMS is a > component of z/VM; it can't be independent of z/VM, it *is* z/VM.
original CMS was "cambridge monitor system" running stand-alone on 360/40. The same 360/40 had virtual memory hardware modifications to support developement of virtual machine cp/40 in parallel. When standard 360/67 with virtual memory became available, cp/40 morphs into cp/67 ... with CMS still running both stand-alone and in virtual machine ... cp40/cms development discussed here http://www.garlic.com/~lynn/cp40seas1982.txt also mentioned in http://www.ibmsystemsmag.com/mainframe/administrator/Virtualization/importance-today/ and my recent posting in this mailing list http://www.garlic.com/~lynn/2017b.html#30 Virtualization's Past Helps Explain Its Current Importance In the morph from CP67/CMS to VM370/CMS, they dropped and simplified a lot of CP67, change CMS name to conversational monitor system, and put test in CMS to cripple it from running on bare hardware. In the early 80s, CMS under MVS had really bad performance ... not because of CMS ... but MVS structural issues ... vm370/cms could provide .1sec interactive cms response when MVS/CMS was 1sec or worse with similar workload on same hardware. Some people thought that CMS might fix the really bad TSO interactive characteristics ... but it wasn't so much TSO versus CMS ... but underlying MVS structural issues. In the wake of failure of FS project in the mid-70s (never announced or shipped, FS would completely replace 360/370 and completely different and during FS, 370 projects were being shutdown, the lack of 370 products during the FS period is credited with clone makers gaining market foothold). In the wake of FS failure, there was mad rush to get 370 products back in the pipelines. 303x and 3081 were kicked off in paralle ... and head of POK managed to convince corporate to kill vm370/cms product and transfer all the vm370/cms to POK for MVS/XA work ... or otherwise MVS/XA wouldn't be able to meet ship schedule (well into the 1980s). Endicott eventually managed to resurrect VM370/CMS product mission ... but had to reconstitute development group from scratch. Aside, Tymshare had started offering there CMS-based online computer conferencing to SHARE for free as VMSHARE in Aug1976. In the VMSHARE archives there are customer comments about code quality during this period as Endicott rebuilds a vm370/cms development group http://vm.marist.edu/~vmshare At the time of the VM370/CMS shutdown there was development of greatly expanded CMS support for MVS system services, read/write MVS (shared) disks, etc ... which all disappears with the shutdown .... which was just fine with POK. After Endicott resurrects VM370, they were much more interest in CMS having DOS/VS capatibility (than MVS compatibiity; aka DOS/VS system services). With 4300s, Endicott manage to start making market position where large corporations were ordering multiple hundred 4300s at a time for placing out in departmental areas (sort of leading edge of coming distributed computing tsunami). This became such a large market, Endicott managed to get corporate to declare vm370/cms as the strategic interactive offering. At the time, the only disks for placing out in non-datacenter environment were FBA, which MVS didn't support. The requirement was also for support where it was several tens of systems per support person ... rather than MVS requiring several people per system. There was also late 70s, where customers were looking at 4341 cluster having higher throughput than 3033, more storage, more I/O, much lower environmentals, smaller footprint, and much lower cost. At one point POK felt so threatened that head of POK managed to get the allocation of critical 4341 manufacturing component cut in half. I participated in 4341 benchmarking for LLNL that was looking at getting 70 for a compute farm ... sort of the precursor to the current cluster supercomputers Some of the VM370/CMS people that went to POK, did do a virtual machine implementation to support MVS/XA development ... which was never intended to be released ... which contributed to idea for CMS under MVS. During the 80s when customers weren't migrating from MVS to MVS/XA like they were suppose to ... the internal tool was packaged as the migration aid to ... aid migration. Then POK had justification for a big group to bring the migration aid up to the feature, function, performance of VM370. At the same time, somebody inside IBM had added full 370-XA support to VM370. There was escalation between POK and Endicott over VM/XA, whether to have a large development group to bring migration aid up to vm370 level or to use the VM370 with XA support already running. For whatever reason, POK won. When I was undergraduate at the university ... totally redid OS/360 sysgen ... part of old 68fall SHARE presentation: http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14 Also rewrote a lot of CP67 code. Original CP67 CPU overhead increased elapsed running time from 12.9 secs to 34.2secs per job (21.3 secs of overhead CPU). CP67 pathlength optimization reduced elapsed running time to 17.4secs/job, CP67 CPU overhead reduced from 21.3sec to 3.9secs (lots of specific pathlengths reduced by factor of 100 times). It also mentions doing careful sysgen of OS/360 to reduce standalone time from over 30secs/job to 12.9secs/job ... careful placements of datasets and PDS members on disk to optimized arm seek time and multi-track search time for PDS members. CP67 for "normal" OS would have looked less bad since instead of nearly tripling elapsed time (12.9+21.3 to 34.2), it would have less than doubled elapsed time (35+21.3 to 56.9). The CP67 pathlength enhancements for standard system would have been 35+3.9 to 38.9secs ... compared to 12.9+3.9 to 17.4secs (careful OS/360 sysgen and data ordering significantly reduced wait time to run the jobs). Must of CMS CPU time was frequently CP67 doing disk I/O simulation (ala "CCWTRANS") ... I did a special disk CCW that CMS would use when running in virtual machine, cut that time by something like 80-90%. The people at science center http://www.garlic.com/~lynn/subtopic.html#545tech roundly critized me for violating 360 "architecture" ... if I was to do something that was virtual machine specific, I had to do it with the "diagnose" instruction ... which is defined as model dependent, and can have the fiction of "virtual machine" model. Thus was born diagnose I/O when running in virtual machine (later VM370 crippled CMS being able to run stand alone). trivia, recent mention that "CCWTRANS" was also borrowed for moving MVT to OS/VS2 http://www.garlic.com/~lynn/2017b.html#8 BSAM vs QSAM -- 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
