Accessing Labels outside the subroutine in DCL

[Pradeep Nair_1]

I have a DCL script where i need to access label from subroutine, which i had declared outside the subroutine. The DCL structure is like below..

main_prog:
...
...call sub1
...
sub1 : subroutine
...
...
goto main_prog
...
...

when goto main_prog executes in the subroutine..i'm getting an error.
%DCL-W-USGOTO, target of GOTO not found - check spelling and presence of label.

Appreciate any tips to resolve this.

Thanks in Advance.

Pradeep Nair.

[Martin Hughes]

Try

$ ENDSUBROUTINE

[Pradeep Nair_1]

Hi Matrin,

Sorry i didn't mentioned endsubroutine in the script structure.

With endsubroutine also give the same result unfortunately.

Thanks
Pradeep Nair.

[Martin Hughes]

Hi Pradeep,

What I meant is this;

$main_prog:
$!...
$ call sub1
$ goto main_prog
$
$sub1 : subroutine
$!...
$endsubroutine

[John Gillings · Accepted solution]

Pradeep,

The USGOTO warning is correct. The scope of the subroutine is strictly between the label and the ENDSUBROUTINE. Subroutines have their own symbol and label spaces. In some ways it's like having a procedure within a procedure.

From a program structure perspective, jumping to an external label would be a very bad thing, as you would leave a dangling CALL on the stack. If you did it in a loop, you'd eventually exhaust command procedure levels and get:

%DCL-W-STKOVF, command procedures too deeply nested - limit to 32 levels

To achieve what you want, you need to EXIT the subroutine cleanly, passing back a status that the caller can use to branch on. For example:

$ main_prog:
...
$ CALL SUB1
$ IF $STATUS.EQ.3 THEN GOTO main_prog
...

$ SUB1 : SUBROUTINE
...
$ EXIT 3 ! tell caller to branch
...
$ EXIT 1 ! tell caller to not branch
$ ENDSUBROUTINE

You should use odd numbers as exit status values so DCL doesn't interpret them as error or warning conditions.

Another, more powerful mechanism is to use a global symbol to return an operation to perform on return. Note the "==" as it MUST be a global symbol. For example:

$ MAIN_PROG:
...
$ SUB1_RETURN_OP==""
$ CALL SUB1
$ 'SUB1_RETURN_OP'
...

$ SUB1 : SUBROUTINE
...
$ SUB1_RETURN_OP=="GOTO MAIN_PROG"
...
$ SUB1_RETURN_OP=="WRITE SYS$OUTPUT ""SUB1 OK"""
...
$ EXIT
$ ENDSUBROUTINE

[Hoff]

DCL is working as expected, and as documented.

A CALL invokes another procedure level; it works just like a @ procedure invocation.

Put another way, you have to EXIT your way back out of a CALL'd subroutine; either an EXIT explicitly issued, or implicitly via reaching the ENDSUBROUTINE.

You cannot GOTO your way out of the CALL'd routine.

The DCL procedure level is analogous to a stack frame in a compiled language; symbols and such can be passed in, but are not passed back out by default. In the case of a CALL'd routine, you can think of the DCL commands between the entry point and the EXIT or ENDSUBROUTINE as being located in a private DCL procedure file.

Stephen Hoffman
HoffmanLabs

[Pradeep Nair_1]

Greate Help John, Martin and all.

We need to take care of Exit status from the subroutine rather branching to the main procedure.

Now i changed the script to new structure.

main_prog
...
...
call sub1
if $status.eq.3 then goto main_prog
...
...
sub1:subroutine
...
...
goto exit_me
...
...
exit 1
exit_me:
exit 3
endsubroutine

[Pradeep Nair_1]

It was a great experience to have different ideas & knowledge from the forum members...

Thanks for all the support.

Pradeep Nair.