Getting name of "root" DCL script

[Jack Trachtman]

(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?

TIA

[Hoff]

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.

[John Gillings]

Jack,

   It's possible, but not directly from DCL. Somewhere around I have some code to do a DCL procedure "traceback". Let me know if you want me to go hunting for it.

[Jack Trachtman]

Ok, so not as easy as I presumed.

I'll fall back to my original idea (ala Hoff) & consider defining something within my "root" script.

(Now, how do I close this stream?)

[John McL]

If it's really important to you, you could use something like

If (logical DCL_CUR_LEVEL exists) then increment it else set to 1.

define DCL_PROC_<cur_level> as F$ENVIRONMENT("PROCEDURE")

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.

[Hoff · Accepted solution]

There exists a documented interface for the DCL procedure depth.  

Here is a (slightly edited) demonstration of the available interface, and (if you're rolling your own) this stuff allows you to get the depth easily:

$ @s1
depth 1, max 32, proc S1.COM;1
depth 2, max 32, proc S2.COM;1
depth 3, max 32, proc S3.COM;1

$ type s%.com

S1.COM;1

$ x = f$env("DEPTH")
$ y = f$env("MAX_DEPTH")
$ z = f$env("PROCEDURE")
$ write sys$output "depth ''x', max ''y', proc ''z'"
$ @s2

S2.COM;1

$ x = f$env("DEPTH")
$ y = f$env("MAX_DEPTH")
$ z = f$env("PROCEDURE")
$ write sys$output "depth ''x', max ''y', proc ''z'"
$ @s3

S3.COM;1

$ x = f$env("DEPTH")
$ y = f$env("MAX_DEPTH")
$ z = f$env("PROCEDURE")
$ write sys$output "depth ''x', max ''y', proc ''z'"
$

And yes, a CALL to a DCL subroutine will (also) increment the procedure depth.