Re: IF statement, I don't understand this

In article <492nekFmm166U1@xxxxxxxxxxxxxx>,
"Frank Swarbrick" <Frank.Swarbrick@xxxxxxxxxxxxxx> wrote:

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

I like your solution. The abv. rel. cond.s tend to cause cnfsn.

However, you will always find some twit that will do something like:

Move 55 to ACCOUNT-TYPE

I would suggest that this would prevent such behavior:

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

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

Not quite so necessary when it is a stand alone 01-level. But such
flags tend not to be freestanding things -- it is more likely to be part
of some group of data items retrieved from a database or file.
.