Re: Regarding EVALUATE TRUE

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

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

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?

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

Ken

.