Maybe its time to have two lists - one for "Pedantic or Historical Discussions" (POHD) , and one for "Useful Technical Exchange" (UTE) (sorry if these acronyms are taken, I fully expect this thread to blossom to discuss improper usage :-)
A rough count of recent traffic on the "USS" TLA yields well over a hundred posts, whereas only a handful of UTE on z/OS UNIX. Discussing two lists will likely turn pedantic, and since it has probably been discussed before, historical. Unfortunately, many folks (and poor newbies) interested in UTE will just tune out, since a few on list seem to think that POHD == UTE. Kirk Wolf Dovetailed Technologies http://dovetail.com PS> Here's a mildly aggressive idea: prefix your new UTE threads with "UTE:" and as the OP be diligent and respond to any posts on your thread that vector to pedantic or historical discussions with an altered subject line prefixed "RE: POHD:" Note that I have preemptively tagged this thread "POHD:" On Wed, May 4, 2011 at 5:00 PM, Anne & Lynn Wheeler <[email protected]> wrote: > [email protected] (Mike Schwab) writes: >> http://en.wikipedia.org/wiki/IBM_AIX >> IBM wrote TSS/370 in 1980 then VM/IX then AIX/370 in 1988 then AIX/ESA >> until 1999 when it merged into MVS/ESA Open Edition. > > tss/360 was done in the 60s (official system for 360/67) ... was > decommited and lived on as small special project. some of the > single-level-store (paged-mapped filesystem) ideas were picked up for > (failed) future system effort ... misc. past posts mentioning future > system > http://www.garlic.com/~lynn/submain.html#futuresys > > folklore is that after demise of future system, some of the participants > retreated to rochester and did s/38 ... which then morphs into as/400 > > in the 80s, tss/370 got something of a new life ... as base for special > bid mainframe unix for AT&T ... stripped down tss/370 kernel (SSUP) with > AT&T doing unix interfaces to the SSUP kernel interface (in some sense > this is somewhat analogous to USS for MVS). this was competing with > Amdahl's GOLD/UTS unix internally inside AT&T. > > AIX/370 (in conjunction with AIX/386) was done by palo alto group using > the unix-like LOCUS done at UCLA. This was similar but different from > the unix-like MACH done at CMU ... which was used by a number of vendors > including NeXT and morphs into current Apple operating system after Jobs > returns to Apple. AIX/370 morphs into AIX/ESA. > > The "argument" for (Amdahl) UTS under vm370, aix/370 under vm370, > tss/370 ssup, and vm/ix (on vm370) was that the cost to add mainframe > RAS&erep to unix was several times larger than the base, direct, > straight-forward unix port (running under vm370 &/or tss/370 leveraged > the already existing ras&erep support w/o having to re-implement > directly in unix). This was aggrevated by field service stand that it > wouldn't service/support machines that lacked mainframe RAS&erep. > > I ran internal advanced technology conference in '82 ... and some of the > presentation were about VM/IX implementation ... old post reference: > http://www.garlic.com/~lynn/96.html#4a > > Palo Alto group had also been working with Berkeley to port their > unix-like BSD to mainframe ... but they got redirected instead doing a > PC/RT port ... released from ACIS as "AOS" ... as an alternative UNIX to > the "official" AIXV2. > > The wiki page says much of the AIX v2 kernel was written in PL/I. The > issue was that the original "displaywriter" was based on ROMP, cp.r, and > PL.8 (sort of pli subset). Redirected to the unix workstation market > required unix&C (all being done by the company that had done pc/ix and > had been involved in vm/ix). For the internal people, a project called > VRM was devised ... a sort of abstract virtual machine layer ... to be > done by the internal employees trained in pl.8. The claim was that the > combination VRM plus unix port to VRM ... could be done in shorter time > and less resources than unix port directly to ROMP hardware. The exact > opposite was shown when the palo alto group did the BSD port direct to > ROMP hardware (for "AOS"). VRM+unix drastically increased original/total > development costs, life-cycle support costs and complicated things like > new device drivers (since both non-standard unix/c device driver to VRM > interface as well as VRM/pl.8 device driver had to be developed & > supported). misc. past posts mentioning 801, romp, rios, pc/rt, aixv2, > aixv3, power, rs/6000, etc > http://www.garlic.com/~lynn/subtopic.html#801 > misc. old email mentioning 801 > http://www.garlic.com/~lynn/lhwemail.html#801 > > Besides various other issues, the AIX wiki page skips over the whole > generation of OSF > http://en.wikipedia.org/wiki/Open_Software_Foundation > and the "unix wars" > http://en.wikipedia.org/wiki/UNIX_wars > > Project Monterey > http://en.wikipedia.org/wiki/Project_Monterey > > skips over the whole cluster scaleup after IBM bought Sequent and > support for Sequent's 256-way SCI-based Numa-Q. Recent posts in > (linkedin) "Greater IBM" (current & former IBMer) discussion > http://www.garlic.com/~lynn/2011d.html#7 IBM Watson's Ancestors: A Look at > Supercomputers of the Past > > the sequent wiki ... mentioned in the above post ... used to be somewhat > more caustic about sequent being dropped shortly after the sponsoring > executive retired: > http://en.wikipedia.org/wiki/Sequent_Computer_Systems > > as noted in the "Greater IBM" post ... at one time, IBM had been > providing quite a bit of funding for Chen's Supercomputer ... Sequent > later acquires Chen Supercomputer and Chen becomes CTO at Sequent ... we > do some consulting for Chen (before Sequent purchase by IBM). > > Part of the speculation for IBM's purchase of Sequent was that Sequent > was major platform for some of the IBM mainframe simulator products. > > much of the "posix" (aka unix) support in MVS during the first half of > the 90s was sponsored by the head of the disk division software > group. in the late 80s, a senior disk engineer got a talk scheduled at > the internal, annual, world-wide communication group conference ... and > opened the talk with the statement that the communication group was > going to be responsible for the demise of the disk division (because the > strangle-hold that the communication group had on datacenters). Large > amounts of data was fleeing datacenters to more distributed computing > friendly platforms. The disk division had attempted to come out with > traditional products to address the problem ... but they were constantly > blocked by the communication group. As a result, there were doing all > sorts of things "outside-the-box" to try and work around the > communication group's roadblocks. the head of the disk division software > group would periodically ask us to consult on some of the efforts. > > for other drift, recent thread in comp.arch about tss/360 supported > "position independent code" (i.e. possible to directly map a disk > image into virtual memory at any arbitrary virtual address w/o having to > perform any link-edit modifications to the contents of that image) > ... and the horrendous problems attempting to do anything similar using > anything from the os/360 genre: > http://www.garlic.com/~lynn/2011f.html#76 PIC code, RISC versus CISC > also referenced: > http://www.garlic.com/~lynn/2011f.html#79 DCSS ... when shared segments were > implemented in VM > > misc. past posts mentioning (tss/370) ssup: > http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development > Philosophy > http://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture > and compiler support > http://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns > http://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware > http://www.garlic.com/~lynn/2005s.html#34 Power5 and Cell, new issue of IBM > Journal of R&D > http://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard > http://www.garlic.com/~lynn/2006g.html#2 The Pankian Metaphor > http://www.garlic.com/~lynn/2006m.html#30 Old Hashing Routine > http://www.garlic.com/~lynn/2006p.html#22 Admired designs / designs to study > http://www.garlic.com/~lynn/2006t.html#17 old Gold/UTS reference > http://www.garlic.com/~lynn/2007.html#38 How many 36-bit Unix ports in the > old days? > http://www.garlic.com/~lynn/2007b.html#3 How many 36-bit Unix ports in the > old days? > http://www.garlic.com/~lynn/2007k.html#43 John W. Backus, 82, Fortran > developer, dies > http://www.garlic.com/~lynn/2007m.html#69 Operating systems are old and busted > http://www.garlic.com/~lynn/2008e.html#1 Migration from Mainframe to othre > platforms - the othe bell? > http://www.garlic.com/~lynn/2008e.html#49 Any benefit to programming a RISC > processor by hand? > http://www.garlic.com/~lynn/2008l.html#82 Yet another squirrel question - > Results (very very long post) > http://www.garlic.com/~lynn/2008r.html#21 What if the computers went back to > the '70s too? > http://www.garlic.com/~lynn/2010c.html#43 PC history, was search engine > history, was Happy DEC-10 Day > http://www.garlic.com/~lynn/2010e.html#17 Senior Java Developer vs. MVS > Systems Programmer (warning: Conley rant) > http://www.garlic.com/~lynn/2010e.html#72 Entry point for a Mainframe? > http://www.garlic.com/~lynn/2010i.html#28 someone smarter than Dave Cutler > http://www.garlic.com/~lynn/2010o.html#0 Hashing for DISTINCT or GROUP BY in > SQL > > -- > 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: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
