Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!security!genrad!decvax!ittvax!bunker!bunkerb!garys
From: garys@bunkerb.UUCP (Gary Samuelson)
Newsgroups: net.unix-wizards
Subject: From VMS to UNIX
Message-ID: <245@bunkerb.UUCP>
Date: Fri, 30-Sep-83 16:08:53 EDT
Article-I.D.: bunkerb.245
Posted: Fri Sep 30 16:08:53 1983
Date-Received: Sun, 2-Oct-83 20:37:17 EDT
Lines: 108

The discussion of moving from one OS environment to another
(TOPS-xx -> UNIX) has prompted me to add my two bits worth.
I have recently moved from a VAX/VMS environment to a VAX/UNIX
environment, so I think it safe to say that the difference is
in the software.

So far (approximately 6 months) I prefer VMS.

Several reasons come to mind, without even trying hard:

1. Useful documentation.  The VMS manuals are complete, consistent,
   and indexed.  For those of you who don't know, in this context
   'index' means an alphabetized list of topics, with references
   to volume(s) and page(s) where each topic is discussed.  Yes,
   I have seen the permuted index at the beginning of the Unix
   Programmer's Manual; I'm not impressed.  To use the Unix
   Programmer's Manual, I have to have prior knowledge of either
   the name of the command which does what I want, or the wording
   of the one line description of that command.  The problem is
   compounded by the fact that the manual I have is a hybrid of
   '3rd Berkeley Distribution,' 4th Berkeley Distribution',
   '7th Edition,' local stuff, and who knows what else.  In general,
   if I don't already have the information I need, it's hard to
   find it in the manual.  Not all the commands are documented
   in my manual, anyway.

2. On line help information.  And, yes, I know about the 'man'
   command.  With many of the VMS utilities, there was a 'help'
   facility which could be used while running that utility.
   Furthermore, you could specify what topic and subtopic and
   subsubtopic you needed help on.  Of course, if you have
   already memorized the manual, you don't need help, and would
   not find this a useful feature.

3. Meaningful status messages.  VMS features 4 part status messages,
   each of which can be individually disabled, if you're fond of
   terseness.  The four parts are facility, severity, mnemonic, and
   text.  Facility is the name of the software which discovered the
   error, severity is how bad it is (success, information only, warning,
   severe, fatal), mnemonic is an abbreviation (such as NOTFOUND), and
   text is a descriptive phrase.  The other day, using Unix, I spent an
   hour trying to find out what 'error code 1' meant.  It turned out
   to mean a multiply defined symbol.  When 'cp' can't open a file,
   I need to know why not.  Was the name mispelled, is it protected,
   is the device offline, is the device protected, is the device
   broken, is the device full, etc. etc.

4. Meaningful status codes.  This is really the binary equivalent of
   the status message.  The low 3 bits of the status returned by
   VMS functions indicates whether the function was completed
   successfully or not (this translates directly into severity,
   above).  Conveniently, odd numbers always meant success, but
   could mean success with additional information.

5. Meaningful file extensions.  With VMS, you don't need to have
   a program called 'file' to 'guess' what type it is; you know
   by looking at the extension.  A source file for the BASIC
   language ends in '.BAS'; for FORTRAN, '.FOR' etc.  An object
   file ends in '.OBJ'.  A command file (script in Unix) ends
   in '.COM'.  Unix's 'file' utility has called scripts 'C'
   source text on occassion.  By the way, what's the difference
   between 'English Text' and 'Ascii Text'?  As an added benefit,
   if you invoked the Fortran compiler, it knew it was supposed
   to look for a file whose name ended with '.FOR', if no
   other extension was supplied.

6. Consistent command formats.  Qualifiers always start with a
   slash.  Filenames always consist of alphanumerics (yes, I've
   seen the arguments about funny characters in file names, and
   I know they are occassionally useful).  Qualifier names can
   be more than one character long, so you don't have to remember
   whether '-o' or '-O' is what you want.

7. Automatic version numbers.  Each file has a version number
   associated with it.  When you make a change, the version number
   is incremented.  When you specify a file without an explicit
   version number, the latest version is used, which is usually
   what is desired.  When you delete a file, you must specify
   a version number, so that files don't get deleted accidentally.
   If you make a change which turns out to be incorrect, the
   previous version is still available.

8. Abbreviations.  Both command names and qualifier names could
   be abbreviated to the minimum required to be unique.  The full
   name could be used in a command file, both to aid a future
   reader and to prevent ambiguities when a new command is added.

9. User defined commands.  Under VMS, I could define a command to
   replace any of the system commands, and it didn't require a
   dollar sign in front of it, it didn't require a whole file
   (minimum size 1 block), and it didn't take up room in my directory.

10. Separate protection bits for write and delete.  I could keep from
    deleting a file, while retaining the ability to modify it.
    Useful in conjunction with version numbers.

11. Consistency.  This is probably the biggest, without which some
    of the problems above could not be fixed.  Only one company
    supplies VMS, as far as I know.  You can add your own modifications,
    but no one else is expected to consider them part of VMS.
    Since VMS comes from only one source, there is the possibility
    of vendor support.

Those are advantages, in my opinion, of VMS over UNIX.  And yes, I
do know that UNIX has advantages over VMS; I know about pipes, and
subshells.  But so far I prefer VMS.

Gary Samuelson