Path: utzoo!utgpu!water!watmath!watdragon!trillium!bpdickson
From: bpdickson@trillium.waterloo.edu (Brian P. Dickson)
Newsgroups: comp.os.vms
Subject: Re: Help us defend against VMS!
Summary: Opinions, some facts
Keywords: VAX, UNIX, VMS, together
Message-ID: <5468@watdragon.waterloo.edu>
Date: 2 Mar 88 22:54:49 GMT
References: <2235@bsu-cs.UUCP> <2075@rti.UUCP>
Sender: daemon@watdragon.waterloo.edu
Reply-To: bpdickson@trillium.waterloo.edu (Brian P. Dickson)
Organization: U. of Waterloo, Ontario
Lines: 53

I have caught the end of another skirmish in a battle that shouldn't exist.
Why do I say that, you ask? Because VMS isn't UNIX and vice-versa, which is
important in its own right. Because, in an academic environment, exposure to
more than one *good* operating system is important. Because they both run on
VAXen.

There are companies, such as HCR in Toronto, who make UNIX emulations that run
*on top of* VMS, making both OS's available simultaneously. This may be avoiding
the issue, but for a small campus with only a few machines, this is one route.

Pro-UNIX: most of these arguements have been heard. Many vendors, source,
portability, the 'net, modifibility, etc.

Pro-VMS: not many of these have been mentioned yet: in non-academic
environments, DECnet is tremendously useful, because with a very large number
of machines, you never worry about paths; however, machine names must be unique.
If a large number of campuses connected via DECnet, information could be shared
very easily, via DEC's CONFERENCES (basically a cross between UNIX news, and
BBS's). Also, if someone makes a file (W:R) readable, you can SET DEFAULT to
his *machine & directory*, and do stuff with the file. Security is a larger
issue, normally controlled by the addition of machines to the network, and
tyrranical managers on each machine. 
Another thing in favour of VMS is the HELP facility; it can be used to get a
lot of useful information about languages as well as utilities; true, not all
of the information is always available, but for most languages, syntax, usage,
parameters for functions, and structure can be found; the tree structure of
help is one of its best features.
The main arguement for *how* VMS is intended to be used, most systems written
under VMS are intended to be installed commands, which involves more than just
putting it in the equivalent of /bin. It is meant for less-than-fully computer
literate users. *This does not mean secretaries, as it does with IBM :-)*.
This means you can set up an entire system for, say, a research scientist, and
the fact that *you* wrote it is invisible to him. (When it breaks, you can
blame DEC :-) :-) :-). This means parameter-passing, help, and lots of other
things are handled mostly by VMS, not your own programs.

Details on CONFERENCES: instead of sending the stuff all over the country,
the article remains on the machine, until it is read (ie the contents are
sent over via DECnet, but never stored). Each machine/site/cluster does not
duplicate stuff; however no single machine has all of the news stuff on it.
EG: watmath would have sci.math.*, another machine would have rec.arts.*,
utzoo would have sci.space.*, and so on. Less usage of disk space, more
usage of the network itself. Great for very specific, high signal/noise ratio,
real-news stuff, ie the faculty & grad students on most campuses.

========
Recommendations: Get UNIX *and* VMS machines for undergrads, VMS for grads,
faculty and administration, if you can afford it. If not, get VMS with a UNIX
implementation running on top. You may need an ULTRIX between other UNIXes and
the VMS machines for them to talk, but if most code is written in portable C
code, not many problems will arise.
--
Brian Dickson