Nested If else statements

[kpie...@gmail.com]

I am trying to use nested if statements in Cobol. As far as I can tell I am following the style guides, but keep receiving the error:

file_name.cob:64: Error: syntax error, unexpected ELSE
^ This is the second ELSE statement

The purpose of the code is to function as a Caesar cipher, but it seems to only be the nested if statements that are producing the error. I tried putting the nested statements after the ELSE clause of the initial IF statement, but that was unsuccessful as well.

I am using open-cobol, and and compiling with the '-free' option on the 1.1 compiler

IF CharCount < 26
ADD firstnum, CharCount GIVING stringShift.
DISPLAY stringShift.

IF FUNCTION MOD(stringShift, 26) IS NOT ZERO

MOVE FUNCTION MOD(stringShift, 26) to stringShift
DISPLAY stringShift

MOVE abc(stringShift:stringShift) TO newChar
DISPLAY newChar

STRING newString DELIMITED BY "", newChar DELIMITED BY SIZE INTO newString

DISPLAY newString
ELSE
STRING newString DELIMITED BY "", searchChar DELIMITED BY SIZE INTO newString
DISPLAY newString
END-IF
ELSE
STRING newString DELIMITED BY "", searchChar DELIMITED BY SIZE INTO newString
DISPLAY newString
END-IF.

Note: I know this is a beginner question, but have looked at a lot of documentation and am at a loss.

Thanks!

[Kerry Liles]

Assuming you pasted the code verbatim in your example, the periods in
the two statements immediately after "IF CharCount < 26" are part of the
problem... If you are using END-IF scope delimiters, do NOT use periods
at the end of any statement except the last statement in a paragraph!
The period at the end of "ADD firstnum, CharCount GIVING stringShift."
terminates the IF - not at all what you intended.

HTH

[Kerry Liles]

On 4/25/2013 3:00 PM, Kerry Liles wrote:
> On 4/25/2013 2:38 PM, kpie...@gmail.com wrote:

...snipped original

>
> Assuming you pasted the code verbatim in your example, the periods in
> the two statements immediately after "IF CharCount < 26" are part of the
> problem... If you are using END-IF scope delimiters, do NOT use periods
> at the end of any statement except the last statement in a paragraph!
> The period at the end of "ADD firstnum, CharCount GIVING stringShift."
> terminates the IF - not at all what you intended.
>
> HTH

In other words, do not mix periods as end of statement and scope
delimiters like end-if

Personal taste, but I prefer not using periods at all except for the one
(that I believe is required!) at the end of a paragraph...

[kpie...@gmail.com]

That was it! You, my good sir, are a gentleman and a scholar. Thank you!

-Kevin

On Thursday, April 25, 2013 3:00:23 PM UTC-4, Kerry Liles wrote:

[Pete Dashwood]

Hi Kevin,

Kerry has explained your problem, but I thought I'd add something about
nested IFs which might help you and others:

Dashwood's guidelines for NESTING COBOL IF:

1. Use nested IFs ONLY to represent a "decision tree".

2. Nest ONLY into the TRUE branches. (I confess to some rare cases where I
have used the FALSE branch but doing this is "best avoided")

3. DON"T embed other statements into the TRUE or FALSE branches. (See
example following)

4. Use scope delimiters, not periods (full stops).

5. Don't nest to too many levels. ("too many" is determined by what you can
see... if your nested IF goes over pages, rethink it.)

OK, here's a decision tree (in English):

If condition 1 is true AND condition 2 is true AND condition 3 is true, I
want to do action 1. But, if condition 1 is true AND condition 2 is true AND
condition 3 is NOT true, I want to do action 2, and if condition 1 is true
AND condition 2 is NOT true, I want to do action 3, and if condition 1 is
NOT true I just want to carry on (do nothing).

Note that there is a dependency between the conditions and we don't even
want to look at lower levels if upper levels are not true.

Here it is translated into COBOL:

IF c1
IF c2
IF c3
action 1
ELSE
action 2
END-IF
ELSE
action 3
END-IF
END-IF

Note there is no other code embedded in the IF branches... like this:

IF c1
PERFORM...
COMPUTE...
IF c2
READ... etc.

Although the above is perfectly legal and COBOL supports it well, it isn't
very long before the code becomes cluttered and error-prone. Experienced
COBOL programmers can manage it but beginners will find it bewildering and
(especially if scope delimiters haven't been used) they will make logic
errors.

I can't prove it, but I suspect that anything nested in this way could be
broken into simpler IF or EVALUATE statements and so nothing is really
gained by doing it. Perhaps the same is true for my decision tree.

Finally, an example from back in the day, before we had EVALUATE. I have a
variable (call it "ReEntryIndicator") which can have the values 1 thru 3.

This was sometimes used for switching serial reuse on re-entry. Obviously, I
used GO TO...DEPENDING, but some sites came to frown on this, so the nested
IF was one possible alternative.

(I want my decision tree to only be nested in the TRUE branches so I negate
the conditions... like this:)

IF ReEntryIndicator NOT = '1'
IF ReEntryIndicator NOT = '2'
IF ReEntryIndicator NOT = '3
' PERFORM BadReEntryIndicator
ELSE
GO TO Entry3
END-IF
ELSE
GO TO Entry2
END-IF
ELSE
GO TO Entry1
END-IF

Looking with today's eyes, this is not something you would want or need to
do, but it serves to demonstrate what I'm saying about nested IFs.

Hope this helps somebody...

Pete.
--
"I used to write COBOL...now I can do anything."

[Tony Ennis]

Thank you too sir. I had same issue, looking around for hours how to sort it out!

[Kerry Liles]

Funny that this post showed up today... just last night I was thinking
that COBOL should have an option to DISallow the use of periods thus
making sure there is no chance of misinterpretation...

This of course would mean getting rid of the diagnostic/error that
occurs if there is no period on the statement BEFORE a paragraph start.

THAT error always annoyed the hello out of me - if there is a NEW
paragraph name why is there an error? The previous paragraph obviously
has therefore ended. Same argument can be applied to having the useless
period immediately AFTER the paragraph name!

[Robert Jones]

How would you expect a compiler to distinguish a paragraph name from an misspelt operand, e.g.
DISPLAY data-name
paragraph-name ADD something
?
What I have started doing is putting the full stop before and after the paragraph name as follows
DISPLAY data-name
. paragraph-name. ADD something

[Kerry Liles]

ah, good point. I was thinking (only) about the sort of COBOL I have
used the most over the last 50+ years - where Paragraph names have to
start in the A margin (column 8). I often forget about the "looser"
COBOL variants like those available on PCs etc.