EVALUATE AND instead of ALSO why does it work

[Erich Mueller]

EVALUATE TRUE
WHEN statuscrt = 1020 AND CSRLL > 10 AND PTEX13 = SPACES

I used that and later I read in the manual that ALSO is the name of the game and not AND
surprise 1 the compiler does not complain
surprise 2 it works

question should I better go to ALSO
Erich

[Mickey White]

Me thinks it is....
evaluate true also true
when this also that
when any also that
when any also any
...
The also allows more that one true statement

[Brian Tiffin]

ALSO allows for more than one testable condition that matches 1 to 1 to the number of conditions given in an EVALUATE.

AND reduces two boolean expressions to a single.

EVALUATE cond-a ALSO cond-b expects a WHEN clause with two separate booleans.

The boolean for cond-a may be the results of a complex boolean expression inside a WHEN clause, reduced to a single expression via AND, OR, NOT. Same for cond-b, it may be a bunch of expressions with AND OR, separated by ALSO.

The EVALUATE ALSO count of conditionals needs to match all the WHEN ALSO counts.

The ALSO conditionals can be completely unrelated, AND will always reduce two expressions to a single boolean.

ALSO is like having nested IF, versus a single IF with multiple and/or/not expressions reduced to a single boolean result.

The answer to the title question is that AND reduces to the single TRUE given for the EVALUATE. ALSO would not work in the WHEN there, unless it matched with an ALSO in the EVALUATE.

The answer to the last question is a control flow issue. Would it be better as a nested IF or one IF with a bunch of tests and-ed, or-ed and not-ed together. With EVALUATE ALSO you can design entire multi-conditional decision tables into a single statement.

By and large, Erich, it's AND and OR for "normal" control flow programming. EVALUATE ALSO for condensed decision tables and managing multiple might-be-unrelated conditionals.

Cheers,
Blue

[Simon Sobisch]

Brian said nearly all. Two things to add:
if you have very different conditionals you'd normally stay with EVALUATE TRUE (or EVALUATE FALSE) and combined ones with and/or
if you have a common decision table that involves multiple variables: use ALSO, possibly with the object ANY in the places where a subject doesn't matter:

EVALUATE AGE ALSO GENDER
   WHEN 0 THRU 9 ASLO ANY
      DISPLAY "Children"
   WHEN 10 THRU 17 ALSO 'F'
   WHEN 12 THRU 19 ALSO 'M'
      DISPLAY "Special Adolescents"
   WHEN 10 THRU 19 ALSO ANY
      DISPLAY "Adolescents"
   WHEN 20 THRU 45 ALSO ANY
      DISPLAY "Adults"
   WHEN 46 THRU 60 ALSO ANY
      DISPLAY "Middle age"
   WHEN 60 THRU 100 ALSO ANY
      DISPLAY "Old"
   WHEN 1751 ALSO "M"
      DISPLAY "Santa Clause"
   WHEN OTHER
      DISPLAY "you are a miracle"
END-EVALUATE.

Don't we have good examples for this in the FAQ and/or PG?

[Erich Mueller]

Thank you Gentlemen for all the details
As I understand Brian AND/OR is possible .... fine and simple and nice.
And I see all the advantages of ALSO

But it is not documented (so far as I read )
So my concern is, if I use it more often will it still work in later releases.
I ran into it simply replacing a number of IFs by WHEN without checking the manual.
So it looks like one of those undocumented features which disappear some day
and you get surprised by an error recompiling older code.
So my clearer question: "Is WHEN AND .... OR ... a fully supported feature ?

Simon, there are indeed examples in FAQ 4.1.17 +21 f.i.(and in the net) but none with AND

I wish you all a warm summer close to good working and filled refrigerator Erich

[Simon Sobisch]

There are two boolean evaluate-subjects - EVALUATE TRUE and FALSE. As with any subject it takes an object of the same type - and everything with AND/OR that correctly evaluates to a boolean condition works there - this was true since the COBOL85 standard and won't change. Please check the programmer's guide, which is the COBOL Language documentation part for GnuCOBOL if there's something missing for you, if yes please create a bug report for that.

[Vincent (Bryan) Coen]

It is in the current Programming Guide.

What are you reading for information for GnuCobol ?

mod edit for some reply-to

[Brian Tiffin]

So my clearer question: "Is WHEN AND .... OR ... a fully supported feature ?

Absolutely. Passes tests, and NIST was not shy of stress testing the spec.

GnuCOBOL passes all tests thrown at it for the complex issue that is COBOL control flow and boolean expressions, or it gets fixed as soon as feasible after discovery. Improper control flow is a no-no, full stop.

These include all the shortcuts, last identifier and test mentioned carries over to the next fragment of the boolean expression. A AND B OR C OR D OR ... can get very hairy. GnuCOBOL will get it right, however hard to mentally unwind...

See https://gnucobol.sourceforge.io/faq/index.html#and for a sample of shortcut boolean expressions, Erich.

Group those in an as complex an EVALUATE ALSO... WHEN ALSO... statement block as you can handle, GnuCOBOL will match expectations from Standards, old through new.

Cheers,
Blue