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