On Oct 29, 2008, at 2:49 AM, James Hofmeister wrote:

> Hello All,
> It would be very cool to see MPE running as a Xen virtual machine on
> Linux.
> How to do this is something that donna and I have discussed over a
> glass of
> California wine more than once...
> My thoughts and discourses...
> - Emulation of the RISC instruction set is vitally important to avoid
> reworking a lot of Modcal (enhanced MPE Pascal) and SPL code.

Well, this is already done on HP-UX, the Arial emulator will
seamlessly run HP-UX PA-RISC binaries.
That means processor emulation is indeed possible. SIMH would make a
really good starting point.

Q. Is there a Principles of Operation for PA-RISC available somewhere?

> - I would lay down the MPE file system on top of Linux ext3 file
> system {if
> we reach size limitations on a single file system of 8-16tb, then
> ext4 or
> XFS) in the same way the MPE file system exist on top of POSIX today.

If by that you mean, write a big honking Linux file and use it as a
virtual disk, I agree with you. Yes, you loose a bit of speed that
way, but not all that much, and MPE/ix would have full control of the
virtual disk. This also makes backup and disaster recovery chores much
easier. It doesn't matter what filesystem you use to stores the
virtual disk files on then, it will "just work."

> - I don't see why any of the rich file types implemented on MPE
> would not operate in the same manor as they do today with the
> exception of
> MSG files and their support for process to process communications.
> Again as
> I mentioned above, the MPE file system would be implemented on top
> of the
> Linux ext3 file system and we are counting on the emulation of the
> instruction set to execute the file system code.
> - With the RISC emulation mode for the Image code, I would expect
> that the Image database would operate with the same functionality as
> it does
> today on top of a MPE file system. It certainly is also possible to
> abstract the image calls and point to a Linux distribution data base
> or a
> vendor purchased data base. Anyone want their MPE application
> writing to an
> Oracle RAC?
> - Capture all MPE I/O calls at the highest possible point in the MPE
> O.S.
> code and insert an abstraction layer which translates from MPE to
> the Xen
> Virtual machine I/O abstraction layer. Expect to say good bye to
> sysgen,
> all I/O devices attached to the server would be linked in the Xen
> Domain
> zero.

I would not modify the MPE/ix code at all - just simulate the hardware
they are talking to.
Disks, DTCs, SCSI controllers, what have you. Easier to do a
simulation for than to allow the host
devices to show through directly.

> - This provides MPE access for the most part to all existing and
> *new* disk, SCSI tape, USB storage, SAN storage, SAN tape libraries/
> robots,
> network iSCSI storage, and other block and character I/O devices
> recognized
> by Linux; maybe even your Cannon camera or your ipod. One thing
> interesting
> about Linux is old drivers never seem to die...
> - If you require a MPE historic tape device as an example, it is
> possible to accomplish this if a converter and/or interface card
> exists to
> this device which will connect from the device to the PCI bus. Then
> all you
> need is a positive attitude and a Linux driver writing class; not to
> worry,
> there are a lot of open source drivers you can leverage source code
> from.
> - Capture all MPE Network calls at the socket interface replacing
> MPE's
> sockets code, TCP, UDP, NIC drivers, etc. with the Xen Virtual machine
> Network abstraction layer.
> - It would be useful to perform triage of the service level MPE
> network code and eliminate any ARPA or NS services which are
> duplicated by
> services in Linux or which still use the NETIPC network sockets.

Ah- why? It isn't hard to make the physcial device under MPE point to
a TUN device under Linux,
and just add a second IP address (and ARP resolution) on the card.
This is the way we do it for
Hercules, Wang, and SIMH emulations. Works great....

> - Retain network services that touch the MPE file system. Some
> tough decisions exist here, including the decision to keep or
> discard VT &
> DSCOPY. For DSCOPY and some other NETIPC based services, it would be
> necessary to create a NETIPC to BSD sockets abstraction layer if
> they were
> to be kept. Keep in mind: On Linux unencrypted protocols are un-
> cool. VT,
> TELNET, DSCOPY and FTP on MPE are all unencrypted protocols.
> - As with abstracting the I/O layer above, abstracting the network
> layer will provide huge improvements over the MPE networking
> functionality
> including SSH, 1gE and 10gE NIC's, iSCSI, NIC bonding and all of the
> other
> standard Linux/UNIX networking features. Expect to say good bye to
> nmmgr,
> most of networking would be configured in the Xen Domain zero.
> - The emulation of the MPE console is a big deal. The concept of a
> console
> is significantly different from MPE to Linux or UNIX where the console
> really is only used for system boot/recovery. My vote would be to
> perform
> triage on the MPE console functionality, implementing Linux style
> console
> logging to a text file and rework the MPE "recall/reply" printer
> management
> and tape management console functionality. It is probably time for
> all of
> the "operator" commands to be evaluated for similar functionality in
> Linux
> or UNIX and again triage some of the functionality with the
> perspective of
> MPE running in "lights out" data centers.

