thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (05/14/91)
It's second draft time! I received a fair amount of support and comments concerning the first draft, ranging from wrong-words/typos thru grammar to hard-info comments. All of these have been welcome, and I feel that they were all important. Please do the same with this draft. Hopefully, there will be fewer things to complain about. I also hope that something you thought absolutely essential hasn't been edited out. If so, put in a plug and a reason, and we can see about adding it back. :-) I still have some personal comments/questions that are prefaced with a set of bangs (!!). These are still not intended to be part of the letter. In fact, I'm finding the letter to be wordy and verbose. :-) If people can see simple ways to cut back, I will certainly entertain the idea. When sending edits, please send enough context to make it clear. When sending comments, please do the same. When sending opinions, please be clear. Please do _NOT_ include the entire draft in mass postings. The last thing we need is to have everybody listing out the whole draft, and posting it back on the net. :-( by the way, I'd like to convert this to a final draft by the 20th of May, since time is definitely of the essense. Sometime in there we'll start collecting signatures too (note the bottome of the draft for more on that). Hopefully, we can get this out before the end of the month. With Memorial Day messing up the U.S. for a while, that means 'get active'. Before the draft starts, an English lesson, and a public apology. I got an edit from Dave Paschich concerning "its" and "it's" -- >> "It's" is a contraction of "it is". "Its" is the possessive form of "it." >> It's the world's most common grammar mistake, but one which drives me >> absolutely up the wall. I tried to send to Dave on this, and failed (couldn't figure out a path). He is, of course, absolutely correct. What's worse is that I know this. What's worst is that I am driven up the wall and across the ceiling when others do it, and I did it in capital letters, centered, to people throughout the world. I apologize. Mea magna culpa. -- jt -- John Thompson (I'M STILL ENGAGED!!! -- however, I won't broadcast it any more) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com (129.30.60.41) ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- <draft start> OPEN LETTER TO HP/APOLLO: DRAFT #2 HEWLETT-PACKARD, AND THE SLAYING OF ITS APOLLO ACQUISITION !! Note that it's not "it's" any more! :-) !! I got several comments on the inflammatory nature of this title. !! However, many still voiced agreement. I would like to find a more polite !! way of saying this same thing -- suggestions? Background: ----------- When Hewlett-Packard and Apollo Computers merged in mid-1989, there were many people who voiced doubts about the continued viability of the Apollo CISC and RISC platforms. HP/Apollo made many presentations stating that there would be continued, long-term support for Domain/OS on current and future merged platforms. HP/Apollo claimed that there would be second generation RISC platforms for both PRISM and PA-RISC, before a merged RISC platform running Domain/OS, HP-UX, and OSF was released in 1992 or 1993. With the announcement of the HP 9000/700 series and the cancellation of PRISM-2, the DN10000 system has become obsolete. For Apollo users who need leading-edge computer speed at affordable prices, the Series 700 would be a very attractive addition to their Apollo computer clusters, if it ran the Domain Operating System (Domain/OS). !! In general, this paragraph's content was kept, but the phrasing was made !! more readable, and less incendiary. Recent entries in the comp.sys.apollo USENET newsgroup have, as usual, covered a vast and varied territory. Three issues, in particular, have caused concern among Apollo users. We would like Hewlett-Packard to formally reply to those issues. !! A preposition is not something to end a sentence with. :-) !!Changed 'Topic X' to 'Issue X' below, to keep in synch with above terms. Issue 1 : The future of the DN10000 - Problems ---------------------------------------------- Until recently, most owners of DN10000 systems have been assured that there would be ongoing upgrades to the series. When it was first introduced, the DN10000 took the lead in workstation speed and cost-effectiveness. At that time, the sales literature made the explicit claim of "PRISM designed to triple performance every two years." The performance of the HP 9000/730 demonstrates that such a claim was technically possible. However, in October 1989 HP unveiled the new PRISM CPU and announced a speed increase of only a factor of two. Recent announcements by third-party software vendors concerning their future support of the PRISM platform made us nervous, but still HP/Apollo was promising the PRISM-2 CPU upgrade, that would bring the systems back in line as a high-end compute server. Eventually, though, these assurances turned sour, and recently, HP announced that there would not be even a PRISM-2 upgrade, leaving many of us holding an expensive white elephant. !! General opinion was 'no-quotes' from magazines etc. Although the DN10000 series was released almost three years ago, and can therefore be called a mature (if not obsolete) technology, many of the systems in place are only less than two years old. Depreciating a one to four hundred thousand dollar investment in this length of time is not acceptable. Cutting off the PRISM upgrades would have been similar to Motorola deciding not to develop their 68040, or HP deciding to throw out PA-RISC after one generation. !! I originally had (and intended to have) '68010'. I was trying to show the !! absurdity of tossing the family out after the first member. Perhaps the !! 68040 is more apt, though, because of the delays that Motorola had. We fully realize that HP needs to merge their two RISC lines, just as they have (very successfully) merged the CISC lines with the 9000/400 series nodes. However, a merger of lines implies that both original products will contribute, and that the end product will be a viable replacement or upgrade to either line. This is not the case with the DN10000 and the 700 series lines. The current incarnation of the 700 series system can not run in the Apollo Token Ring. Few companies can blithely recable their entire building, and this therefore limits the possibility of Apollo sites purchasing the PA-RISC systems in the near future. Even worse, though, the 700 series nodes cannot execute code written for the DN10000 (or other Apollos) even after recompilation (unless it was code that would run on any "vanilla-Unix" type platform. It is, bluntly, a Hewlett-Packard node, and not an HP/Apollo node, as advertised. Issue 1 : the future of the DN10000 - Solutions ----------------------------------------------- At minimum, we need to have a replacement path provided to move from the DN10000 systems to the series 700 machines. If HP/Apollo were to offer a free, equivalent-power upgrade to its DN10000 customers, at least some of us would be able to transition from one to the other. This would not, however, satisfy the needs of many users who, for one reason or another, are restricted to Domain/OS for an extended period. A better plan would be for HP/Apollo to make an PA-RISC CPU board for the current DN10000 systems, so that we can still utilize the disks, memory, and other peripherals that are on our current systems. The DN10000 system is a very elegant parallel processing system. The single-CPU solution that the 700 series offers is not sufficient for those of us who have single-node software licenses, but wish to run several jobs in parallel (and at full speed). A multi-CPU PA-RISC system in a DN10000 would be helpful in many respects. It would let us utilize internal disks and tape drives currently in the DN10000, and it would provide a partial fulfillment of Hewlett-Packard's commitment to the DN10000 series. This would not satisfy all of our requirements, but would provide a minimum response to our needs. It would also provide a basis for the first multi-processor, second-generation PA-RISC system. Making an Apollo system upgradable to a parallel PA-RISC system might also convince us that HP/Apollo is serious about making PA-RISC an Apollo as well as an HP solution. !! I have expanded this section to reflect our requirements more closely, !! rather than stating what any half-hearted marketing plan could do. Several companies are waiting for responses from their software vendors on the resolution of this issue. Mentor Graphics has stated that they will not support the DN10000 with their next s/w release, and that we will be "taken care of to our satisfaction." Until this issue is resolved bye Hewlett-Packard, these vendors won't be able to clearly define what this means. !! I want this here, to stress the importance of timeliness, but I'm not sure !! that it flows well here.... Issue 2 : Support of Domain/OS - Problems ----------------------------------------- Even more critical to our needs than a particular hardware platform is a reliable, supported operating system and software environment. The O/S group within Apollo has almost always managed to provide extensive backward compatibility within Aegis and Domain/OS. Indeed, the entire Apollo network concept is based on transparency of the network and of the individual machine. When the DN10000 was introduced, there were concerns about the transparency possible between RISC and CISC machines on the same network. Basically, people doubted that Domain/OS would be the same on both platforms. Apollo did a very impressive job of making the differences minimal. The O/S installation tools themselves were made into compound executables (cmpexe). If a site had a single DN10000 with no media device, there wasn't a problem; the administrator could simply install the software using another node's tape drive. The O/S and other Apollo software could be merged together to form cmpexe objects for many of the products. Although it was not glamorous, one site actually booted a DN10000 diskless off a DN3000 in order to repair and reload the DN10000's disks without continually booting from cartridge tape. The benefits from this hardware transparency are obvious -- programs written for the CISC nodes could be ready to run almost immediately, and show a tremendous increase in performance; the current file systems could be accessed in a transparent, logical, and consistent manner; client-server Domain/OS programs could exchange information just as easily between the CISC and RISC platforms as they had before in a CISC <-> CISC exchange. The HP Series 700 workstations, however, will not support Domain/OS. Moreover, the initial release will not support OSF/1. Until OSF/1 becomes stable on the PA-RISC system, and applications are ported to OSF/1, the only operating system that could be used is HP-UX. However, HP-UX does not interact with Domain/OS better than any other vendors' Unix implementations. The learning-curve for an operating system is at least a year, yet HP-UX would be used at Apollo sites for no more than two years. This creates an unacceptably high personnel cost for system administration. Even if it weren't, the lack of an acceptable level of interaction between Domain/OS and HP-UX makes it almost impossible for many Apollo networks to include the new 700 series workstations. Issue 2 : Support of Domain/OS - Solutions ------------------------------------------ Ideally, we need to have the 700 series workstation run Domain/OS, in an Apollo Token RIng (as well as in an ethernet) environment. Whether it is true or not, Hewlett-Packard's decision to not port Domain/OS to the new RISC platform implies an extreme indifference to the needs of their Apollo customers. According to rumor, HP/Apollo engineers have already ported at least part of Domain/OS to the PA-RISC architecture. If this is true, a dedicated, concerted effort might still be able to produce a Domain/OS release that would allow us to transition to the next generation RISC platform, either as the 700 series or as CPU upgrades to the current DN10000 systems. !! Still looking for confirmation / refutation.... Failing this, we need to see an intensive effort to make OSF/1 available and stable as an O/S platform, and immediate modifications made to Domain/OS to allow interoperability between the current Domain/OS systems and OSF/1. A minimal level of interoperability would include the registry services, proper file-sharing (in its current state, NFS is not acceptable to a Domain/OS user), and at least limited inter-system status information (the Unix remote shell 'rsh' is also not acceptable to most Domain/OS users). These 'hooks' must be made available in the immediate future, not in late 1991 or in 1992. With the useful life of a workstation continually decreasing, it will make little sense for us to purchase systems that are (technology-wise) a year old. !! The comment was made that we shouldn't ask for Domain <-> HP-UX hooks, !! because they might give them to us! What we _do_ need is Domain <-> OSF !! hooks, and we need them NOW! Issue 3 : The transition to OSF - Problems ------------------------------------------ OSF is being touted by HP/Apollo (and admittedly by others as well) as being the latest, greatest, standardest operating system to come around. HP is also saying that it will have all the nice features that make us like Domain/OS so much. Unfortunately, when pressed, it comes out that OSF will not have many of the 'Domain-isms' that endeared Apollo to us in the first place, and that kept us with Apollo all this time. These include (but are certainly not limited to) file-typing, user-definable filetypes, PADs, truly transparent file systems, "automagic" networking, and the Apollo display manager (with all it's capabilities). HP-VUE is evidently a very impressive graphical interface, but it will need these Domain features before many Apollo users will willingly transition to it. These include the file-backed output transcripts, 'cooked' input (as an optional input mechanism) with infinite undo, the ability to drive the DM with text input from the <Command> prompt, and the ability to bind keys to those same commands. (For example, it is easy to bind a key to go into the output pad, search up for the last 'cc' command, paste that command into the input pad, and execute the line. This particular example can be semi-duplicated with the 'history' mechanism, but many other commands cannot be imitated at all.) Hewlett Packard representatives do not recognize that the qualities of Domain/OS are often significantly better than OSF/1. They describe OSF/1 as having Domain tools, such as Task Broker. In point of fact, Task Broker is an HP-UX tool ported to Domain/OS, that can require (automatic) file transfers to the remote system. In contrast, all files in a Domain/OS cluster are available to any node. After hearing that, we begin to question what other parts of OSF may be mis-represented. HP also does not seem to fully appreciate the features of the Apollo display manager (DM) that they are replacing. Although there are many opinions on what features are "best" in a window manager, the uniformity of the commands over the full range of windows (edit, output, and input) is probably near the top of many people's lists. The DM is not just a window manager with an editor attached; it is a consistent, well designed manager of the input and output devices for the Apollo workstation. Many of its capabilities have been mentioned earlier, but it is important to stress that the consistent behavior of the DM throughout the entire user interface is extremely important. !! Any OSF guinea pigs out there want to comment? !! Any other relevent problems? Issue 3 : The transition to OSF - Solutions ------------------------------------------- Most of us have come to the conclusion that we will need to transition to OSF. HP/Apollo could ease this transition by providing a Domain/OS release in the immediate future that would allow interaction with OSF. Coupled with a stable OSF release on the 700 series, this might even provide an acceptable alternative to porting Domain/OS to the PA-RISC platform. If full interaction is not possible in the immediate future, an incremental implementation starting with registry and file services would allow some of us to begin transitioning, and would provide assurance to the rest of us that we will not be abandoned. It must be stressed that this interaction with Domain/OS must be provided to allow for a transition, and that it must be provided in a timely fashion, since this is an industry where even six months can obsolete hardware. Extensions to the OSF solution are essential to the success of HP/Apollo. As a minimum, HP/Apollo should offer an extended Motif and HP-VUE for its OSF product. These extensions would provide the DM capabilities that Apollo users have become accustomed to (see the above section), and would result in an added-value product that would be better than the standard, while still embracing the OSF standard. HP/Apollo should also investigate the modification of the DM to run within OSF. At SR10.3, the DM was modified to be "Inter-Client Communication Conventions Manual (ICCCM) compliant, which means it is a fair X client." This implies that extensive work has already been done to ensure that the DM can function in an X environment. This should ease any transition to an OSF operating system as well. Ongoing support is also needed for the current hardware. HP/Apollo must support the keyboards that are currently in use. HP/Apollo must also continue to provide keyboards with the 'Domain' keys on them (with appropriate bindings). A very useful capability of Apollo systems has been the extensive, user-definable keyboard they have provided. Although productivity is often enhanced by the use of a mouse, it is very possible to run Domain/OS without ever removing your fingers from the keyboard. This is possible due to the vast key-definition capability provided by the DM. The current HP/Apollo justification for not augmenting OSF's abilities is that "standard is better" is unacceptable. It is the capabilities of the machine, and the user environment, that are most important in making purchases. Providing a set of tools that is no better than Dec's or IBM's will provide no incentive to stay with HP/Apollo, or even with OSF. Providing full interoperability with other OSF machines, while providing added capability when interfaced with other HP/Apollo systems, and/or providing additional tools in HP/Apollo's OSF offering will give us the justification we need. Standards are essential, but better is better even it is not a standard. Extensions to HP OSF/1 with 'Domain-ism' will be a added value to HP's workstations in the market place and distinguish Hewlett-Packard from the rest of the OSF crowd. Standards should never be used as an excuse for not providing the best tools. !! Anything else to add? Conclusion ---------- HP/Apollo has again released a top-end workstation with the 9000/700 series product line. Now, they must provide a timely mechanism to let their Apollo customers use these workstations in their current environment. If we need to move from Domain/OS to HP-UX or OSF without a smooth transition (jumping from one moving train to another is not 'smooth'), that we will start from scratch in our workstation vendor search. Without Domain/OS (or interoperability with Domain/OS), HP's machines are just like anyone else's. Unless we can depend on HP/Apollo to support our transitions, we will not be able to rely on their products at all. We hope that Hewlett-Packard will accept this critique in the same positive spirit with which we have prepared it, and will act quickly to fulfill our three requests. Individual replies are not expected: as we have used the USENET as a public forum for the gathering of this information, we would we enjoy hearing HP/Apollo's response in this group. !! Again, almost verbatim from USENET LETTER 1. Disclaimer ---------- This document was written with input from numerous people. While all signatories support its aims and general thrust, not everyone is necessarily in complete agreement on the details of all points. The views expressed are those of individuals, and do not in general represent official policy of the institutions or companies of which the signatories are members. (This should not be taken as a license to discount those views, however: in the long run the individual views of computer users and system managers tend to affect or even determine institutional computing policy and purchasing decisions.) !! (Yes, I grabbed this almost verbatim from the first USENET letter.) !! I moved conclusion before the disclaimer, because I'm used to the !! disclaimer being the first or last thing. However, I'm worried about !! lessening the impact of the conclusion by putting things after it. !! Comments? Opinions? Signatories ----------- !! Start working on them some more. Format should be as before, made up !! of no more than 6 lines of no more than 78 chars. Please list who you !! are, who you work for, and (optionally) a brief statement of what sort of !! systems you have. If there's still room, a quick blurb on what parts of !! this are particularly important to you might be nice. !! If you're willing to collect and forward signatures, please send mail !! to me. Please list in the message where you're at, since the return !! address can get munched, and isn't always enlightening. !! DON'T FORGET TO SEND EDITS, TOO, THOUGH!!!! <End of draft>