Evaluate statement using ALSO

[jbeale]

I read about the EVALUATE statement in the COBOL/370 Language Reference Guide and am having a difficult time understanding some of the ways to use ALSO.
For example, the following is straight forward:
EVALUATE ISS-STATE
WHEN '22'
PERFORM 22-PROCESSING
WHEN '32'
PERFORM 32-PROCESSING
WHEN OTHER
PERFORM OTHER-PROCESSING
END-EVALUATE.
My question is that when ISS-STATE = '32' and certain plans, I want to PERFORM 32-PROCESSING, but when ISS-STATE = '32' and plans other than the certain plans, I want to PERFORM OTHER-PROCESSING. I currently have the following:
EVALUATE ISS-STATE
WHEN '22'
PERFORM 22-PROCESSING
WHEN '32'
IF ISS-PLAN = 'ABC' OR 'DEF'
PERFORM 32-PROCESSING
ELSE
PERFORM OTHER-PROCESSING
END-IF
WHEN OTHER
PERFORM OTHER-PROCESSING
END-EVALUATE.
Is there a way to use WHEN...ALSO... or am I better off sticking with the way I have it coded now?
Thank you in advance for your help.
Jody

 

[k5tm]

Jody,

Here is one possibility:

EVALUATE ISS-STATE ALSO ISS-PLAN
  WHEN '22' ALSO ANY
     PERFORM 22-PROCESSING
  WHEN '32' ALSO 'ABC'
  WHEN '32' ALSO 'DEF'
     PERFORM 32-PROCESSING
  WHEN OTHER
     PERFORM OTHER-PROCESSING
END-EVALUATE.

Tom Morrison

 

[Lunker]

I like the method you used. I've never cared much for the ALSO option. If you use ALSO on the EVALUATE you have to use it on every WHEN. That means when you have state 22 you have to use ALSO ANY. I think it just adds confusion.

You could use AND and OR in the WHEN phrase or use the imbedded IF like you did.

 

[3gm]

I think Tom's approach is perfect for the example given.

However, if the number of WHENs is large and most of them are ALSO ANY (i.e. the second variable is not really central to the logic flow), I tend to go with embedding an IF in the body of the EVALUATE.

I also prefer not to EVALUATE TRUE unless I really have to as I feel it allows one to drift too far from the traditional CASE logic that EVALUATE should implement.

Glenn

 

[jbeale]

Tom, Lunker, Glenn:
Thank you all for your helpful advise. Based on your answers, I now understand the use of EVALUATE using ALSO. With this in mind, I will use what I have already coded, and will keep your responses in my TEK-TIPS folder.

Jody

 

[k5tm]

Glenn wrote:
I also prefer not to EVALUATE TRUE unless I really have to as I feel it allows one to drift too far from the traditional CASE logic that EVALUATE should implement.

I agree with this, but have an important exception.

I tend to use condition-names (88 levels) a lot to improve readability of my code. This leads to situations where you can get some highly readable WHEN ... ALSOs, eg:

EVALUATE TRUE ALSO TRUE
WHEN  IS-CURRENT-MONTH  ALSO  IS-NORMAL-PAYDAY
   imperative-statement-1
WHEN  IS-CURRENT-MONTH  ALSO  IS-SPECIAL-PAYDAY
   imperative-statement-2
END-EVALUATE

I do not encourage using this except where it presents itself rather naturally.

A Final Note​

Never, never, never allow EVALUATE FALSE, which will render a program almost totally unreadable. Tom Morrison

 

[Lunker]

Tom:
I agree with your use of EVALUATE TRUE. We don't code literals in our Procedure Divisions. We advocate condition names (88) as you said for readability. In most cases we use EVALUATE TRUE and all of the WHEN phrases have 88 levels defined under the same field.

I would prefer to use AND instead of ALSO and write your statement as this:

EVALUATE TRUE
WHEN IS-CURRENT-MONTH AND IS-NORMAL-PAYDAY
imperative-statement-1
WHEN IS-CURRENT-MONTH AND IS-SPECIAL-PAYDAY
imperative-statement-2
END-EVALUATE