campbell@maynard.BSW.COM (Larry Campbell) (05/01/88)
In article <2725@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
<>Based on a superficial (and rather skeptical, raised-eyebrow) look
^^^^^^^^^^^
<>at VMS, I conclude as follows.
<>
<>VMS's design makes it very difficult to include structured control
<>structures in DCL. The UNIX shells can save their context between
<>commands because they execute other programs as subprocesses. Under
<>VMS subprocess creation is so painfully slow that it is seldom done.
<>Thus the DCL interpreter cannot save its entire context when executing
<>another program. To use while loops and if-then statements the DCL
<>interpreter would have to save quite a bit of the current context so it
<>could continue executing the current control structure. Nested control
<>structures would require even more information to be saved. Alas, the
<>DCL interpreter and VMS make this nearly impossible.
<>
<>This is also the reason why VMS does not allow multiple commands
<>on the same line. Doing so would mean saving the command line
<>between executions of different programs so the command interpreter
<>could then pick the next command on the same line.
[This is really getting off the comp.lang.c track, so I've cross-posted
and directed followups to comp.os.misc]
A little knowledge is a dangerous thing, Rahul. Although VMS does not
create new subprocesses to run user programs, DCL does not have to get
out of the way when running a user program because the address space
is divided into two parts -- one for the user and one for DCL (and RMS).
The user part keeps getting zapped and reloaded with user programs,
but the DCL/RMS part (P1 in VMS jargon) stays around as long as you're
logged in.
So there is no _technical_ reason why DCL couldn't easily have multiple
commands per line, and reasonable control structures. The reason it
doesn't is cultural -- the VMS people have a FORTRAN mentality. For a
FORTRAN-inspired system, VMS isn't too bad. ("Gee, for a fat girl,
you don't sweat too much.")
--
Larry Campbell The Boston Software Works, Inc.
Internet: campbell@maynard.bsw.com 120 Fulton Street, Boston MA 02109
uucp: {husc6,mirror,think}!maynard!campbell +1 617 367 6846cetron@utah-cs.UUCP (Edward J Cetron) (05/02/88)
In article <2822@bsu-cs.UUCP> campbell@maynard.BSW.COM (Larry Campbell) writes: >In article <2725@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: ><>Based on a superficial (and rather skeptical, raised-eyebrow) look > ^^^^^^^^^^^ ><>at VMS, I conclude as follows. ><> ><>VMS's design makes it very difficult to include structured control ><>structures in DCL. The UNIX shells can save their context between ><>... ><>another program. To use while loops and if-then statements the DCL Golly, I wish Rahul had told this to the VMS development team! Seems version 5 (which is in SDC at this very moment and has been for 2 weeks) supports full if-then-(else) constructs. And I seem to recall a hint that while loops might not be too far behind.... -ed cetron@cs.utah.edu
jh@mancol.UUCP (John Hanley) (05/03/88)
In article <1079@maynard.BSW.COM> campbell@maynard.UUCP (Larry Campbell) writes: >In article <2725@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: ><>Based on a superficial look at VMS, [structured control in DCL seems hard]. ><>...also... VMS does not allow multiple commands on the same line. to which Larry points out that applying Unix notions to VMS in this case is just silly and that there's no need for spawning off expensive processes just to save context. In fact VMS even supports local variables (local to nested .COM files) without resorting to sub-procs, though Mr. Dhesi doesn't seem to crave local variables here. >So there is no _technical_ reason why DCL couldn't easily have [1] multiple >commands per line, and [2] reasonable control structures. And if you want them, there's no reason _not_ to have them! 1) DO_MULTI.COM: $ 'P1' $ 'P2' (etc.) I use something a little more complex because I prefer to seperate commands with a slash, but if you don't mind typing lots of quotes, this works just fine: $ @DO_MULTI "cmd1 arg arg" "cmd2 arg" The @do_multi, of course, inevitably winds up in a login.com symbol.... 2) I don't personally use it, but I remember seeing a compiler-design project that some professor posted on a DECUS tape, that translated a very C'ish (or Bourne-shell'ish) structured DCL dialect to plain old DCL .COM files, and very quickly, too. The output looked rather like Ratfor output: the IF-THEN-ELSE's, FOR's, and WHILE's get translated to spaghetti GOTO's with lots of generated labels mixed in. If anyone is currently using a spruced-up version of this translator, please post it, to silence the VMS bashing! (I admit that DCL would be much nicer if it had a native for(;;). 'Course, Bourne would be much nicer if it had a native expr ;^) The most serious design deficiency of VMS is the heavy expense of creating new subprocesses, and even this can be gotten around a-la Eunice by keeping them alive for future use rather than deleting them when an image exits. Anyone out there have a good "pipes" utility for building VMS pipelines with mailboxes? --John Hanley System Programmer, Manhattan College ..!cmcl2.nyu.edu!manhat!jh or hanley@nyu.edu (CMCL2<=>NYU.EDU) (The other serious design deficiency of VMS looks like it might be reliance on an inefficient lock system, which could limit highly-parallel performance. I'm dying to see how DEC is going to get decent speedups with VMS running on a hundred processors....)