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

Are you trying to say you can't crash MPE?  Perfection is always a good
goal.  No, a "less solid" MPE wouldn't be worthwhile in my book.  But if
anything underlying Image running either directly on Unix or on MPE atop
Unix is unstable, it can be adequately addressed.  Disk arrays are more
solid than any 7937 ever was, just use 'em.  Other specifics?

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

If that's all you need, get a Linux PC and use Eloquence; you don't even
have to recode the intrinsic calls (so I understand).  Image is VERY
important, but except for those folks who can't recompile, swapping out
Image for something that works at least similarly would be a piece of cake;
its elegant simplicity takes care of that (ok, adding a semi-automatic
locking read mode would be nice).  If all I had to do without were Image,
Eloquence is a no-brainer.  Granted it's not likely you'll find an e3k NOT
running Image, but that's not nearly the robustness of the entire system.
To be functional for me, I need my good old Cobol programs to be able to
interact with the OS & file system exactly as they always have (with the
possible exception of blowing up after writing the 1024th record;-), my
jobstreams to continue to function as written and beyond 2026, and I need to
be able to spool & schedule in- & output.  That is to say, I need to be able
to take my entire suite of applications, recompile if needed, and run inside
the MPE shell atop Unix as if I were on a 3000, without spending 5 years
converting the HP COBOL to another.

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

You seem to miss my point entirely; please re-read?  In my vision, MPE does
the locking for its own files, and couldn't care less about non-MPE files.
Specifically, MPE (the Ux user) owns all the files below /MPE/.  Now if MPE
provides these nice tools ATOP Unix, they're potentially saleable to every
Unix shop on the planet.  You don't like cron?  Use MPE (or pieces thereof
cloned to also run in non-MPE space).  Don't wanna buy Syncsort?  Use MPE
Sort (which might well turn around and use Syncsort, it doesn't matter - I
need MPE Sort syntax and correct results).  Locking would be enforced by
virtue of the MPE (Unix) filesystem, available only to (root of course, doh,
and) that Unix user known as MPE, which would enforce its own locking
schemes (the same ones it uses now) upon anyone who dares enter the polite
MPEshell.

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

For the purposes of emulating MPE, I believe MPEShell could be written to
run on EVERY Unix; to do so its writers would face the restriction of
avoiding internal use of variant code.  But let's assume I'm dead wrong; you
pick, it doesn't matter, but please have them promise to support their OS
for a few years?

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

Um, don't share root's password?  If you have a stupid root, you don't have
much of a system; I'd be more inclined to share an SM MPE password.  Granted
MPE's politer to MANAGER.SYS than Unix is to root, but rm=purge either way.
As I said before, all those magic mpe file types would be owned, understood,
managed & accessed by mpe.  only.

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

Just not true!  By isolating your interaction with the machine to that done
inside the MPEShell, which guards all your MPE data by being its owner, the
writers of that MPEShell can emulate every old locking scheme ever devised,
or build new ones.   A locking system IS an honor system, but obviously
MPEShell can honor its own rules.  There's no MPEShell-external honor system
needed other than root knowing better than to mess with that filesys and
nobody else gets in.  Oh, and be sure it's dismounted before unplugging the
cpu?

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

uh, the disk array tells Unix, Unix tells MPE, MPE cries to the user via
FSERR i forgot OUT OF USER DISC SPACE.

> Who decides when a file was last backed up?

MPE Store would still work just fine if you want to use it (I would if any
of my MPE apps needed to verify that - they're already written to talk to
MPE).  Emulating the MPE file system would obviously include provision of
space for Store-date, etc.

Next critical overlooked item please?

Tracy (not about to do the write myself, but I'm not tired of the concept
yet by any means, and as far as I can tell, it still holds water) Pierce

ps again, we're talking possible, not probable - who's going to undertake
this project?  OpenMPE seems to want to take the whole thing deeper, all the
way to the hardware.  That sounds great from a run-anything-ever-written
standpoint, but I for one do want the on-the-box tools that have evolved in
the Unix world, right alongside the world I've developed on my 3000s.  Maybe
HP will see (or already has seen) the value and go for it, but not before
they've sold a lot more PCI hardware to those pesky RISC cheapskates who
call themselves customers.  ;-)  lessee, that would be about 2006.  why do
YOU think they're stalling?  not because MPE's worthless.

Have a great weekend, all,

Tracy

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