dhesi@bsu-cs.UUCP (Rahul Dhesi) (05/23/87)
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
corwin@bsu-cs.UUCP (Paul Frommeyer) (05/23/87)
For the sake of the massive debate raging over the process creation under
DCL, here are the gory details as laid out by Digital themselves in the
VMS internals book:
The creation of a new proces requires the cooperation of several pieces
of the executive.
-Creation begins in the context of an existing process that executes a Create
Process system service call. The Create Process system service performs the
following steps:
a. It makes privilege and quota checks
b. It loads the PCB, possibly the JIB if creating a detached process,
and the process quota block with explicit SYS$CREPRC arguments and implicit
parameters taken from the context of the creator.
c. It places the new process into the scheduler's data base.
-The initial scheduling state of the new ocess is COMO (computable but
outswapped). Thus, execution of the shell process is suppressed until the
swapper process moves the new process into the balance set. The following
steps are performed in the context of the swapper process:
a. The swapper inswaps the template process context from SHELL, a portion
of the executive image SYS.EXE.
b. The process header is built according to the values of SYSBOOT
parameters for this configuration.
-The final steps of process initialization take place in the context
of the new process in a routine called PROCSTRT. PROCSTRT performs
the following steps:
a. The arguments from the PQB are moved to their proper places in the
process header and P1 space.
b. The image activator is called to activate the image.
c. The image is called at its entry poin
There's a whole chapter more of this (Chapter 20), but that's the general
overview. There seems to be something to both mine and Rahul Dhesi's
view based on this evidence (this will teach me to get my facts straight...).
It appears that DCL is only a partial contribution to the slowness of
process creation. While I was right in saying all the data structures are
in memory, the creation of the process in an outswapped state may be what
slows things down. If the creation could be coprocessed, with DMA image
load simultaneous with data structure manipulation, that might speed
things up. Well, if Digital ever hires me like I desperately wish
then perhaps I'll have an opportunity to learn more about process
manipulation in VMS...
N.B. Apologies for any typos in the above transcript.
--
Paul "Corwin" Frommeyer "Experience is no substitute for competence."
UUCP:
{seismo,ihnp4}!{iuvax,pur-ee}!bsu-cs!corwinjdh@bsu-cs.UUCP (John Hiday) (05/23/87)
In article <695@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > > The Wollongong Group realized very early on that VMS creates processes > very slowly.... VMS is not that slow creating processes. It's just the way DCL spawns processes that seems slow. Unless you tell it not to DCL copies all your symbols logical names, and keypad definitions from the parent process to the new process by sending them one by one through a mailbox. That is the part that takes so long, especially if you're the kind of user we have around here that has a LOGIN.COM the size of the new testament. Try the /NOSYMBOL /NOLOGICAL /NOKEY qualifiers on the SPAWN command or try using the $CREPRC system service directly. If you've got privs, skip accounting in the $CREPRC and make it even faster.
hwe@beta.UUCP (Skip Egdorf) (05/24/87)
>In article <19385@sun.uucp>, landauer@sun.uucp (Doug Landauer) writes: >> 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 think that a more important historical perspective involves the DecSystem-10 and DecSystem-20 series. In the late '60s and early '70s, TOPS-10 on the DEC-10 was the sort of "in" operating system that Unix is today. Everyone who was a true computer guru had to use one (the AI labs, etc.). (as a former TOPS-10 user, this reputation was solidly based...). One of the real marketing strengths was the single operating system used by the whole line of machines, TOPS-10. The ARPANET community had been playing with some upstart called TENEX. (Golly, does this story sound familier to VAX folks?) It became clear that DEC would have to support TENEX in some form as well as TOPS-10, and there were internal wars over this drastic step. The multi-OS group won, and DEC introduced the DecSystem-20 with a new operating system called TOPS-20 (TENEX). The single-OS group in DEC saw the 10/20 start to fade, and fought even harder to have only one OS on the new VAX. Would someone with more first-hand knowledge of the internal battles over this within DEC care to comment? Skip Egdorf hwe@lanl.gov
sy.Ken@CU20B.COLUMBIA.EDU.UUCP (05/27/87)
[landauer@sun.uucp (Doug Landauer)]: 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). Add RSTS to that list... -------
budd@BU-CS.BU.EDU.UUCP (05/28/87)
I worked for DEC/LCG as a software engineer, and as someone who tries to keep an open mind, I was apalled by the amount of TOPS-10 bashing was present among s/w developers. RMS and DBMS development was being dropped, FORTRAN v10 (ANSI full F77) was nearly not released for TOPS-10. Sucessive versions of TOPS-10 were released by customer demands for the new features: 7.00 SMP, 7.02 DECnet, 7.03 Extended Addressing. It shocked me that a group that had many times been on the edge of extinction could indulge in such internal bigotry. Phil Budne Boston University