Re: IF statement, I don't understand this

Chuck Stevens<charles.stevens@xxxxxxxxxx> 03/30/06 9:03 AM >>>
Another mistaken assumption is that abbreviated combined relation
conditions
somehow imply a different (and probably higher) precedence from that which

would occur in their fully-expanded counterparts -- that the fact that an
abbreviation occurs in 'ASM010-I-DIR = "L" OR "R" OR "S" ' somehow means
this gets evaluated as a unit (as it might in English). It doesn't. The

abbreviated conditions are treated as if they were expressed in their full

form, and the resulting full conditional expression is then evaluated.
Absent parentheses, it's AND before OR, and otherwise left to right.

Personally, I think abbreviated combined relation conditions are a delusion

and a snare, to be avoided in new code and eliminated from old whenever
they
are encountered. They represent a "cute" feature of early COBOL that has
*long* outlived its usefulness, and that (so far as I know) no other
language has seen fit to emulate.

And I also agree that for anything but the most trivial combined relation
conditions (abbreviated or not), the use of parentheses to make the
programmer's intent crystal clear is a really good idea.

I find them useful from a "less to type" standpoint, but the definitely can
be confusing. What's interesting is that if he had something like

01 SHH-SHIP-CODE PIC 9 VALUE 1.
88 SSH-SHIP-CODE-5 VALUE 5.
01 ASM010-I-DIR PIC X VALUE "R".
88 ASM010-I-DIR-LRS VALUES "L", "R", "S".
and
IF SHH-SHIP-CODE-5 AND ASM010-I-DIR-LRS
DISPLAY "TRUE"
ELSE
DISPLAY "FALSE".
END-IF.

Then he'd get the answers he is looking for, since the 88-level test is
evaluated for a single "truth condition", as it were, rather than as three
separate tests separated by or.
Or something like that...

I'm a fan of 88-levels for that reason alone, as well as the fact that they
can make code more readable. Who knows what codes "L', "R", and "S" mean in
this case. But with a sensibly named 88-level (which I don't have because I
don't know what "L", "R" and "S" mean!) it can be quite readible, from a
business logic standpoint. Of course there is the disadvantage that you may
"lose" the field name itself, but... It would perhaps be nice of 88-level
usage could be "tweaked" a bit so that we could have something like...

01 ACCOUNT-TYPE PIC 99.
88 INTEREST-BEARING VALUES 11, 21, 31, 41.
88 NON-INTEREST VALUES 10, 20, 30, 40.

IF ACCOUNT-TYPE IS INTEREST-BEARING
PERFORM CALCULATE-INTEREST
END-IF

A bit more verbose, which I'm generally not in favor of, but it seems to me
to have no other downsides.

Frank

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
.