> 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.

But not as solid as MPE/IMAGE are, and isn't that our goal? Is an "less
solid" MPE worthwhile?

Look at it this way: for most people, MPE is just a framework to run
IMAGE. It's really IMAGE we are wanting, right? And that's where the
"robustness" demands come from.

> 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.)

There is no technical reason that things like enforced kernel-level
locking, and concepts of records, file types, etc, cannot be added to
UNIX. After all, it's ultimately all ones and zeros. :) But there are
two reasons it's very hard: 1) the expense of such an effort would be
unrecoverable, given the size of the market that an "MPE-friendly" UNIX
rewrite would appeal to, and 2) rewriting the kernel this way means the
kernel isn't really UNIX anymore, and HP-UX/iX gets the dreaded
"proprietary" tag by all the Sun and IBM salesmen on the planet. Of
course we all know that proprietary and open mean different things
whether you are an engineer, an administrator, a programmer, or a
marketing manager, but when it comes to selling a box, the marketing
manager gets to define what that is.
> 
> To put MPE atop Unix (flavor unimportant, really; vanilla 
> preferred), 

No such thing. :) You *have* to pick one. There is no "standard" UNIX.
All UNIX flavors claim to be the One True UNIX, and everyone else's are
envious also-rans.

> 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.  

But this breaks the UNIX tenet that root is God and can do anything to
anything, any time. So which do you do? Lock out root? Or allow root to
do things to MPE files? And as soon as root can do something to an MPE
file, one can assume that eventually it will do something BAD, because
root is too stupid to understand the difference between a circular file,
a message file, a PRIV file, and a spool file.

What would be needed would be an MPEfs (like NFS, CIFS, etc) filesystem
extension to the UNIX kernel. But again, the kernel lacks some very
basic functionality that MPEfs would require. (NFS is a good example of
a file system that tried to extend what UNIX could do. It's been ... 25
years? And you still can't lock a file thru NFS reliably). A filesystem
can be NO BETTER than the kernel it runs on, and the UNIX kernel just is
not robust enough to provide the file system capabilities that MPE (and
by extension, IMAGE) require. 

> 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.  

Who decides when a disk is full? MPE? Or UNIX? 
Who decides when a file was last backed up?

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