Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Getting name of "root" DCL script

SOLVED
Go to solution
Jack Trachtman
Super Advisor

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?

 

TIA

5 REPLIES
Hoff
Honored Contributor

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.

 

John Gillings
Honored Contributor

Re: Getting name of "root" DCL script

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.

A crucible of informative mistakes
Jack Trachtman
Super Advisor

Re: Getting name of "root" DCL script

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
Trusted Contributor

Re: Getting name of "root" DCL script

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
Honored Contributor
Solution

Re: Getting name of "root" DCL script

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.