Re: Regarding EVALUATE TRUE





<klshafer@xxxxxxx> wrote in message
news:1187362496.040834.44620@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Original code as >> ;


I was a little disappointed that, in response to your request, and having
taken the (admittedly short, and for amusement only) time to apply Boolean
simplification to:

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...
EVALUATE TRUE
WHEN WEA1CAS-STATUS = IND-TYPE-OF-CASE
CONTINUE
WHEN WEA1CAS-STATUS > SPACE
AND CASE-OPEN OF WEA1CAS-SACSTAT
PERFORM 2000-FINISH-CASE-EDIT-S
WHEN WEA1CAS-STATUS > SPACE
AND CASE-CLOSED OF WEA1CAS-CASE-STATUS
PERFORM 3000-FORMAT-WEA1CASA
PERFORM 4000-UPDATE-WEA1CASA-6CASH
WHEN WEA1CAS-STATUS = SPACE
AND CASE-OPEN OF WEA1CAS-CASE-STATUS
IF CASE--OPEN OF CSN-CASE-STATUS
PERFORM 3000-FORMAT-WEA1CASA
PERFORM 4000-UPDATE-WEA1CASA-6CASH
ELSE
CONTINUE
END-IF
WHEN OTHER
CONTINUE
WHEN OTHER
DISPLAY "BAD INTERNAL ERROR - SHOULD NOT REACH HERE!"
PERFORM 999-ABEND-EXIT
END-EVALUATE

and obtained...

IF NOT CASE-EXISTS-EXACTLY
IF NOT CASE-EXISTS-BUT-NOT-EXACT
PERFORM 1000-SET-CASE-TYPE-MSG
ELSE
PERFORM C110-SET-CASE-TYPE-MSG
END-IF
ELSE
IF NOT WEA1CAS-STATUS = IND-TYPE-OF-CASE
EVALUATE TRUE
WHEN WEA1CAS-STATUS > SPACE AND
CASE-OPEN OF WEA1CAS-SACSTAT
PERFORM 2000-FINISH-CASE-EDIT-S
WHEN (WEA1CAS-STATUS > SPACE AND
CASE-CLOSED OF WEA1CAS-CASE-STATUS) OR
(WEA1CAS-STATUS = SPACE AND
CASE-OPEN OF WEA1CAS-CASE-STATUS AND
CASE--OPEN OF CSN-CASE-STATUS)
PERFORM 3000-FORMAT-WEA1CASA
PERFORM 4000-UPDATE-WEA1CASA-6CASH
END-EVALUATE
END-IF
END-IF

.... you then chose to ignore this result completely and snipped it from your
response.

I think this is pretty amazing. Especially when you think it was postulated
by two people who lived more than 100 years before the first electronic
computer was ever assembled. (there is apochryphal evidence that Augustus De
Morgan assisted Lady Lovelace to write the first "program" for Babbage's
ill-fated Analytical Engine, which might very well have been the first
computer program ever written.)

(Alistair might be interested to know that De Morgan lost the sight of his
right eye soon after birth and was teased at school about it.)

Given that you claimed in an earlier post to be "cleaning up" the mess, I
would have thought this would be of some relevance.

Instead, it seems you were distracted by the shiny bauble of a coding
technique you hadn't seen before :-)

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!


Perhaps optimization of convoluted code might be on the agenda some time in
the future?

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...".

So much for style.

Now, how about a programmer actually cleaning up bad code? Your thoughts on
a postage stamp, by return, please :-)

<snip>

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.)


I have found in my (admittedly still ongoing) experience that parsimony
often helps understandability.

I seem to recall something about brevity being the soul of wit... it is also
the soul of COBOL maintenance programming. The less there is, the more
quickly it can be assimilated.

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


.