%DCL-E-INVIFNEST, invalid IF-THEN-ELSE nesting structure or data inconsistency

[Debasis Bhar]

Script is
====
$ para1 = f$edit(p1,"upcase,trim")
$ IF ("''para1'" .eqs. "ONLINE") .OR. ("''para1'" .eqs. "1") THEN goto LOOP_DISK
====
I am getting the below error message but it is going to LOOP_DISK label. Any idea how i can correct this error message?

%DCL-E-INVIFNEST, invalid IF-THEN-ELSE nesting structure or data inconsistency

[Heinz W Genhart]

Hi Debasis Bhar

I copied the two lines of code into a commandfile and executed it without any error message. The two lines are correct (only a label loop_disk is missing).

Is this the whole script? Can you supply the rest of the script

Regards

Geni

[Debasis Bhar]

here is the error message in set verify mode.. p1 is online..

$ para1 = f$edit(p1,"upcase,trim")
$ IF ("ONLINE" .eqs. "ONLINE") .OR. ("ONLINE" .eqs. "1") THEN goto LOOP_DISK
%DCL-E-INVIFNEST, invalid IF-THEN-ELSE nesting structure or data inconsistency
$ LOOP_DISK:
...
...
...

[Richard Brodie_1]

The error is likely in one of the lines you haven't shown.

$ @T
$ IF 1 then goto a
%DCL-E-INVIFNEST, invalid IF-THEN-ELSE nesting structure or data inconsistency
$ a: exit

$ type t.com

$ IF 1 then goto a
$ endif ! Pointless endif
$ a: exit

[Kris Clippeleyr]

Debasis Bhar,

Is it possible that by taking the branch (goto LOOP_DISK) you're jumping out of or into an IF-THEN-ELSE-ENDIF construction?

I've copied your snippet of DCL-code, added 4 lines:

$ ENDIF
$ EXIT
$LOOP_DISK:
$ write sys$output "Reached LOOP_DISK"

and then by executing this procedure, I get the "invalid IF-THEN-ELSE".
If I remove the "$ ENDIF" line, all is well.

So, I suggest you check the line between the "goto LOOP_DISK" and the LOOP_DISK label for ill-constructed IF-THEN-ELSE-ENDIFs.

Regards,
Kris (aka Qkcl)

[Willem Grooters]

In searching for a label, DCL will do the comparison in IF statements and only check the codepath that conforms the outcome. If you jump out of, or into a IF_THEN_ELSE_ENDIF block, it could cause this and other problems.
Quite likely this is caused by a coding error.

[Jan van den Ende]

Debasis Bhar,

I have not (yet) seen enough of the script to have a definite answer, but my guess would be infamiliarity with DCL history.

Once there was only the following construct:

$ IF condition THEN command

Most often "command" was something more then a single statement, and the only ways to achieve that were GOTO label, or @

When IF .. THEN [possible ELSE] was introduced, as always VMS engineering was NOT to break existing code, so, the old construct had to be retained.

The "trick" they used was to add pseudo-commands:
$ THEN
which allowes for, but does not require
$ ELSE
and had to be ended by
$ ENDIF

So, now there are TWO different IF constructs:

$ IF condition THEN command

( notice: NO !!! ENDIF )

and

$ IF condition
$ THEN
< commands >
[ $ ELSE
< other commands > ]
$ ENDIF

In the second construct only may themselves be IF constructs; although it is considered bad practise to use the first construct within the second.

My guess is that you used the first construct, but still used $ ENDIF

hth

Proost.

Have one on me.

jpe

[Hoff]

Turn on procedure verification, invoke the procedure, and count the numbers of times you've entered a multi-line IF and the numbers of times you've exited a block via its matching ENDIF.

OpenVMS stinks at this sort of DCL-level tracing; it's often somewhat tedious to find these errors in non-trivial DCL procedure code. There's unfortunately no visible "nested" count for IF-THEN-ELSE stuff. Not until you blow out with the INVIFNEST error, that is.

The other approach is the brute-force approach, and involves refactoring and restructuring the code of the DCL procedure. Of cleaning up the GOSUB and GOTO and CALL and the flow control.


ps: this:

$ IF ("''para1'" .eqs. "ONLINE") .OR. ("''para1'" .eqs. "1") THEN goto LOOP_DISK

can be replaced with this:

$ IF (para1 .eqs. "ONLINE") .OR. (para1 .eqs. "1") THEN goto LOOP_DISK

And I don't know what this DCL code is doing here, but this code really smells like a parser of some sort. Possibly parsing DCL command output? And there are better ways to do that than DCL.

[Jon Pinkley]

When verification is on, the "''para1'" .eqs. "ONLINE" provides more useful debugging information than para1 .eqs. "ONLINE", especially when it isn't equal.

However, when the para1 symbol value contains double quotes the "''para1'" construct does work in the general case. The := assignment and & substitution have different effects as well.

$ para1 = """this has double quotes"""
$ para2 = "''para1'"
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
\HAS\
$ para3 = para1
$ para4 := "''para1'"
$ para5 = &para1
$ sho sym para*
PARA1 = ""this has double quotes""
PARA3 = ""this has double quotes""
PARA4 = "THIS HAS DOUBLE QUOTES"
PARA5 = "this has double quotes"
$

Getting symbol substitution to work when double quotes are involved is a real pain.

[Graham Burley]

Get a copy of Charlie Hammond's DCL checker, written in good old DCL, perhaps from here:

http://www.digiater.nl/openvms/freeware/v80/dcl_check/

It's a useful tool to have around and will probably find the problem with your command procedure.