[email protected] (Skip Robinson) writes: > The name 'DB2' seems to have followed the 1980s tradition of what I call > 'name bloat', the practice of inflating a moniker in one way or another to > make a product look more mature or more elegant. The paragon in my mind was > dBASE II from Ashton-Tate. There never was a plain old dBASE. The roman > numeral was added from the get-go to make the product seem new and improved. > Moreover, there was never an 'Ashton'. That name was invented because, gosh > darn it, it sounded good hyphenated with Tate, a real person. > > Before DB2 there was precedent for name bloat within IBM. There never was a > plain old 'JES'. The product emerged from the cocoon as JES2. There had been > a predecessor product called 'HASP', which may or may not have been an > acronym for Houston Automatic Spooling Priority, but the name 'J-E-S' was > born complete with suffix. > > Meanwhile there did emerge a 'JES3', but it was not an evolutionary > descendant of JES2. Both products have coexisted, albeit uneasily, for > decades. We used to imagine a JES5 or JES6 (depending on one's arithmetic > proclivity) that would somehow combine the best features of both products, > but it's almost certainly DOA. Likewise, the prospects for a 'DB3' are as > dim as a distant star.
note that VS1 had JES1 (Job Entry Subsystem 1) https://en.wikipedia.org/wiki/OS/VS1 The official names were OS/VS1 and OS/VS2 ... so JES2 originally may have originally been to designate it was for OS/VS2. Long ago and far away, my wife was in the GBURG JES group and was part of the catchers for ASP turning into JES3. She was then co-author of JESUS (JES UNIFIED SYSTEM) document ... which merged the features in JES2 and JES3 that respective customers couldn't live w/o ... for various reasons never saw the light of day. A Fascinating History of JES2 http://www.share.org/p/bl/et/blogid=9&blogaid=238 For the truth we must go back to the mid 1960's. IBM's OS/360 was in trouble. The spooling (wonder where that name came from) support was slow and the overhead was high. Many programming groups independently attacked the problem. ASP, loosely based upon the tightly coupled IBM 7090/7094 DCS, held the lead in the OS/360 spooling sweepstakes. ASP's need for at least two CPU's fit well with IBM Marketing's plans for the System/360. Meanwhile, a group of IBM SE's, located in Houston, developed a different product of which they were justifiably proud. They wanted to popularize it, as they correctly suspected it would be the balm for OS/360 users, increasing the usability and popularity of the operating system, and, not incidentally, furthering their careers. All they needed was the right name! A name which was easy to remember, a name which would draw attention to their product, and a name to distract from the ASP publicity. That name was Half-ASP, or HASP. Naturally, if HASP and ASP were products of two different companies, the FTC would have stepped in to stop such a predatory product name. Regulatory action was prevented, however, because IBM is "one big happy family", believed by many to be larger than the Government. ... snip ... of course officially, the "H" stands for "Houston" https://en.wikipedia.org/wiki/Houston_Automatic_Spooling_Priority then my wife was con'ed into going to POK to be responsible for loosely-coupled architecture ... where she "peer-coupled shared data architecture" ... which saw very little uptake (except for IMS hot-standby) until SYSPLEX & Parallel SYSPLEX ... contributing to her not remaining long in POK (along with the ongoing periodic battles with the communication group trying to force her into using SNA/VTAM for loosely-coupled operation). some past posts http://www.garlic.com/~lynn/submain.html#shareddata as undergraduate in the 60s, I got to make a lot of HASP modifications (I had also been hired fulltime by the university to be responsible for production mainframe systems) ... including implementing terminal support and conversational editor in HASP for a form of CRJE. https://en.wikipedia.org/wiki/Remote_job_entry DB2 may have been because some had hopes that the official new DBMS "EAGLE" might still be able to rise from its ashes ... or it was to designate the OS/VS2 (aka MVS) version of System/R as opposed to the earlier SQL/DS version of System/R (that ran on VM370, VS1, DOS/VSE). trivia: one of the problems with the System/R tech transfer to Endicott for SQL/DS ... was that several enhancements to vm370 had been made to make System/R much more efficient. For various reasons, the Endicott people didn't want to make SQL/DS release dependent on getting enhancements into VM370 ... and so that had to be dropped. -- 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
