IBM Mainframe Forum

I don't think there will be a limit for nesting of statements (including IF) because the compiler will just generate code with branches,

the problem will not be the CODE GENERATION but the SHIFT/REDUCE parsing logic
very rough approach ... but enough to clarify


if one of the inside processes contains an IF construct
the outer IF cannot be reduced until the inner IF is

and keep nesting... keep nesting
and the compiler will accumulate things to be reduces until the deepest IF can be reduced

as I said ... VERY ROUGH explanation

Well, I've never seen a recorded limit for nesting with an IBM COBOL.

I may have a play later. I'll generate:



Compile it with NOOPTiMIZE. See what happens

my comment about parsing was pretty general

MIGHT not even apply to the specific paring logic used by IBM

the IF part never gave me problems
it was the ELSE part that fouled things up
( using Yacc and bison )

Ditto Enricho; I have seen the ELSE giving trouble, rarely an IF.
And Billy, nested IF/THEN/ELSE, ohh I've seen those, a guy had coded this huge construct, went some 20+ layers down, and to complicate things, there were couple of sub-layers which again had few IF/THEN/ELSE. He had actually coded a copybook for this whole construct.
Never seen that big an EVALUATE though; can expriment just to see what the compiler throws up

Thanks.

OK, I'll stick an ELSE in and cut the number of IF statements in half. I don't think it'll be a problem - we'll see

Well, not as clear-cut as I thought.

First problem is on the listing. The nesting indicator is only two digits, so greater than 99 levels of nesting and it prints as "**".

However, more than 99 levels of nesting work.

However, nowhere near as many as I thought.

It seems like 16380 is either the number of levels of nesting you can have, or 32760 is the maximum number of statements you can include in the nest. I'm not going to look further to find out which Beyond that point the compiler goes to pot, with a number of weird errors.

So, yes, there is an undocumented limit to the number of levels of nesting, at least for an IF and presumably for anything else that can be nested.

However, except for a small possibility for generated code, the limit is so far from approachable as to not matter. Even the 99 levels of nesting would be enormously difficult to code, understand or change.

At 16380 levels the program does still work At 16381, it just doesn't compile, with multiple messages entirely undrelated to the nested code.

Out of interest, here's how I generated the program, using DFSORT.



I then concatenated the three output datasets (OUT1, SORTOUT, OUT2) as input to the COBOL compiler.

On executing the program, the value "B" is displayed, which is the expected result. I turned the OPTimizer off, of course. Mmmm.... perhaps I should try with it on as well, to see what happens...

These users thanked the author BillyBoyo for the post:

Aki88 (Thu May 08, 2014 12:26 pm)

The OPTimizer does not attempt to optimise my 16000+ levels of nesting.

Just one word for that wow, and I mean 'W O W'; drat, I was using a nested PERFORM to generate my statements, lest the remaining stuff, I am keeping that SORT card in my tool library right away

This is good info; thanks Billy, this will come really handy. We have an

Cheers.

Well, it was some fun. Learned some stuff myself.

Be aware that normally I only need one OUTFIL for a generated program. However, the HEADER1 and TRAILER1 are reporting functions, and REPEAT cannot be used with reporting functions on the same OUTFIL.

Of course, it doesn't hurt to have them as three datasets and concatenate.

These users thanked the author BillyBoyo for the post:

Aki88 (Thu May 08, 2014 2:30 pm)