From VMS to UNIX

[Guy Harris]

Some of the points are valid criticisms of UNIX, some are not:

	1. Useful documentation.

UNIX documentation is useful for people who already know what is there.
There is no way that a state where the existing UNIX documentation is the
*only* documentation available can be justified, except by saying "we can't
afford the time".  Now that UNIX is a Real Live commercial operating system,
this doesn't hold water.

	2. On line help information.

On this one, people may argue that VMS-style on-line help is the wrong
solution to the problem.  I don't take any stand on this myself, but I
can see the point of the people who want more than "man".

	3. Meaningful status messages.  VMS features 4 part status messages,
	   each of which can be individually disabled, if you're fond of
	   terseness.

I don't know if I'd go as far as having UNIX put out VMS or OS/360-style
error messages (I seem to remember a case where a low-level VMS routine
detected an error; it dutifully printed an error message, and passed the
error code back to the next routine up, which dutifully printed an error
message, ...), but "can't open"-type messages aren't the best that can
be done.  If UNIX told you why the file couldn't be opened, it would save
a lot of "ls" commands to figure out if the file doesn't exist, or isn't
readable/writable by you, or....  ("perror" doesn't provide the ideal
interface for producing the sort-of standard UNIX error message
"program: complaint").  N.B. UNIX isn't the only system which does this;
RSX-11M also has "can't open"-style messages.

	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.

The inability of UNIX system calls to indicate success with additional
information (like "the write to the tape succeeded, but it also hit the
foil at the end of the tape") is a nuisance.

	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.

With UNIX, a source file for the C compiler ends in ".c"; for FORTRAN, ".f",
etc.  An object file ends in ".o".  A command file ends in nothing, because
it can be *either* an executable image (VMS ".EXE") or a shell file
(VMS ".COM").  "File" does the best it can with heuristics, but it can't
get it 100%.  Nothing prevents you from creating a file with a null extension,
or worse an *invalid* extension, with VMS.  I could create a binary file
called "FOO.BAS" and watch the fun when someone tries to "TYPE" it.  (The
difference between "English text" and "Ascii text" is based on character
frequencies, although a file of all nulls is considered "English text"(!).)
As an added benefit, you can type

	f77 foo.f bar.f bletch.c mumble.s frotz.o

and compile and link a program consisting of two FORTRAN modules, one C
module, one assembler module, and one already-compiled object module.

	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.

The UNIX command format is a bit of a pain, but there is a tradeoff between
terseness (which speeds up work) and clarity.  Qualifier names in UNIX
*can* be more than one character long (the "-onetrip" qualifier to "f77"
is a case in point), but they generally aren't.

	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.

As long as the operating system can be told to keep only the last version,
or last N versions around, this isn't too bad (although there is code
required to implement it, and extra work for users; there is a tradeoff
here).  If versions hang around until you explicitly purge them, this is
no good, because versions can pile up (I saw a file on a VMS system with
50 some versions!).  Under UNIX, systems like the Source Code Control
System and the Revision Control System provide this and more besides for
source files, and having several versions of object or executable code
is of unclear merit.

	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.

Abbreviated command names would be tricky under UNIX because of its flexibility
in adding new commands.  To disambiguate the command it would have to look
in ALL the directories in your search path.  Which brings us to:

	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.

If your command did a lot of work (i.e. it wasn't just a shell variable),
it would be either a program or a shell file and as such would have to
take up a whole file and a directory entry.  Some UNIX shells (the C shell
and the Korn shell; the latter is an extended Bourne shell) support the
ability to add commands by creating "aliases" or "functions"; in this case
they do not require an executable or shell file.  How convenient is it to
add new commands under VMS?  Under UNIX you can have multiple directories
full of commands, and as soon as you drop a file in there it is available
to everyone who has that directory in their search path.  Can the same be
said for VMS?

	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.

Nice, but again there is a tradeoff here.

	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.

Well, since VMS only runs on one machine this is a bit easier to do.  Try
a shop with a VAX-11 or two and several 68000-based workstations.  Unless you
put VMS up on the 68Ks (a little tricky, considering how much of VMS is still
in MACRO-32) you have a far greater consistency problem than if they both
ran UNIX.  UNIX comes from several sources and the vendors generally support
it (Bell supports the PDP-11, VAX-11, and 3B versions, and most people offering
"UNIX boxes" support the version on their machine).  Western seems to be trying
to bring all UNIXes under one roof (theirs), with their arrangements with
the major chip vendors.

So yes, there are things that VMS (or any other OS) does better than UNIX,
and there are things UNIX does better than other OSs.  One thing UNIX does
better than almost all other operating systems is run on most of the machines
a heterogeneous site has in house; this alone is worth a *lot*.  (We can do
development on fast VAXes, and ship the code to our 68000 machines and debug
it.)  So it's certainly not an open-and-shut case for VMS; if a lot of the
problems with UNIX that *can* be cleared up are, a lot of the anti-UNIX
arguments will fall by the wayside.

	Guy Harris
	{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy