On Oct 28, 2008, at 5:57 PM, Peter M. Eggers wrote:

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

Okay, that is somewhat reasonable. You can run full function  
(commercial) mianframe emulation, Vax emulation, PDP-11 emulation,  
Data General, Perkin Elmer, Unisys (Burroughs), Unisys (2200), Wang  
VS,  and at least a dozen other emulators this way. On top of Linux I  
mean.

Now most of those will define a very specific Linux version, and a  
restrictive set of hardware you can run that Linux on.

> VPlus/View be rewritten to create and use html forms.
>
> (Turbo)Image rewritten to use one of the generic database APIs  
> available for
> Linux.
>
> Something like OCTCOMP for those that have essential binaries  
> without the
> source
>
> Officially supported distributions be GPL-2 licensed,  
> cryptographically
> signed, and easily verifiable.  Any modifications would be treated  
> like MPE
> privileged mode use now.
>

Why not simply write a library (set of intriniscs) that hook into  
native Linux library calls? That gives you access to the clib and any  
other library on the system. Also, you have no need to rewrite any  
existing code, hardware drives, etc.- just emulate the existing  
processor.


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

MMM- okay. On the other hand, why not provide emulated support for the  
existing calls?

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

Well, you would have to mount all the DASD, real or virtual under that  
one directory. Can be done of course, but it might be simpler to just  
let it have normal account access. For example, you might want to the  
emulator to be able to access storage on different mount points that  
are from different, or differently designed storage.  Big old fat slow  
storage, and lots of it, for rarely used files like images and such.  
Fast multispindle disk space for transactional files, database, etc.  
Mirrored storage for system volumes etc.

That applies whether or not you intend to use "raw" disk volumes, or  
simple write big old disk files under linux to emulate particular  
drives.

Flex-ES for instance allows you to do either, and as a result you can  
get some REALLY fast disk access from a PC. Darn near as fast as on a  
hardware based mainframe.  "Transvirtual Systems", which provides Wang  
emulation, only uses Linux disk files to emulate Wang volumes.  Both  
ways work.


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

So you are saying port the code to run natively under Linux here. Okay  
I can see that.
Might want to consider some kind of PAM based authentication to  
emulate the existing
user authentication and authorization methods.
>
> 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.
>

Okay, except the code that runs as a Linux application kind of  
qualifies as a psuedo-OS.
It has to be maintained, and it is going to be more of less dependent  
upon the version of the Linux kernel.
Hardware drivers, for some reason, always have to be maintained. For  
example, it may be necessary to
hook up and read an existing HP3K disk, or share a drive with an  
existing HP3K. Or use a special purpose tape
drive, or ... you get the idea.


> All the newest server hardware is automatically supported.

Ah, here I take exception with you. Unless you have totally - and I  
mean totally - virtualized all the hardware drivers, then you are  
going to have specify, with great precision, the hardware the emulator/ 
simulator is guaranteed to run on. Otherwise, there will be platforms  
it doesn't work on, and with that, issue upon issue of support.


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

Two different trains of though here -
    True emulation, which would run existing binary software with no  
change

                     vs

    Psuedo-port of MPE to Linux, preserving some or most of the  
aspects of the OS but running native code under Linux.


Both had advantages. True emulation is easier but there are some great  
advantages to the second way.

Of course, there is a third possibility too - port the OS itself to  
run on a new platform. Personally, I think that would be the most  
advantageous, because it really gives you a new HP3K.

The second and third possibilities do require access to the existing  
source code; the first does not, though access to documentation on the  
processor and the hardware interfaces would be a good thing to have.  
Reverse engineering is not fun when faced with a massive project.

So - pretend you have a venture capitalist out there willing to invest  
say, $5M. What product do you present, and how do you make that  
product make a sufficient return on his investment to cover the risk,  
and reward the people that do the work?

A new appliance box that does something cool with MPE? An invulnerable  
web server perhaps? Or a drop in box for accounting?
Or...
?

By the way, I don't have $5M, nor do I have an idea of how a New HP3K  
would be marketed, or even if it can. (One possibility is that HP3K  
becomes regulated to the hobby market.)

One thing I know, if someone layered a cool GUI on top of MPE, and  
turned it into a Windows killer, made it ruun on x86, HP would jump on  
that like white on rice... :)

-Paul


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

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