[email protected] (John Eells) writes: > It's certainly true that running the first large MVS system required a > significant number of people (operators, production control, system > programmers, etc.). However, the second through *n*th had far lesser > incremental cost. I was a sysprog during this period and we supported > 30-34 MVS systems (depending on the year) plus several VM systems with > perhaps 3 people per MVS system overall. > > I know of at least one customer who ran a one-person system > programming shop at the time, too. > > Also, because a substantial fraction of system programmer time was > devoted to debugging at the time, I rather suspect the average ratio > (whatever that might be) has improved markedly.
re: http://www.garlic.com/~lynn/2014g.html#83 Costs of core CP67 & VM370 took some time to get to unattended operation. Big first push was in the 60s with CP67 and being able to offer 7x24 online availability ... system costs were recovered by billing and leaving system up 7x24 when (initially) there was very low useage ... was big transition ... part of it was reducing total cost of operation as much as possible ... automatic ipl w/o human intervention, lots of other stuff w/o human interventiona. This was also in the period that machines were leased/rented with charges based on the system meter (which ran whenever processor and/or any channel was busy). An early gimick was special CCW so that things were reading for incoming characters ... but the channel wasn't classified as busy (so system meter would stop if there wasn't actually any activity). One of the characteristics of the system meter was all activity had to be quiet for at least 400ms before it actually stopped. Note that long after systems had converted from lease to sales ... and system meter was important ... MVS still had an internal system task that woke up every 400ms (to make sure that system meter never stopped). There was a problem as more and more services moved into virtual machines (common terminology now calls it virtual applicance, but then was called service virtual machines) ... that even if the system auto re-ipl'ed w/o human intervention ... there was increasing need to have the services running virtually automatically come up. I was doing lots of performance enhancements and turning at the science center http://www.garlic.com/~lynn/subtopic.html#545tech and developed automatic processes including automatically bringing up running operational virtual machines (automatically re-ipl between each benchmark, even in some cases re-ipl totally different systems). All during the FS period, http://www.garlic.com/~lynn/submain.html#futuresys I continued to work on 360/370 stuff ... even periodically ridiculing the FS stuff (which wasn't exactly a career enhancing activity). Then with failure of FS and mad rush to get stuff back into 370 product pipelines .... not just 3033&3081 but software ... which contributed to decision to release in products various pieces of stuff I was doing during the period. some old email about moving bunch of stuff from cp67 base to vm370 and discussion of various pieces. http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 above mentions csc/vm ... one of my hobbies was providing enhanced production operating systems to internal datacenters. Another piece was "autolog" ... which I had originally used for automated benchmarking ... but internally was increasingly used to automatically bring up service virtual machines ... and was included in vm370 release3 for that purpose. There was also a bunch of my integrity stuff picked up for release3 ... that eliminated all sorts of system failures. Then it was decided to pickup other pieces for release as the "Resource Manager" (initially with release3 plc9, aka nineth monthly update). Note that the 23jun69 unbundling announcement there was start charging for software, but they managed to make the case that kernel software should still be free. http://www.garlic.com/~lynn/submain.html#unbundle However, the lack of 370 products during the FS period is credited with giving the clone processors market foothold. Coming out of the FS failure, it was decided to start transition to charging for kernel software ... and my resource manager was selected as the guinea pig as separately charged for component. Also as part of the release, I had over 2000 (automated) benchmarks that took 3months elapsed time ... usually carefully selected configurations and workloads to validate correct operation. some posts http://www.garlic.com/~lynn/submain.html#benchmark after I transferred from science center to San Jose research, the internal distribution csc/vm morphed into sjr/vm. I also got sucked into doing significant upgrade for the disk engineering and development labs. They were operating pre-scheduled, stand-alone testing on numerous mainframe around the clock, 7x24. At one point they had tried MVS for concurrent testing ... but found it had 15min MTBF in that environment. I offered to rewrite I/O supervisor to make it bullet proof and never fail ... so that they could do on-demand concurrent testing ... significantly improving productivity. Afterwards, I would increasingly be dragged into playing disk engineer http://www.garlic.com/~lynn/subtopic.html#disk I was also doing DBMS stuff ... Bank of america was early adopter of the original sql/relational implementation System/R (that had been done at vm370 370/145 at san jose research) on 60 vm/4341s. Old email proding me that I needed to further improve (reduce) the care&feeding for large number of distributed vm/4341s. old email as Jim was leaving IBM for tandem, he was palming a bunch of stuff on me, working with BofA, consulting to the STL IMS group, etc. http://www.garlic.com/~lynn/2007.html#email801016 earlier email from Jim about BofA (& 60 4341s) http://www.garlic.com/~lynn/2010.html#email800311 posts mentioning original sql/relational system/r http://www.garlic.com/~lynn/submain.html#systemr 4300s were selling against DEC VAX machines in the low&mid range market. they sold about the same number in market involved small numbers of machines ... big difference was large corporations ordering hundreds of 4300s at a time. old post with a decade of VAX sales sliced&diced by model, year, US/non-us http://www.garlic.com/~lynn/2002f.html#0 as can be seen in the above, by the mid-80s, low&mid range market was starting to shift (to workstations and large PCs). At the time, MVS in this market wasn't even close for consideration. SHARE was doing studies/reports comparing the amount of human effort supporting vm/4341 compared to vax/vms ... recent post with old email about fortran Q (initially went out as iup opt=3 for FORTHX) ... but also references SLAC having done one of the (for SHARE) VMS/CMS comparisions http://www.garlic.com/~lynn/2014g.html#email820322 in this post http://www.garlic.com/~lynn/2014g.html#71 -- 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
