thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (05/21/91)
This is it!
Actually, it isn't quite. However, unless there's something HORRIBLY wrong
with this draft, it is the final one that will be sent to HP personnel. The
only thing I hope to see corrected is the occasional typo. Signatures are
now welcome! You should see a related item for "USENET LETTER - SIGS" with
the details.
-- jt --
John Thompson
Honeywell, SSEC
Plymouth, MN 55441
thompson@pan.ssec.honeywell.com
When in danger, when in doubt --
run in circles, scream and shout.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
----------------------------------------------------------------------------
OPEN LETTER TO HP/APOLLO
HEWLETT-PACKARD, AND THE DESTRUCTION OF ITS APOLLO ACQUISITION
Background:
-----------
When Hewlett Packard and Apollo Computer merged in mid-1989, many people 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 been made
obsolete. For Apollo users who need leading-edge workstations, the Series 700
would be an attractive addition to their Apollo networks, but Hewlett Packard is
not providing the Domain Operating System (Domain/OS) for these machines. HP is
also failing to provide for a timely, smooth transition to OSF/1.
Recent entries in the comp.sys.apollo USENET newsgroup have covered a vast and
varied territory. Three major issues have caused concern among Apollo users.
We would like Hewlett-Packard to formally reply to those issues.
Issue 1 : The future of the DN10000 - Problems
----------------------------------------------
Until recently, most owners of DN10000 systems have been assured that HP/Apollo
would provide 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 these assurances turned sour, and recently,
HP announced that there would not be a PRISM-2 upgrade, leaving many of us
holding an expensive white elephant.
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 actually less than two years old, and were marketed as
viable, upgradable systems. Depreciating a one to four hundred thousand dollar
investment in this short a time period is not acceptable. Cutting off the PRISM
upgrades would have been similar to Motorola deciding not to upgrade the 68000
line after its first release, or HP deciding to throw out PA-RISC after one
generation.
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 limits the possibility of Apollo sites purchasing the PA-RISC systems
in the near future. Even worse, 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 a 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 allow us to 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.
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 software release, and that we will
be "taken care of to our satisfaction." Until this issue is resolved
by Hewlett-Packard, these vendors won't be able to clearly define what this
means.
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. Hewlett-Packard's
decision to not port Domain/OS to the new RISC platform implies an extreme
indifference to the needs of its 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.
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.
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, the Apollo display manager with all its capabilities,
and the "automagic" networking provided by Domain/OS. Specific networking tools
include the node-name cataloguer (ns_helper), disk-space monitors (lvolfs -all),
status monitors (ps //nodename, pst -n //node, and dspst -n //node), and
node-configuration monitors (nodestat -c). In acquiring Apollo Computer, HP
gained a team of people who are very familiar with networking issues and
solutions. Hewlett Packard needs to capitalize on this knowledge by providing a
superior set of networking tools for OSF.
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. 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.) There are many opinions on what features are "best" in a
window manager, but the uniformity of commands over the full range of windows
(edit, output, and input) and an easily used, intuitive interface are probably
near the top of most 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 all processes running on an 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.
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. It also must be
noted that there are many HP/Apollo customers who will not be able to begin a
transition to OSF in the near future. These customers need to run Domain/OS,
and will need to have Domain/OS ported to the 9000/700 platform before they will
purchase the new workstations.
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 advanced apabilities to which
Apollo users have become accustomed (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 --
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 when it is not a standard. Extensions to
HP OSF/1 with 'Domain-ism' will be an 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.
Conclusion
----------
Hewlett Packard has again released a top-end workstation with the 9000/700
series product line. Now, it must provide the means for its Apollo customers to
use these workstations in the Domain/OS environment, and provide an upgrade or
transition for the owners of the Apollo DN10000 systems. If we are forced to
move from Domain/OS to HP-UX or OSF without a smooth transition (jumping from
one moving train to another is not 'smooth'), then 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 its
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, so
would we enjoy hearing HP/Apollo's response in this group.
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.)
Signatories
-----------
John Thompson - Design Services Engineer / System Administrator
Honeywell Solid State Electronics Center || Plymouth, MN 55441
thompson@pan.ssec.honeywell.com || (612) 541-2604
Honeywell SSEC has about 70 Apollo workstations, including 3 DN10000s.
I am concerned with all of the issues, as I must maintain a functional
network which meets the H/W and S/W needs of Honeywell SSEC projects.
!!
!! Use this as an example, if you wondered what a signature might look
!! like. Note that it can be truly dull and boring. :-)
!!
!! See a related USENET posting for details on the actual posting of sigs.