Re:
> - 4GB limit on MPEXL_SYSTEM_VOLUME_SET even if you have a larger drive
Yeah..pretty dumb. They've announced they're working on fixing this.
IIRC, the problem is in the firmware, which assumes a 4 GB limit
for the address of the boot software. I'd have assumed that would
mean "hey, just put the boot image in the first 4 GB somewhere",
but...:)
> - no software mirroring of this 4GB.
Yep. Of course, software mirroring sucks anyway :)
> - you've just made your disaster recovery and upgrade processes more
> difficult if you make the MPEXL_SYSTEM_VOLUME_SET multiple disks to get
> around the 4GB limit and any important files creep on the other disks.
true.
> - 8 character names of MPE namespace files and queues is VERY hokey.
So, use HFS files! (POSIX hierarchical directory structure and file names)
> - HFS/POSIX namespace files don't map cleanly to 8 character MPE
> namespace files with symbolic links.
Huh?
I use this all the time.
cd /etc/foo
ln -s myposix_named_file /SYS/PUB/MINE
or
:newlink mine.pub.sys, /etc/foo/myposix_named_file, mine.pub.sys
> - The EDITOR edlin wannabe editor seems limited compared to vi and
QEDIT...it's been the editor of choice on the HP 3000 for 20+ years.
(Also runs on HP-UX)
(There's QEDIT for Windows, which works with the HP 3000 / HP 9000,
but I haven't warmed up to it yet.)
(The reason I like QEDIT is that I can mix line-mode style editing
with visual editing, something few other editors can do well.)
> - You cannot edit many system files using vi without corrupting them and
> needing to FCOPY them back into a usable format.
That's like saying "if you use a stupid utility to edit something
that has a particular format (unknown to the utility), you'll have problems".
vi is stupid...it doesn't understand record structures. It's an editor
of bytestream ASCII files ... a barely adequate one at that.
Rule 1: get QEDIT, and use it for MPE files.
Rule 2: get QEDIT, and use it for HFS files.
Rule 3: see rules 1 and 2 :)
> This is supposedly fixed in the current MPE release, which I don't have.
> FCOPY is analagous to CONVERT file /FDL in VMS.
Don't know FDL.
FCOPY is similar to an enhanced "dd" in Unix, it's a record-oriented
file data manipulator.
COPY is similar to "cp" in Unix, it's a file oriented copier.
> - The onerous patching and upgrade process, and the difficulty of
> determining your actual patchlevel from the OS maintained files.
Not an OS feature, but a *product* feature. Yes, MPE's patching process
could be better.
OTOH, there are some positive aspects...
It's trivially easy for the system manager to apply a one-word patch
to running code on MPE/iX, should that be necessary. (Even if the code
is in a critical part of the kernel.)
(No, it doesn't happen often.)
> - Patches are not generally available for download and can not (until the
> recently released current version??) be installed from CDROM.
Not really...itrc.hp.com has them. You can grab "patchman" from HP's
web site (it ought to be distributed with the OS!), and it will tell you
what patches exist, and which you should install, and will download them
and do some (all?) of the installtion for you. True, we've only had
patchman for the last 2 years or so.
> - Although the program "mail" is shipped in the POSIX environment, there
> is no MTA to actually send any mail off the system without installing
> sendmail.
Mail isn't part of the Unix *operating system*, although it's usually
bundled with various Unix *products*. There are several Unix-style
mailers available for MPE. I frequently use MAIL from Telamon (ftp.telamon.com),
because it works well.
> Sendmail itself IMHO is one of the cryptic low points of Unix software and
> hardly an asset to MPE.
true...but we have sendmail, too.
> - The facility to automatically reboot without operator intervention at
> the system console is a separately sold option. (see Autorestart/IX)
So?
BTW, if you want to trigger a reboot remotely, that ability has been
available for about 15 years ... not well known, perhaps.
> - I can change between OpenVMS/Tru64/Linux/Windoze at will with firmware
> settings on my Alphas. I need HP field engineer & his magic number
> generator to do the same between HPUX and MPE.
And you want to .... why? :)
Presumably, you're running licensed copies of the VMA and Windows software.
HP has chosen not to allow a user to license both HP-UX and MPE for the
same box.
If you installed the PA-RISC version of Linux on an HP 3000 (presuming it's
one of the PA-RISC hardware versions that Linux supports), you
could do the same thing: bootup either OS. Now, Linux won't know about
the MPE file system, and vice versa ... but there's nothing stopping
anyone from writing an inferior MPE-look-alike file system for Linux
(or, nothing stopping them from doing a hell of a lot of work and writing
a work-alike/look-alike good MPE file system ... if they implement the
Transaction Manager :).
BTW, can you say "fsck". An MPE user doesn't know that that word is...
a typoed version of f*ck ... which is what's said when a Unix user
has to run it.
I have never seen, nor heard of, file system damage caused by a reboot
on MPE...not now, nor with the Classic MPE V. (Yes, some other things
can sometimes damage the file system (e.g., disk drive problems),
but that's pretty rare.)
(My partner has spent all day trying to resurrect a client's HP-UX system
that had 3 disk drives fail this weekend... after the drives were replaced,
HP-UX notes that 3 volumes are missing from some volume groups, and
3 unknown problems are present ... 8 hours of fighting HP-UX and SAM later,
well...they're still fighting, so there's no resolution yet.)
> - User licensing & hardware very strictly tied.
So? That's not an *operating system* issue, that's a *product* issue!
> - Some machines have deliberately software reduced CPU speeds while the
> corresponding 9000's models do not apparently to force MPE users to more
> expensive machines.
Yep. I think that's wrong, definitely not the HP Way. But, HP's 3000
group has an incredibly good relationship with the users...we talk with them
daily, meet with them periodically .. a relationship that's the envy of
the industry. Heck, I want that kind of relationship with the *HP-UX*
people!
> - It seems generally as stable as my VMS systems - this is a big plus.
> - The POSIX environment is handy (tho slow) and does add more options for
> modern software
> - From my limited experience the TurboImage database seems competent and
> versatile.
MPE's good points:
1) it lets you get things done.
This cannot be overstated... If you can think of something new
to do with a computer, there will be a way to do it on MPE.
Let's say I want to write a product that would let me mount
a disk on a Sun system as if it were a local disk on a 3000 ...
not a *file system* (e.g., NFS), but a *disk*.
I could do that easily with MPE, even to the extent of handling
page faults across the network.
I couldn't even *begin* to do this with HP-UX. (Yes, I can
(and have) written kernel-level / driver-level code for HP-UX.)
Part of the reason this is possible is that I can write "user" code
that runs at ring level 0 ... something not possible on HP-UX.
Another part is that (with appropriate security) I have the ability
to see/modify kernel code and data ... from a user process (i.e.,
from outside the kernel).
2) it's stable.
I have some code that's run unchanged, un-recompiled, since 1979.
2.5) reliable.
The Transaction Manager means that file system data structures,
and IMAGE data structures are protected from corruption caused by
system failures. If you want to have the same level of protection
for user data in a file, you can...trivially.
3) it's scalable.
Few, if any, OS's have demonstrated scalability from a single user
up to thousands of users.
4) it's easier to manage.
This is *NOT* open to debate. For 20+ years, I've seen site after
site after site ... without a single exception ... spend far more
money and far more time maintaining every other operating system
than they spend for maintain their MPE systems.
Yes, it's harder to find an MPE-trained person than a Unix or Linux
or NT person ... but you only have to find one instead of two or three
or a dozen. Plus, in their spare time they'll probably be the DBA
for an IMAGE database, it's that easy.
5) addressing ... 64 bit since 1986.
Even *today*, HP-UX is basically a 32-bit operating system.
...with stacks limited to tens of megabytes (roughly), and no
ability to access much data beyond that.
Since MPE XL 1.0, MPE users have had the ability to have global/stack
data of to 1 GB, and up to a thousand blocks of up to 4 GB of data
directly addressable by their code.
64 bit? Been there, done that!
As of release MPE/iX 6.5, we can have disk files much bigger than 4 GB...
but with the same file system interface as before! (No, *we* don't
have to set special flags saying "large files" when we compile
our code, unlike Unix :)
6) mapped files ... done right!
Essentially every disk file is accessible either via file system intrinsics
and/or mapped file access. Note that "and/or"...a *BIG* departure from
HP-UX. (HP-UX file system buffers and their mapped file access do not
share data, so if a user updates a file via "write()", there's a good
chance that mapped file accessors won't see that data ... basically not
a problem on MPE). (MPE's file system uses mapped access internally,
so *all* file accesses eventually go through the same mapped access.)
7) kernel APIs are extremely powerful. Want to see if a virtual address
is in memory? freeze it? post it if dirty? forget it? Trivial.
(True, not well documented)
8) debugging the kernel is easy, and available to any system manager that
wants to learn how to do it. HP-UX just this year announced some form
of kernel debugging .. it requires 11i, and it requires a second
9000 to run the user interface on. (And I don't know if it's as
powerful.)
9) IMAGE is bundled in, and is powerful and easy to use.
We had one client, a commercial bank in London, switching from
MPE & IMAGE to HP-UX & Oracle. We warned them that they would
need three times the CPU and three times the disk space to get
comparable performance.
After they switched over, they called us to tell us we we wrong...
they needed *five* times the CPU and *five* times the disk space.
Relational databases are good for some things ... MPE had one years
ago (ALLBASE). But, they aren't good for what people do most: day
to day business. For that, hierarchical / network databases tend to
outperform relational databases.
IMAGE allows datasets ("tables") up to 80+ GB. Unlike most other
databases, the users have a *say* in IMAGE. We've had a large number
of user-request enhancements implemented in the last 10 years.
10) easy to reverse-engineer.
Got a problem you need solved, and you think some part of the OS
knows how to solve it (or something similar)? It's very easy to
look and see how things get done.
11) POSIX
Rated as "most open" system by Gartner group.
12) superior IPC
Multiple message passing mechanisms to choose from (although we
still lack some of the finer control features provided by Burroughs
MCP (e.g., queue.memorylimit := xxx)
If you throw away most of the features of message files, you get pipes.
At a lower level, ports (dumb name) provide a fascinating and
powerful message passing facility. (Some similarties can be found
in the Amiga OS)
MPE's bad points:
1) overhead.
Because we have more protection, because we have a hell of a lot
more functionality, some operations take more time:
file opening
file closing
process creation
process termination
2) marketing
(including: A-Class clock slowdown, and 9000/3000 licensing issues)
3) marketing (yeah, thought I'd mention it again)
4) raw sockets ... or lack thereof
5) low-level terminal control/interaction
What we have works better than HP-UX's, but we don't have as much,
and some HP-UX (and other Unix) software is hard to port because of this.
MPE was never designed to be an operating system that gets interrupted
for every damn keystroke entered by the user ... unlike UNIX which
started life as a single user operating system. The result is that
we have never handled terminal I/O as directly (low-level) as Unix...
OTOH, that history shows why record-oriented (a line of characters + <return>)
I/O and block mode (an entire screen) are so efficient on MPE, compared to
HP-UX.
6) POSIX porting ... some rough spots
--
Stan Sieler sieler_at_allegro.com
www.allegro.com/sieler/wanted/index.html www.sieler.com
Received on Tue Sep 04 2001 - 15:52:00 BST