Message-ID: <anews.Aucbvax.5711>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Mon Jan 11 17:59:43 1982
Subject: Purpose of this list

>From mike@RAND-UNIX Mon Jan 11 17:53:05 1982
Is it my imagination, or has "INFO-VAX" become "INFO-VMS"?

Couldn't we start an INFO-VMS list for these messages and leave
INFO-VAX for messages and comments about the VAX hardware and
product line?

Thank you very much,
A Berkeley VMUNIX user,

	Michael Wahrman

Message-ID: <anews.Aucbvax.5793>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Thu Jan 14 16:30:54 1982
Subject: INFO-VMS mailing list creation

>From Samuelson@SANDIA Thu Jan 14 16:25:48 1982
It is obvious that it is time to create INFO-VMS.  I think it would be
nice if some VMS system would support it, but until someone volunteers,
I will get it started.  Please send a note to Samuelson@SANDIA if you
want to be on the list.  I will be out of town until Thursday, Jan 21,
but will make up the list on that date from all the responses I get by
then.  If someone with a VMS system on the net volunteers I will send
the list to them.  Lets give the UNIX guys a break, they have enough
problems of their own, just like anybody who runs VMS does!

On Thursday, Jan 21, I will send a note to everybody on the list,
wherever it will live, announcing it.  Fair enough?

- Sam -
-------

Message-ID: <anews.Aucbvax.5791>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Thu Jan 14 16:06:31 1982
Subject: Discussion of what is appropriate on this list

>From JSOL@USC-ECLB Thu Jan 14 16:04:48 1982
Let this be the final message on the  subject. When I created INFO-VAX
I had intended that  it be a resource  for VMS Systems programmers  to
use to  communicate   on  problems   (as   UNIX-WIZARDS  is  for  UNIX
people).  Since  then the  discussion has   broadened into  a  general
discussion  of VAXen, both hardware and software, and INCLUDING  UNIX.
I welcome this broader aspect  and recognise the potential benefit  to
the I  whole   ARPAnet  community,  and  I  am    perfectly    willing
to allow  this to  go   on,   but   am very disappointed that   people
have nothing better  to  do   with their   time other   than flame  on
INFO-VAX about  how they don't want to hear  about VMS bugs.

In the light  of this, I  hearby declare that  topics relating to  VAX
hardware or software, VMS or UNIX, or any other operating system (such
as RSX, believe it or not there is a version of RSX which does run  on
VAXen) are welcome on  INFO-VAX.

If you are on the list for ANY OTHER REASON, then please get off  now.
Send mail to  INFO-VAX-REQUEST@MIT-AI and  I will be  happy to  remove
you. 

What everybody  has to   do  is weigh whether  or not the benefits  of
being on this list are greater or less than the amount of trouble  and
time you have to spend weeding  out the junk. ALL mailing  lists  have
this  problem, *even* mailing  lists  which are in  the digest   form,
or have   delayed redistribution   (such that  a moderator  weeds  out
requests to be added, etc. The  moderator's responsibility is  limited
to just THAT!).

Please, let's not  flame on  about the appropriateness  of some  vague
group of subscribers, or submitters. If  you wish to discuss this  any
further, please send mail to INFO-VAX-REQUEST. If this discussion gets
too far  out of  hand, I  *will* institute  policies to  prevent  such
things from happening again  (such as delayed redistribution).  Please
don't force me to do this!

Angrily,
JSol

Message-ID: <anews.Aucbvax.5798>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Thu Jan 14 19:53:07 1982
Subject: The final word on INFO-VAX vs INFO-VMS (Oh how I wish)

>From Samuelson@SANDIA Thu Jan 14 19:45:57 1982
Since the mailing list INFO-VAX was created and has been maintained
by JSol, I think it is reasonable to continue to use it as it was
originally established.  Therefore, INFO-VAX will continue to be open
to any and all discussions of VAX related topics, including hardware,
VMS, or whatever.  Please accept that as a fact.

The list has been moved from MIT-AI to SANDIA, since SANDIA is not
as busy as AI.  The addresses of interest are:

	INFO-VAX@SANDIA		to send to the whole list
	INFO-VAX-REQUEST@SANDIA		for all changes to the list

