any bug in script (if ... goto ?)

[Davor_7]

i have a captive account and when you login you could see menu options to select.
in the login.com, the function is done by:
$ if operation .eq. 1 then goto option1
$ if operation .eq. 2 then goto option2
$ if operation .eq. 3 then goto option3
$ if operation .eq. 4 then goto option4
$ if operation .eq. 5 then goto option5
$ if operation .eq. 6 then goto exit
$option1:
$...
$option2:
$...
$option3:
$...
$option4:
$...
$option5
$...
$exit
$logout

but... when i do the test, it sometimes displayed the error:
%DCL-W-USGOTO, target of GOTO not found - check spelling and presence of label
\option2\ (option2 is for example)
i can make sure that the script is correct. so i have to doubt whether there's some bug in the "if... goto..."

who faced to the similar problem before ?
thanks!

[Robert_Boyd · Accepted solution]

Davor,

I've faced this kind of problem MANY times.

Do you have a copy of DCL_CHECK.COM yet? if not, I highly recommend you get a copy and run it against your command procedure.

There is possibly an unbalanced if/then/endif construct or some other similar problem.

The most common problem I have like this is incorrectly matched or missing pieces of if/then/else/endif pairs.

DCL_CHECK usually narrows down these problems quickly. Checking it visually is sometimes tricky without an aid like this.

Robert

[Davor_7]

i havenot the DCL_CHECK.COM, can you help to share ?

btw, i maybe found some clues. each time when it's failure. the options at the bottom are not available.
i tried to shorten the script by shorten the DCLs to let the code be more tidy. as a result, i found that all the options are ok !!
so i still doubt this is not relevant to the constructure problem like you said...

of course, you can take a try to shorten the code:)

[Steven Schweda]

Does it always fail for "option2"?

It's pretty easy to get %DCL-W-USGOTO if you
have a bad IF-ENDIF somewhere.

alp $ type err.com
$ if (p1 .eqs. "1") then goto r_1
$ if (p1 .eqs. "2") then goto r_2
$ goto r_e
$!
$ r_1:
$ write sys$output "r_1"
$ if (p1 .gt. 0)
$ then ! Note: Missing ENDIF.
$ goto end
$!
$ r_2:
$ write sys$output "r_2"
$ goto end
$!
$ r_e:
$ write sys$output "r_e"
$ goto end
$!
$ end:
$ write sys$output "end"


Here, "r_2:" is easy to see, but:

alp $ @ err 1
r_1
end

alp $ @ err 2
%DCL-W-USGOTO, target of GOTO not found - check spelling and presence of label
\R_2\


If you can't see your problem, you might try
DCL_CHECK:

http://h71000.www7.hp.com/freeware/freeware70/dcl_check/

[Davor_7]

it's not always in option 2
it's always in the options at bottom (option 4 or 5)

[Volker Halle]

Davor,

DCL is an interpreter. So it always has to read ALL LINES in your DCL procedure, if it needs to find a (not previously seen) target label.

While reading the DCL script and finding an 'IF', it will skip all lines until finding a corresponding 'ENDIF', because you cannot transfer control (with $ GOTO label) into an IF ... ENDIF block.

So if there is an IF and no matching ENDIF, DCL will reach EOF of your script and report the %DCL-W-USGOTO error.

If this happens for the options 4 and 5 only, the probability is high, that the error is in the code for option3:

Volker.

[Davor_7]

VOLKER,
i donot agree with your point even if it would be possible a reason for such common question.

still in this example. when i found option 4,5 cannot be run, i tried to reassign the sequence of "option". i cut option4&5 on the top of option2. and then, i found option2,3 cannot be run. that's why i said "the options at the bottom" is unavailable in the above article... :)

[Ian Miller.]

DCL_CHECK can be downloaded from
http://h71000.www7.hp.com/freeware/freeware70/dcl_check/

and is recommended for this sort of problem.

[Steven Schweda]

> DCL_CHECK can be downloaded from
> http://h71000.www7.hp.com/freeware/freeware70/dcl_check/
> and is recommended for this sort of problem.

Doh! Why didn't _I_ suggest that?!

[Hein van den Heuvel]

An other pointer to dcl_check can be found under the 'top 5 stories' on http://dcl.openvms.org/

In there you may also find my reply to a 'goto lable in list' question:
http://dcl.openvms.org/stories.php?story=04/10/15/7698841

Davor wrote: "VOLKER,
i donot agree with your point even if it would be possible a reason for such common"

You may disagree, but Volker is right. Your punishment is to have to read his reply 3 times over. Your subsequent argument more or less proves his point. It looks like there is some bad dcl code say 2/3 into the file, any option 'below' that point can not be point, and DCL reads through it all.


