(MPE vs VMS) HP & Compaq

On Tue, 4 Sep 2001, Stan Sieler wrote: That occurred to me after I sent it, and I realized that I was something of an ASSSSSS :-) Well, these are OS's of classic hardware. And I still want a 3000 for the collection. Below are my justifications for my statement, admittedly biased as a system manager with considerably more VMS experience than MPE: - 4GB limit on MPEXL_SYSTEM_VOLUME_SET even if you have a larger drive - no software mirroring of this 4GB. Neither of these limitations exist on versions of VMS released in approximately the last decade, although there are specific size limitations tied to certain models of older hardware that have been discussed here. Admittedly hardware RAID is a better solution but not always an option in real life - 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. - 8 character names of MPE namespace files and queues is VERY hokey. I attended an MPE class at HP in Boston presented by one of the regulars on comp.sys.hp.mpe and he carried on about the cryptic nature of Unix commands but he lost all his moral authority on that topic as far as I was concerned with this limitation in place. Cryptic commands vs. cryptic filenames and queues, a pain either way. None need be cryptic in VMS. - HFS/POSIX namespace files don't map cleanly to 8 character MPE namespace files with symbolic links. A personal gripe; my specific problem was I wanted a legible HFS/POSIX filename for a file to be accessed by a 8 char MPE namespace compatible COBOL program. I created a symbolic link which caused a MPE filename supposedly to map to the HFS filename. I was unable to get the old COBOL app recognize it although other things could, and using a file equation was not an option I wanted to pursue. - The EDITOR edlin wannabe editor seems limited compared to vi and makes TPU/EVE in VMS seem like star office in comparison. It was funny listening to the intructor carry on about vi and then use EDITOR. Another personal preference quibble, I suppose. - You cannot edit many system files using vi without corrupting them and needing to FCOPY them back into a usable format. This is supposedly fixed in the current MPE release, which I don't have. FCOPY is analagous to CONVERT file /FDL in VMS. - The onerous patching and upgrade process, and the difficulty of determining your actual patchlevel from the OS maintained files. VAX versions of VMS are not any better as far as determining your patch level. But the patches/upgrades are decidedly less onerous. - Patches are not generally available for download and can not (until the recently released current version??) be installed from CDROM. - 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. Sendmail itself IMHO is one of the cryptic low points of Unix software and hardly an asset to MPE. - The facility to automatically reboot without operator intervention at the system console is a separately sold option. (see Autorestart/IX) - 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. - User licensing & hardware very strictly tied. - 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. I believe the only hobbling of CPU's done with Alpha was between machines intended to run only NT vs. those intended for all platforms and then it was a functionality rather than speed modification. What I do like about MPE/IX - 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.