IBM Mainframe Forum

Hello,

This is one 'doofus' of a question but had me stumped for a moment, because it'd never really occurred to me before; not in this manner to say the least!

A friend asked me today:
a. What is the maximum number of ELSE that an IF/THEN/ELSE construct have in COBOL?
b. How many WHEN selection objects can be coded in a COBOL EVALUATE/WHEN construct? <50 for sure was my reply but honestly, I do not know the exact number >

Did I just miss something in the Language Reference manual there!?!?

Thanks.

Yes, you did. You should look at the Appendix with Compiler Limits. Always the place of "how many" and "how big" questions. Whilst there, familiarise youself with the Appendix names, so you'll know the sort of stuff to find collected together.

Visit to my optometrist was due for sometime; and Billy, you just bolstered my appointment with him
I've been to the Appendix for I don't know how many times and God - did I overlook the info

Having said that, found the EVALUATE/WHEN details; though couldn't get the info on IF/THEN/ELSE; can you show the light, please.

Damn, and after all the years of application programming, it still feels like the learning phase; maybe I should switch to sysprog and learn the stuff.

Thanks.

I do not speak cobolese
but from a compiler point of view
as far as the un-nested IF/THEN/ELSE no limit
( apart the program size )

there could be one for nested ones
but in general there could be limits for every nested-nesteable construct

under <mvs> usually all depends on the region parameters
for some constructs You might find out the hard way by unsuccessful compilations
( the same is true for almost any high level language )

Thanks Enricho.

Cheers.

<Missed adding earlier>
It was the nested IF loop I was referring to; my bad I missed being specific there; and yup, there has to be an upper cap for that one.

Having said that, it would be real bad a design if we have 100s of nested IF/THEN/ELSE; the program would resolve each condition for every record even if it is not required; and for a very large input - that's a disaster.

Thanks.

if we have 100s of nested IF/THEN/ELSE; the program would resolve each condition for every record

the program behavior will depend on the data being processed
in the worst case it will go to the deepest nesting level

but also the performance will depend on the smartness of the coding
if You know that some patterns are more likely than the other ones
You should take that it into account when coding the if sequence
so to resolve the IF with minimum depth traveling

slightly off topic ...
for example the C compiler supports the builtin function __builtin_expect(...)
so that the compiler can optimize the instructions for the TRUE/FALSE test

enrico-sorichetti wrote:in the worst case it will go to the deepest nesting level

but also the performance will depend on the smartness of the coding
if You know that some patterns are more likely than the other ones
You should take that it into account when coding the if sequence
so to resolve the IF with minimum depth traveling

Completely agree on that point; one will also have to write the constructs in such a way, that a programmer sitting to debug the nested conditions - can make sense of it in the first look, else they'll get lost and after sometime, maybe even reach a point where they are unsure which IF condition this END-IF referred to

Cheers.

With the latest release of COBOL you can now have comments on the same line as code so you can at least document your END-IFs better

I don't think there will be a limit for nesting of statements (including IF) because the compiler will just generate code with branches, I don't think it has to take the nesting into account. I may be wrong for why, or phrasing it poorly, but I don't think there is a limit.

The EVALUATE is different, because the compiler has to generate code for the entire self-contained construct, so there has to be a limit. A Nested IF, or nested anything, is an "artificial" construct, not a compiler construct. The compiler construct is the simple IF (or whatever), it is the programmer who "nests", just combining the simple elements. There will be nothing (except final limits on program sizes) to restrict the number of nested EVALUATEs, for instance, even though there are limits within the EVALUATE. It is interesting that unlike EVALUATE, SEARCH ... WHEN... has no limits. No time to think about that now...

I have seen a 256-WHEN EVALUATE. Someone decided to decode the bits in a byte that way. I didn't realise it was exactly on the limit, as well as being very stupid.

Yes, there is nothing in the language which restricts idiocy. At exceptional times this may be useful. Never nice. These types of things should be covered by site-standards