>> have to doubt whether there's some bug in the "if... goto..."

There is no immediate bug, but I do hope it is an abbreviated example with the range checking left out. Even so, I would change that "$if operation .eq. 6 then goto exit"
into an unconditional "$goto exit", or follow it by an "$goto invalid_operation_choice"


btw...
If you have nice tight checking on the 'operation' variable being in the 1..6 set, then I'd change the whole 'if operation' lot by a single line:
$goto option'operation

Cheers,
Hein.

[Jan van den Ende]

Davor,

you do not have to agree with Volker, but he did a decent job (at least, in my opinion) of explaining things. And he is EXACTLY right, down to the point where he suspects the coding error: in the processing of option 3.
You almost said so yourself: putting 1 & 2 behind 3, then THOSE can not be found.

Have a REAL good count of your
$ IF
$ THEN
$ ENDIF
balance. Be aware that
$ IF .. THEN xx
should NOT be counted, because xx in THAT construct must be a SINGLE statement, and it is self-ending.
(and the reasons for the difference are that it is needed for compatibility with old code)

And really, DCL_CHECK, pointed by Steven & repeated by Ian, does that "Real good counting" better and faster than any human can.

Beleive me, I also have run into this error regularly, but each and every time the system was right and I was wrong!

Success.

Proost.

Have one on me.

jpe

[Thomas Simpson]

You are missing the colon from the EXIT label, so the target of the GOTO was not found.
It also appears to be missing off the OPTION5 label. Also note that as presented, your script will execute all the options after the intended one because there is no GOTO statement to transfer control to the EXIT label in the script. So, for example, if OPERATION = 4, options 4, 5 and 6 would be executed. I'm not sure if this is what you intended.

Regards,
Tom

[Allan Bowman]

In addition to the missing colons, also note that if the operation entered is not 1 thru 6, then option1 will be executed. You can check for the value beforehand and then replace all of the IF statements with the statement:

$goto option'operation

I have used this method in a number of procedures and it makes it very easy to add options later.

Allan in Atlanta

[Jan van den Ende]

Davor,

an easy implementation of Allan's chech (and I have seen way too many faulty ones!)

$ valid_choices = "/1/2/3/4/5/"
..
$ good_choice = f$locate("/''choice'/",valid_choices) .le. f$length(valid_choices)

(any line-wrapping by forum makeup, NOT to be coded!)

Mind the following details:
- BEGIN and END valid_choices with the separator (I chose "/", any character NOT in the set of valid choices will do)
- search for the string Saparator-Choice-Separator to exclide choices of which the valid choice only is a substring
- by equating good_choice to the result of a comparison it either gets the value "TRUE" or "FALSE", so you can simply do
$ IF GOOD_CHOICE
$ THEN
$ GOTO OPTION'choice'
$ ELSE
$
$ ENDIF


Success.

Have one on me.

jpe

[Hein van den Heuvel]

Oh my, look at all the over-engineering and duplication of replies. Might as well add one more...

I think Davor tried to help us by cutting fluff before posting, but with that his conversions and checks are gone.
Since he uses a .EQ. test, we may assume that the virable is already known to be an integer, and the valid range checking is then best done with a .GT.0 and .LT.max.
Or indeed, given the selection construction in place already by just fixing up the last compare and/or add a catchall one beyond it (my preference, as it does not overload the 'last' choice and is thus more maintainable.

Hein.

[Rudolf Wingert]

Hello,
if you mail is correct, then option 5 is not a label (I miss a : ) and the branch to option5 will fail.
Hope this helps. Best regards R. Wingert

[Davor_7]

Hi all,
the option5 missed a colon ":" is my typo error~ hehe. in deed, there's no error in my script even in IF-THEN-ELSE constructure.

To volker,
what i mean before is, i agree your answer is probably the rootcause for such problem,but i donot compromise that in my case :) but thanks all the same.

I still think this is a strange problem, and many folks have been discussing it for a long time...
pls allow me close this thread since this problem has been fixed after i cut off some unuseful lines in the script.
if whoelse find the similar problem like what i have, we can reopen it for further discussion or testing.

thank you everybody~ have a good day :)

[John Gillings]

Why not replace all those IF THEN statements with:


$ on warning then goto badoption
$ goto option'operation'
$
$ option:
$ badoption:
$ WRITE SYS$OUTPUT "error message"
$ GOTO menu-loop
$
$ option1:
$...
$ option2:
etc...

DCL is interpreted, so exploit it!

[Davor_7]

good idea :)

let me try it later..

thanks!