Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!oliveb!sun!landauer From: landauer@sun.uucp (Doug Landauer) Newsgroups: comp.unix.questions Subject: Re: bsd unix vs. dec's vms Message-ID: <19385@sun.uucp> Date: Wed, 20-May-87 18:57:44 EDT Article-I.D.: sun.19385 Posted: Wed May 20 18:57:44 1987 Date-Received: Sat, 23-May-87 08:45:49 EDT References: <5828@shemp.UCLA.EDU> <34ab0e42.8be4@apollo.uucp> <3583@jade.BERKELEY.EDU> <667@bsu-cs.UUCP> Reply-To: landauer@sun.UUCP (Doug Landauer) Followup-To: comp.os.vms Organization: Sun Microsystems, Mountain View Lines: 132 This is mostly about VMS -- if there are any followups, please send them to comp.os.vms. In article <667@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <3583@jade.BERKELEY.EDU> steven@pearl.berkeley.edu (Stephen the >Greatest [or so he claims]) says this about VAX/VMS: >> ...Also, I hate the shell (or command inter- >>pretor) in VMS. Why can't anybody in DEC write something like C-Shell? >>I think VMS is absolutely able to support a C-Shell-like command interface. Stephen is right -- VMS can indeed support shell-like interfaces. Several VMS software packages exist which are Unix-lookalike systems: Eunice, from The Wollongong Group; VMS/Workbench (or whatever they call it these days), from Interactive Systems; something whose name I forgot, from HCR (sorry), and at least a couple others. Even DEC sells something called the DECshell, which runs on VMS. I don't know which shell(s) it looks like, but I've heard it can ease somewhat the pain of working with VMS. >VMS is not able to support a C-Shell-like command interface for a rather >important reason. The UNIX shell interface depends heavily on process >creation and many commands create several processes. VMS can support shell-like user interfaces just fine. They are just slower than DEC's own CLI ("Command Line Interpreter", or "Command Language Interpreter", I forget which) because of the way DEC's CLI invokes images, and because, as you say, >VAX/VMS is extremely inefficient at creating new processes. [ There is an ambiguity in the term "DCL" -- many VMS users use "DCL" to mean the CLI, but it really means the language ("DEC Command Language") that the CLI interprets. I'll use "the CLI" to mean DEC's CLI for VMS.] >When the >VMS command interpreter executes a user program, it does not create a >new process, but simply does the equivalent of a UNIX exec() system >call. Thus the current invocation of the command interpreter >effectively dies and is replaced by the user program. (How it regains >control after the user program terminates is a long, long story that >I don't fully understand.) The two true statements made in the above paragraph are "it does not create a new process" and "[Rahul doesn't] fully understand". The CLI regains control because it did not die and was not replaced by the user program. The CLI normally lives in what DEC calls "P1" space. Think of the VAX address space as being divided in four parts: P0, P1, S0 and S1. P0 is your user program space, P1 is for the CLI, and the S spaces (I'm not sure whether S1 exists) are where the VMS kernel lives. When the CLI starts up a command, it does so with an "IMAGE ACTIVATION" system call -- this reads the command into P0 space and lets it start running. More evidence that it is still around is in the awful interface that they implemented for parsing DCL-style command qualifiers. (How it does that is a long, long story that would cause me to puke before I got finished explaining it.) >The above does not prevent DEC from providing a structured shell >programming language. However, the command language (modestly named >DEC Command Language) appears to have a batch environment as its design >basis, and has very little "memory" of past statements executed. In a >batch enviroment, where each control card is separately interpreted, it >is difficult to provide control structures such as >if..then..else...endif, while and for loops, etc. > >More evidence that DCL has little or no memory: there is no way of >giving multiple commands on the same line. This is just circumstantial evidence, and your conclusion is totally wrong. What we need here is a little historical perspective. My conclusion from the same evidence is that the design of DCL simply showed a lack of foresight on DEC's part (they underestimated how successful the VAX would be, and how successful Unix would be on it, and overestimated the continued importance of the PDP-11), and a "foolish consistency" -- one design goal was that command interpreters which understand DCL had to run on PDP-11-sized machines, and I suspect that they decided that putting in too fancy a command language would prevent such interpreters from being feasible on such small machines. >To properly handle multiple >commands, the command interpreter would have to save the previous >partially-executed command line somewhere. But since the command >interpreter effectively does an exec() each time it executed a user >command, it can't save information and reuse it very easily--the >next command is really executed by a brand-new invocation of the >command interpreter. > >I am only speculating here, ... ... "here" being your whole article ... > ... but I haven't heard any better explanations >of why DCL is oriented towards a one-command-one-line-only-no-control- >structures command interface. Look at it from DEC's point of view at the time that DCL was designed: the PDP-11 was the single most successful computer (in terms of units shipped) in the history of computing. [ or damn close -- anyone know for sure? ] DEC *had* to continue to support it. They had gone through an awful fiasco on the PDP-11 where DEC themselves sold *five* different operating systems for that machine (maybe more -- let's see, DOS, RT-11, RTOS, RSX-11M, and RSX-11D which became IAS). And to the great chagrin of their in-house OS programmers, there were as many PDP-11s running Unix as were running some of their own operating systems. DEC needed some consistency at that point. The motivation for designing DCL was to prevent something like that from happening on the VAX, without abandoning their enormous installed base of PDP-11 users. They wanted a single OS to be dominant on the VAX line, and at that they've been almost totally successful. [I don't know the exact numbers, but I think that about 80% or 90% of all VAXen run VMS.] Of course, they finally had to give in and lend some token support to a version of Unix, but they're certainly in a better position now than they were with the PDP-11. It's hard for people who weren't in the field then to see how important the PDP-11 was to DEC before the VAX came out. Don't get me wrong -- I hated it when I had to program on VMS, and I hated DCL. However, it's good enough for who it's for, and it was designed a decade ago, in a very different world. -- Doug Landauer Sun's network: landauer@morocco Phone: 415 354-4747 ARPA Internet: landauer@sun.com UUCP: {amdahl, decwrl, hplabs, seismo, ...}!sun!landauer Disclaimer -- I have never worked for DEC, but have worked with DEC machines (off and on) for the past 15 years.