Emulate the serial console port, point a telnet session to it...

> - The process scheduler should be abstracted to interface to the Linux
> process/task scheduler as well as the Linux I/O scheduler and Linux
> memory
> manager.

Run each MPE/IX "CPU" as a separate task or thread. Process
scheduleing stays within MPE/ix for most stuff, but Linux on the
outside handles most of the real processor scheduling. Also run tasks
or threads for disk controllers, DTCs, Ethernet, etc.

> - The MPE spooler and network spooler should be abstracted to
> interface to
> the Linux cups printing solution. Hmmm... We probably need an
> 'hponly'
> printer solution to say in harmony with MPE (sorry I couldn't resist
> and yes
> I need you to buy HP printer ink so I can retire some day).

> - The DTC terminal I/O would need to be triaged. There is nothing
> like the
> DTC functionality in Linux that I am aware of. I have heard of a
> scary
> serial to USB solution. I have seen several H/W serial to ssh
> solutions
> that could replace most of the DTC terminal functionality and again
> network
> printing is the Linux solution to all of your printing needs.

I would make them virtual and just depend upon telnet or NVT or NSVT
communications into the system.
If you really really need serial communcations, you can do that with
physcial hardware, ARTIC or orther cards provide
hundreds of serial ports for a Linux box. Or if you only need a few,
then a USB serial port adapter will usually work just fine.
The problem is in attaching those real ports to a virtual machine
instance running MPE/ix. It;s possible, not even all that difficult,
but what you wind up doing is converting a serial connetion to a
network connection anyway... so.... ??

> - The Job/Session and CI commands functionality is where the beef
> is. I
> would expect to see a huge amount of effort here to evaluate every MPE
> command and parameter, determine how it interfaces to MPE data
> structures
> and determine which are best to emulate and which are best to
> abstract to a
> Linux interface. There is a lot of SPL and Modcal code here to
> investigate,
> it would appear to me that the smoothest path would be to emulate
> "all" of
> the MPE core O.S. data structures and abstract to Linux at the
> highest level
> necessary to provide the expected functionality and interface to the
> hardware.
> - POSIX vs. Linux bash shell - not sure what difficulty to expect
> here.
> - I would 'goto' heaven happy if we could port something as useful
> as debug
> and dat with macros to Linux! I guess at the same time we would
> need to
> convert MPE system aborts to Linux panics and MPE hangs to Linux
> hangs

gdb runs out of process of course, and the memory model under Linux is
wildly different than under MPE/ix.
However, it ain't all that hard . Drop me a line off-list and I can
help you out with that stuff.

> I guess it is getting late and I could write pages more... I am
> sure that
> for anyone who is considering the implementation of a MPE emulator,
> that my
> notes above are just a drop in the bucket to the investigation and
> analysis
> that they have already performed. I am sure smarter people have
> already
> identified smarter solutions than I have expunged above.

Snort - don't bet on that. There are smart people, and there are smart
people who actually DO things.
It takes a lot of effort to put anything down in writing. It;s a good

Emulation of the platform to the point you can boot and run MPE/ix on
a Linux instance isn't all that difficult a task, but it woudl
probably take six months for a dedicated project, and more like two
years on a volunteer basis.

What I wonder is how it would be marketed, if at all. If marketed,
what would be the factor that makes MPE/ix attractive to a target
audience? We know that existing companies would probably transfer to
it in a shot- totally eliminate the hardware issues that way.

But what would draw people to the OS? I like it because it is clean
and reminiscent of design options I love in other OS's. And I am quite
fascinated by the history of computer systems and computer languages.
But most people won't be attracted by that.

I guess the easy way to say it is like this: assume a working
emulation that loads up on a linux and you get a fully running copy of
MPE/ix, terminals login over the network, it prints, disk space is
essentially limited only by how much space you can put on the Linux
box. What would you do with it?

That isn't meant to be an annoying question by the way - would you go
to a friend and sell it to them to solve a problem? What is the
problem and why wodl MPE solve it? Would you use it at home just for
fun? Somewhere in between?


> I also am sure I got something in the above wrong... Please feel
> free to
> gently correct me -< I hope my input is helpful and not
> discouraging.
> P.S. My Ideals are my own, not necessarily my employers.
> Peace,
> James Hofmeister
> * 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 *