stansbury%mwvms@MITRE.ARPA (07/01/87)
--------
The following command procedure shows what appears to be a bug in the DCL
scoping of labels in command procedures. When this command procedure is
invoked on a VMS V4.5 system and you answer 1 to the first prompt and 2 to
the second, you get the following error message:
%DCL-W-USGOTO, target of GOTO not found - check spelling and presence of label
when DCL attempts to execute the
$ if c .ne. 3 then goto a1_start ! a1
statement. Note that the label A1_START is indeed defined at that
procedure level. If, however, you switch the order of the a2 and c2
subroutines, the command procedure works okay.
Has anyone else seen this behavior, and if so, do you have any suggestions
for ways around it (besides switching the order of a2 and c2)?
Jack Stansbury
jws@mitre.arpa
$ on warning then stop
$ write sys$output "Answer 1 to the first prompt and 2 to the second prompt"
$start:
$ write sys$output "This is start" ! start
$ inquire a "Input a" ! start
$ if a .eq. 1 then call a1 start ! start
$ if a .eq. 2 then call a2 start ! start
$ if a .eq. 3 then exit ! start
$ goto start ! start
$
$b1: subroutine ! b1
$ write sys$output "This is b1 called from ''p1'" ! b1
$ write sys$output "Exit back to ''p1'" ! b1
$ exit ! b1
$ endsubroutine ! b1
$
$a1: subroutine ! a1
$a1_start: ! a1
$ write sys$output "This is a1 called from ''p1'" ! a1
$ inquire c "Input c" ! a1
$ if c .eq. 2 then call c2 a1 ! a1
$ if c .ne. 3 then goto a1_start ! a1
$ write sys$output "Exit back to ''p1'" ! a1
$ exit ! a1
$ endsubroutine ! a1
$
$a2: subroutine ! a2
$a2_start: ! a2
$ write sys$output "This is a2 called from ''p1'" ! a2
$ inquire c "Input c" ! a2
$ if c .eq. 1 then call c1 a2 ! a2
$ if c .eq. 2 then call c2 a2 ! a2
$ if c .ne. 3 then goto a2_start ! a2
$ write sys$output "Exit back to ''p1'" ! a2
$ exit ! a2
$ endsubroutine ! a2
$
$c2: subroutine ! c2
$ write sys$output "This is c2 called from ''p1'" ! c2
$ call b1 c2 ! c2
$ write sys$output "Exit back to ''p1'" ! c2
$ exit ! c2
$ endsubroutine ! c2mccurdy@sdsu.UUCP (Mike McCurdy) (07/02/87)
In article <8707011941.AA06570@mitre.arpa>, stansbury%mwvms@MITRE.ARPA writes: > -------- > scoping of labels in command procedures. When this command procedure is > invoked on a VMS V4.5 system and you answer 1 to the first prompt and 2 to > the second, you get the following error message: > %DCL-W-USGOTO, target of GOTO not found - check spelling and presence of label > > when DCL attempts to execute the > > $ if c .ne. 3 then goto a1_start ! a1 If a 2 is entered in response to the second prompt, the "If c ..." statement will never be encountered. You will receive an -UNDEFINED SYMBOL error as you branch into a different procedure level for the C variable. You can simplify things by using GOSUB's instead of CALL's. Mike McCurdy San Diego State University None of this should be held against me.
stansbury%mwvms@MITRE.ARPA (07/07/87)
--------
In reference to my question about a possible DCL bug, Mike McCurdy writes:
>>scoping of labels in command procedures. When this command procedure is
>>invoked on a VMS V4.5 system and you answer 1 to the first prompt and 2 to
>>the second, you get the following error message:
>>%DCL-W-USGOTO, target of GOTO not found - check spelling and presence of label
>>
>> when DCL attempts to execute the
>>
>> $ if c .ne. 3 then goto a1_start ! a1
>
>If a 2 is entered in response to the second prompt, the "If c ..." statement
>will never be encountered. You will receive an -UNDEFINED SYMBOL error as
>you branch into a different procedure level for the C variable. You can
>simplify things by using GOSUB's instead of CALL's.
If you enter a 2 to the second prompt (i.e., c == 2), the above statement
is executed when the 'call c2 a1' statement finishes. However, the problem
is that DCL has lost track of the 'a1_start' label, and thus you get the
USGOTO error message. I don't get any UNDEFINED SYMBOL error messages from
executing that command procedure.
Jack Stansbury
jws@mi""# @ Dni