Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!oddjob!gargoyle!ihnp4!inuxc!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.unix.questions
Subject: Re: dsb unix vs. dec's vms
Message-ID: <667@bsu-cs.UUCP>
Date: Mon, 18-May-87 17:08:48 EDT
Article-I.D.: bsu-cs.667
Posted: Mon May 18 17:08:48 1987
Date-Received: Tue, 19-May-87 06:28:23 EDT
References: <5828@shemp.UCLA.EDU> <34ab0e42.8be4@apollo.uucp> <3583@jade.BERKELEY.EDU>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 55

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.

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.

VAX/VMS is extremely inefficient at creating new processes.  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 inability to create a process efficiently (it can take about 2 to 6
seconds to create a new process on a typical VMS system under a typical
load) leads to all sorts of problems.  You will note that VMS utilities
do not let you escape to a command shell easily (most do not let you do
that AT ALL).  If you could escape to a command shell (which would
involve creating a new process), you would notice the slow speed.  But
since users are not allowed to do most things that could reveal VMS's
inefficiency, they frequently begin to believe that VMS is more
efficient.  They often quickly change their mind when they use
something like DEC's All-In-One software, which uses multiple
processes.

The above does not prevent DEC from providing a structured shell
programming language.  However, the command language (modestly named
DEC Comamnd 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.  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, 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.

Then again, the VMS mail utility has no Cc: field.  Great Mysteries
of Our Time.
-- 
Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi