Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1a 7/7/83; site rlgvax.UUCP Path: utzoo!linus!philabs!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: From VMS to UNIX Message-ID: <1228@rlgvax.UUCP> Date: Sat, 1-Oct-83 07:11:22 EDT Article-I.D.: rlgvax.1228 Posted: Sat Oct 1 07:11:22 1983 Date-Received: Sun, 2-Oct-83 15:17:01 EDT References: <245@bunkerb.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 161 Some of the points are valid criticisms of UNIX, some are not: 1. Useful documentation. UNIX documentation is useful for people who already know what is there. There is no way that a state where the existing UNIX documentation is the *only* documentation available can be justified, except by saying "we can't afford the time". Now that UNIX is a Real Live commercial operating system, this doesn't hold water. 2. On line help information. On this one, people may argue that VMS-style on-line help is the wrong solution to the problem. I don't take any stand on this myself, but I can see the point of the people who want more than "man". 3. Meaningful status messages. VMS features 4 part status messages, each of which can be individually disabled, if you're fond of terseness. I don't know if I'd go as far as having UNIX put out VMS or OS/360-style error messages (I seem to remember a case where a low-level VMS routine detected an error; it dutifully printed an error message, and passed the error code back to the next routine up, which dutifully printed an error message, ...), but "can't open"-type messages aren't the best that can be done. If UNIX told you why the file couldn't be opened, it would save a lot of "ls" commands to figure out if the file doesn't exist, or isn't readable/writable by you, or.... ("perror" doesn't provide the ideal interface for producing the sort-of standard UNIX error message "program: complaint"). N.B. UNIX isn't the only system which does this; RSX-11M also has "can't open"-style messages. 4. Meaningful status codes. This is really the binary equivalent of the status message. The low 3 bits of the status returned by VMS functions indicates whether the function was completed successfully or not (this translates directly into severity, above). Conveniently, odd numbers always meant success, but could mean success with additional information. The inability of UNIX system calls to indicate success with additional information (like "the write to the tape succeeded, but it also hit the foil at the end of the tape") is a nuisance. 5. Meaningful file extensions. With VMS, you don't need to have a program called 'file' to 'guess' what type it is; you know by looking at the extension. A source file for the BASIC language ends in '.BAS'; for FORTRAN, '.FOR' etc. An object file ends in '.OBJ'. A command file (script in Unix) ends in '.COM'. Unix's 'file' utility has called scripts 'C' source text on occassion. By the way, what's the difference between 'English Text' and 'Ascii Text'? As an added benefit, if you invoked the Fortran compiler, it knew it was supposed to look for a file whose name ended with '.FOR', if no other extension was supplied. With UNIX, a source file for the C compiler ends in ".c"; for FORTRAN, ".f", etc. An object file ends in ".o". A command file ends in nothing, because it can be *either* an executable image (VMS ".EXE") or a shell file (VMS ".COM"). "File" does the best it can with heuristics, but it can't get it 100%. Nothing prevents you from creating a file with a null extension, or worse an *invalid* extension, with VMS. I could create a binary file called "FOO.BAS" and watch the fun when someone tries to "TYPE" it. (The difference between "English text" and "Ascii text" is based on character frequencies, although a file of all nulls is considered "English text"(!).) As an added benefit, you can type f77 foo.f bar.f bletch.c mumble.s frotz.o and compile and link a program consisting of two FORTRAN modules, one C module, one assembler module, and one already-compiled object module. 6. Consistent command formats. Qualifiers always start with a slash. Filenames always consist of alphanumerics (yes, I've seen the arguments about funny characters in file names, and I know they are occassionally useful). Qualifier names can be more than one character long, so you don't have to remember whether '-o' or '-O' is what you want. The UNIX command format is a bit of a pain, but there is a tradeoff between terseness (which speeds up work) and clarity. Qualifier names in UNIX *can* be more than one character long (the "-onetrip" qualifier to "f77" is a case in point), but they generally aren't. 7. Automatic version numbers. Each file has a version number associated with it. When you make a change, the version number is incremented. When you specify a file without an explicit version number, the latest version is used, which is usually what is desired. When you delete a file, you must specify a version number, so that files don't get deleted accidentally. If you make a change which turns out to be incorrect, the previous version is still available. As long as the operating system can be told to keep only the last version, or last N versions around, this isn't too bad (although there is code required to implement it, and extra work for users; there is a tradeoff here). If versions hang around until you explicitly purge them, this is no good, because versions can pile up (I saw a file on a VMS system with 50 some versions!). Under UNIX, systems like the Source Code Control System and the Revision Control System provide this and more besides for source files, and having several versions of object or executable code is of unclear merit. 8. Abbreviations. Both command names and qualifier names could be abbreviated to the minimum required to be unique. The full name could be used in a command file, both to aid a future reader and to prevent ambiguities when a new command is added. Abbreviated command names would be tricky under UNIX because of its flexibility in adding new commands. To disambiguate the command it would have to look in ALL the directories in your search path. Which brings us to: 9. User defined commands. Under VMS, I could define a command to replace any of the system commands, and it didn't require a dollar sign in front of it, it didn't require a whole file (minimum size 1 block), and it didn't take up room in my directory. If your command did a lot of work (i.e. it wasn't just a shell variable), it would be either a program or a shell file and as such would have to take up a whole file and a directory entry. Some UNIX shells (the C shell and the Korn shell; the latter is an extended Bourne shell) support the ability to add commands by creating "aliases" or "functions"; in this case they do not require an executable or shell file. How convenient is it to add new commands under VMS? Under UNIX you can have multiple directories full of commands, and as soon as you drop a file in there it is available to everyone who has that directory in their search path. Can the same be said for VMS? 10. Separate protection bits for write and delete. I could keep from deleting a file, while retaining the ability to modify it. Useful in conjunction with version numbers. Nice, but again there is a tradeoff here. 11. Consistency. This is probably the biggest, without which some of the problems above could not be fixed. Only one company supplies VMS, as far as I know. You can add your own modifications, but no one else is expected to consider them part of VMS. Since VMS comes from only one source, there is the possibility of vendor support. Well, since VMS only runs on one machine this is a bit easier to do. Try a shop with a VAX-11 or two and several 68000-based workstations. Unless you put VMS up on the 68Ks (a little tricky, considering how much of VMS is still in MACRO-32) you have a far greater consistency problem than if they both ran UNIX. UNIX comes from several sources and the vendors generally support it (Bell supports the PDP-11, VAX-11, and 3B versions, and most people offering "UNIX boxes" support the version on their machine). Western seems to be trying to bring all UNIXes under one roof (theirs), with their arrangements with the major chip vendors. So yes, there are things that VMS (or any other OS) does better than UNIX, and there are things UNIX does better than other OSs. One thing UNIX does better than almost all other operating systems is run on most of the machines a heterogeneous site has in house; this alone is worth a *lot*. (We can do development on fast VAXes, and ship the code to our 68000 machines and debug it.) So it's certainly not an open-and-shut case for VMS; if a lot of the problems with UNIX that *can* be cleared up are, a lot of the anti-UNIX arguments will fall by the wayside. Guy Harris {seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy