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 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 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.