> -----Original Message-----
> From: John R. Wolff
> <[log in to unmask]> wrote:
>
> >Can anyone provide me with a brief listing of differences [...]
>
> Wow, where do I begin?  I am afraid this may be more than brief.

I too had in mind to write a rebuttal to some of John's points, and while I
have some knowledge of unix (Linux specifically) I am still a bit of a
NOVICE when it comes to HP-ux in particular [which is one reason I bought an
HP-ux workstation off of e-bay -- $150 w/shipping, and came with 11.0
preloaded...]

> [...]  As you read this, please keep in mind that I am
> totally biased in favor of the HPe3000 MPE/iX [...]

I think this is a point many people on this thread have overlooked

> 1) File system - With MPE everything looks like a file, including
> peripherals.

Actually, I think you have that backwards -- under *nix, "everything is a
file"; under MPE, you have FILES and DEVICES [LDEVS] (although the line is
blurring with every release)  This is one reason why under *nix, it is
trivial to write "socket" applications -- the "socket stream" is "just a
file" and can be accessed by the normal file I/O routines exactly the same
as if they were a disk file or a user at a terminal.  Under MPE, this isn't
quite the case (it is close, and using the netIPC I think it is almost
indistinguishible, but there are some "gotchas" that crop up from time to
time)

[...]
> MPE provides logical device numbers for peripherals such as
> printers, tape drives, etc. for easy reference.

I think the point made about "/dev/<reasonable_name_for_devices>" is well
made here, although since release 4.5 of MPE, this "should" be possible as
there is a "/dev" hierarchy -- has anyone tried or succeeded in making
human-readable "device" names under MPE?  [btw: the "reasonable_name" bit is
new even for unix -- there seems to be a long standing tradition that
whenever faced with the choice of making a name easy or cryptic, cryptic
seems to win out...]

> HP-UX has only simple character based files (like a PC)
> without structure that cannot be locked.

Actually file level (and even byte-level) locking is available under *nix -
refer to any standard "c-library" discussion of the routines "flock" and
"fcntl(2)"  [i.e., "man" pages...]

> (In my opinion the file system is the most important
> difference between MPE and UNIX.)

THIS may be true, but not neccessarilly for the reasons you've stated :)

> 2) Spooler - MPE has a robust built-in spooler that is easy to manage.
> HP-UX has a crude spooler that comes with it, but most people shop for
> better ones as an extra cost option.

Dunno about this as I do very little printing.  On the plus side for *nix,
of course, is better management of remote/networked printers (but from
recent reports, so long as you have an "HP" printer or "jetdirect"
card/device, all is well for MPE as well...)

> 3) MPE is far and away a much more reliable operating system
> that rarely crashes or needs to be rebooted.

There are really two factors here: hardware reliability and software
reliability -- since the hardware is the same for 9000's vs. 3000's, we can
eliminate that part of the discussion.  However, ask any group of admins for
any machine how reliable the systems they run are, and you're bound to hear
a story or two of even a WINDOWS machine with uptimes in excess of a couple
of hours ;)  [this very PC I'm posting from currently has an uptime of 6
days, 22 hours+, and prior to that, I'm fairly certain I had left it running
for a month or more]  (btw: to find the uptime of a win9x machine, look for
"system information" under programs/accessories/system -- it should display
on the initial page)

But, getting back to "MPE is more reliable" -- I think it has been pointed
out on this thread and others that "buggy user applications" [which "leak"
memory] are the primary reason that modern machines "have" to be rebooted --
the point-in-favor of MPE is the fact that the ability to write "bad" code
is rather difficult [not impossible] -- when your "process" terminates, the
system can clean up (most) memory leakages; and a "crash" of your
application usually terminates the job or session hosting the application;
hence the low occurance of "memory leak" restarts.  Good code on good
hardware should have uptimes of weeks, months, or years [or even "1 day" if
you run a true 9-to-5 shop where the system gets shut down every night...]

> 4) MPE has a much more flexible security system than UNIX.

Pick up a copy of "burn before reading" and repeat that statement :)

> 5) MPE actually has the concept of application accounts to [...]

[at this point, I think you were "getting into the swing of things" as these
items got a little wilder, resorting to negative phrases for *nix such as
"you have to play mind games" or "it has a 'crude' form of..." -- not that
this is a bad thing, but it degraded your stance in the eyes of those that
followed...]

I think I agree with this, or maybe it is just that the MPE way of
segregating users-by-application makes more sense for a "business" computer
than it does for, say, a process-control plant or a college laboratory.  MPE
accounts and *nix "groups" are just two variations on how to regulate
computer "resources" -- a direct comparison is an apples-and-oranges type of
problem...

> 6) There are many programming languages available for MPE
[...] You can even have different flavors of COBOL or Fortran

Again, I think you had this backwards: on *nix systems, it is not uncommon
to have multiple versions or releases of a compiler available.  Other than
purchasing a third-party version of C or Cobol for MPE, I don't see how this
is possible under MPE (i.e., with HP-supplied compilers -- so far as I
recall -- it has been "the current version only" for MPE)

> Of course, to get the full benefit ... you have
> to utilize the many proprietary features offered.

This is true regardless of platform :)

> HP-UX is usually limited to one instance of a given language
> per computer.

