EVALUATE/WHEN in COBOL



EVALUATE/WHEN in COBOL

Postby Aki88 » Wed May 07, 2014 12:08 pm

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 :mrgreen: but honestly, I do not know the exact number :shock: >

Did I just miss something in the Language Reference manual there!?!? :oops: :o :cry:

Thanks.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

Re: EVALUATE/WHEN in COBOL

Postby BillyBoyo » Wed May 07, 2014 12:17 pm

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.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Re: EVALUATE/WHEN in COBOL

Postby Aki88 » Wed May 07, 2014 1:13 pm

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

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. :geek:

Thanks.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

Re: EVALUATE/WHEN in COBOL

Postby enrico-sorichetti » Wed May 07, 2014 1:29 pm

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 )
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
enrico-sorichetti
Global moderator
 
Posts: 2994
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 164 times

Re: EVALUATE/WHEN in COBOL

Postby Aki88 » Wed May 07, 2014 1:36 pm

Thanks Enricho.

Cheers.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

Re: EVALUATE/WHEN in COBOL

Postby Aki88 » Wed May 07, 2014 1:55 pm

<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.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

Re: EVALUATE/WHEN in COBOL

Postby enrico-sorichetti » Wed May 07, 2014 2:05 pm

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
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
enrico-sorichetti
Global moderator
 
Posts: 2994
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 164 times

Re: EVALUATE/WHEN in COBOL

Postby Aki88 » Wed May 07, 2014 2:17 pm

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 :lol:

Cheers.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

Re: EVALUATE/WHEN in COBOL

Postby NicC » Wed May 07, 2014 2:34 pm

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
   END-IF     *> comment
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic

These users thanked the author NicC for the post:
Aki88 (Wed May 07, 2014 2:37 pm)
NicC
Global moderator
 
Posts: 3025
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisies (almost)
Has thanked: 4 times
Been thanked: 136 times

Re: EVALUATE/WHEN in COBOL

Postby BillyBoyo » Wed May 07, 2014 3:06 pm

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 :-)

These users thanked the author BillyBoyo for the post:
Aki88 (Wed May 07, 2014 3:46 pm)
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Next

Return to Stupid Questions

 


  • Related topics
    Replies
    Views
    Last post