Mike Belshe writes:
>Craig D. Lansing ([log in to unmask]) wrote:
>: The 9000's tend to run with
>: less operator intervention for longer periods of time.
 
>I disagree with this completely.  One of the things MPE customers like
>most about the HP3000 is how little operator intervention is required.
>(Can someone back me up on this?)
 
The last time I managed a commercial environment, about ten years ago,
we had to restart the computers every couple of months or so. More
recently, our development environment, one system has been up for
about nine months (it was last restarted sometime in April), and the
other for three (and before that, for six). Both systems ran lights-out in
empty office space for well over a year before we moved into our new
facility; they were visited about every six weeks. I don't remember the
restart schedule, but you get the idea.
 
Another data point: MPE had a bug at one point in time that would cause
it to crash every 24 days, like clockwork. In fact, it _was_ clockwork;
the system timer, which counts milliseconds since the last restart,
overflowed causing an unexpected arithmetic trap in an interrupt routine.
That bug was first found in (I think) 1978. MPE has a _long_ history of
reliability.
 
>As an example of reliability, consider the UNIX file system.  NFS is
>particularly unreliable (and used on most UNIX systems).  It uses UDP as
>its underlying transport, allowing packets to be lost, delivered out of
>order, truncated, or even changed!  Even a local UNIX file system will
>often be corrupted when a kernel panic occurs because a dirty superblock
>can be left unflushed in memory.  That WON'T HAPPEN on an MPE box.  MPE
>goes through a lot of work to maintain filesystem integrity even through
>an unexpected crash.  UNIX will gladly trash your filesystem if you just
>forget to call sync().
 
Unix is a standard that lackes standards. Of course it's easier to
program a Unix box. On MPE, you have to worry about checking for
successful completion of operating system calls, dealing with unexpected
user input, checking returns from memory allocation routines, generating
detailed diagnostic messages, providing some kind of on-line help,
warning the user if they're about to do something dangerous,
and a bunch of other things. You have to do it because HP has set the
standard, and they provide all that in their own software. On Unix,
nobody expects any of those things, so there's no real point to doing
them.
 
There's nothing intrinsically wrong with Unix; it's a reasonably
well-designed multitasking operating system. Even in the Unix-Hater's
Handbook, people could find very few things to dislike about the
design. What everyone complained about was the implementation:
utilities that mindlessly trash data; a file system that sometimes
keeps files straight and sometimes doesn't; the lack of consistency
(indeed, the essential randomness) in the user interface; and worst of all,
the blithe unconcern about the need to fix any of it.
 
That's why I'm hopeful about MPE iX's POSIX implementation. It just might be
the best of both worlds: an industry-standard API to an operating system
with the inherent reliability and attention to detail that has characterized
MPE in the past. In short, a standard interface to an operating system
with standards.
 
-- Bruce
[log in to unmask]