Absolutely fascinating Anne and Lynn. I was just a lowly COBOL applications programmer back in those days and finally taught myself BAL. I do remember the sad day of the "unbundling" and no more freebies.
And then a few years later, I remember the day someone in the software group at Banker Trust, NY, showed me this new thing called, CP67, that could do what???????? Run other operating systems? Impossible. Unheard of. We were all stunned. I have since come to realize that even though MVS is more robust with more functionality, that when all is said and done, VM is really the only "true" operating system, because it is the only operating system that can run other operating systems. In effect reducing MVS to the level of a CICS. How fascinating to see the evolution of software from VM/CMS to VAX/VMS and from GML to HTML. Absolutely amazing. You have a phenomenal background. You should write a book, the History of Data Processing, if you have not done so already. These things are too important not to survive the wreck of time. On Fri, Feb 19, 2010 at 7:46 PM, Anne & Lynn Wheeler <l...@garlic.com>wrote: > The following message is a courtesy copy of an article > that has been posted to bit.listserv.ibm-main,alt.folklore.computers as > well. > > > gahe...@gmail.com (George Henke) writes: > > True. But it does not predate SVS, VS1, MVT, MFT, and OS Rel 17 from > > which (except for VS1) MVS evolved. Furthermore, a duck is still a > > duck no matter what you do to it, no matter how you dress it up. z/VM > > is certainly larger, more robust, and more powerful, than ever, but no > > matter what you do to it, it still just a hypervisor as one of the > > links included by some of the creators of PR/SM in the trail notes > > pointing out that PR/SM is now officially referred to as the "LPAR > > Hypervisor". > > re: > http://www.garlic.com/~lynn/2010d.html#58 LPARs: More or Less? > http://www.garlic.com/~lynn/2010d.html#59 LPARs: More or Less? > > science center had original done virtual machine cp40 on a 360/40 with > special hardware modifications to support virtual memory (they > originally had tried for 360/50, but could get any because so many were > going to FAA for ATC system). When standard 360/67 with virtual memory > hardware support came available, cp40 morphed into cp67. past posts > mentioning science center > http://www.garlic.com/~lynn/subtopic.html#545tech > > a more detailed early history can also be found here: > http://www.princeton.edu/~melinda > > lots of customers that had been sold 360/67s to use with tss/360 > ... switched to cp67 when tss/360 had delivery problems (others just > dropped back to running the machines in 360/65 mode with os/360). > > old post that has part of presentation I made at 68 SHARE meeting in > Boston about lots of performance enhancements I had done for MFT > (completely reworked stage2 sysgen for careful placement of datasets and > PDS members for optimal disk arm mition) and cp67 (lots of code changes > to significantly reduce cp67 pathlength) > http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14 > > One of the things that CP67 needed to handle for virtual machine > operation was channel program translation ... creating a shadow copy of > the virtual machine channel program ... with real addresses (rather than > virtual machine addresses). SVS faced the same exact problem in EXCP > processing handling the passed channel program. The SVS initial > implementation started out by borrowing the channel program translation > routine (CCWTRAN) from cp67 (basically MVT laid out in large virtual > address space, with minimum support for single virtual address space, > most of the work was CCWTRANS doing channel program translation for > EXCP). > > One of the first distributed development projects was between Endicott > and the science center to implement vm370 virtual machines in cp67 > running on real 360/67. Part of this resulted in also creation of the > cms multi-level source management infrastructure. The science center > cp67 service had a lot of non-employees from various higher educational > institutions in the boston area. As a result, there had to be a lot of > procedures to keep 370 virtual memory activity from unauthorized people. > The cp67 system running on the real 360/67 was "cp67l", "cp67h" ran in a > 360/67 virtual machine (away from prying eyes of unauthorized people) > with the changes to simulate 370 hardware, "cp67i" ran in 370 virtual > machine (with changes to conform to 370 rather than 360 virtual memory). > This environment was running standard for a year before the first 370 > with real hardware virtual machine was available. Then for a long time > "cp67i" was standard operating system that ran internally on large > number of 370s for long period (before vm370 was available). > > It took quite some time for science center got a real 370 to replace > 360/67 ... and look at moving from cp67 to vm370. However, i had > continued to work on 360 stuff (this was also during the height of > future system activity ... and possibly not exactly career enhancing, > but was periodicly making less than flattering comments about > FS). Eventually this old email references moving a lot of virtual > machine enhancements from cp67 base to vm370 base: > http://www.garlic.com/~lynn/2006v.html#email731212 > http://www.garlic.com/~lynn/2006w.html#email750102 > http://www.garlic.com/~lynn/2006w.html#email750430 > > the 23jun69 unbundling announcement started charging for application > software (somewhat as result of various litigation) ... but managed > to make the case that kernel software was still free. misc. past > posts mentioning unbundling > http://www.garlic.com/~lynn/submain.html#unbundle > > it has been claimed that the distraction of FS allowed clone processors > to gain foothold in the 370 market. Somewhat as a result, there was > eventually decision to start charging for kernel software. The mad rush > to get stuff back in 370 product pipeline contributed to decision to > release a lot of stuff I had been doing all during the FS period. Some > of this included the dynamic adaptive resource manager that I had > originally done as undergraduate and was picked up and shipped in cp67. > > There was a lot of simplification done as part of the morph of cp67 to > vm370 ... and one of the things dropped was dynamic adaptive resource > manager. As part of the post FS-period ... it was also decided to > release my resource manager on vm370 (which I had been shipping to a lot > of internal locations). However, the clone processors contributed to the > decision to start charging for kernel software ... and my resource > manager was selected to be the guinea pig ... and I got to spend a lot > of time with business people working out policies for kernel software > charing. > > misc. past posts mentioning some of the stuff that went into the > resource manager > http://www.garlic.com/~lynn/subtopic.html#fairshare > http://www.garlic.com/~lynn/subtopic.html#clock > > one of the other things at the science center was that GML was invented > there in 1969 ("G", "M", & "L" are the initials of the peoples' last > name) ... and support for GML tag processing was added to the CMS > "script" document processor. GML was subsequently standardized as SGML > ... some past posts > http://www.garlic.com/~lynn/submain.html#sgml > > waterloo did a clone of the cms "script" document processing command. > these references talk about the waterloo script SGML support morphing > into HTML at CERN (which then morphed into varioius other MLs). > > A History of Scientific Text Processing at CERN > http://ref.web.cern.ch/ref/CERN/CNL/2001/001/tp_history/Pr/ > > above mentions using Waterloo's clone of CMS SCRIPT command and getting > first laser printer (3800) in 1979. Above also describes evolution from > script/GML/SGML to Web & HTML. the evolution from script/GML/SGML to > WEB/HTML also described here > http://infomesh.net/html/history/early > > and first webserver outside cern is slac vm/cms system > http://www.slac.stanford.edu/history/earlyweb/history.shtml > > -- > 42yrs virtualization experience (since Jan68), online at home since Mar1970 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- George Henke (C) 845 401 5614 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
