Aduke.1643
fa.info-vax
utcsrgv!utzoo!decvax!ucbvax!mhtsa!harpo!chico!duke!bcw
Tue Jan 19 22:14:54 1982
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
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
