# Did COBOL have an English-like "or" operator?

Did COBOL also handle that other newbie mistake, allowing one to write

if a == 'orange' or 'apple' or 'banana'

if a == 'orange' or a == 'apple' or a == 'banana'

(or using some set membership operator if your favourite language has one)?

• Possibly something new with the IS. I can't recall ever having used an IS in a condition. Possibly a is equal to 'orange' or equal to 'apple' or equal to 'banana' . I'll have to install a cobol compiler and find out.
– cup
Jun 24, 2021 at 10:57
• What is the mistake? Both of those are equivalent in COBOL. Jun 24, 2021 at 10:58
• i meant those code snippets to be interpreted as if they were written in some language popular today, like Python or Java, where they are definitely not equivalent, but often trip people up, as witnessed by the number of dupes of this question. Jun 24, 2021 at 11:01
• That is, both are equivalent, except COBOL uses = (or EQUALS) for equality, not ==. Jun 24, 2021 at 11:02
• Why the past tense? COBOL is, even though it is an ancient language, still very much in active use today. There are a fair number of retired COBOL programmers that earn a nice supplement to their pension doing consultancy, because their expertise is still in very high demand and there are very very few youngsters that have that expertise or are willing to learn. Jun 24, 2021 at 21:54

The language defined in the original COBOL report from 1960 did indeed (see section 3.2.2). A normal “compound condition” consisted of a series of “simple conditions” (relations) separated by AND and OR; however, there were two abbreviated forms:

1. An expression like X = Y AND X = Z could be abbreviated to X = Y AND Z. The report gives the tricky example A = B OR C AND D, which turns out to be equivalent to A = B OR (A = C AND A = D).
2. When one logical operator is used throughout, you can replace all but the last with commas. Thus A = B, C OR D is the same as A = B OR A = C OR A = D.
• No Oxford comma? Jun 24, 2021 at 18:31
• @dan04 Not in the report I linked, but perhaps some dialect allowed it. Jun 24, 2021 at 18:52
• @dan04 Oxford, Kansas (population approx. 1,000) don't need no stinkin' commas :) Jun 24, 2021 at 22:10
• I don't think we're in Kansas anymore
– ysth
Jun 25, 2021 at 5:14

COBOL also has Level 88 conditions. Not quite what you are asking, but related.

For example:

01 WS-FRUIT      PIC X(20).
88 APPLE      VALUE "Apple".
88 BANANA     VALUE "Banana".
88 ORANGE     VALUE "Orange".

Now I can use:

IF APPLE OR BANANA OR ORANGE

The variable name is not even necessary because it knows which variable those level 88 conditions are associated with.

I can also do this:

01 WS-FOOD      PIC X(20).
88 FRUIT      VALUE "Apple" "Banana" "Orange.
88 VEGGIE     VALUE "Corn" "Bean" "Potato".
88 SNACK      VALUE "Pretzels" "Chips".

Then I can do this:

MOVE "Bean" TO WS-FOOD.
..
..
IF VEGGIE
DISPLAY "It's a vegetable"
ELSE
DISPLAY "Not a vegetable".
• 88 Level conditionals were amazingly useful at simplifying huge, broken IF clauses. COBOL was an amazingly effective language if you were taught by experts, and didn't blanch at using GOTO. Jun 25, 2021 at 3:49
• @RonJohn well, whoever thought a 30-line if statement could possibly be a good idea in the first place was either incompetent (in which case it's not too surprising that it can be refactored to a fraction of the size), or was forced to that desparate move by the limitations of a language that is more concerned with having the code read “like English” than implementing actually efficient, consistent semantics. Anyway, how you find these 88-thingies read “like a sentence” eludes me... the example here certainly isn't readable, despite being easily expressable as very English-like e.g. Python. Jun 25, 2021 at 10:07
• @l "whoever thought a 30-line if statement could possibly be a good idea in the first place" was writing corporate income tax software. I don't know about your country's tax laws, but they're damned complicated in the US. Jun 25, 2021 at 10:11
• Now, indeed I never had to read COBOL, so I could be wrong, but the fact that it has a built-in construct for this particular situation seems a red flag indicating that they needed to improvise to avoid such if statements, which are really just a very specific instance of the refactorability problem. Apparently 88 gets the job done, but it wouldn't work in many other situations, and it looks like it doesn't come with any of the other advantages of OO or functional programming – like making it easy to write unit tests. Jun 25, 2021 at 11:05
• @RonJohn these kids today... In my day we had to code uphill barefoot in the snow... Jun 25, 2021 at 15:18

You can do

if a = 'orange' or 'apple' or 'banana'

in COBOL, it translates as

if a = 'orange' or a = 'apple' or a ='banana'

You need to be careful when doing this as it does not always work the way you expect when you mix in And or not clauses. I would suggest using brackets and keeping it simple i.e.

if (a == 'orange' or 'apple' or 'banana')
and fruit-age < 12

This question https://stackoverflow.com/questions/4342218/issues-with-ands-and-ors-cobol/4342263 shows an example of the problems.

Taken from the above

IF DL-CLASS-STANDING = 'First Yr' OR 'Second Yr' AND
GRAD-STAT-IN = ' ' OR 'X'

From memory means

IF DL-CLASS-STANDING = 'First Yr'
OR (DL-CLASS-STANDING = 'Second Yr' AND  GRAD-STAT-IN = ' ')