ditto above -- one of the first things I did with my "new" HP-ux system was
download and install GCC (directly from HP no less!) thus giving me HP's
"standard" compiler alongside the more-or-less "de facto" standard...

[then again, gcc is ALSO available for MPE]

> COBOL and C+ seem to be the popular choices on HP-UX, but there are
> others.

I think if you were to enumerate the languages available for *nix and
compare them to MPE, you'd be overwhelmed.  HOWEVER, this isn't a fair
comparison -- I suspect if you compare the languages available ON HP-UX
SPECIFICALLY (instead of the entire *nix world), the list of "unique"
languages for each platform would be roughly the same. (in length, not
content...)


> 7) MPE comes bundled with an outstanding database called
> Turbo IMAGE.

Undisputed point :)

[what may be in dispute is whether or not the "world out there" really needs
a RELATIONAL database -- this is kind of an "if only...", but "if only HP
had been behind the whole 'IMAGE' thing, perhaps the databases of today
would favor hierarchical"]

> 8) MPE has an easy to use and robust command language (JCL) with many
> commands for both operation of the system and for user applications.
>
> HP-UX has a crude, cryptic set of commands which are clumsy to use and
> requires much care to learn.

Somewhere in the annals of time someone once theorized that our lives were
measured (predetermined) by the number of keystrokes we made -- thus was
born the unix concept of using shorthand for commands -- by typing just "cp"
instead of "copy", you were guaranteed a nearly double life span.  Of
course, this was all a tongue-in-cheek jab at Unix and the cryptic commands,
but looking at the spectre of "carpul tunnel" and other repetitive strain
problems, perhaps this unknown jokester was onto something...

> 9) MPE is designed for both interactive users as well as jobs
[...]
> With HP-UX the concept of "jobs" is another mind game.

I think this is a side effect of "conditioning" -- people who start with one
way of doing things are naturally hesitant or reluctant to learn a different
but functionally equivalent method or command.  I know I fall into this
"boat", I just have to learn how to use paddles instead of oars (ps instead
of showjob)

HOWEVER: THIS (and the bit about commands in general) might present a great
opportunity for someone: create an "MPE shell" that has all the old familiar
commands mapped to unix equivalent commands and/or write new commands that
display the unix data in an MPE fashion -- the source code for "ps" is
freely available [for linux], all you need to do is write an output format
that matches MPE's showjob output and you'll be in a position to make
millions (ok, maybe thousands) of new friends who will absolutely rave over
your "product" :)

> 10) MPE gives us the major benefit of compatibility from one

If we're going to point fingers, consider either of these "upgrades":

  * 4.0 to 4.5/5.0

  * MPE/V to MPE/XL (to mpe/ix)

Admittedly, from an "applications" viewpoint, nothing much changed; for a
systems programmer, however, the world was radically altered by these
releases [and yes, I realize the second example also entails a hardware
change, so it isn't a 'fair' comparison :)]

> 11) MPE requires and enforces the separation of code and data
[...]  This also is a major reason why MPE is much more reliable.

I think I made this same point way back at #3

> 12)MPE protects itself from damage, even from the system manager

and this is an extension of the discussion on commands and shells.  **true
story alert** even the greatest minds at VEsoft slip on occaision -- instead
of "deletespoolfile @[log in to unmask]@", someone typed "purge @[log in to unmask]@" -- anyone who has
been around an unix administrator for more than 10 minutes will hear of
"rm -rf *" and the ramifications it has.  Under MPEX, the same is true...
[admittedly, MPEX is an add-on shell, but with recent releases of MPE the
ability to use wildcards on PURGE has been implemented, so it is just like a
cobra waiting to strike...]

> 13) Transition to an upgraded HP3000 or replacement of the
> system disc is a relatively simple matter of reloading ... from tape.

the presumption here is the "upgraded/replacement" system has indeed been
"configured" -- also, the opponents of this statement have taken the tack
that any "upgrade" equipment [and certainly and "disaster recovery" systems]
are NOT already configured.

Either way, I do believe that so long as the HARDWARE configuration has been
taken care of (i.e., disks assigned to volume sets or "volume groups" in
HP-ux parlance) restoring the user data and previously-compiled programs
should have the same effect for both systems: the applications won't run
until the 'users' have been recovered (from tape or by re-typing by hand)  I
think the "point in MPE's favor" is that the various tools and OS-supplied
utilities take care of these mundane details a little better than they do
for *nix [then again, how difficult is it to store the "/etc" directory?]

> 15) MPE can dynamically disable bad memory allowing a system to be
> gracefully shutdown.  HP-UX panics in such a situation and
> crashes.  Two different approaches with the same hardware.

This is a new one to me [then again, maybe this HAS been helping me sleep at
night, and I just didn't know it...]  Of course, "graceful" shutdown or not,
a "shutdown" at 3:00 am still means waking up to a call from a frantic
operator when you manage a 24x7 shop...


I think I snipped it somewhere along the line, but "ever since v4.5" of MPE,
there has been the ability to change programs (and UDC's, for that matter)
"on the fly" -- as some have mentioned, "purgelink" from the "shell" will
purge a file that is "in use", thus allowing you to rename or copy a new
version into the old name space.  MPEX surfaced this "posix" feature with
the ";inuse" keyword to the :PURGE command [initially undocumented, but as
purglink became better known and the "stability" of the pulling the rug out
like that was proven, this eventually became a published keyword]

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