Putting Pete on the OPENMPE board is the only way to cure him of this addiction!
   
  -Craig

Pete <[log in to unmask]> wrote:
  I have been busy with a number of things, but have had the opportunity to
talk to some old HP3000 hacks. I personally believe that HP is interested
in having the HP3000 and MPE die a graceful death. Recent information only
adds to that opinion. Maybe I am wrong, and HP will give MPE in its
entirety to OpenMPE. But, the cost of supporting MPE and its lack of modern
capabilities, I believe is a huge hurdle to overcome. Yet, I still think
that the MPE application environment is a great one for end users,
application developers, and admins. So, in brief, here is what I propose:

1) MPE-NG (MPE next generation) is run as a highly secure and simple user
space (user mode) environment on top of Linux optimized for end users,
application developers, and operators/admins. MPE-NG will use as much
existing open source as possible to use the concept of "standing on the
shoulders of giants" as possible and reasonable.

2) MPE-NG exists as a Linux user directory tree making use of a standard
Linux file system (like XFS) taking advantage of ACLs (access control lists)
and EAs (extended attributes). Many of the files will be hidden from
MPE-NG's view (i.e. system tables). The intrinsic interface will present
the standard "file.group.account" view of normal MPE files for end users and
app programmers. I've always wanted to extend this concept to one more
level to something called domain (file.group.account.domain) so that you
could have PROD, QA, DEV domains exist side by side securely on the same
computer, but that would be a future debate.

3) MPE-NG's privilege mode is simply access to all of the normal files in
the Linux user directory tree for MPE-NG, and normal Linux programming
access.

4) From the Linux point-of-view, there is only one user, "MPE" (or "mpe",
if you prefer). The MPE-NG command interpreter handles the normal HELLO and
JOB commands to logon (possibly "(COMMAND)" also, if needed). An additional
command LINUX to be added to logon to a normal Linux user and get to a
normal Linux shell -- equivalent to gaining PM.

5) PM intrinsics are nothing more than an API into Linux. All access to
Linux and server hardware will pass through them.

6) VPLUS will be reimplemented using a web interface underneath that either
CUI clients (i.e. lynx, elinks/links) or GUI clients (i.e. Firefox, MSIE,
Epiphany, Opera) can use.

7) IMAGE will be reimplemented using a generic Linux data store library
with modules for at the least common RDBMSs, but using Image DB@ intrinsics.

8) POSIX and HFS will not be included as it creates unnecessary complexity
and more problems than it solves, IMNSHO. All of this will be available on
the MPE-NG PM side, which is simply Linux as described above.

9) All code to create the "MPE-NG on Linux" environment will be GPL/LGPL.
Anyone can look at it, and anyone can contribute bug fixes and
enhancements. The production version will have an official body (like
OpenMPE) with the ability to pick and choose what contributions to include
in the "Official Distribution" that is cryptographically protected from
unauthorized modification. Any number of test or development trees could
exist on anyone's Linux system.

10) Development source control be governed by a non-centralized SCM
system/program like Mercurial (simple and clean), or Git (more robust and
what the Linux kernel hackers use).

Issues:

There will be some gotchas, there always are. So far, I have seen none
expressed that were valid. Reviewing some of the web sites by 3rd parties,
issues have been listed that are either issues only for HP-UX or are not
valid anymore. I have seen where it was claimed that Linux has no concept
of JCW's and has no equivalent of "putenv(...)", which is not only NOT true,
but the functionality is provided by a Linux function called "putenv(...)"!
No concept of memory mapped files? Also not true, Linux has a function
called "mmap(...)" to do just that. Although not as simple as MPE's, it is
more powerful in that it allows for just memory mapping a portion of the
file. But of course, from the MPE-NG environment side of things, it will be
exactly as simple as real MPE, on the Linux (MPE PM) side, nothing fancy has
to be done, it's all there! You want to access that additional
functionality? No problem, add the accesses as a simple and intuitive
extension to FOPEN (or HPFOPEN without HFS). Many of the "modern" MPE
intrinsics were designed to be extended, making adding functionality without
breaking existing code relatively easy. Now for some real issues.

1) A significant number of sites will not be able to use this virtual
MPE-NG system without being able to use binaries that can't be recompiled
due to loss of source or more likely 3rd parties that don't want to bother
recompiling. A PA-RISC emulator or interpreter will have to be created, or
one of the existing projects like QEMU enhanced with PA-RISC instruction set
capability.

2) Lack of money to create and maintain. "Have to have money to create,
can't get money until created." Catch-22. I am willing to create an MPE-NG
command interpreter as an exercise to learn Python. Once it is working,
profile it and create C routines to replace the "< 10% of code that uses >
90% of CPU time". I may actually get some VERY TALENTED help on this! If I
can create an MPE command interpreter that runs on Linux and executes UDCs
and command files with the same results as an HP3000, could some money be
"invested" to complete the project? If we could get enough volunteer
participation on the development side, maybe very little money, if any,
needs to be invested.

3) People that want to help, but think they don't have anything to offer.
Most of the man power and resources needed are not in development. Most of
the development will be using existing open source software -- only creating
the glue to put the pieces together and creating a secure and robust
configuration to prevent intentional or accidental crashes and security
breaches. So how can you help?
3a) Write a script to identify all of the programs that you are using.
Identify those programs that you do not have the source to (lost, 3rd
party), and make a list of those.
3b) Create a script or simple program to list all of all intrinsics used by
all of the programs in use. Should be a single non-duplicated list of
intrinsics in alphabetical order. Another list with all of the intrinsics
called by each program would be useful too. Share this with others that
don't have the skill or time to create.
3c) Provide a test account(s) for me (who lacks access to an HP3000) to
compare results with an actual HP3000 MPE environment.
3d) Create and/or maintain documentation within the chosen SCM.
3e) Test beta versions.
3f) Prod your HP3000 vendors into supporting the effort with time, money, or
resources.
3g) Research COBOL compilers for Linux.
3h) Help make a Linux PA-RISC emulator possible any way you can (prodding,
time, money, testing, etc.).
3i) Provide access to a variety Linux servers for performance testing,
system sizing, and configuration recommendations.
In short, if you can't help in development or funding, there are ample
opportunities in providing resources, documentation, testing, research, and
evangelizing!

If there are any serious issues I have missed, please reply with a detailed
description. Anyone willing to make any contribution as outlined above,
please let me know who you are and what you can offer! A public mailing
list for contributors/developers has been created (Google or Yahoo
preference?). Whining, bellyaching, "MPE is dead!" mantras, and other
content-less replies will be ignored.

- Pete


 		
---------------------------------
Stay in the know. Pulse on the new Yahoo.com.  Check it out.