As a result of this, I will NOT be creating a new list for INFO-VMS
and I hope that no one will.  Let those who are interested in UNIX
use their list if they wish.  If you are not interested in remaining
on this list please send a note to INFO-VAX-REQUEST@SANDIA.

- Sam -
-------

Message-ID: <anews.Aucbvax.5807>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Sat Jan 16 10:40:02 1982
Subject: pandora's box

>From MILLER@MIT-AI Sat Jan 16 10:28:50 1982
In asking folks about vms versus unix, I have seen very strong opinions
by very knowledgeable people on both sides.  I have never seen so little
consensus among the group of people whose opinions I normally trust.

We are about to get a VAX.  We want to run LISP (whatever flavor is
going to be widely adopted and well-supported).  A lot of the usage
will be for text editing (as close to ITS Emacs as possible), document
preparation (as close to R as possible), and electronic mail (as close
to BABYL as possible).

Which OS should we run, ignoring the small matter of $43,300 for System III
sources plus Berkeley stuff (we are a private company) if we choose unix?

Thanks, Mark
ps. If the moderator feels this topic is inappropriate (or too controversial?)
for the list, please feel free to just reply to me privately.

Message-ID: <anews.Aucbvax.5809>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Sat Jan 16 11:43:37 1982
Subject: pandora's box

>From JSOL@USC-ECLB Sat Jan 16 11:35:13 1982
You seem to  be missing  my point.  I think your question is just  the
kind of thing that should be asked. I don't think anyone has  disputed
that. The problem was that people were asking specific VAX   questions
(e.g. about a  specific operating  system), and   other  people   were
calling  the  topics inappropriate.   I   think   any  discussion  wrt
VAXEN  is appropriate on a list called INFO-VAX.

--JSol

Message-ID: <anews.Aucbvax.5823>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Sun Jan 17 00:53:32 1982
Subject: Standards

>From FC01@USC-ECL Sat Jan 16 23:18:57 1982
	I was wondering about peoples attitudes  towards standards in systems
and programming languages. I somehow manage to often get caught  in the midst
of  an argument/discussion about  some so called  standard. As an example, I
am currently in a drawn out flaming session about (of all things) what user
name  to give users on a Unix system. Now it all  started when I asked people
what they wanted their user IDs to be. Is that a sin! I was met with three
opinions, my own being that people should get any userID they want, and if
they don't care to specify one initials  are as good as  anything else. Alas
the arguments came: 'You should force people  to use their ARPA-NET name'
'You should default to the arpanet name' 'you should  use last names' 'you
should allow choice and  default to  <arpanet/last> name',  ... etc. I guess
good healthy dissagreement is  a good thing, and people should be aware of all
the  options available  to them, but I  just can't see people getting all  in a
a huff about things that are features. I am pleased with any feature I find,
but I  don't live or die by them. I don't call people fools or turkeys just
because they don't have my favorite version of my favorite feature in their
version of my favorite <language/editor/command  interpreter/...>. I don't
think that all fortran (and yes even Cobol) programmers are in the last
century. I  do however think that  every system should have a good macro
processor that  allows the user  to flexibly determine the  user interface
desired for any given type of usage, and allows a reasonable degree of system
feature/drawback independance. I guess I am crazy, but  I find that fortran 4
is transportable almost anywhere with little trouble if you  keep to the
standard, and I try to just so I can remain free of system quirks. I also use
more or less standard lisp 1.5  or so  features to avoid the pain  of changing
lisps. I also use the individual debugging features, etc, but try  to  keep my
code pure. So the next time you  feel like flaming about such things, be glad
you have what you can get,  try to make life better for yourself by asking if
better things exist, but don't insult your own intelligence by using abusive
phrases like I sometimes do.
			Fred
-------

Message-ID: <anews.Aucbvax.5843>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Mon Jan 18 17:26:13 1982
Subject: Th Fight of the Century

>From RUBENSTEIN@HARV-10 Mon Jan 18 17:22:55 1982
Samuelson ought to sell tickets -- someone could make a mint on this.

I use VMS and have been as my primary activity for the last year.  I have
also run vmunix on my 750, although I am not nearly so experienced with
that system.

