[email protected] (Jesse 1 Robinson) writes: > The name change was much bandied about at SHARE in Providence. I for > one have gotten over my indignation and am ready to move on. If you > really want to be offended by an assault on the sensibilities, how > about the fact that there never was a D(bee)1? The product was spawned > in an era where calling anything '2' gave it a veneer of > respectability as if it were a new and improved version of some > mythical precursor. That was implicitly fake news, which we now know > is reprehensible skullduggery.
the original sql/relational implementation done on vm/145 at san jose research in bldg. 28 on main plant site (before almaden was built up the hill). past posts http://www.garlic.com/~lynn/submain.html#systemr the "official" next generation DBMS was code named EAGLE (DB1?). while the corporation was preoccupied with EAGLE, we managed to do tech transfer to Endicott and get it out as SQL/DS. Then when EAGLE imploded, there was requests about how fast could sql/ds (system/r) be ported as MVS. This was eventually released as DB2 originally for decision support *ONLY*. 1995 System/R reunion http://www.mcjones.org/System_R/ HTML version http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95.html Some EAGLE reference http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-System.html#Index164 from above: Eagle was an IMS successor; it was going to do everything. And they were very worried about path lengths. So there had been something in IMS called TP1. But TP1 was more of a general characterization; ET1 was a specific program. And then Jim wrote all this stuff down in an article that he published in Datamation. It had Anonymous et al. or something like that as the author[ ... snip ... When Jim leaves for Tandem, he palms off some amount of stuff on me releted to System/R as well as consulting with the IMS group. later we were doing cluster scaleup for rs/6000 ha/cmp ... working with oracle, ingres, sybase, etc for commercial scaleup and national labs for scientific scaleup. for cluster scaleup, the issue was ibm's RDBMS cluster was mainframe only (loosely-coupled). These other vendors had open system source base that also supported DEC VAX and DEC VAX/Cluster. I did a cluster scaleuup distributed lock manager that emulated the DEC VAX/Cluster semantics ... making it easier for them to port to HA/CMP. The mainframe DB2 group started complaining that if I was allowed to go ahead, it would be at least 5yrs ahead of them. This is reference to Jan1992 meeting in Ellison's (Oracle CEO) on cluster scaleup http://www.garlic.com/~lynn/95.html#13 Within a few weeks of the above meeting, cluster scaleup was transferred, announced as IBM supercomputer for numeric/scientific *ONLY*, and we were told we couldn't work on anything with more than four processors ... some old email for the period http://www.garlic.com/~lynn/lhwemail.html#medusa posts mentioning ha/cmp http://www.garlic.com/~lynn/subtopic.html#hacmp Trivia: one of the oracle people mentioned in the Ellison cluster scaleup meeting claims he was the primary person when he was at IBM, doing the SQL/DS tech transfer to STL (now SVL) for port to MVS (to become DB2). Totally other trivia: in the wake of being told we couldn't work on more than four processors, we leave IBM. Later two of the other Oracle people in the Ellison cluster scaleup meeting are at a small client/server startup responsible for something called the "commerce" server. We are brought in as consultants because they want to do payment transactions on the server. The startup had also done some technology called "SSL" they wanted to use ... the result is now frequently called "electronic commerce". -- 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
