[Info-vax] /END=label

[Stephen Hoffman]

On 2018-08-27 16:54:57 +0000, Dave Froble said:

> On 8/27/2018 8:18 AM, Marc Van Dyck wrote:
>> For the moment, I just set exit with ss$_endoffile in $status. I can 
>> then test that in the next line and branch if needed. But I find the 
>> /END=label method much more elegant...
> 
> What you're doing, as I understand it, is invoking a program from DCL, 
> and then exiting the program.

Pragmatically, there's no difference here between a foreign command, an 
automatic foreign command, a user-written command invoked via DCL, or 
an executable that is RUN.

> Personally, I find testing the result of the program exit, and taking 
> appropriate action, rather elegant.  Guess this is a reason some like 
> VMS, and some hate VMS, why some like Unix, and some hate Unix.  
> Different people have different expectations.

Unix scripts can and often do use the same sorts of status tests, 
though Unix does lack the architected condition value constructs of 
OpenVMS; the different severities.

DCL error handling is a fair amount of coding and there's no 
lib$match_cond-like, no error object construct nor any sort of 
signal-related processing.   I'm not particularly fond of having 
constants embedded in DCL or anywhere else, and getting symbols from an 
executable into DCL (via SDL or otherwise) is clunky at best.  DCL 
doesn't (yet?) have a particularly means to dig those errors out of the 
executables, either.  Lots of glue code.

DCL doesn't deal at all well with application signals and asynchronous 
I/O and asynchronous events outside of ^C and ^Y and ilk, which 
unfortunate.  DCL gets and processes one error, and can't deal at all 
well with what else a signal frame could provide.

In more recent times, what the OpenVMS signal provides would likely be 
mapped into an error object, and DCL could then query or otherwise poke 
at the object as required.

DCL also exits on error, where shell scripts commonly continue 
processing until EOF or an explicit exit.  Which usually then means DCL 
procedures then get SET NOON and shell scripts can get some combination 
of set -o nounset, set -o errexit and/or set -o noclobber.

For some of what's been implemented in the aeon or three since sh and 
DCL and ilk, there's PowerShell: 
https://docs.microsoft.com/en-us/powershell/scripting/getting-started/getting-started-with-windows-powershell?view=powershell-6 


$status and related error handling aside, DCL dealing with run-time 
errors is a mess; stackdumps and crashdumps are not handled even 
remotely well.

And yes, I could see having some qualifiers that map to symbols, though 
I'd prefer to see the executable trigger the transfer of control 
indirectly via a callback, and not resort to embedding the literal DCL 
label into the compiled code nor into any non-DCL-scripting language.  
Keep that handled via the CLI.  But DCL doesn't do that, lib$do_command 
of a GOTO (if that even works) is hideous, and DCL needs a much wider 
overhaul or wholesale replacement.  Repeated nibbling around the edges 
of an implementation doesn't usually produce simplicity nor elegance 
nor consistency, as you and most everybody else well knows.


-- 
Pure Personal Opinion | HoffmanLabs LLC