Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!ukc!eagle!icdoc!iwm
From: iwm@doc.ic.ac.uk (Ian W Moor)
Newsgroups: comp.unix.questions
Subject: Re: dsb unix vs. dec's vms
Message-ID: <447@ivax.doc.ic.ac.uk>
Date: Sun, 31-May-87 11:42:08 EDT
Article-I.D.: ivax.447
Posted: Sun May 31 11:42:08 1987
Date-Received: Tue, 2-Jun-87 05:01:30 EDT
References: <5828@shemp.UCLA.EDU> <34ab0e42.8be4@apollo.uucp> <3583@jade.BERKELEY.EDU> <667@bsu-cs.UUCP>
Reply-To: iwm@doc.ic.ac.uk (Ian Moor)
Organization: Dept. of Computing, Imperial College, London, UK.
Lines: 51

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

From a quick reading of part of the VMS internals book, DCL is an interpreter
with its variables in protected memory (Executive mode I think) and its code
in shared system memory. Running a program involves reading code into memory
and CALLing it, there is no way that the command interpreter has to restart. 
DCL lacks proper structuring facilities, from VMS 4.4 it has IF THEN and
GOSUB RETURN, but nothing more; I consider this a serious design error in DCL
and not VMS though.
It does seem to be better than shell at string
handling and file io however. Process creation is slower than Unix 
but not excessively spawning a sub process from an editor or debugger is
a matter of a second or so. It seems that in many cases Unix uses processes as
an implementation technique because they are cheap, so straight ports of code
to VMS run slowly, but a little work speeds them up: MMS (DEC's Make clone)
creates a single subprocess and feeds commands commands to it rather than
creating a process per command.

-- 
Ian W Moor
  UUCP: seismo!mcvax!ukc!icdoc!iwm
  ARPA: iwm%icdoc@ucl                        
           
 Department of Computing   Whereat a great and far-off voice was heard, saying,
 Imperial College.         Poop-poop-poopy, and it was even so; and the days
 180 Queensgate            of Poopy Panda were long in the land.
 London SW7 Uk.