Anyone who says that VMS is obviously unusable in a program-development
mode is full of it in the worst way.  I have found that as a total system
(hardware, software quality, reliability, documentation, transportability,
facility of use, hardware adaptability and many other factors), VAX/VMS
is a superior system to evry one with which I am familiar (let me stress
that unix is not yet among these).  This includes systems ranging from
IBM DOS and WYLBUR oriented systems to HP-3000 to TOPS-10, Tenex and Tops-20.
The thought and coordination that have gone into the planning of VMS are
impressive, the more so when you begin to learn about its internal
structure.  It is not the hairy mess that unix die-hards scream about;
rather, it is a clean, well-thought-out, reliable system.

Furthermore, while I do NOT claim that it is an ideal programming
language, FORTRAN-77 on VMS can be used to produce efficient,
maintainable, transportable programs, if used with care by someone who
has been trained to do so.  I would even go so far as to add that it can be
done efficiently with respect to the time of the programmer.  Every experienced
programmer knows that the actual coding phase is small;  the trade off
is invariably between the design and debugging times.  I submit that
the design phase is relatively independant of the eventual language
of implemantation, and that since this is the most profitable place to
put your effort, the choice of language is quite secondary.

My initial, limited experience with unix has led me to believe that
it has many worthwhile features.  My initial impression is that it
is not as efficient as VMS for heavily loaded systems.  However, I am
not qualified to make comparisons yet.  I would appreciate it if
you wouldn't do so either, unless you have extensive experience with
BOTH systems.  I would welcome, even applaud, the person who can give
me an honest comparative critique of the two systems with a reasonable
overview perspective.  We do not need to refer to one another as
"braindamaged" or "narrowminded" -- if these systems have the advantages
that are claimed for them, a simple presentation of the facts should
be more than adequate.

Stew

Message-ID: <anews.Aduke.1643>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!mhtsa!harpo!chico!duke!bcw
X-Path: utzoo!decvax!ucbvax!mhtsa!harpo!chico!duke!bcw
From: duke!bcw
Date: Tue Jan 19 22:14:54 1982
Subject: VAX/VMS versus Unix

This is in reply to the query from MILLER@MIT-AI about the
virtues of VAX/VMS versus those of Unix.  The article is
rather lengthy, so those not interested in discussions of
this type should be warned.

Unfortunately, I don't see a clear-cut preference for either
VAX/VMS or Unix on the merits of the operating system alone.
The systems have rather different ideas about what is and
is not important, and any evaluation must consider the
rather different environments which the two systems were
designed to address.  This discussion will be broken up into
sections comparing specific areas of the operating systems.

I. The user's view of a file

In Unix, the user's view of a file is that of a series of
bytes.  Lines in a text file are delimited by <newline>
characters, which makes the processing of text files quite
uniform.

In VMS, the user's view of a file is that of a series of
records.  Lines in a text file are typically separated into
a one-to-one correspondence with records (although this is
not strictly necessary).  Some text files might have embedded
carriage control (a la Unix), and some might just be records
without any explicit carriage control (there is a special
designation for files of this type).  The system supports
features such as ISAM and record locking to prevent the cross-
update of records in a file.

It is difficult to compare the two forms of file organization
because they are intended to fulfill different capabilities.
It seems to me that it is easier to deal with the text files
on Unix because they have a uniform format, and you don't
have to worry about all of the different types of records
(fixed-length versus varying-length, Fortran carriage control
versus internal carriage control versus implied carriage
control, and sequenced versus non-sequenced) in your programs.
On the other hand, files which are shared in large, multi-
user applications are easier to deal with on VMS than on Unix
because Unix provides no method to prevent cross-update of
records (indeed, the concept of a record is foreign to the
Unix file structure).  There have been some hacks developed
to allow only one user access to a file, but these are not
always useful in large applications -- they can drastically
affect throughput when many records are being modified.

II.  The user's file areas (directories)

Both Unix and VAX/VMS support tree-structured directories.
File names in Unix may be up to 14 characters long, and
may include any characters (except things like blank and
tab, and the directory separator character, /);  upper and
lower case alphabetics are considered different characters.
File names in VAX/VMS consist of a 0-9 character name and a
0-3 character extension, all alphanumeric;  upper and lower
case alphabetics are considered identical.  VAX/VMS has an
interesting feature called the file version number, which
means that old versions of your file will be preserved until
you delete them (the number of old versions preserved can be
adjusted).  Both of these schemes seem reasonable.

III.  The internal implementation of the file system

In Unix, a file internally looks like a list of blocks.  The
list is represented as a tree of pointers in a data structure
called an i-node.  File buffers are kept in the system area
and the user must execute system calls to read or modify them
(even if they are currently in memory).

In VMS, a file internally looks like a list of extents (that
is, contiguous groups of blocks).  The list is represented as
a list of pointers in a data structure called a file header.
File buffers are kept in the user's area and the user may
read or modify them directly.  It is possible to specify such
things as read-ahead or write-behind on multibuffered files
to speed up access.  It is also possible to do multiblock I/O
to the files (thus using the semicontiguous nature of the
files, since contiguous blocks can be read in one operation).

The Unix internal implementation is simpler, but the VMS
internal implementation allows greater throughput (at least in
some applications).  The larger throughput will probably not
be noticeable unless the system is dealing with large files.

IV.  The command structure

A Unix command is the name of a program in one of several
default directories.  The parsing of the options on the command
line is left to the individual programs (leading to a certain
amount of inconsistency in option processing), but the wild
cards for the files are expanded before the names are passed to
the program.  This has the advantage that everything can use
the wild card file names, and the disadvantage that it is not
possible to use wild cards for other purposes (for example, the
names in the user authorization file) without quoting the wild
cards.

A VMS command is processed by a command interpreter and may be
abbreviated to as few characters as are unique.  The parsing of
the options and the files on the command line are done by the
command interpreter, which leads to more uniformity in the
syntax of the commands, but makes it harder for non-hackers to
add new commands since they have to grow their own parser.
The wild cards are not expanded by the command interpreter, but
are left to the individual programs.  This has the advantage
that wild cards can be easily used for purposes other than that
of file names, but the disadvantage that there are a number of
commands and user programs which don't bother to expand the
wild cards, leading to non-uniformity in the handling of wild
cards.  VMS commands also tend to be somewhat wordier than the
Unix commands, which may make them more mnemonic for new users
but which will make for more typing for those familiar with the
system.  The system will prompt for arguments not given to a
command, easing the introduction of new users to the system.

The Unix command language has the interesting property that it
is quite easy to direct the output of one command to the input
of another command without the necessity of creating temporary
files and so forth.  This is made especially useful given the
fact that Unix text files are all written in a uniform format,
so that there are relatively few incompatibilities to deal with
when doing this.

Interestingly enough, although VMS has the low-level operating
system primitives to do the same thing, the VMS people did not
put this type of capability into the user interface.  It might
not be as useful even if they did because of the different file
formats which proliferate on a VMS system, but it would be a
possibility.  There have been Unix emulations which run under
VAX/VMS which enforce the use of a standard file format and
which use these operating system primitives;  two which I will
mention are the LBL software tools (written in Ratfor) and the
Eunice system (essentially modified versions of Unix utilities).
These both make a VMS system look similar to a Unix system,
although the result is not as good as the original.

Both VMS and Unix have extensive online documentation, although
the VMS documentation is probably better organized -- they have
a tree-structured help facility, so that you don't have to get
information on all the obscure options that the command has in
order to find out the syntax for the one you want.  It isn't
perfect, but it's better than the one-page document which is all
the Unix commands ever get (even in the printed documentation).

V.  The Process Structure

Both VMS and Unix allow a process to own subprocesses;  both
also support processes running in the background (although they
use rather different terminology).  VMS also supports a batch
environment.  Both support the sharing of pure data (such as
the code of an executing program), but VMS supports the sharing
of pure data and code not just between different copies of the
same program, but between different programs.  The Berkeley
people have been talking about putting this type of capability
into Unix.

In the current version of Unix, all I/O is synchronous with
respect to the requesting process.  This often makes Unix hard
to use in real-time situations, although there has been some
talk about putting in asynchronous I/O (with a completion flag)
into some future version of Unix.  VMS already has this.

In Unix, it is easy for a process to run with the privileges of
the owner of its file rather than those of the user running the
file.  If the process is written in a secure fasion, this allows
anyone to write programs runnable by anybody which can modify
files owned by the writer but not readable or writable by the
world, without having to make any special requests to the
system manager.

VMS allows an image file to be "installed" with elevated
privileges.  Since the act of installing an image requires a
considerable level of privilege in itself, this is not something
which can be done without the intervention of the system manager.

VI.  System Integrity Issues

VMS will recover from many power failures (assuming that its
memory wasn't scrambled), and has support for dealing with bad
disk blocks.  The vanilla version of Unix does not address
these problems, although the Berkeley group has done some work
in this area.

VII.  Other Software Considerations

Unix has a great quantity of software available in the public
domain which can be obtained for a nominal fee.  VMS has some,
but generally not the quantity as Unix.  On the other hand, my
observation of public-domain software has not been very favor-
able;  generally, you seem to get what you pay for (nothing, in
this case).

Both have a number of packages offered by various firms which
you can find easily in ComputerWorld or any other trade journal.

VMS is currently supported by DEC with many layered products;
Unix support is currently in something of a state of chaos.
With the new consent decree, the support for Unix may approach
that of VMS, or Bell may let the current chaos continue.

I might mention that the above opinions about public domain
software are purely my own -- some of the people to whom I
have shown this article disagree with my evaluation of the
worth of public domain software.  Although a couple of the
public domain programs which I have encountered have been
worthwhile, I have had some bad experiences with others
which may make up for the useful programs.  Caveat emptor.

Also, if you get Unix from Bell, you get the sources with the
license whilst with VMS they are an expensive extra license.
Therefore, you can make modifications to Unix more cheaply
than to VMS.  VMS has update kits which come out about every
2-3 months, so modifying significant system components can
be a risky business.

VIII.  Conclusions

Unix tends to work best in environments which consist of many
small projects, especially those with lots of text editing.
Unix may also need more attention from support staff because of
the question of support for the system.

VMS tends to work best in environments which consist of large
projects, especially those with real-time or large, heavily
disk-bound applications and relatively little text editing by
comparison.  VMS also works well in situations needing a lot
of outside software (either from DEC or others), since there
are probably rather more packages offered for VMS than for Unix,
at least by commercial enterprises.

To sum up (and oversimplifying outrageously), Unix tends to be
better in timesharing shops with a sophisticated user group
and in program development (academic computing, for example),
and VMS tends to be better in the real-time and traditional
data processing environments where program running time can
be at least as important as program development.

			Bruce C. Wright @ Duke University

Message-ID: <anews.Aucbvax.5854>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Tue Jan 19 23:21:25 1982
Subject: Unix VMS Eunice

>From decvax!duke!ucf-cs!whm@Berkeley Tue Jan 19 23:19:28 1982

It seems to me that if UCB can implement the changes described in
CSRG TR/4 (Proposals for the Enhancement of Unix on the Vax), Berkeley
Unix will be far ahead of VMS.  I would certainly advise anyone who
is debating Unix-VMS to get a copy of that report and consider
what is outlined there.  (I think ucbvax!mosher is the person to contact
for a copy.)

On the other hand, from Kashtan's report, Eunice seems to be making leaps
and bounds.  If Kashtan can indeed provide an environment on VMS which
is identical to that found under Unix, I would be tempted to get VMS
with Eunice and then perhaps have "the best of both worlds".  But, I
am (as of yet) unconvinced that such an environment can be provided.  

				Bill Mitchell
				University of Central Florida

Message-ID: <anews.Aucbvax.5868>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Wed Jan 20 10:55:09 1982
Subject: Re: pandoras box

>From cbosgd!mark@Berkeley Wed Jan 20 10:11:44 1982
The only real reason I've heard people cite for running VMS is that the
VMS Fortran compiler produces much better code than the UNIX f77 compiler.

If transportability of software across hardware boundaries means nothing
to you, and if you like intricate packets of funny little goobies to
do common ordinary I/O, then go with VMS.

Message-ID: <anews.Aucbvax.5891>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Thu Jan 21 09:36:49 1982
Subject: VAX/VMS versus Unix

>From JSOL@USC-ECLB Thu Jan 21 09:34:26 1982
Until a month ago, I was the systems programmer for a VAX VMS system.
One of the things I thought was really interesting about VMS was that
it required very little of my time to keep working. My job was more a
clerk's job (filling out SPR's, calling DEC for problems, backing up
the filesystem when the operators had trouble, restoring from really
bad crashes occasionally), than a systems programmer's job. Therefore
I would say that VMS is better in a business environment where
"Hackers" are not present (or are very expensive, compared to clerks
which you can pay minimum wage to). From a profit/loss point of view,
the VAX/VMS  is highly reliable at a minimum cost. Every software
maintainence task is reduced to a magic command, insertion of a floppy
disk, and some coffee while you wait the hour and a half that it takes
to update (sometimes).

