Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ptsfa!ihnp4!inuxc!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.os.vms
Subject: Re: bsd unix vs. dec's vms
Message-ID: <695@bsu-cs.UUCP>
Date: Fri, 22-May-87 23:43:24 EDT
Article-I.D.: bsu-cs.695
Posted: Fri May 22 23:43:24 1987
Date-Received: Sat, 23-May-87 19:09:48 EDT
References: <5828@shemp.UCLA.EDU> <34ab0e42.8be4@apollo.uucp> <3583@jade.BERKELEY.EDU> <667@bsu-cs.UUCP> <19385@sun.uucp>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 86

In article <19385@sun.uucp> landauer@sun.UUCP (Doug Landauer) writes:
>                 ...VMS can indeed support shell-like interfaces.

Before we go on, let's make sure we are on the same wavelength.  
The ability to support a UNIX-like interface is not quite the
same thing as the ability to do this *efficiently*.  

>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.

The Wollongong Group realized very early on that VMS creates processes
very slowly.  Eunice apparently creates a number of processes, about
fifteen or so, and suspends them.  Then, when it needs a new process,
it reuses one of the suspended processes.  (Is it fifteen processes per
user, or collectively?  I'm not sure.)  The compromise here is between
wasting CPU time creating a new process, or wasting system resources
keeping spare processes around just in case you need them.  So I
emphasize:  Because process creation is so slow, VMS cannot
*efficiently* support a UNIX-like command interpreter.

Here is more of what I originally said:
>>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.

Here is how Doug Landauer responds (name-calling edited out):
>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...

"Just slower" is probably an understatement, and certainly is
inconsistent with saying that they are supported "just fine".

Here is more of what I originally said:
>>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.

Doug Landauer again:
>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.
[...name-calling....]
[...speculation that DCL had to run on PDP-11 machines...]
>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.

This assumes that something designed ten years ago cannot change.
Fortran77 should not have if-then-else statements, because it didn't
have them ten years ago.  4.3BSD should not have the C-shell, because
there was a time when it only had the Bourne shell.  For that matter we
should not even be using C or Pascal or Fortran or even DEC's own
Bliss, because there was a time when everybody used assembly language.

This is invalid reasoning.  It presupposes the complete absence of
progress.

There is no reason why a PDP-11 cannot support a command interpreter
with control structures.  The Bourne shell runs just fine on PDP-11s.

The real problem seems to be that the VMS command interpreter assumes
deep in side that each command line is independent, and new command
lines cannot depend on the execution of previous ones.  One can
speculate that adding control structures would be too drastic a change,
and DEC does not want to start from scratch again.
-- 
Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi