Re: Regarding EVALUATE TRUE

On 8/15/2007 at 4:58 PM, in message
<1187218735.434830.115180@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
klshafer@xxxxxxx<klshafer@xxxxxxx> wrote:
On Aug 15, 5:31 pm, "Frank Swarbrick"

My comments after Frank's quotations...

<Frank.Swarbr...@xxxxxxxxxxxxxx> wrote:
I am curious on your opinion about the following:

EVALUATE TRUE
WHEN ICMMSTR-ACC-OWIRE-LIM NUMERIC
MOVE ICMMSTR-ACC-OWIRE-LIM TO WIRE-OUT-LIMIT
WHEN ICMMSTR-CMP-OWIRE-LIM NUMERIC
MOVE ICMMSTR-CMP-OWIRE-LIM TO WIRE-OUT-LIMIT
WHEN ICMMSTR-HDR-OWIRE-LIM NUMERIC
MOVE ICMMSTR-HDR-OWIRE-LIM TO WIRE-OUT-LIMIT
END-EVALUATE

The logic is to set WIRE-OUT-LIMIT to the value of the first of three
possible fields that has a valid numeric value. In other words, even if

all
three ICMMSTR fields are numeric, WIRE-OUT-LIMIT should be set to the
value
ICMMSTR-ACC-OWIRE-LIM. In other words, it is *dependant* on the
'short-circuit' logic of EVALUATE. I see nothing wrong with that.

I'm pretty much OK with it. Certainly the fact that each of the
imperatives has a common destination field makes the intent of the
programmer easier to ascertain. I could certainly describe what it
does simply as "assigns wire-out limit according to a hierarchy of
ACC, CMP, and HDR limits." It shows good functional cohesion.

Using IF END-IF IF END-IF IF END-IF would not accomplish what I want.
On
the other had, IF ELSE IF ELSE IF would, but I much prefer the evaluate.

About an hour ago, yes, it occurred to me that the above particular
representation of EVALUATE TRUE is indeed *exactly* like our old
friend IF...ELSE IF..ELSE IF. Ever the traditionalist, I might still
prefer that to the EVALUATE TRUE representation above.

On the other hand, if I had to code it with EVALUATE, probably I would
go for something in the "middle", kinda like this...

EVALUATE TRUE
WHEN ICMMSTR-ACC-OWIRE-LIM NUMERIC
MOVE ICMMSTR-ACC-OWIRE-LIM TO WIRE-OUT-LIMIT
WHEN OTHER
EVALUATE TRUE
WHEN ICMMSTR-CMP-OWIRE-LIM NUMERIC
MOVE ICMMSTR-CMP-OWIRE-LIM TO WIRE-OUT-LIMIT
WHEN OTHER
* *** ICMMSTG-HDR-OWIRE-LIM IS ALWAYS NUMERIC
MOVE ICMMSTR-HDR-OWIRE-LIM TO WIRE-OUT-LIMIT
END-EVALUATE
END-EVALUATE

no! No! NO!!

This is exactly why I prefer (a normal) EVALUATE to the IF ELSE IF ELSE step
ladder. With a normal evaluate each of the possible branches is at the same
'level'. With IF ELSE stepping and your corruption (sorry) of EVALUATE
you're constantly increasing the level. That's just, umm, yucky. :-)

Yeah, its kinda wordy, 11 lines (not including comment) vs. your 8,
but the structure makes it more clear to me what trumps what.


However, let me get to what is _really_ bothering me. See, I'm not
working with Frank Swarbrick's code :-), which I can read and
understand, I'm working with the following code, from a Real Life Case
Management System, where there is no specification and the original
programmers have left long, long ago... -

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 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
END-EVALUATE

It is left as an exercise for all the Students reading this forum to
determine the conditions under which the WHEN OTHER is executed :-).

Hmm, that looks fairly readable to me. I certainly don't think that
changing it to an IF/ELSE step ladder would make it any better. To me it
would make it a lot worse.

Keeping with good _Structured Design_ principles of high functional
cohesion, can somebody summarize in a sentence or two what single
function the above EVALUATE performs?

No, but I doubt you could do that in any case. It's simply complex business
logic. Complex business logic requires at least somewhat complex
programming logic. Not sure how you can get around that!

There are many more examples where that one comes from :-)...

So, Mr. Swarbrick, please allow me to qualify a bit more my guideline
-

"All in all, I think that it is a very bad idea to use EVALUATE TRUE
with WHEN condition-1 and WHEN condition-2 and WHEN condition-3 where
condition-1, condition-2, and condition-3 refer to separate data-
elements and there is an absence of a natural and clear ordering of
those conditions."

Sorry, I still don't agree. I actually find your example to be quite
elegant! Sorry. :-)

(Oh, except the IF in the final case is indented incorrectly by one
additional space.)

The only more readable thing I could think might be this:

IF CASE-IN-COMPLETE
SET IN-COMPLETE-CASE TO TRUE
PERFORM 1000-SET-CASE-TYPE-MSG
EXIT PARAGRAPH.

IF NO-CASE-EXISTS
SET NON-EXISTING-CASE TO TRUE
PERFORM 1000-SET-CASE-TYPE-MSG
EXIT PARAGRAPH.

IF WEA1CAS-STATUS = IND-TYPE-OF-CASE
EXIT PARAGRAPH.

IF WEA1CAS-STATUS > SPACE
AND CASE-OPEN OF WEA1CAS-SACSTAT
PERFORM 2000-FINISH-CASE-EDIT-S
EXIT PARAGRAPH.

IF WEA1CAS-STATUS > SPACE
AND CASE-CLOSED OF WEA1CAS-CASE-STATUS
PERFORM 3000-FORMAT-WEA1CASA
PERFORM 4000-UPDATE-WEA1CASA-6CASH
EXIT PARAGRAPH.

IF 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
EXIT PARAGRAPH
END-IF
END-IF.

Actually, looking at that makes me realize that your final WHEN before the
WHEN OTHER could be simplified(?) to

WHEN 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

But perhaps the "ELSE CONTINUE" used to be "ELSE <statement>" in which case
it makes sense why it was done that way.

Anyway, I realize that the above could be done without the EXIT PARAGRAPH
statements, and rather with connecting ELSEs, but again, if I were do that
It'd end up with this:

IF CASE-IN-COMPLETE
SET IN-COMPLETE-CASE TO TRUE
PERFORM 1000-SET-CASE-TYPE-MSG
ELSE
IF NO-CASE-EXISTS
SET NON-EXISTING-CASE TO TRUE
PERFORM 1000-SET-CASE-TYPE-MSG
ELSE
IF WEA1CAS-STATUS = IND-TYPE-OF-CASE
CONTINUE
ELSE
IF WEA1CAS-STATUS > SPACE
AND CASE-OPEN OF WEA1CAS-SACSTAT
PERFORM 2000-FINISH-CASE-EDIT-S
ELSE
IF WEA1CAS-STATUS > SPACE
AND CASE-CLOSED OF WEA1CAS-CASE-STATUS
PERFORM 3000-FORMAT-WEA1CASA
PERFORM 4000-UPDATE-WEA1CASA-6CASH
ELSE
IF 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
END-IF
END-IF
END-IF
END-IF
END-IF
END-IF
END-IF.

This, in my opinion, is atrocious! Readable, yes. But hard to extend
because you end up running out of room on the right!

Anyway, I'll stick with EVALUATE.

Frank

.