Rutgers uses their VMS systems for both Research use (using
statistical packages written by outside groups such as IMSL and SPSS).
Unfortunately these prorams were never converted to run under UNIX
(hint: it is my impression that UNIX hackers wished those programs
would fade away along with IBM 370's), and since many non hackers
(i.e. *u*s*e*r*s* - remember them? the ones that make it possible for
us hackers to hack for free??) depend on these packages for their
work (imaging doing a thesis for the School of Agriculture on food
consumption naionally broken down by regions).

My theory is that UNIX is better for an environemt where there are
(unix) hackers, and relatively few non hackers, while VMS is good for
environemts where management wants to cut costs down to the bare
minimum (and where the majority of the users are either perpetual
novices or are forced to deal with computers against their wishes).

--Jsol

p.s. I think UNIX and VMS are the way they are because Bell Labs and
DEC wanted their respective operating systems to be that way.

Message-ID: <anews.Aucbvax.5903>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Thu Jan 21 23:36:40 1982
Subject: unix vs. vms.

>From RJF@MIT-MC Thu Jan 21 23:31:03 1982
RJF@MIT-MC 01/22/82 01:10:39 Re: unix vs. vms.
To: info-vax at MIT-AI
The most telling points in this comparison are as follows, in my
opinion:
1. VMS runs on one computer line: the DEC VAX-11.  UNIX runs on several
computers, and will undoubtedly run on others in the future.  The
degree of portability of programs from one UNIX system to another is
substantial.  Work done on VMS is less portable.
2. While UNIX may not have exactly the features you want, there is
a somewhat receptive community considering changes, and thus mis-features
may be corrected.  Even whole subsystems (e.g. file system) can be
altered.  VMS, by comparison, has a much more diverse constituency,
including COBOL types, the code is expensive to change (even to get
a copy of the code in machine-readable form is moderately big bucks),
and it seems that DEC is (probably for good financial reasons)
not eager to shake its own boat.

I believe these reasons are the primary ones behind ARPA's choice
of UNIX as the VAX operating system for VLSI and Image Understanding
contractors, and also the reasons for the Dept of Energy choosing
VAX UNIX as the first priority system for Applied Math software
development.

if you wish to respond to me directly, please do so.  I am not on info-vax.

Message-ID: <anews.Aucbvax.5915>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Fri Jan 22 13:23:34 1982
Subject: UNIX vs VMS

>From decvax!duke!unc!lynn@Berkeley Fri Jan 22 13:20:08 1982

I am glad to see that some sense is coming into this discussion rather
than polemics.  The initial DEC market for the VAX 11/780 was
scientific research groups that needed a substantial computer capacity
for low cost, and had a quarter million dollars to spare.  Examples are
quantum chemists, crystallographers, molecular dynamicists, and similar
types who do large scale FORTRAN number crunching (but not the
gigascale crunching required by the nuclear weapons simulaters).  These
people can only afford an in-house computer if it can be run pretty
much on a turnkey basis -- a research group or university chemistry
department simply has a very difficult time finding money to hire
systems programmers, and can't afford them if they get the personnel
slot.  You can hire a Ph.D. chemist to do academic research for $15,000
a year, but he is going to get unhappy if he works next to a good
hacker with much less training and knowledge in chemistry (this is a
chemistry department, remember?) who is earning twice as much money.

At last the point -- most of DEC's VMS customers ARE NOT INTERESTED IN
COMPUTERS.  They have to have them, but they don't want one that gets
in the way of their research.  They would much rather spend their
resources on their research interests directly, not on keeping their
computer fed.  I am a crystallographer turned hacker, and was the
entire systems staff for such a group for three years.  VMS is a very
good system for such people.  True, they "ought" to use their computers
more creatively, but they are not interested in that.  They are
interested in chemistry, or whatever.  (That is why a Ph.D. will work
for $15,000 a year and be happy.)  One reason I left was frustration
with their total lack of interest in the computer as anything except a
numerical engine, but from their point of view they were correct --
they got five times the work done IN CRYSTALLOGRAPHY after they got the
VAX and stopped trying to use the university computer center.  I am now
(among other things) the system manager for a computer science
department with a couple of VAXen and a PDP-11 all running UNIX, and
get frustrated with people's lack of interest in natural sciences.

Of course any VMS system that can get this note is probably an
exception, full of hackers and doing fascinating computer science
things.  Otherwise they wouldn't be on the net reading remote mail in
the first place, and they will all jump on me with both feet and
hobnail boots.
			Lynn F. TenEyck 
			University of North Carolina
			duke!unc!lynn (uucp only)

Message-ID: <anews.Aucbvax.5926>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Sat Jan 23 07:06:32 1982
Subject: RMS's VMS deficiencies

>From RWK@SCRC-TENEX@MIT-AI Sat Jan 23 07:02:00 1982
    Date: 21 January 1982 20:20-EST
    From: Richard M. Stallman <RMS at MIT-AI>
    To: info-vax at SANDIA

    The deficiencies of VMS I described two years ago,
    which are in the file RMS;VMS > on MIT-AI,
    as far as I know have not been fixed.
    They add up to a lot of problems with trying to make
    a multi-process command environment (such as is used
    on ITS and Twenex) to run on VMS, plus lots of assorted
    uglinesses and things that can't be done.

I have edited in some comments (enclosed in '[]') and written it to
AI:RWK;VMS >.  While not "fixed", the situation is much improved.  In
particular, it is now much much easier to make the fixes, and generally
not require any changes to VMS as it is distributed.  Thus the
enhancements could be distributed as just another package and installed
by any competent system manager in 15 minutes or so.

Message-ID: <anews.Aucbvax.5935>
Newsgroups: fa.info-vax
Path: utzoo!decvax!ucbvax!info-vax
X-Path: utzoo!decvax!ucbvax!info-vax
From: ucbvax!info-vax
Date: Sat Jan 23 18:17:30 1982
Subject: Interesting patch available, and a comment on UNIX/VMS

>From FONER@MIT-AI Sat Jan 23 18:12:07 1982
A couple of comments.  For those who don't own EMAC or VMS, read ahead
for a continuation of the UNIX vs VMS brouhaha.

For those of you who use Gosling's EMACS and are annoyed by the fact
that the VMS TTDRIVER assumes NOBROADCAST when PASSALL is in effect
(meaning that EMACS users, who must run in PASSALL, can't get SENDs
and other broadcast messages), I have a simple patch to TTDRIVER for
VMS 2.3 that eliminates this behavior.  Setting your terminal
NOBROADCAST explicitly still works, of course, but it won't get
implicitly set tht way when PASSALL is in effect.

I can download the patch to this machine and mail it to anyone in a
week if anyone is interested.  I can mail just the patch (and not how
it works, etc) immediately if somebody's in a rush.  I don't
guarantee, of course, that this patch will work for VMS 2.4, and you
should remove it before instaling 2.4.  Once we install our own 2.4,
I'll make a possibly revised patch available if anyone wants it.

The patch itself, interestingly enough, is a single bit.  The problem
is that \finding/ that bit took several hours of looking.

As for the merits of UNIX vs VMS, I don't really want to jump into
this with blowtorch at the ready.  I'll merely make some comments.
Note that I am a novice UNIX user and do system programming for VMS.

I tend to like VMS for several reasons.  It supports version numbers
for files, which makes sense, especially for commercial users.
Research users find that disk space is always at a premium, but
commercial user, who have more money generally, find that accidentally
losing an important file will pay for \many/ disks due to the increased
amount of file storage due to multiple versions of files sometimes
being around.  UNIX users, from my experience, tend to be more cramped
for disk space and thus find the lack of version numbers not a
particular disadvantage anyway---it helps cut down on space use.

VMS also supports a very good set of diagnostics.  As far as I know,
UNIX does not even try to log device errors in any convenient or
consistent way.  VMS keeps a record of any errors that a device
encounters and thus allows system managers and programmers to look at
the log for a device that is about to fail (memory or a magtape drive,
for instance).  This has proved invaluable at the sites I use, for
instance.  And has anyone ever heard of remote diagnostics for UNIX?
I certainly haven't, but most commercial sites to my knowledge have
remote diagnostics from DEC that can save a LOT of time in tracking
down problems...  the hardware guy can show up with what he needs most
of the time under this system and won't have to go back.

VMS also allows you to layer other software on top of it, if
necessary.  For instance, on our 11/750, we have EUNICE running on top
of VMS.  (We're also trying out true Berkeley UNIX for the next week
on that machine, also, to see if some of our software will run under
UNIX but not EUNICE and try to figure out some problems.)  I have
never heard, however, of anything like VMS being layered on top of
UNIX.

VMS is also very good for unsophisticated users.  A colleague of mine,
who is also a UNIX novice and is trying to figure out the fairly
inscrutable user documentation, has commented that one of the major
problems with UNIX is that you really tend to need a UNIX guru for the
first two or three days to steer you through the system---it's far too
easy to get thoroughly lost by yourself.  In this respect UNIX is very
much an expert system.  (Unfortunately for us, we don't have have a
local guru inhouse...  so we're learning our Berkeley UNIX on our own
unless we break down and call on the distributor.)

VMS, as well as giving very useful and verbose error messages (which
\are/ very useful), also gives me many feet of manuals to explain
itself.  I haven't noticed this from the UNIX folks (though apparently
Berkeley UNIX is better than most).

