Duane points out:
> I would like to point some things which add
> some additional reality to the discussions
> on this thread. Not to dissuade anyone from
> pursuing these ideas, but to make sure everyone
> is thinking about the true effort(s).

This is the time to bring these things up!  I would encourage everyone to
blast as many holes in this idea now to uncover any show stoppers.

> * There is a big issue with mpe applications
>   with regard to the file system. In mpe you
>   have files that can be different types and
>   based on the type you get different/specialized
>   behavior. Emulating this on Linux with little
>   or no source code change might be a challenge.
>   But, Linux does support different file systems
>   so an interprising individual could implement
>   a complete mpe file system. Also, consider that
>   without a complete mpe file system you don't have
>   basic things we take for granted like FILE EQUATIONS.

I really think some enterprising individual/company will have to implement
the MPE file system under Linux.  The standard Linux file system, ext2, does
not have a transaction manager.  There are some Linux file systems that do,
like JFS from IBM, but they are not record-oriented and don't have the file
types like MPE.

> * Currently the cobol compilers that are robust
>   enough for recompile migrations of mpe apps
>   are purchased by developer and deployed with
>   run-time charges (per simultaneous execution of
>   cobol code). The compile most are looking at is
>   AcuCobol which is finishing up a hp3ek port.
>   This compiler is an interpreter and doesn't currently
>   generate native instructions (except for Sun UltraSparc).

Just wondering out loud here, if you still have the PA-RISC Cobol 85
compiler and you run it in the emulator, would it create PA-RISC
executables?

> * Even though mpe provides a core set of functionality
>   a lot of shops have chosen to use additional 3'rd
>   party tools. Some for job management, some for
>   report management and some for data management.
>   Migrating a package like Amisys might require
>   additional migration efforts for any tools that
>   application depends upon. Some of these tools are
>   using internal knowledge of mpe and its file system
>   to work. For example, lots of applications depend
>   upon Suprtool. What would you do if wasn't available?

There would definitely have to be changes in programs that go deep into
operating system.  IIRC, you didn't want to run the old spooler utility
SPOOK5 on a XL machine unless you wanted to take a break while operations
recovered from a system abort.  Clearly, some tools would run but not as
efficiently in an emulation mode.

> * Some vendors have already wrapped mpe like features into
>   their applications so they could run on hp-ux. Maybe it
>   would be a good idea to find these solutions and see if
>   they would be a good starting point or maybe even a solution
>   for those that want a more painless migration.

Some of those third parties may already have a Lunix versions too.  It seems
that a lot have started in this direction already.  Suprtool/UX already runs
on Unix and I don't know how tough it would be to get to Linux.  I would
like to know what Linux support would some of the third party vendors have
or plan to have (in a different thread please.)

Continuing with Duane's initial thoughts, another one that may be trouble is
the networking layer.  Would the emulator have it's own TCP/IP stack or
would you try to share one.  Would it be wise to have multiple IP addresses,
one for Linux and another for the MPE/LX?

> Wishing everyone the best during this holiday/migration season :-)

Right back at you and the same to the other MPE folks, including classic,
native and emulated...

Mark Wonsil

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