HP3000-L Archives

June 2008, Week 4

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:
"Peter M. Eggers" <[log in to unmask]>
Reply To:
Peter M. Eggers
Date:
Sat, 28 Jun 2008 14:02:50 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (140 lines)
On Fri, Jun 27, 2008 at 4:49 AM, Craig Lalley <[log in to unmask]> wrote:
> Well, Geert from Ordina Denkart has done it, and it's very good.  it's called MPUX
>
> MPE-UX.

It is good to see that there is already a proof-of-concept that is
actually working.  When I originally presented the idea on the OpenMPE
list, seemed like there were doubts that it would work, doubts that it
was economically feasible, and doubts that MPE could be brought back
from fading into the sunset.

> (Some how, I think Stan was involved)...
>
> But Geert is no longer there.... so what has happened to Ordina-Denkart?
>
> Can anyone respond?   I seriously don't know the answer.
>
> -Craig
>
> --- On Fri, 6/27/08, Jim Phillips <[log in to unmask]> wrote:
>
> From: Jim Phillips <[log in to unmask]>
> Subject: MPE On Linux
> To: [log in to unmask]
> Date: Friday, June 27, 2008, 6:15 AM
>
> On Thu, 26 Jun 2008 17:32:23 -0700, "Peter M. Eggers"
> <[log in to unmask]> wrote:
>
>> What I think could work is this:
>>
>> Use a stripped down and optimized version of Linux to run MPE as a
> service.
>
> Sounds good to me.  Actually it was exactly what I was thinking, or almost - I
> was thinking "Why not modify the Linux kernel to boot into MPE (okay, an
> MPE-like environment)?"  But MPE as a service works for me.
>
> So, who's interested in coding up a MPE environment in Linux?  And where do
> I sign up?

I tried to get the concept going many months ago on the OpenMPE list.
Besides the naysayers, there was a couple of people that could have
been very helpful to success of the project, but couldn't afford the
time.  A few with considerable encouragement, but couldn't help due to
lack of technical ability.   Yet, when asked to provide HP3000 access
or make lists of essential software or lists SL routines or any kind
of non-technical assistance, encouragement suddenly dried up as did my
enthusiasm.

I have some time that I could commit on an ongoing basis, with periods
that I could spend considerable amount of time on the project.  But, I
don't have access to an HP3000, and I can't/won't do it alone.

I would like to see a community supported and developed project,
ending up with an official branded product that is easily verified.
Third party commercial support could provide MPE on full blown server
of workstation Linux.  Third parties could have recommended 3rd party
customized versions that are not officially supported, or if there is
actually a high level of confidence in their ability and product, it
could receive a special branding.  In any case, commercial entities
would be encouraged to provide highend utilities like Robelle's
Suprtool , or services like high level security:  penetration testing,
security consulting, system hardning, etc. (the basic system should
still provide really good and really simple security far beyond
something like Windows in the MPE tradition).  Not trying to put any
commercial entities out of business, and would encourage their
participation in both the community developed basic system and in
creating niche or highend utilities, and of course commercial
applications and systems to run on it.  Should be a win-win for
everyone involved.

To start, I would create a command interpreter and login routine that
is the shell for a Linux user "MPE" that would mimic the MPE's user
login prompt, and an 80% solution for implementing the most important
MPE commands and command options.  Creating, listing, and purging
empty files would be a good first step and a momentum builder.

To start for ease of implementation, the Linux user MPE's home
directory would be akin to a virtual machine map or database, if you
prefer.  I would like to see a 4th level of directory structure added
to MPE:  file.group.account.domain, i.e. ITEMS.DATA.ACME.PROD or
SL.PUB.SYS.TEST -- same rules apply for assumed name parts.  On the
hidden Linux side [of the iron curtain], these files would be
/home/MPE/PROD/ACME/DATA/ITEMS and /home/MPE/TEST/SYS/PUB/SL
respectively.  The file labels for could be put into Linux extended
attributes, but level support has been dependent upon file system
used.  I think the better idea is just (using above example)
/home/MPE/PROD/ACME/ITEMS.labels -- separate simple file:  easy to
code for on the Linux side, and presented normally on the MPE side
with great flexibility going forward.  Temporary files would be
implemented as /home/MPE/temp/PROD/ACME/DATA/ITEMS or as
/home/MPE/PROD/temp/ACME/ITEMS (pros and cons both ways - could be as
system configuration).  System tables, like JMAT, /home/MPE/.jmat, or
in the domain as a virtual machine, /home/MPE/PROD/.jmat .  Tables
that are per user like the JITs:  /home/MPE/PROD/CHRIS/.jit (where
CHRIS is the MPE user).  Down the road, if performance is an issue,
these MPE system tables could be copied to ramdisk, memory mapped, or?
(Linux never seems to be without options).  On the MPE side, all looks
normal and all of the Linux/Posix is hidden and only accessed
indirectly through MPE's PM cap.

In theory, when logged onto Linux as MPE, all should look and act like
MPE.  The window to the underlying Linux should be through SL.PUB.SYS
.  Only system programmers would be modifying or adding routines to
there, and provide normal looking procedures to applications and
utilities.  How to do this simply and elegantly, and still provide for
ironclad security in the finished product, I am still pondering.

This describes an alpha version, that if could be functional in less
than a month could provide enormous momentum to the project.  Once you
are sitting there at an MPE prompt, creating/listing/purging files,
you are going to want to put something in them to display.  The
framework to do so will be there, and most programmers will be hard
pressed to resist the urge add a little magic to SL.PUB.SYS to make it
happen.  Using the Linux development model, maybe a couple of other
programmers with less time or motivation will jump in with
suggestions, bug fixes, or enhancements.  Some official gatekeeper at
some point will anoint some combined effort version golden, and give
it an official stamp of approval (maybe gpg signed, and/or simply
added to an official repository?).  Then someone is going to want to
edit the data in the files, and so hopefully the project begins to
takeoff!

As I stated before, the official version should me supported by a
stripped down version of Linux that just provides the hardware support
for MPE to grow into providing the ultimate RAD (Rapid Application
Development) platform for business IT solutions, that is also quick
and simple to operate.  The best of the Linux options will be vetted
by the community, and provided in a user friendly interface and
platform, MPE.

Running on a full blown Linux distribution should not be much of a
problem, and provides yet another commercial opportunity.

Pete

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

ATOM RSS1 RSS2