The ability to actually change the operating system is actually not
very important, at least at my sites.  The patch I mentioned above is
absolutely the FIRST time anyone here has needed to change the
operating system.  Almost everything you might want to can usually be
done without actually \changing/ anything...  you can just add more
code elsewhere.  This helps to make the system maintainable, since it
resembles almost every other VMS in the world and DEC can (and does)
update it for this reason.  This is despite the fact that we'reusing
some of our VMS systems for some damned strange applications and with
some very unusual hardware.

Also, I have heard from people who have taken the VMS Internals course
at DEC that the internal organization of VMS is very clean and very
well thought out.  I have heard just the opposite about UNIX (any
version) because it has grown by bits and pieces, mostly of the hack
variety.  This \must/ have something to do with the maintainability and
essential correctness of the system.

Please don't interpret this as unbridled enthusiasm for VMS.  There
are many things that it could do better.  I think many people on this
list have touched on the places that could do with improvement.
But here are also several areas that can be important to certain
classes of users that make it very useful to them, too.  Not needing a
system programmer on the payroll is one reason.  (We have a couple around
because we are constantly hanging strange hardware off the machines,
for one thing.)  Not needing a guided tour throught the first time is
another reason.  And being \supported/ by a manufacturer can be very
nice for reporting bugs and such, unlike many UNIX systems which are
essentially reliant on their local gurus (and whatever skills they may
or may not have) for fixing.  Not every site can afford to pay someone
who can deal with ALL possible bugs in the operating system.

Also, as this same colleague of mine has suggested, the fact that UNIX
is strongly used by university and research types means that hacks and
other useful information is easily propagated by lots and lots of
interaction between sites and conversations in the halls.  Commercial
users don't talk to each other as easily, because they're often doing
things that they may not want anyone else to know about.  Furthermore,
it's more obvious that it took MONEY to come up with whatever useful
software they may have, and thus that it's to their own competitive
advantage to retain that software and not proliferate it.  University
users have a very different perspective, almost an opposite one.

If I've stepped on toes, I'm sorry.  This is my opinion, biased by
systems programming in a VMS environment for a couple of years and
being fairly unfamiliar with UNIX (especially at the systems
programming level).  It's pretty certain that many people may disagree
with me---the ARPAnet is composed mostly of university computers, and
most university VAXen run UNIX rather than VMS.  If the net were
composed of mostly commercial users doing number crunching and
database handling, the bias of this discussion would be very
different.

						<LNF>