Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Lynn Wheeler Newsgroups: comp.os.linux.misc,comp.unix.shell,alt.folklore.computers Subject: Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Date: Sun, 08 Nov 2026 12:21:49 -1000 Organization: Wheeler&Wheeler Lines: 88 Message-ID: <87ik27arr6.fsf@localhost> References: <18dee4b6cab427fa$865$2574533$802601b3@news.usenetexpress.com> <11cdg33$47sq$1@dont-email.me> <11cdp6v$1qa8$3@gal.iecc.com> <875wy85ba3.fsf@localhost> <11cpv8t$c3gs$1@dont-email.me> <11cqpn5$nfgo$2@dont-email.me> <11cqqh2$ntcu$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Sun, 08 Nov 2026 22:21:58 +0000 (UTC) Injection-Info: dont-email.me; logging-data="800688"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+9NwAnLNqatO6fiMn6upXPKX5iEelRNkU="; posting-host="98d7c4ad43b3a6b29b8871fe584fafd4" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:ux+8g+S9ItVoJDt+gzSuRnfOfWA= sha1:K1uBEXRuXdpFgAWkC3CIxjoxors= sha256:oFntb90aiJTorITFAomz/OKY/dRE3rHOjrqoJLaPlSc= sha1:O464Xb42BKkdSLBaeIUvDFXHS48= sha256:9skX9gpOFI6NUiEulmTLN+dnadOokf+gpH6v5JybIuc= Xref: csiph.com comp.os.linux.misc:95362 comp.unix.shell:27348 alt.folklore.computers:236675 Lars Poulsen writes: > If we define mainframes a large, very robust systems, they are still > very relevant. Although it may be true that the major technology was > in place before 1990 (non-stop cluster systems, transaction locking > with completion/rollback and strategic redundancy). What you call > customer inertia is also known as vendor lock-in. trivia, after early 70s "Future System" http://www.jfsowa.com/computer/memo125.htm https://en.wikipedia.org/wiki/IBM_Future_Systems_project https://people.computing.clemson.edu/~mark/fs.html imploded, head of POK was convincing corporate to kill the VM370 product, shutdown the development group and transfer all the people to POK for MVS/XA. Endicott eventually acquires VM370 responsibility (for the mid-range), but has to recreate a development group from scratch. I get asked to help with a 16-CPU 370 and we con the 3033 processor engineers into helping in their spare time (a lot more interesting that remapping 168 logic to 20% faster chips). Everybody thought it was great until somebody tells the head of POK that it could be decades POK's favorite son operating system ("MVS") had effective 16-CPU (MVS documents were claiming that MVS 2-CPU support only had 1.2-1.5 times the throughput of single CPU, because of high multiprocessor support overhead, POK doesn't ship a 16-CPU system until after the turn of the century). Head of POK then invites some of us to never visit POK again and directs the 3033 processor engineers, "heads down and no distractions". About the same time, Endicott talks me into helping with ECPS for the 138/148 (also used with 4331/4341), identify highest executed 6kbytes of VM370 kernel execution for re-implementing directly in machine microcode (at 10:1 performance increase, mid-range 370s were avg. 10 native instructions for every 370 instruction). Archived post with initial analysis, 6kbytes accounted for 79.55% of kernel execution: https://web.archive.org/web/20260416141952/https://www.garlic.com/~lynn/94.html#21 After being invited to never visit POK again, I transfer out to IBM San Jose Research on the west coast and worked with Jim Gray and Vera Watson on the original SQL/relational RDBMS, System/R. After Jim Gray left IBM SJR for Tandem (fall1980), he did studies of system availability and outages. He was finding that hardware was becoming much more reliable and outages were shifting to environmental (floods, earthquakes, storms, etc) and people mistakes, needing redundant systems at geographically separated distances. https://courses.cs.duke.edu/spring11/cps210/papers/Gray_computers_stop.pdf https://web.archive.org/web/20260219063547/https://www.garlic.com/~lynn/grayft84.pdf As Jim was leaving, he was foisting off stuff on me including BofA; Research had System/R joint study with BofA and they ordered 60 VM4341s for System/R. Some amount of resistance from STL, IMS and next great DBMS "EAGLE". Was able to do tech transfer to Endicott (under the radar while company was pre-occupied with "EAGLE") for SQL/DS. Then when "EAGLE" implodes there was request how fast could System/R be ported to MVS, eventually released as "DB2" (originally for decision support only). Also when 1st transfer to west coast, I got to wander around silicon valley datacenters (and consolidated HONE was just up the road), including disk bldg14/engineering and bldg15/product test across the street. They had been doing 7/24, prescheduled stand-alone testing and mentioned that recently they had tried MVS, but it had 15min MTBF (in that environment, requiring manual re-ipl). I offer to rewrite I/O Supervisor, making it bullet proof and never fail allowing any amount of ondemand, concurrent testing (greatly improving productivity). I then do an internal research report "I/O Reliability Enhancement" and happen to mention MVS 15min MTBF, bringing down the wrath of the MVS organization on my head. Bldg15 gets the 1st engineering 3033 outside POK 3033 processor engineering (trivia: after 3033s started shipping, 3033 processor engineers start on trout/3090). Testing was only percent or two of CPU, so we scrounge up a 3830 controller and 3330 string and setup our own private online service. Summer 1978, bldg15 also gets engineering E5/4341 (year before 1st customer ship). Jan1979, branch office hears about it and cons me into doing (CDC6600 Fortran) benchmark for national lab that was looking at getting 70 VM4341s for compute farm (sort of leading edge of the coming cluster supercomputer tsunami). Spring 1979, some USAFDC (in the Pentagon) wanted to come by to talk to me about 20 VM4341 systems, visit kept being delayed, by the time they came by (six months later), it had grown from 20 to 210. Also saw large corporations ordering hundreds of VM4341s at a time for installing out in departmental areas (sort of the leading edge of the coming distributed computing tsunami). VM4341s also contributed to HONE system popping up all over the world (and inside IBM, departmental conference rooms becomes scarce, so many converted to VM4341 rooms). -- virtualization experience starting Jan1968, online at home since Mar1970