Re: OpenMPE redux, executive view. - Hewlett Packard

This is a discussion on Re: OpenMPE redux, executive view. - Hewlett Packard ; James - I really enjoyed reading your comments as you obviously grasp the situation and the nuances of what it would take to implement! On Wed, Oct 29, 2008 at 12:49 AM, James Hofmeister james.hofmeister@comcast.net > wrote: > Hello All, ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: OpenMPE redux, executive view.

  1. Re: OpenMPE redux, executive view.

    James -

    I really enjoyed reading your comments as you obviously grasp the situation
    and the nuances of what it would take to implement!

    On Wed, Oct 29, 2008 at 12:49 AM, James Hofmeister <
    james.hofmeister@comcast.net> 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...



    Running as a virtual machine under Xen seems to be a good solution for
    homesteaders stuck in time. I am thinking that a solution that incorporates
    the newest software and hardware technologies in an MPE development and
    operational environment has a chance to grow some legs and become
    competitive again.

    ---

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



    By hiding the file system from FREADs, DBPUTs, FWRITEDIRs, etc. the most
    appropriate file system or database could be chosen without needing to
    expose technical details to business applications. This functionality
    already exists.

    - 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 RISC
    > instruction set to execute the file system code.



    Why bother with emulation? A message file can exist as a normal Linux file
    with another Linux file hidden to user mode MPE containing the file label
    causing the MPE intrinsics such as FREAD to treat it properly with the 2
    pointers.

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



    As I stated, there are already database abstraction APIs available for Linux
    that Image calls could access that inturn link to a large variety of
    databases. It would make sense to only "officially" support a couple of
    databases, but the generic APIs allow for migration to future databases
    without application code modification.


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



    This works whether you are creating a Xen virtual machine or using Linux as
    your hardware interface layer.


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



    My point exactly! Old Linux drivers exist as long as there is old hardware
    to be driven.

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



    Drivers for HP-IB (IEEE 488) already exist. I suspect that you should be
    copying those tapes to optical disc (CD, DVD, Blu-ray, etc.) before you
    retire your HP3000.

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



    Business apps shouldn't need to worry about this. Create a simple business
    app oreinted interface that calls the Linux network 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.



    Why not eliminate the MPE network code altogether?


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



    Think about what business reason you need them for at all. The mechanism
    for getting a terminal connection or moving data around from network node to
    network node should be transparent to the application. There is a variety
    software for Linux that makes the network transparent to the application.
    It can and should be used.

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



    Once again, the concept works without Xen, and the benefits are great due to
    the reduction in highly technical code that needs to be maintained and kept
    current.

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



    Not that difficult. Messages can be logged to the console from any number
    of log files with "tail -f ...". The recall/reply mechanism are just a
    couple of intrinsics looking at the system table containing the console's
    ldev and using it appropriately to communicate through IPC calls.

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



    I can see the need for MPE job management. There are some differences
    between MPE processes and Linux processes. Can an MPE environment be
    effective with Linux process controls and data?

    - 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 also don't think that DTC provides any needed functionality, and I think
    is HP3000 only hardware.


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



    Job/Session info and control could be maintained by keeping a JMAT file and
    JIT files in the MPE directory. The MPE system code could be used as is for
    the most part with a bit of file memory mapping.


    > - POSIX vs. Linux bash shell - not sure what difficulty to expect here.



    Linux is fully POSIX compliant. Exposing POSIX in MPE is a *bad* thing in
    my opinion. Linux and/or POSIX functionality should only be exposed through
    an MPE interface that maintains MPE's look-and-feel, IMNSHO!

    - 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



    Very funny. NOT!

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



    Good stuff and insightful!

    - Pete

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


  2. Re: OpenMPE redux, executive view.

    In message
    , Peter M.
    Eggers writes
    >James -
    >
    >I really enjoyed reading your comments as you obviously grasp the situation
    >and the nuances of what it would take to implement!


    Reading what James has to say, you certainly get the feeling that here
    is somebody who knows *exactly* what he is talking about. I wish I
    did.....

    >On Wed, Oct 29, 2008 at 12:49 AM, James Hofmeister <
    >james.hofmeister@comcast.net> 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...


    Why not have two glasses and really blue-sky this thing? :-)

    Given the above 'I wish I did', I can't comment much on the gory
    technical details. But Pete replied to your:

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


    with:
    >Business apps shouldn't need to worry about this. Create a simple
    >business app oreinted interface that calls the Linux network layer.


    and I wonder if this is not to misunderstand what business users will be
    looking for. The paradigm here must be the PA-RISC machine's HP3000
    Compatibility Mode (even if HP can't spell it properly) which let users
    of Classic systems port them, at the binary level and with the absolute
    minimum of change, often none, to PA-RISC.

    For an MPEmulator to attract existing HP3000 business users, it must
    aspire to that level of compatibility, and even if the underlying
    processes handle things quite differently, the goal must be that every
    invocation of an openly documented MPE process is accepted, and produces
    effectively the same results as it would have on a real HP3000.

    Even if that process is three levels down in the binary of an app the
    customer does not have the source code for. The MPEmulator can't turn
    round and say 'Well, gee, I'm sorry, but none of this stuff exists here
    and you'll have to go make Linux network calls now'.

    Roy
    --
    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 *


+ Reply to Thread