mikec@hou2g.UUCP (#M.CONDICT) (11/28/84)
Those VMS-ites who enjoy denigrating UNIX should show some respect. Virtually
every feature in the early versions of VMS that made it useable (barely!) was
copied from UNIX -- this is well known within the original development group,
which was headed by a UNIX-lover (gasp, gasp!). In fact, Version 1.0 of VMS
was a system apparently designed by concatenating the RSX-11M Operating Sys.
manuals with the UNIX Version 7 manuals, then shuffling or deleting a few
pages. I guess the idea was to be upward compatible with RSX while putting in
all the UNIX goodies as well. Here are a few examples for your amusement:
o They saw the utility of a command processor as powerful and flexible as the
Bourne shell, so they tried to put one in VMS. Unfortunately, what they
ended up with (DCL) was an interpreter for, roughly, a subset of FORTRAN.
Whoopee!
o The notion of standard input and output was implemented through the use of
logical names SYS$INPUT, SYS$OUTPUT. Unfortunately, many standard commands
do not read SYS$INPUT or write SYS$OUTPUT, and anyway they forgot to put
any I/O redirection syntax into the shell. Very useful indeed!
o Unix pipelines were implemented as VMS mailbox devices. Unfortunately, they
neglected to put anything in the shell that would automatically construct
such mailbox-pipelines and connect commands through them. In fact, by
default, users are not even given permission to make such mailbox devices.
o Tree-structured file systems are wonderful, so they just had to have them
in VMS. Unfortunately, they attempted to overlay the notion on top of the
RSX "two-dimensional array of directories" syntax, producing the wonderfully
elegant notation "DB0:[USER.GLERP]WHATEVER.FTN;13" for a file that in
UNIX would be something like "/usr/glerp/whatever.c". Also, to ensure
compatibility with RSX and avoid frightening users, they restricted each
name in a directory path to nine letters or digits, upper-case only, thank
you very much. Oh, and they forgot to put in the device-independent, single
directory tree -- every file name must be preceded by the device-name on
which the file resides, unless this device is the default. Strange things
are done with logical names in a futile attempt to relieve the user from
knowing the full device name of various commonly used files and devices.
o They weren't impressed at all with the UNIX "&" construct for invoking
background processes, so they ignored it, almost. By writing a program
you could get a parallel process started up, but don't ask the shell to do
it for you (in fairness, they've since implemented a very badly designed
"SPAWN" command, intended to serve this purpose).
o As in RSX, they had a facility for getting user-supplied arguments into
user-written programs. Unfortunately, as in RSX, the shell could not be
induced to pass such arguments to such programs, which had to be invoked
by saying "RUN program". This also, apparently, was intended to avoid
frightening users, most of whom were assumed to be FORTRAN-hacking engi-
neers who don't trust software anyway.
The most recent time I was forced to use VMS, I promptly implemented a DCL
program that provided a UNIX-like shell, with I/O redirection, "echo" and
"read" commands, background processes, a history mechanism and even a
rudimentary pipe-line facility. Its utility was somewhat limited by the
above-described brain-damage, however, and I eventually switched to Eunice.
I called the program DSH (for Dumb Shell) and it is still in use at NYU as
far as I know.
If I've made any statements that are not true of the latest and greatest
version of VMS, it is because I escaped from VMS at Version 3.0. Please
forgive any such inaccuracies and may I roast in hell for defaming DEC's
finest operating system.
Michael Condict ...!{allegra|decvax}!hou2g!mikec
AT&T Bell Labs
Holmdel, NJpritch@osu-eddie.UUCP (Norman Pritchett) (11/29/84)
As a VMS hacker I suppose it is my duty (:-)) to give some sort of repsonse to this article. I thank Michael for saying which version of VMS he was using because a lot of it sounded as if his only exposure to VMS was version 1.0. I'd like to start out with just a couple of statements and corrections to his comments about VMS and DCL. >o They saw the utility of a command processor as powerful and flexible as the > Bourne shell, so they tried to put one in VMS. Unfortunately, what they > ended up with (DCL) was an interpreter for, roughly, a subset of FORTRAN. > Whoopee! I'm not certain if you had the oppurtunity to fully explore , among other things, the many neat lexical functions to perform string-handling, query device and system status. I'll admit there is a definite lack of structured control statements like an ELSE for IF-THEN statements, DO-WHILE's and -UNTIL's. I'll consider this statement as being subjective; DCL has good points and bad points and I'm happy to live with bad ones to have the good ones. >o The notion of standard input and output was implemented through the use of > logical names SYS$INPUT, SYS$OUTPUT. Unfortunately, many standard commands > do not read SYS$INPUT or write SYS$OUTPUT, and anyway they forgot to put > any I/O redirection syntax into the shell. Very useful indeed! There is only one command that I've found which didn't recognize the SYS$INPUT, or SYS$OUTPUT assignments -- the SHOW SYMBOL command. All of the others seem to consistently use those logical names. There is another one to consider: SYS$COMMAND which defines where command input as opposed to data input is coming from. Unfortunately, VMS utilities do not consistently use SYS$COMMAND, they may use the assignment of SYS$INPUT instead. I'll agree with the need for I/O redirection syntax in the shell. > ... to ensure > compatibility with RSX and avoid frightening users, they restricted each > name in a directory path to nine letters or digits, upper-case only ... DEC's learning, version 4 now allows 31 characters and selected special characters in a filenames and names in directory path's. Filenames may also have extenstions 8 characters long. >o As in RSX, they had a facility for getting user-supplied arguments into > user-written programs. Unfortunately, as in RSX, the shell could not be > induced to pass such arguments to such programs, which had to be invoked > by saying "RUN program". This also, apparently, was intended to avoid > frightening users, most of whom were assumed to be FORTRAN-hacking engi- > neers who don't trust software anyway. Hate to say this but the shell can be induced into passing arguments. You can tell the shell to run a program by having a symbol defined as the program name preceded by a `$' (as an example: foo :== $myprogram). After you make that definition you merely type the symbol name and the program is run. If you wish to pass arguments from command line just put them after the symbol name ( e.g. foo THESE ARE MY ARGUMENTS) >Those VMS-ites who enjoy denigrating UNIX should show some respect. This is my real message; If I at all appeared to be anti-UNIX here please forgive me for leaving the wrong impression. I personally do not enojoy seeing anyone put down any operating system. Each is a tool which is good at doing sometings well and somethings not so well. I actively use VMS, Unix and Tops-20. In times past I used RSTS/E and RSX-11. Each had features which I found particularly appealing and some which are not. You will not find me saying anyone of these is worse than the other (excepting RSuX). The people that I know who continually put down one system or another tend to be those who try to use things that their system does best on a different system. It is probably very naive of me to expect this, but I wish that everybody would stop complaining about everbody else's operating system. If you don't like the way a certain system handles things then why don't you try doing the things it's good at instead or find an operating system which does what you want? -- ---------------------------------------------------------------------- Norm Pritchett ..osu-dbs!pritch
joe@fluke.UUCP (Joe Kelsey) (11/30/84)
> From: mikec@hou2g.UUCP (#M.CONDICT) > Those VMS-ites who enjoy denigrating UNIX should show some respect. Virtually > every feature in the early versions of VMS that made it useable (barely!) was > copied from UNIX -- this is well known within the original development group, > which was headed by a UNIX-lover (gasp, gasp!). Well known by whom? I personally heard a very detailed description of the history of VMS, and not a single person involved with version 1.0 of VMS had ANY experience with UNIX. In fact, I believe that their only knowledge was that a couple people had read the Communications paper, and that was it! > In fact, Version 1.0 of VMS > was a system apparently designed by concatenating the RSX-11M Operating Sys. > manuals with the UNIX Version 7 manuals, then shuffling or deleting a few > pages. I guess the idea was to be upward compatible with RSX while putting in > all the UNIX goodies as well. Here are a few examples for your amusement: VMS was derived 80% from RSX, with a few UNIVAC and MULTICS concepts thrown in at random. Dave Cutler (father of RSX and almost any worthwhile product from DEC, bit-twiddler extrodinaire) had the most influence on VMS in the early days, and since he parctically wrote RSX single-handedly, VMS was very much influenced by his preferences. Dave was known as one of the major UNIX-phobes at DEC, although he may or may not have overcome some of his phobia since writing the VAX-11 C run-time library. > here he proceeds to give examples of UNIX things VMS bungled. The only thing that anyone who developed VMS admits was influenced by UNIX was the mailboxes. None of your other examples have any validity as being anything related to UNIX, except maybe by hindsight. Every single one of them was based on RSX ideas. I don't really mind people who choose to say that UNIX or VMS is better and then give reasons. I just wish that if you are going to claim something about history that you would check your facts. Personally, I can see no reason to choose either system. Both have major flaws, along with major plusses. When you compare actual operating system capabilities, it comes out as a wash. Neither is my favorite operating system, no matter which viewpoint you use: user, application programmer, systems programmer, system administrator, etc. Unfortunately, my current favorite is now destined to become a dinosaur: TOPS-20. Sigh. /Joe
pc@unisoft.UUCP (Paul Campbell) (12/01/84)
[slurp] I too must put my 5c in ... (first a bit about my background ... I port Un*x for a living, I have also spent the last 4 years as a VMS hacker ... so I feel I have a good view of both worlds). I feel the main reason for the 'enemity' between VMS and Un*x people is a lack of knowledge and experience (here I mean YEARS of experience, what you need to really understand an operating system's environment and feel comfortable using it) on both sides. Here are my feelings about them ... 1) EDT vs vi - they are relatively similar in power for normal use vi: good points - better search facilities, can work on almost any terminal bad points - impossible to learn/teach EDT: good points - you can teach a novice computer user to use it in 15 minutes bad points - you have to use a DEC compatible terminal 2a) kernel hacking - VMS provides more 'hooks' than Un*x, but then you don't have the source (or objects) to reconfigure VMS, on the other hand allocation of system resources and the loading of device drivers is done dynamicly either at boot time or while the system is running. If you have the sources you can do 'anything' in Un*x, but in VMS you have the fiche and it is not necessary to change the kernal to do kernal things ... there are ways for a user program to get into kernal mode to do these things. Un*x does a few simple things well, VMS does these things and as well provides you with the hooks do do many operating system things (page mapping signals, interrupts etc). I had to implement virtual Un*x machines on VMS (with the Un*x kernal running in Supervisor mode, each running with its own virtual disk (so we could give students 'virtual disk crashes' for them to recover from)) all the operating system things that you require are there, they are not in Un*x and I don't see how I could possibly do the same without a lot of Un*x kernal modification! 2b) kernel hacking cntd - I feel that the fact that VMS sources are not readily available is a major reason why people don't do more hacking, however DEC do give a good course on VMS internals and once you learn how to read the fiche you can do almost anything. Even though much of the VMS kernel is written in assembler there is no reason why you can't use almost any language for kernel code (I have used Pascal and FORTRAN). Bugs, DEC's support is really very good, it can take time for patches to arrive but if they are really critical they will get them to you express (I come from the furthest reaches of the world, the deep south of New Zealand). 3) portability - Un*x is portable, VMS is not (FULL STOP). I could go on for pages more ... but as a summary ... I feel that they are both good operating systems, each with a different emphasis and that there are good reasons for using either one. Most of the points raised by both sides are probably to some extent valid and at the same time can be shot down in FLAMES by the oposition. Finally just be glad you don't have a 43xx/370 etc, then we could all argue about the merits of many different operating systems rather than just two. Cheers Paul Campbell (ZL4TFW) ..!ucbvax!unisoft!paul
fouts@orville (Martin Fouts) (12/02/84)
Hmm, interesting comments. And what were you smoking at the time? ----------
geoff@desint.UUCP (Geoff Kuenning) (12/02/84)
In article <378@hou2g.UUCP> mikec@hou2g.UUCP (Michael Condict) writes: >Those VMS-ites who enjoy denigrating UNIX should show some respect. Virtually >every feature in the early versions of VMS that made it useable (barely!) was >copied from UNIX -- this is well known within the original development group, >which was headed by a UNIX-lover (gasp, gasp!). The way I remember it (I was in the 11M group at the time) is that Dave Cutler headed the VMS group. He was a tried-and-true Deccie, the author of 11M, and not what I would call a UNIX-lover. I also remember the name of Peter somebody (can anybody help me?). I cannot believe that a true-blue UNIX lover at the head of the VMS group could have produced anything so hard to use, even given the influence of various committees and other groups within DEC. >In fact, Version 1.0 of VMS was ... apparently designed by concatenating >the RSX-11M ... manuals with the UNIX Version 7 manuals, then ... deleting a >few pages. I guess the idea was to be upward compatible with RSX while >putting in all the UNIX goodies as well. Here are a few examples for your >amusement: I think you give them too much credit. RSX-11M compatibility *was* a specific goal, and some people had read a few UNIX manuals. There probably were a few peon-level UNIX-lovers around too, but they didn't have much influence. That's probably why it wound up the way it did -- UNIX ideas got interpreted by people who had never seen UNIX, and so they didn't understand which parts were the important one. >o They saw the utility of a command processor as powerful and flexible as the > Bourne shell, so they tried to put one in VMS. Unfortunately, what they > ended up with (DCL) was an interpreter for, roughly, a subset of FORTRAN. > Whoopee! DCL was (is?) a committee product, was strongly influenced by the need to hang it on top of both TOPS-20 and RSX, by the existing IAS command interface, and by the RSX-11M "indirect processor". The design of this last was motivated largely by the RSX-11M sysgen upgrade project. If there was Bourne shell influence in the first DCL spec I saw, it was sure well hidden. [I am going to leave out several things I agree with wholeheartedly] >o Tree-structured file systems are wonderful...[but the syntax is the] > elegant notation "DB0:[USER.GLERP]WHATEVER.FTN;13"... To be fair, this is partly because RSX-11M had tree-structured file systems. "WHAT?" you say, "This guy's *nuts*." Actually not. I went to put tree-structured file systems in 11M (the file system is implemented largely in a user-mode library, so it's remarkable what a person with sources can do without touching the kernel). Imagine my surprise when I discovered that most of the work was in removing restrictive checks for recursive directory references. It was obvious that the person who did it originally had heard of directory trees and had left the hooks all over the place. For those of you who have never had the misfortune to use 11M: I have often praised its real-time performance and marketplace success. But the human interface -- you thought UNIX had a wierd, non-intuitive, inconsistent human interface? You ain't seen nothing yet until you've seen: PIP DB0:[101,124]ALPHA.DAT/NV/ME=DK1:[123,321]BETA.TXT;3,.DOC;7,;9,.C;*,GAMMA (say what?) (For you innocent unbloodied ones: that's cat /usr/joe/beta.{txt,doc*,c*} /usr/joe/gamma.c* >/usr/mary/alpha.dat assuming you keep old versions in .co and .doco, or some such. At least you could put blanks in for readability if you had room [80-character input buffers, you know..]) -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff
mark@elsie.UUCP (Mark J. Miller) (12/04/84)
VMS was probably (surly) not a direct result of UNIX influence. However, many UNIX - inspired ideas (tree-structured filing systems, pipes, redirected-IO) had certainly found their way into the computer psyche by the time the VMS project got rolling, and this probably best explains whatever similarities there are between the two systems. Now that DEC supports ULTRIX, it will be interesting to see, in the years to come, if VMS and UNIX will ever be able to merge into a single compatable system. -- Mark J. Miller NIH/NCI/DCE/LEC UUCP: decvax!harpo!seismo!elsie!mark Phone: (301) 496-5688
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/05/84)
Right on, Norm! Let's stop this silly VMS-vs-UNIX debate, which is only meaningful to VAX users anyway (most of us are not).
ron@BRL-TGR.ARPA (12/10/84)
Actually, I've found that a couple of hours using our Cyber make me really appreciate the elegance of our other mmachines including VMS, UNIX, and OS/1100. -Ron