How do Unix and VMS compare?

[rbbb at RICE.ARPA]

From:  David Chase <rbbb at RICE.ARPA>

I wasn't going to CC info-unix, but that seems to be the thing to do,
sooo...

VMS over UNIX

	The fortran is better; it is mostly correct, doesn't explode on
correct code, and is usually faster.  It also provides better error
messages.
	I think the Pascal is better, but I haven't compared the two
myself (I hate Pascal).  The Pascal jocks want me to be sure that VMS
Pascal is under maintenance, etc etc, and they seem to use it more than
the Pascal that comes with Berkeley Unix, so I guess they like it better.
	If you use macro-assemblers, there is none for unix, and MACRO-32
is fairly feature-filled.  I wrote the back end of a BCPL compiler in
MACRO-32 (OCODE --> assembly language).
	When the next minor version of VMS comes out, your programs will
still run.  When the next major version of VMS comes out, your programs
will still run.  We are still running (under 3.6) programs that were
linked under 2.5, and these programs are linked against a user-written
library full of change-mode vectors.  Of course, the library is installed
as a shareable image, so it has been changed many times.
	With VMS, you can do all of the things that are hard under unix;
you can do mutual exclusion, you can do shared memory, you can do
concurrent io.  You can single-step debug your kernel-mode code, if you so
chose.  You can reload device drivers without rebooting the stinking
operating system.  You get ISAM files, if you want them.
	VMS is easier to manage.  You have much more control over
resources than under Unix.  Batch queues, for instance.
	VMS tends to get more performance out of its hardware, through
clustering, asynchronous IO, and good paging.  These things can be tuned
for a particular installation, though they can also be mistuned.
	If I write something under VMS, and decide I maybe want to sell it
or give it away, I don't have a dozen lawyers breathing down my neck.
	Shareable images and shareable libraries are pretty fun;  shared
programs (like shared text) for the images, and shared libraries (like
nothing available in Unix) for shared text and swift and easy software
updates (change the library, but don't need to relink).

UNIX over VMS
	Most of the VMS "user interface" is abysmal.  We're talking EDT
for an editor and DCL for a "command language interpreter".  No make.
No awk.  DCL scripts can be almost bearable, and you can get at all sorts
of neato information from DCL, but there's no IF, no DO, no CASE; only
GOTO.  Perhaps there DEC program products out there that make life
bearable; the people here chose the path of writing a unix emulator,
rather than porting the selected useful programs.
	Certain operations are slow under VMS; some file io and process
creation are two.

	Special VMS hates:

	I can run my terminal (it's a file, right?), but to get its
protection I have to do a (from DCL) F$GETDVI("TT", "VPROT") rather than
whatever I might do for a real file.  This sucks a bit.
	There is no explicit way to make links, but I can by making the
source directory non-writeable, then renaming into the target directory.
This allows everything BUT a single node directory loop, which is
explicitly verboten for some bizarre reason.
	"Concealed devices" may only be one directory level deeper than a
real device, and there is no way to "SET DEF" to the root of the concealed
device and have it still act like a device.
	Although there appears to be some sort of terminal-independent
library for VMS, many or all of the screen-oriented programs don't seem to
use it.
	Networks??  With DECNET you can speak to any other DEC OS around.
Who would ever want to do more????  (Actually, there do seem to be
provisions for speaking SNA and X.25, but I'm not terribly familiar with
them).
	File names are TOO short (N.B. this goes away with VMS version 4,
up to 39.39.version number, I think.)

	Special VMS loves:

	BACKUP is really ace, though it has a fairly steep learning curve.
Much more function than tar.  (Not as hard to learn as "find", because I
have wanted to use both, and I still haven't figured out "find".)  This
may not seem like much, until you lose some important data.  I can do
BACKUPs on an active file system.
	When I say "help", I usually get help, and there appears to be a
uniform help interface across DCL and many commands.
	The RMS file syntax, though grotesque, is often used to provide
more power than I get from the Unix shell expansion syntax.  The most
useful feature for me is the ability to say "all files in this directory tree
that look like this", as in "[...]*.obj.*".  Someone could add this to
their favorite shell without too much damage, I think.  I could do this
with a find, but as I said before, I haven't been able to master find.
	I can add pagefiles and swapfiles while the system is running, and
I need not scratch a disk to expand them (N.B. this depends very much on
the availability of contiguous space for creation of these files).
	I can read and write ANSI label tapes (remember ANSI?? you know,
"ANSI: consider it a standard...") so that I can communicate with other people
running practically anything but Unix.
	Logical names:  They're great, period.  We hacked unix "make" to
treat environment variables in the same way.
	Things WORK.  No surprises (except for those mentioned above).
	The options to commands have names that I can remember.


Special Unix hates:

	A stinking minor version change breaks the whole world.  Already
there are two different Unixes.
	Unix encourages C, and that is bad.  C is just assembly language
with pretensions.
	If I miss a keystroke, I type "rm *>CKP".  This is very bad.
	Often things don't work.  The "bugs" section on every manual page
is a real loser, since no one seems to fix things, and if they did, that
might break someone's program that depends on the bug.


General impressions:  probably if you have a gang of software developer
sort of guys, they will want to run Unix because "it makes them more
productive".  I expect that Unix + make + awk + emacs (you can afford it)
will allow programmers to hack out more code than they would under VMS,
but they might not need to hack out so much code under VMS.  This depends
upon the nature of the code being written.  I snicker every time I see
some plea for ISAM files or mutual exclusion or shared memory on the net.

Once an application is written, I expect that the previous user interface
(shell or DCL) will be hidden, and that the quality of the OS underneath
will be more important.  From this point of view I think that VMS is much
better (I know, I know, QIO takes a million parameters, but most of them
are optional, and it usually does the right thing if you leave them
alone).  Imagine this situation; I have invested zillions of dollars in an
application (running under 4.1) that has become essential, and it won't run
under 4.2.  This can also happen in VMS land, but is much less likely.

In an educational environment, there are again tradeoffs.  Educational
machines here have had bad problems with severe load and security
doodling; I'm not sure that VMS would help, but I suspect that it could.
Many of the neato-utilities for Unix could be rewritten for VMS (for
instance, one of the programming projects for a course here was "make"
written in Pascal).

I am very very happy with emulators; we run Phoenix (written here) and I
freely switch from one interface to the other (to the utter disgust of the
Unix Zealots around here).  I have learned to use EDT for the quickie
editing jobs, and emacs for the more involved ones.  We wrote IP and UDP
for VMS, so we can communicate in a primitive fashion over the ethernet
(I'm sorry, but UUCP is just a little too mickey mouse for me.  I've had
to use it, and I hate it).  Much of this software is available, or soon
becoming available.

For some background on why I say what I do; I have managed a 780 running
VMS+Phoenix for over two years now, and I do program development on
whatever is available.  Both the VMS and Unix have been heavily sanitized
with local scripts, com files, and programs; I am nearly helpless in
vanilla Unix (not so for VMS only because I am manager and MUST know how
to work in raw VMS; all of our users are non-portable). In a pinch I fix
things on the "real" Unix machines.  I also maintain emacs across Phoenix,
4.1, and SUN/BSD4.2. In my much darker past I used cards on an ITEL (now
NASCO) AS/6 running MVS, later SPF.  Did you know that you can pipe the
output of one JCL job step to the input of another? (Chew on that).

drc