Alfredo says:
>
> [log in to unmask] (Ron Seybold) said:
>
> >No one can doubt there's a new skirt in town. Customers might keep that in
> >mind the next time they're told an operating environment that's different
> >from their own (read: not MPE) will solve all their problems. Down here in
> >Texas, we like to "dance with them that brought you." It can be a lot less
> >costly date.
>
[snip]
>
> Let's go dancing, folks!
>
 
To dance, we must decide what dance to dance:
 
Shall we start by defining a new O.S.  for a 64/128 bit networked (or
distributed) future? HP has already started down the 64-bit Unix path and is
now leaping to catch up on the 32-bit NT/Windows path.  Are we asking them to
take yet another? Or are we asking them to merge one of these paths with a
"new" MPE?
 
A better question might be what is MPE? Eric brought into question the
command and user-account structure.  Others may think the commands,
user-group-account format, and backward compatibility *as* MPE.  Someone
months ago quoted some MPE source code comments that describe what is good
MPE behavior in a program - is this what MPE is to us?
 
Should the new O.S.  be based on a a revised (64-bit, treaded, etc.) MPE
kernal and a redesigned file system (64-bit, suited to trends, simple, but
transaction managed/journaled), with an "MPE" ci and the traditional
file.group.account file structure hung above it, along side a revised HPUX
command shell, and a win32 api (with a 64 to 32 translation layer)?
 
Could we provide MPE user compatibility by mapping login ids to
user.account:system under DCE authentication and home directories to home
group.account:system on the Distributed File System part of DCE?
 
What would we want in a new MPE?
--
-- - - - Speaking for myself and not necessarily anybody else - - - - - -
Richard Gambrell        | Internet: [log in to unmask]
Mgr. Tech. Services     | POT:      504-483-7454     FAX: 504-482-1561
Xavier University of LA | Smail:    7325 Palmetto, New Orleans, LA 70125