edgould1...@comcast.net (Ed Gould) writes: > So, it was IBM saying if you don't run VM, FY? I think the many MVS > sites would take exception to that. From my perspective VM was OK > some things but not for PRODUCTION. VM was a sand box so the real > work was to be done on MVS.
re: http://www.garlic.com/~lynn/2015.html#84 a bit of hope? What was old is new again. http://www.garlic.com/~lynn/2015.html#85 a bit of hope? What was old is new again. depends on what you mean by "real work". Nearly all "online", "network" and various other kinds of "real work" inside IBM ... went on with VM. there was the virtual machine based (initially cp67, then vm370), world-wide online sales&marketing support HONE system ... and by mid-70s, an IBM mainframe couldn't be ordered w/o having been processed on HONE. some past HONE posts: http://www.garlic.com/~lynn/subtopic.html#hone when I first transferred from Cambridge http://www.garlic.com/~lynn/subtopic.html#545tech to San Jose Research, they let me wander around various locations in silicon valley (there use to be a joke that I worked 4shifts a week, 1st shift in SJR, 2nd shift in disk engineering, 3rd shift in STL, now SVL, and 4th shift/weekends at HONE). when I first transferred, I found the disk engineering and development lab was all being done "stand-alone", mainframes being scheduled 7x24 for testing. At one point they had tried to use MVS (allowing multiple concurrent testing), but in that environment, MVS had 15min MTBF (hang/fail requiring manual restart). I offerred to rewrite I/O supervisor so that it would be bullet proof and never fail, enabling. multiple concurrent, on-demand testing ... significantly improving productivity. I wrote an internal document describing all the enhancements ... and happened to include the MVS 15min MTBF reference ... which drove the POK MVS over the edge (not that I couldn't prove it true, but that I had made the information public inside IBM) ... and I was eventually told that while they couldn't actually get me fired, but they would be able to make sure that I never got an corporate award for the work. One of the other side-effects was since it was my software, any problems disk enginneering would constantly suck me into working on their problems. They also start insisting that I sit in on conference calls with pok channel engineers. past posts mentioning getting to play disk engineer in bldgs. 14&15 http://www.garlic.com/~lynn/subtopic.html#disk old email reference that 3380s about to ship and MVS system is hanging/crashing in *all* the standard FE error injection tests (and in 2/3rds of the cases, MVS leaves no indication what caused the failure). http://www.garlic.com/~lynn/2007.html#email801015 note that the internal network originated at the cambridge science center (virtual machine based) and was larger than arpanet/internet from just about the beginning until sometime in the middle 80s. Most of the nodes were vm370 and much of source development went on vm370 systems (even for mvs based products). part of the issue was severe limitation with the MVS networking support ... limit on max defined nodes were much less than total number of internal nodes ... also mixed up design so networking & job control information was intermixed in headers ... resulting in traffic between dissimilar MVS releases crashing MVS. As a result, any MVS systems were restricted to edge nodes, fronted by VM370 systems that had special code that would convert all header information into exact format required by the directly connected specific release of MVS. http://www.garlic.com/~lynn/subnetwork.html#internalnet Note that this wasn't SNA ... at least not until the late 80s when the communication group insisted that it convert to SNA ... which was major factor leading to its demise. the same technology was also used for the corporate sponsored university network BITNET (EARN in europe) which was also larger than arpanet/internet for a time. some past posts http://www.garlic.com/~lynn/subnetwork.html#bitnet Also, the original relational/sql System/R was developed on 370/145 vm370 at san jose research in the 70s. STL was responsible for IMS ... but nearly all the developers did their work on vm/cms. The followon to IMS was EAGLE ... and while the corporation was preoccupied with EAGLE, it was possible to get tech. transfer for System/R to Endicott released as SQL/DS. When EAGLE finally imploded, they wanted to know how fast could System/R be ported to MVS ... eventually released as DB2. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
