Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!floyd!cmcl2!seismo!hao!hplabs!sri-unix!rbbb@RICE.ARPA From: rbbb@RICE.ARPA Newsgroups: net.unix Subject: How do Unix and VMS compare? Message-ID: <1000@sri-arpa.UUCP> Date: Mon, 18-Jun-84 20:43:13 EDT Article-I.D.: sri-arpa.1000 Posted: Mon Jun 18 20:43:13 1984 Date-Received: Thu, 21-Jun-84 01:45:35 EDT Lines: 157 From: David ChaseI wasn't going to CC info-unix, but that seems to be the thing to do, sooo... VMS over UNIX The fortran is better; it is mostly correct, doesn't explode on correct code, and is usually faster. It also provides better error messages. I think the Pascal is better, but I haven't compared the two myself (I hate Pascal). The Pascal jocks want me to be sure that VMS Pascal is under maintenance, etc etc, and they seem to use it more than the Pascal that comes with Berkeley Unix, so I guess they like it better. If you use macro-assemblers, there is none for unix, and MACRO-32 is fairly feature-filled. I wrote the back end of a BCPL compiler in MACRO-32 (OCODE --> assembly language). When the next minor version of VMS comes out, your programs will still run. When the next major version of VMS comes out, your programs will still run. We are still running (under 3.6) programs that were linked under 2.5, and these programs are linked against a user-written library full of change-mode vectors. Of course, the library is installed as a shareable image, so it has been changed many times. With VMS, you can do all of the things that are hard under unix; you can do mutual exclusion, you can do shared memory, you can do concurrent io. You can single-step debug your kernel-mode code, if you so chose. You can reload device drivers without rebooting the stinking operating system. You get ISAM files, if you want them. VMS is easier to manage. You have much more control over resources than under Unix. Batch queues, for instance. VMS tends to get more performance out of its hardware, through clustering, asynchronous IO, and good paging. These things can be tuned for a particular installation, though they can also be mistuned. If I write something under VMS, and decide I maybe want to sell it or give it away, I don't have a dozen lawyers breathing down my neck. Shareable images and shareable libraries are pretty fun; shared programs (like shared text) for the images, and shared libraries (like nothing available in Unix) for shared text and swift and easy software updates (change the library, but don't need to relink). UNIX over VMS Most of the VMS "user interface" is abysmal. We're talking EDT for an editor and DCL for a "command language interpreter". No make. No awk. DCL scripts can be almost bearable, and you can get at all sorts of neato information from DCL, but there's no IF, no DO, no CASE; only GOTO. Perhaps there DEC program products out there that make life bearable; the people here chose the path of writing a unix emulator, rather than porting the selected useful programs. Certain operations are slow under VMS; some file io and process creation are two. Special VMS hates: I can run my terminal (it's a file, right?), but to get its protection I have to do a (from DCL) F$GETDVI("TT", "VPROT") rather than whatever I might do for a real file. This sucks a bit. There is no explicit way to make links, but I can by making the source directory non-writeable, then renaming into the target directory. This allows everything BUT a single node directory loop, which is explicitly verboten for some bizarre reason. "Concealed devices" may only be one directory level deeper than a real device, and there is no way to "SET DEF" to the root of the concealed device and have it still act like a device. Although there appears to be some sort of terminal-independent library for VMS, many or all of the screen-oriented programs don't seem to use it. Networks?? With DECNET you can speak to any other DEC OS around. Who would ever want to do more???? (Actually, there do seem to be provisions for speaking SNA and X.25, but I'm not terribly familiar with them). File names are TOO short (N.B. this goes away with VMS version 4, up to 39.39.version number, I think.) Special VMS loves: BACKUP is really ace, though it has a fairly steep learning curve. Much more function than tar. (Not as hard to learn as "find", because I have wanted to use both, and I still haven't figured out "find".) This may not seem like much, until you lose some important data. I can do BACKUPs on an active file system. When I say "help", I usually get help, and there appears to be a uniform help interface across DCL and many commands. The RMS file syntax, though grotesque, is often used to provide more power than I get from the Unix shell expansion syntax. The most useful feature for me is the ability to say "all files in this directory tree that look like this", as in "[...]*.obj.*". Someone could add this to their favorite shell without too much damage, I think. I could do this with a find, but as I said before, I haven't been able to master find. I can add pagefiles and swapfiles while the system is running, and I need not scratch a disk to expand them (N.B. this depends very much on the availability of contiguous space for creation of these files). I can read and write ANSI label tapes (remember ANSI?? you know, "ANSI: consider it a standard...") so that I can communicate with other people running practically anything but Unix. Logical names: They're great, period. We hacked unix "make" to treat environment variables in the same way. Things WORK. No surprises (except for those mentioned above). The options to commands have names that I can remember. Special Unix hates: A stinking minor version change breaks the whole world. Already there are two different Unixes. Unix encourages C, and that is bad. C is just assembly language with pretensions. If I miss a keystroke, I type "rm *>CKP". This is very bad. Often things don't work. The "bugs" section on every manual page is a real loser, since no one seems to fix things, and if they did, that might break someone's program that depends on the bug. General impressions: probably if you have a gang of software developer sort of guys, they will want to run Unix because "it makes them more productive". I expect that Unix + make + awk + emacs (you can afford it) will allow programmers to hack out more code than they would under VMS, but they might not need to hack out so much code under VMS. This depends upon the nature of the code being written. I snicker every time I see some plea for ISAM files or mutual exclusion or shared memory on the net. Once an application is written, I expect that the previous user interface (shell or DCL) will be hidden, and that the quality of the OS underneath will be more important. From this point of view I think that VMS is much better (I know, I know, QIO takes a million parameters, but most of them are optional, and it usually does the right thing if you leave them alone). Imagine this situation; I have invested zillions of dollars in an application (running under 4.1) that has become essential, and it won't run under 4.2. This can also happen in VMS land, but is much less likely. In an educational environment, there are again tradeoffs. Educational machines here have had bad problems with severe load and security doodling; I'm not sure that VMS would help, but I suspect that it could. Many of the neato-utilities for Unix could be rewritten for VMS (for instance, one of the programming projects for a course here was "make" written in Pascal). I am very very happy with emulators; we run Phoenix (written here) and I freely switch from one interface to the other (to the utter disgust of the Unix Zealots around here). I have learned to use EDT for the quickie editing jobs, and emacs for the more involved ones. We wrote IP and UDP for VMS, so we can communicate in a primitive fashion over the ethernet (I'm sorry, but UUCP is just a little too mickey mouse for me. I've had to use it, and I hate it). Much of this software is available, or soon becoming available. For some background on why I say what I do; I have managed a 780 running VMS+Phoenix for over two years now, and I do program development on whatever is available. Both the VMS and Unix have been heavily sanitized with local scripts, com files, and programs; I am nearly helpless in vanilla Unix (not so for VMS only because I am manager and MUST know how to work in raw VMS; all of our users are non-portable). In a pinch I fix things on the "real" Unix machines. I also maintain emacs across Phoenix, 4.1, and SUN/BSD4.2. In my much darker past I used cards on an ITEL (now NASCO) AS/6 running MVS, later SPF. Did you know that you can pipe the output of one JCL job step to the input of another? (Chew on that). drc