[Info-vax] DCL's flaws (both scripting and UI)

[Stephen Hoffman]

On 2015-01-23 17:15:00 +0000, Doug Phillips said:

> On 1/23/2015 9:44 AM, JF Mezei wrote:
>> On 15-01-23 02:30, Phillip Helbig (undress to reply) wrote:
>> 
>>> $ pipe dir disk$user:<helbig> | sea sys$pipe login
>> 
>> 
>> Isn't support for <directory> something that dates back fro PDP11 days
>> and supported on VMS just to helop that transition ?
>> 
>> I'd say that support for <directory>  could be deprecated and removed in
>> a version or two of VMS.
>> 
> 
> I don't use <dir> myself, and my few remaining VMS sites are all on 
> Alpha v7.3-2 so I don't know if this has changed with v8.n, but $SEARCH 
> SYS$MANAGER:*.COM ":<" shows that DEC/CPQ/HPQ did use <dir> quite a 
> lot. So, if it's a problem with PIPE, then I say fix PIPE and don't 
> break DCL.

This gets into the accreted nature of DCL and VMS syntax, and allowing 
< and > means making DCL more syntax-aware.

Bash has some of this same mess, where some bash constructs require 
whitespace.  There's also that Unix\ path\ syntax\ has\ its\ warts, but 
it's simpler.

> One "fix" that I'd like to see is removing the *need* to define a root 
> like $DEFINE MYROOT DEV:[MYDIR.] for MYROOT:[SUBDIR]. But, if any ".][" 
> or "][." or "][" in a directory spec were parsed as a single dot we 
> could just use SYS$LOGIN:[SUBDIR]. What problems would that cause?

Or any .><, .>[, .]<, >[, ]<. etc...  Problems?  Donno.  There's 
undoubtedly some customer code around that parses that stuff, and that 
would trip up.

The concealed rooted logical names are an accreted mess, and parsing 
the specifications is less than fun.

> I don't think any thoughtful additions to DCL should break any code 
> that currently exists and as with any other new release of any language 
> or OS, you can't use new features on old versions that don't support 
> those new features.

Yeah.  The thoughtless additions to DCL will probably better involve 
wholesale replacement and a migration.  :-)
> 
> Back in VMS v5.0 we got IF-THEN-ELSE-ENDIF and we all knew that if we 
> used it the .COM wouldn't work on anything older than V5.0 -- but old 
> DCL would still work on v5.0 -- so what's the problem with *enhancing* 
> DCL?

Compatibility adds constraints, and tends to lead to yet more 
accretion.  The <> syntax was for compatibility, and the dsa1:<hoffman> 
was collateral damage.

> I personally have nothing against GOTO but a FOR or DO-WHILE and 
> DO-UNTIL would be nice and there are many times I wish for a CASE or 
> SWITCH or MATCH construct that I could use instead of a series of IF's 
> and GOTO's.

Or instead of using computed gotos; of symbol substitution in the labels.

> I strongly agree with David Froble and others that the simple answer is 
> to use the right tool for the job, but DCL can be enhanced without 
> breaking it.

DCL can certainly be enhanced, yes.  Various enhancements can likely be 
useful to me, too.   But I'd also ask whether a better buggy whip is an 
appropriate goal here.  Sure, the horse industry is a big market, but 
is it the one that VMS can or should be in?  But would something 
different and much better and much more capable draw more folks to VMS, 
and cause existing VMS folks to really upgrade to get the new features? 
 Incremental changes are useful for many site, but they're just not 
going to overhaul existing limitations, nor are they likely to draw in 
new folks.



-- 
Pure Personal Opinion | HoffmanLabs LLC