Strange DCL behaviour, target of GOTO not found.

Hans-Peter Harpoeth

unread,

Oct 25, 1996, 3:00:00 AM10/25/96

to

Hello

Some time ago I ran into the following (strange?) problem in a DCL progra=
m.
%DCL-W-USGOTO, target of GOTO not found - check spelling and presence of =
label

I reduced the code to the following:

$ set verify
$ !
$ if "TRUE"
$ then
$ gosub A
$ endif
$ exit
$ !
$ !-------------------------------------------------------
$ C:
$ !
$ goto E
$ !
$ E:
$ if "TRUE"
$ then
$ !
$ endif
$ return ! C
$ !
$ !-------------------------------------------------------
$ A:
$ !
$ B:
$ if "TRUE"
$ then
$ gosub C
$ goto B
$ endif
$ return ! A

Any further reduction of the code removes the problem.
Ex. try the following:
- Remove the first if statement and call gosub A directly.
- Remove the goto E
- Remove the if statement in the routine C:
- Remove the if statement in the routine A:
I solved the problem by interchanging the order of routine A: and C:.

The problem exists on VMS 5.5 and 6.2 and both on VAX and AXP.

What am I doing wrong ? What is happening here ?

Regards Hans-Peter

--

Hans-Peter Harpoeth BB & OOO
SW development B B & & O O Phone : +45 96 84 49 85
Bang & Olufsen BBBB && O O or : +45 96 84 11 22
Peter Bangs Vej 15 B B & && O O Fax : +45 97 85 59 50
DK-7600 Struer B B & && O O email : hph(a)bang-olufsen.dk
Denmark BBBB && OOO

VERBRUGGEN Marc

unread,

Oct 25, 1996, 3:00:00 AM10/25/96

to

