In message <[log in to unmask]>, 
Peter M. Eggers <[log in to unmask]> writes
>For those that I have bored to tears with the long version, here is the
>short version:
>
>
>Goal:
>
>Maintain MPE as a top, if not THE top business application development and
>operation platform.

Reality:

Keep MPE alive, just about, for those who won't or can't leave it, even 
if all the existing hardware that it runs on becomes no longer available 
and/or economic to run. Please a few hobbyists.

>Current Situation::
>
>The full source code set of MPE (SL.PUB.SYS, IMAGE, VIEW, system utilities,
>etc.) to create a viable working MPE platform, is a huge mountain of
>technical code requiring substantial investment and technical expertise just
>to maintain in a state that is far from state-of-the-art and falls behind
>farther with each passing day.  A huge investment in time and money would be
>required to bring it up-to-date, yet the grossly insufficient market share
>that it has continues to shrink with no foreseeable case for a turnaround in
>sight.

First define 'bring it up to date'. And then settle for 'stabilisation' 
(i.e. freezing). It does at the moment what everybody does with it at 
the moment.

>Proposed Solution:
>
>Run MPE as an easy-to-use and rapid application development platform layer
>atop a hidden Linux operating system.  The Linux kernal and operating system
>would be minimized and optimized to support the MPE layer as an "official
>distribution".  The MPE layer would be designed to run atop a fully
>functional Linux distribution for those customers that have need of a fully
>functional Linux distribution.
>
>VPlus/View be rewritten to create and use html forms.
>
>(Turbo)Image rewritten to use one of the generic database APIs available for
>Linux.

You've just almost described Transport/iX, the product whose web-page 
you couldn't read. I know it didn't like Firefox, but is there no other 
browser than IE that will tackle it?

Although it touches in a lot of places, Transport/iX still only fits 
where it touches, and that's far from everywhere. But it does tackle the 
issue of giving an application-level MPE-alike environment on an OS with 
no real VPLUS, Image, Command Interpreter or Intrinsics executer.

>Something like OCTCOMP for those that have essential binaries without the
>source

And if you had that, then you'd convert TurboImage with it, wouldn't 
you, and not have to rewrite it to use a generic API for some other 
database tool?

Because once you casually toss 'something like OCTCOMP' into the mix, 
you're looking at full PA-RISC instruction set emulation, with all the 
hardware bases covered as well, for existing binaries to still work.

>Officially supported distributions be GPL-2 licensed, cryptographically
>signed, and easily verifiable.

Gotta watch out for those bad hats subverting MPE....

>  Any modifications would be treated like MPE privileged mode use now.

Would that be priv mode as evinced in Image at present? Or would any use 
of new features require recoding to grant priv mode around them?

>Bird's Eye View:
>
>Access to hardware, networking, and other system resources would be through
>MPE PM (privileged mode) Intrinsics using a special library and/or service
>to provide whatever hooks necessary to the underlying Linux operating
>system.
>
>MPE would be a normal Linux user, except it would be completely restricted
>to its own home directory with no read, write, or execute access outside of
>its home directory, except through the special MPE PM Intrinsic interface
>(external library and/or service).
>
>All of MPE would be represented in its home directory: accounts, groups,
>users, and system tables.  System tables could be dynamically created at
>"boot up" on RAM disk with soft links for performance, or left on disk for
>debugging purposes.
>
>The Linux user MPE (or mpe) would have a special shell (not bash, csh, korn,
>sh -- mpesh or mpeci or ci?) that would present the MPE user with the
>standard MPE logon and classic MPE command interpreter.  This shell would
>present the MPE home directory with the standard MPE 'file.group.account'
>structure.  MPE PM users and programs could see the actual Linux directory
>structure, including MPE system tables, file labels, etc.

You really do need to look at Transport/iX. To (i) see what's involved 
in providing the above and (ii) see what the limitations still are and 
(iii) save reinventing, or even reimagining, the wheel.

>Benefits:
>
>Linux does all of the "heavy lifting" with help from gurus from all over the
>world, including, but not limited to, salaried employees of Sun, IBM, and
>*HP*.
>     No hardware drivers need to be written or maintained.
>     No OS kernel needs to be written or maintained.
>
>All the newest server hardware is automatically supported.
>
>All server software (with the exception of some MS titles) run on Linux.
>
>All databases are supported directly or through multiple generic database
>API libraries.  Image intrinsics could be written to interface to one of
>these libraries, allowing access to a variety open source as well as
>commercial databases, including Oracle.
>
>Everything from home routers to IBM mainframes run Linux, though there would
>be a minimal system/resource limit for MPE.

>OK, a bit longer than I intended.  I just don't see how gaining all the
>necessary source to MPE is going to be anywhere close to a practical
>solution in the long term and less so ever year that passes, yet seems to a
>great deal of support and interest.

>  My practical solution IMNSHO, has had no holes poked in it publicly, 
>yet has gathered little interest.  Puzzling.

I think that is because (i) it has been done, mostly, so we know it 
works, (ii) but it took $$$ to develop and is priced accordingly and 
(iii) we also know it does not go remotely far enough to be a true 
MPEmulator.

-- 
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  William Morris

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