Getting name of "root" DCL script

(This has probably been answered before, but my searches have failed to find the solution).

The F$ENV("PROCEDURE") function will return the name of the script it's in. So if it's in script S1 & I run the script via "@S1" it will retturn "S1". If S1 runs "@S2" when in turn runs "@Sn", etc, the function will return name "Sn" (if it's in that script). Fine.

Is there some way to find the name of the "root" script from any level script? In the above example, how can I find the name S1 from script Sn?

Re: Getting name of "root" DCL script

I've worked on DCL that does these sorts of shenanigans, and it tends to be a fairly old programming design (predating GOSUB and particularly CALL), and it can get quite twisty. Particularly when the procedures are invoked via symbols or logical names; when the author(s) used (more of) the features of VMS and DCL, too.

Is there any way to do this? Sure. Root through the DCL control structures in P1 space looking for the DCL procedure data structures. It's possible, but it's not what most folks would consider fun. And it's not documented.

(Brian Schenkenberger had a SYMBOL tool around that might have some of this implemented.)

Any supported, documented, maintainable and upgradeable way? Nope. Not transparently.

If you're willing to modify the existing DCL code, then you can pass along this contextual information of course, and you can also modify the existing DCL procedures to create and invoke procedure levels with CALL statements and related control structures rather than with a new @ invocation.

I'd look to reorganize this DCL, and would consider invoking the sequence from within a program (Python, C, BASIC, whatever), or via CALLs retrofit into the existing procedures, or (for the "least-energy" change) by passing along the contextual information in symbols.

Re: Getting name of "root" DCL script

Put these two lines near the start, and make sure that as you exit you always reset the current level and deassign the logical.

This code isn't dependent on any command procedure, which means you can insert the few lines that you need into any procedure at all. It's easy to write the code that displays the levels and the procedure names.