Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!MITRE.ARPA!stansbury%mwvms
From: stansbury%mwvms@MITRE.ARPA
Newsgroups: comp.os.vms
Subject: RE: DCL scoping of labels in subroutines
Message-ID: <8707071556.AA27206@mitre.arpa>
Date: Tue, 7-Jul-87 11:56:13 EDT
Article-I.D.: mitre.8707071556.AA27206
Posted: Tue Jul  7 11:56:13 1987
Date-Received: Sat, 11-Jul-87 01:19:22 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The MITRE Corp., Washington, D.C.
Lines: 26

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