(MPE vs VMS) HP & Compaq

Re: 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...:) Yep. Of course, software mirroring sucks anyway :) true. So, use HFS files! (POSIX hierarchical directory structure and file names) 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 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.) 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 :) 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. 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.) 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. 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. true...but we have sendmail, too. So? BTW, if you want to trigger a reboot remotely, that ability has been available for about 15 years ... not well known, perhaps. 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.) So? That's not an *operating system* issue, that's a *product* issue! 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! 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(a)allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com