--
I seem to remember that there is indeed a limit on how far the GOTO can
jump. Does anyone know how far ?
o _o
_/[;_ - - _ \<;_
---------(_)>(_)------(_)/ (_)------------------------------------------
Marc Verbruggen-GZ3 voice : 32 3 4503349
Alcatel Bell Telephone fax : 32 3 4503595
de Villermontstraat 38 email : brug...@god.bel.alcatel.be
B-2550 Kontich pmail : see left column
Belgium

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i

mQBNAzJjUrUAAAECAKAFO8xIODggDUQY/VALMARJjhf89J+qFHV/fOKivVtRRJjC
yv+UN2f9aXrZQlOynFSCYPFWUJ8O1YZr2LWGO9kABRG0KFZlcmJydWdnZW4gPGJy
dWdnZW1hQGdvZC5iZWwuYWxjYXRlbC5iZT6JAFUDBRAyY1K11YZr2LWGO9kBATBv
Af9iqymdU6NmWE23xyaWbsi33vB0mNPQdgHYhZo4qVuqMKCM9Sm6Yc+/Ewxm9fIe
4El7AaeIrVexBnNP8itLebqx
=kCTs
-----END PGP PUBLIC KEY BLOCK-----

Stuart Palin

unread,

Oct 28, 1996, 3:00:00 AM10/28/96

to

brug...@god.bel.alcatel.be (VERBRUGGEN Marc) wrote:
[Sorry I could not find the original article so I have hijacked this one]

A very infuriating cause of this problem is labels in block structures
(IF .. ENDIF). Quite rightly you should not be allowed to jump into blocks, but if
you forget to terminate a block you get the misleading USGOTO message (rather than
the more useful INVIFNEST).

$ GOTO L1
$ IF 1
$ THEN
$ CONTINUE
$!ENDIF ! Ooops
$ L1:

Hope this helps.

Stuart Palin

Hans-Peter Harpoeth

unread,

Oct 29, 1996, 3:00:00 AM10/29/96

to

I wrote:
> Some time ago I ran into the following (strange?) problem in a DCL prog=
ram.

> %DCL-W-USGOTO, target of GOTO not found - check spelling and presence of

> label
>
> [...]

>
> Any further reduction of the code removes the problem.

MONSC...@kiddy.btx.dtag.de (Michael Monscheuer) wrote:
[ cut.cut.cut ]
>I once had exactly the same problem. It seems that under particular
>circumstances DCL issues wrong error messages. In this case
>the wrong message "target of goto not found" instead of correctly
>displaying "invalid if-then-else structure". It's just a blind guess,
>but is it possible that your DCL code is somewhat of obnoxiously long ?

Long?? I don't think the 31 lines of code in my original posting is very lo=
ng!

stuart...@gecm.com (Stuart Palin) wrote:
[ cut.cut.cut ]

>
>A very infuriating cause of this problem is labels in block structures

>(IF .. ENDIF). Quite rightly you should not be allowed to jump into block=
s,
but
> if
>you forget to terminate a block you get the misleading USGOTO message (rat=
her
th
>an

>the more useful INVIFNEST).
>
>$ GOTO L1
>$ IF 1
>$ THEN
>$ CONTINUE
>$!ENDIF ! Ooops
>$ L1:

Something like this might be the problem. But if it is, why on earth does it
solve the problem just to interchange the order of routine A: and C:. ???
Or just to remove some dummy goto statement (goto E). ??
Please note this dosn't interfer with any if statements IMHO.
I don't get it. :-(

Dominic Olivastro

unread,

Oct 29, 1996, 3:00:00 AM10/29/96

to Hans-Peter Harpoeth

Hans-Peter Harpoeth wrote:
>
> I wrote:
> > Some time ago I ran into the following (strange?) problem in a DCL prog=
> ram.
> > %DCL-W-USGOTO, target of GOTO not found - check spelling and presence of
> > label
> >
> > [...]
> >
> > Any further reduction of the code removes the problem.
>

[snip]

I'm afraid Hans is being given short-shrift. He has very definitely
found a bug in DCL that someone at DEC should look into. Here is
something interesting:

The first section, as HANs has it, is:

$ if "TRUE"
$ then gosub A
$ endif

This works in that it goes to A, but once in A it fails to find the
label "B"

Now, if this is changed to:

$ if "TRUE" then gosub A

everything works fine. As far as I can tell, there is some bug that
prevents you from entering a subroutine within an IF-BLOCK.

--
Dominic Olivastro CHI Research, Inc
e-mail: chiR...@ix.netcom.com fax: 1-609-546-9633
visit our web site at http://www.chiResearch.com

Dave Cannell

unread,

Oct 29, 1996, 3:00:00 AM10/29/96

to

I think that I've noticed a similair problem if the distance to the
GOTO'd label is quite far away...

Dave

Hans-Peter Harpoeth (h...@bang-olufsen.dk) wrote: : Hello

: Some time ago I ran into the following (strange?) problem in a DCL progra=
: m.
: %DCL-W-USGOTO, target of GOTO not found - check spelling and presence of =
: label

: I reduced the code to the following:

: $ set verify
: $ !

: $ if "TRUE"
: $ then
: $ gosub A

: $ endif
: $ exit
: $ !
: $ !-------------------------------------------------------
: $ C:
: $ !
: $ goto E
: $ !
: $ E:

: $ if "TRUE"
: $ then
: $ !

: $ endif
: $ return ! C
: $ !
: $ !-------------------------------------------------------
: $ A:
: $ !
: $ B:

: $ if "TRUE"
: $ then
: $ gosub C

: $ goto B
: $ endif
: $ return ! A

: Any further reduction of the code removes the problem.
: Ex. try the following:

: - Remove the first if statement and call gosub A directly.
: - Remove the goto E
: - Remove the if statement in the routine C:
: - Remove the if statement in the routine A:

: I solved the problem by interchanging the order of routine A: and C:.

: The problem exists on VMS 5.5 and 6.2 and both on VAX and AXP.

: What am I doing wrong ? What is happening here ?

: Regards Hans-Peter

Thomas F. Smith, Jr.

unread,

Nov 16, 1996, 3:00:00 AM11/16/96

to tsm...@wow.com, tsm...@juno.com

On a related note, something I've found usefull with large DCL
procedures is to add a not normally called label (ie "find_dcl_error:")
to the end of the procedure. Then, at the beginning of the procedure
immediatly gosub find_dcl_error and return. If you receive a target of
gosub not found, move the label closer to the beginning of the command
procedure.

After a few attempts moving the label around you'll be able to determine
the start of the block which broke your code. I've had a couple of DCL
procedures, which should have been .EXE's (they ended up 4-5000 lines in
length) and this helped me find my errors in a matter of seconds or
minutes.

/T