On Wed, Jun 25, 2008 at 12:23 PM, Michael <[log in to unmask]> wrote:
> I strongly disagree with Peter on this; Yeah, MPE is old, and designed for
> data processing, not to be confused with a network proxy gateway, or a file
> server; MPE is not very good at those things. However, MPE is very good at
> data processing and mission critical business applications, and is named MPE
> because of it's multi process environment.

It was named MPE in an era where punched card decks being fed
sequentially through a high speed card reader was the norm.  Back then
MPE had a limit of 256 processes, which effectively limited it to 128
users running a single program.  That was a limitation for some time.
In fact, MPE was protected from users creating process trees by
requiring an additional user and program capability, PH (process
handling).  I was on a team that got around this limitation by
configuring terminals as simple I/O devices (you couldn't logon).  A
batch program was launched that then attached them and created a View
screen UI program on all of them.  Great for performance and security
also.

You have to view the "multi process" in the time it was given.

> You can programmatically start a process(user or system), sessions, or batch
> jobs, and send & recv data between them using various different methods, via
> RAM, evironment vars, sockets, temp file, standard I/O (stdin/stdout), and
> another method that I haven't heard of on any other platform except MPE;
> "Message Files". You can create processes, sessions, jobs in different CS,
> DS and ES scheduling subqueue(s), different user accounts, and still
> communicate in many different methods, with synchronous and asynchronous
> processing.

I never said there wasn't wealth of possibilities.  I probably should
have elaborated a bit more.  The process handling of the MPE operating
system has had a history of being cumbersome and/or inefficient for
application programmers compared to other popular timesharing
operating systems over the years, particularly Unix and its
derivatives.

Like communicating with a process of another user, or even between
processes of the same user in different process trees.  Sure it can be
done in MPE, and I have enjoyed the challenge over the years (it has
got less challenging), but in Unix and especially Linux it is simpler
with less overhead.  But in general, I still think that MPE makes a
better custom business application platform than any other, with some
caveats.

The weakness is not in capability, nor in options, but in simplicity
and efficiency in being able to create, simple IPC, and efficiency.
My view may be a bit distorted due to the different time frames that I
was deep into MPE and Linux/Unix, but I think not too far off.

> How can you say MPE is weak in the multiprocess area?

I guess it depends on what you are measuring, the level at which you
test, and where you draw your labeling lines.

 Just to be clear, it is not MPE's system level process handling that
I think is weak, it is the simplicity and performance of the user mode
process handling that I think is weak.  Also, having a bunch of
different ways to solve a single problem, I don't consider a strength.

It might be interesting to benchmark process creation, deletion, and
communication between MPE, HP-UX, and Linux (seems there is some
support on some PA-RISC boxes).  It's been awhile since I have done
anything substantial on the HP3000, but I would be surprised to find
MPE doing well in such a bench mark.

In a related matter, which seems to get more important each year, how
is MPE's thread support?

- Pete

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