Re: Regarding EVALUATE TRUE

Original code as >> ;
Mr. Dashwood's comments as >
EVALUATE TRUE
WHEN CASE-IN-COMPLETE
SET IN-COMPLETE-CASE TO TRUE
PERFORM 1000-SET-CASE-TYPE-MSG
WHEN NO-CASE-EXISTS
SET NON-EXISTING-CASE TO TRUE
PERFORM 1000-SET-CASE-TYPE-MSG
WHEN CASE-EXISTS-BUT-NOT-EXACT
SET NON-MATCHING-CASE TO TRUE
PERFORM C110-SET-CASE-TYPE-MSG
WHEN CASE-EXISTS-EXACTLY
* *** NOW PROCESS VERY GOOD CASE ACCORDING TO ITS STATUS...
PERFORM 2000-PROCESS-EXACT-CASE
WHEN OTHER
DISPLAY "BAD INTERNAL ERROR IN " WS-CURRENT-PARAGRAPH
PERFORM 999-ABEND-EXIT
END-EVALUATE

The first thing that struck me is that it tests a condition and then sets
another condition...

WHEN CASE-IN-COMPLETE
SET IN-COMPLETE-CASE TO TRUE

... and it does this on several occasions.

I suppose if you have a vested interest in hastening the heat death of the
Universe, this might be acceptable, but to me it is just nonsense. > It does make the following assumptions:
< ... some stuff deleted ... >
1. There's no way I will code the setting of a flag based on a flag, so you
must consider the following to be logically equivalent:

CASE-IN-COMPLETE = IN-COMPLETE-CASE

NO-CASE-EXISTS = NON-EXISTING-CASE

CASE-EXISTS-BUT-NOT-EXACT = NON-MATCHING-CASE


Hmmmm.... thank you for taking time out of your busy day, Mr.
Dashwood, because your observation above has been helpful. It piqued
my curiosity to ask, now just _why_ did the original developer use the
value of a flag just to set another flag? Ahhhh, this is why:
10 MSG-ENTRY-012.
15 FILLER PIC X(05) VALUE

'CASE'. 15 MSG-12-
ACCOUNT-ID
PIC X(10).
15 FILLER PIC X(10) VALUE
', W/OWNER'.
15 MSG-12-OWNER-ID PIC X(05).
15 FILLER PIC X(18).
88 CASE-CREATED-MSG VALUE
', IS NOW CREATED'.
88 IN-COMPLETE-CASE VALUE
', NOT COMPLETE'.
88 NON-MATCHING-CASE VALUE
', NON-MATCHING ID'.
88 NON-EXISTING-CASE VALUE
', IS NOT ON FILE'.
88 IN-VALID-TYPE-CASE VALUE
', NOT VALID TYPE'.

Oooooooohhhhh - look at this, IN-COMPLETE-CASE is not really an
"indicator flag" - it is a text portion of a journal message!
Setting the 88 has the effect of setting the 15-level FILLER to that
value. Now using an 88-level to set a value for FILLER is not an idea
that has ever come to me - so one learns something new every day!

On the other hand, I think what I learned is yet another way that a
programmer "can be too clever for his own good", or more accurately, a
programmer "can be too clever for the good of the maintainers that
follow...".

Perhaps I could be more accepting of the trickery above if all of
these 88-levels had been named something like the first one, namely
CASE-CREATED-MSG had been followed in spirit by IN-COMPLETE-CASE-MSG,
NON-MATCHING-CASE-MSG, and the like. This would provided a clue that
what was being set was a message portion, and not a flag.

However, such tentative acceptance of this trickery might be more
charitable on my part toward the original developer than he really
deserves. A quick browse of the code shows that the fragment above is
the ONLY place where those error message fragments are set - only one
occurrence per 88-level.

Rather than using FILLER, the intent of the code would be so much more
clear by using a more traditional naming like MSG-12-INFO-TEXT,
leaving out the message 88's altogether, and changing the SET
statements above to the more forthright MOVE ", NOT COMPLETE" TO
MSG-12-INFO-TEXT. The result would be less lines of code (in keeping
with your preference for parsimony, Mr. Dashwood), and a more direct
approach (in keeping with my preference for understandability over
cleverness.)

Thanks,
Ken

.