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

[David Froble]

Simon Clubley wrote:
> On 2015-01-19, David Froble <davef at tsoft-inc.com> wrote:
>> Simon Clubley wrote:
>>> With bash, you can have multiple shells active at the same time and
>>> only the commands entered during a specific session will be added to
>>> the history file when that session exits even though the shell has the
>>> full command history from previous shells available (up to a user
>>> defined limit).
>> I don't know why anyone would want 2 script processors at the same time. 
>>   Isn't that multiple sessions?
>>
> 
> Yes. Different terminal sessions running in multiple terminal windows at
> the same time.
> 
>> I also don't understand retaining the history.
>>
> 
> It acts as a cache of your commonly used commands which are available
> for immediate recall across multiple sessions.

I know what it does, I don't understand the need for the history.

Consider:

$ t login.com
$ login_vfy = F$VERIFY(0)
$
$ write SYS$OUTPUT "Performing [DFE]LOGIN.COM ...."
$
$ define /nolog GAMES DISK0:[DFE.GAMES]
$ define /nolog KER$COMM MODEM_PORT:
$ define /nolog TCPIP$FTP_NO_VERSION 1
$
$ cker*mit :== $SYS$SYSTEM:CKERMIT
$ delt :== delete /confirm /created /since=TODAY *.*;*
$ dial :== set host/dte MODEM_PORT:
$ em :== run GAMES:EMPIRE
$ lcp :== $SYS$SYSTEM:LATCP
$ ncp :== $SYS$SYSTEM:NCP
$ nsl :== $SYS$SYSTEM:TCPIP$NSLOOKUP
$ nslookup :== $SYS$SYSTEM:TCPIP$NSLOOKUP
$ print :== print/form=DFE
$ pv :== set process/priv=all
$ snn :== spawn/nowait/notify
$ syh :== show system /noprocess
$ sys :== @DISK0:[DFE]SYS.COM
$
$! SHUTDOWN  == "@SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN YES NO LATER NO NONE"
$ SHUTDOWN  :== @SYS$SYSTEM:SHUTDOWN
$ REBOOT == "@SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN YES YES LATER YES NONE"
$
$ @DISK1:[SOFTWARE]SRCLOGIN.COM
$
$ CANADA :== @DISK0:[DFE.GO]CANADA.COM
$ CLAY :== @DISK0:[DFE.GO]CLAY.COM
$ DFE :== @DISK0:[DFE.GO]DFE.COM
$ DFEUL :== @DISK0:[DFE.GO]DFEUL.COM
$ RENT :== @DISK0:[DFE.GO]RENT.COM
$ WRS :== @DISK0:[DFE.GO]WRS.COM
$
$! set prompt="DFE90A> "
$
$ login_vfy = F$VERIFY(login_vfy)


And there is more in the system SYLOGIN.COM


>>> Some of DCL's scripting limitations:
>>>
>>> 1) No structured programming constructs such as (for example) while
>>> loops.
>> Learn the mantra,
>>
>> "DCL is not a programming language".
> 
> Yes it is.
> 
> It's used to control the startup and operation of VMS.
                ^^^^^^^
> 
> It's used to control user created batch jobs and interactive command
                ^^^^^^^
> procedures.

If the alignment is correct, you'll see that you even agree that it's a 
"command language".

> It doesn't matter that it's used in interpreted scripting environments
> instead of compiled executables; it's still a programming language and
> one which is very dated by today's standards.

Dated, I'll give you, and could stand some improvements.

>> Through all of what you wrote, there is this "feeling" that you are 
>> writing from the perspective of a workstation, not a "server".  Things 
>> such the command line recall and length just don't come up when you're 
>> running programs.  As a software person, I can appreciate what you're 
>> asking for.  But from a production perspective, I don't see that it's 
>> relavent.
>>
>> Not saying you should not have all that you listed.  But, I'd like you 
>> to discuss them not from a development and / or management station, but 
>> from a "running production" perspective.
> 
> These _are_ from a running production perspective (or don't you have
> long or frequently used command lines as well as user written command
> procedures in production use ?)

In general, no, we do not.

Yes, there is command files for backups and some other things.  But we 
do not solve problems in DCL.