Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!agate!ucbvax!ELROND.SSEC.HONEYWELL.COM!thompson From: thompson@ELROND.SSEC.HONEYWELL.COM (John Thompson) Newsgroups: comp.sys.apollo Subject: Future of Domain/OS (on new RISC boxes) Message-ID: <9011291948.AA06247@pan.ssec.honeywell.com> Date: 29 Nov 90 19:48:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 74 First -- sorry to any people who are on the Mentor list as well as comp.sys.apollo. I think it's applicable, though. The December, 1990 _Workstation_ magazine has an article on OSF, the new RISC boxes, the future of Domain/OS, and other miscellaneous news sprinkled within. In it (along with the _BAD_ news about OSF only being on the PA-RISC and 9000/400 nodes (I assume they missed deadline with the "generous" addition of the DN5500)) they have the original and new RISC strategies listed. Without going into the gory details, the original plan had OSF/1 available for both current RISC platforms (DN10000 and 9000/800) in 1989, Domain/OS ported to the 2nd generation HPPA system in 1990/91, and HP-UX, OSF, and Domain/OS on the 3rd generation machines (1992/93). The current plan has several modifications, besides corrections of timeframe (I don't know about everyone else, but in my opinion, there's "lies, damn-lies, benchmarks, and release-dates," in that order). Again, basically, they dropped Domain/OS from the 2nd generation HPPA ======= ========= ==== === === ========== machine, dropped OSF from the DN10000 (this is one of the things they reversed, I think?), changed a "definite" recompile-and-run from the DN10000 -> 3rd generation RISC into a "maybe" recompile-and-run, and dropped Domain/OS from the 3rd generation RISC platform. ======= ========= ==== === === ========== Now, I like to think that I'm a reasonable guy. I understand that hardware depreciates at about 1/2 the speed that it should, since Corp. policy and reality are not in alignment. I understand that software is always written to push the capabilities of the most powerful machine available. I understand that O/S's become obsolete. I understand that OSF is a wonderful system that will make all my wildest dreams come true. ;-) However, I also am responsible for a Mentor Graphics network. I understand that Mentor Graphics has a large investment in Domain/OS and Apollo in general. I also understand that Mentor decided to support the Sun platform with release 8.0 (or sometime after that) of their software, mainly because of customer demands. I understand that, if HP/Apollo decides to stay with their decision to drop Domain/OS from new systems, Mentor may decide to support the Sun first and the HP/Apollo platform second. I understand that, should this happen, I will have to choose between accepting delays in software release or throwing out the Apollos and replacing them with Suns (yuck!) HP/Apollo (Bill Kelly, s/w mktg mgr for Apollo Sys. Div. specifically), says that "The reality of it is that OSF will have the functionality of Domain, so why would you implement Domain again?" I believe that the previous paragraph answers that. Third party software vendors (and Mentor is a HUGE one for Apollo) will ask the same basic question, but turn it around: "Domain has all the functionality that we need; why should we port our code to OSF?" I realize that Domain/OS will die . I don't think that HP/Apollo should take it out back and shoot it, lest they end up missing, and shoot themselves instead. As an afterthought, in the same article, they also say that other products to "help HP/Apollo users feel at home under OSF/1 will include Task Broker, NetLS and NCS 2.0." Pardon my asking, but isn't Task Broker an HP-UX product that was ported to Domain/OS? Seems to me that a product that uses TCP/IP services to shuffle data around will not make me feel like I'm on a Domain/OS system (even if it is a fine product). -- jt -- John Thompson (jt) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com As ever, my opinions do not necessarily agree with Honeywell's or reality's. (Honeywell's do not necessarily agree with mine or reality's, either)