[Info-vax] /END=label

[Paul Sture]

On 2018-08-27, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>
> Try lib$do_command, though I shudder at suggesting that, and haven't 
> tried that for this usage.  Emit a GOTO command, if that wasn't 
> obvious.  And I haven't tried this particular abomination.

Ugh. Where production systems don't contain high level program sources,
that a real recipe for "WTF is happening?" when something goes awry.

> Otherwise, patch DCL to add this feature, and Bob's your uncle.

No thanks! :-)

> More commonly?   Return the usual condition status, or return a symbol 
> or maybe (ugh) return a logical name.
>
> Or return a symbol containing a label and then jump "through" the 
> returned symbol with a GOTO, if you want to twist together the flow 
> control of the executable and the DCL interpreter within your own code.

This takes me back to VMS V2 where the IF staterment was restricted
to 
    IF <cond> THEN GOTO <label>
    
and there was no SUBROUTINE statement.

What you ended up with were constructs like:

$    return_label = "label_10"
$    goto subroutine_1
$label_10:
$    if error .ne. 0 then goto fatal_error
$    return_label = "label_20"
$    goto subroutine_2
$label_20:
$    if error .ne. 0 then goto fatal_error

...

$ subroutine_1:
$    <do stuff>
$    goto 'return_label'
$ subroutine_2:
$    <do other stuff>
$    goto 'return_label'


> Or invert the application logic, and have the executable or a main 
> written in Python, Perl, Lua or some other scripting language process 
> the application activities, and have that scripting code or the 
> executables summon DCL routines when and if necessary.  I shudder at 
> suggesting the emission of a DCL command and the direct execution of 
> that command, but it wouldn't surprise me to find some code that did 
> that.   Or the aforementioned and entirely cringe-worthy usage of 
> lib$do_command.

Where you are going to use lib$do_command to execute GOTO, I'd
definitely recommend putting the target label into a DCL symbol which
the program extracts via LIB$GET_SYMBOL.  This way you can keep the
logic flow visible within the DCL alone.  This should eliminate the "WTF
problem" which occurs on production systems where the program sources
are not available. 

>
> On 2018-08-27 12:18:55 +0000, Marc Van Dyck said:
>
>> But I find the /END=label method much more elegant...
>
> In terms of its general elegance, DCL is closer to a clown car than to 
> a town car.  It was pretty good for the 1970s and 1980s, but 
> expectations and requirements have changed in the ensuing decades.
>
> The limits and foibles of DCL have been repeatedly discussed around 
> here, though the related remediations and potential wholesale 
> replacement are undoubtedly far down the schedule for the folks at VSI.

I'd prefer going the route of "flipping" the problem so that Python,
Lua, or other scripting language does the flow control, calling out to
DCL when needed.

> I write this having just slammed into the 32-bit signed integer 
> limitations and the omission of floating point within DCL.  Again.  No 
> 64-bit integer support, no unsigned integer support, no floating point 
> support, no arbitrary-precision support, no object support, no UTF-8 
> encoding support, problematic local language support at best, no access 
> into iconv nor into the IANA/Olson zoneinfo database, no 64-bit CLI API 
> support, grafted-on piping support, etc.
>

Again, a modern scripting language which can do all this, is more
appropriate.


-- 
The trouble with the world is that the stupid are cocksure and the
intelligent are full of doubt.                 -- Bertrand Russell