HP3000-L Archives

April 2004, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tracy Pierce <[log in to unmask]>
Reply To:
Tracy Pierce <[log in to unmask]>
Date:
Fri, 16 Apr 2004 14:05:42 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (75 lines)
I see what you mean; maybe I'm all wet about this?  I agree re your
foundation of sand analogy, but used well, UX is pretty solid these days.

I'll stick to my SWAG of risk-assessment being the reason for the
who's-on-top decision back in '85 or whenever that was; it simply made sense
to stepwise refine from a known-good point toward the future.  [It might
still make sense to do that if MPE were the robust flagship entity it was at
/iX time, but with MPE now being the little guy as well as being very stable
(what changes lately other than eliminating hard-coded size limitations?),
re-building it to run on top of Unix makes much more sense now.  Even if (?
how not?) it has to be largely rewritten, it's the functionality that has to
be reproduced, and the tools for doing that are infinitely better than they
were 20 years ago, and no drivers will be needed for ciper printers, say.)

To put MPE atop Unix (flavor unimportant, really; vanilla preferred), MPE
files would of course have to map to a real UX filesystem, but that can be
very neatly secured by making MPE the sole owner and writer.  From the
MPEShell, you could expect to do all of MPE's its polite stuff like file
types, locking, predictable English commands, etc, all enforced by MPE which
owns all the data.  So what's the maximum file size?  Not your problem!
You'd have to be IN the MPE shell to do any MPE writing, and from there you
could still drop back to the real shell, unable to clobber any MPE files but
able to read them for further UX processes.  Of course I'm missing something
very important, but what?  7980 tape drives?;-)

Tracy Pierce


> -----Original Message-----
> From: Mark Landin [mailto:[log in to unmask]]
> Sent: Friday, April 16, 2004 10:05 AM
> To: [log in to unmask]
> Subject: Re: MPE on HP9000 ?
>
>
>  On Thu, 15 Apr 2004 15:16:45 -0500 (Central Daylight Time), Tracy
> Pierce <[log in to unmask]> wrote:
>
> >the question was "possibility", not "probability", and our
> friend Alfredo
> >tends to answer in the most positive mindset possible.
> >
> >Yes it is possible.  It's even possible that HP's real
> reason for their
> >abandonment without letting go is...
> >
> >MPE would probably fit atop Unix a lot better than the other
> way around.
> >CSY probably always thought so too, but when MPE/iX
> happened, I'm sure it
> >was a lot less risky to put iX features atop MPE.
>
> I don't know that I would agree. We have a Poxis shell on MPE which is
> a lot of what a "UNIX on MPE" would involve. However, there are just
> some facilities that the MPE "kernel" requires that the UNIX kernel
> does not provide. For instance, there is no facility in the HP-UX
> kernel to lock a file. There are a number of user-implemented ways to
> lock a file, but it's really on the honor system ... no locking is
> enforced by the O/S. Shoot, you can delete open files on UNIX from
> underneath people. UNIX doesn't even understand "records" ... just a
> bag-of-bytes.
>
> UNIX really has some weird idiosyncracies that date all the way to
> it's original design. In many ways, it would be a foundation of sand
> on which to build a robust thing like MPE. Either the kernel itself
> would need some extensive reworking, or some of the features that make
> MPE so good would have to be abandoned.
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2