Xref: utzoo comp.os.misc:421 comp.os.vms:5900
Path: utzoo!mnetor!uunet!husc6!cmcl2!phri!manhat!mancol!jh
From: jh@mancol.UUCP (John Hanley)
Newsgroups: comp.os.misc,comp.os.vms
Subject: Re: marketing vs. demerit (DCL _can_ be structured!)
Message-ID: <380@mancol.UUCP>
Date: 3 May 88 08:32:43 GMT
References: <1988Apr11.201934.20594@utzoo.uucp> <451@goofy.megatest.UUCP> <1988Apr24.004626.3209@utzoo.uucp> <2605@ttrdc.UUCP> <2725@bsu-cs.UUCP> <1079@maynard.BSW.COM>
Reply-To: jh@mancol.UUCP (John Hanley)
Followup-To: comp.os.misc
Organization: Manhattan College
Lines: 51

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