Re: [Tiny-cobol-users] Re: a problem with EVALUATE

[Jim M. <ro...@vi...>]

John

I've got to disagree with you.

The EVALUATE TRUE allows a whole heap of spagetti-coded IF, THEN, ELSEs 
to be replaced by a nice easy-to-follow slab of structured code.  Just 
because Cobol 74 programmers never learnt new tricks doesn't doesn't 
mean they weren't worth learning. 

The EVALUATE TRUE improves program structure and anything that improves 
program structure needs to be supported.

Jim



John R. Culleton wrote:

>On Saturday 20 August 2005 06:44 am, Arnold Trembley wrote:
>  
>
>>Jim Morcombe's sample COBOL program is perfectly legal COBOL.  It
>>compiles cleanly under Realia COBOL, the ANSI-85 "educational" version
>>from about 1990.  Of course, it does nothing upon execution.
>>
>>If you use the EVALUATE TRUE option, you can put pretty much any
>>conditional statement you want in a WHEN clause.
>>
>>With kindest regards,
>>    
>>
>
>
>I have already been corrected on the matter of EVALUATE TRUE. It
>appears that the EVALUATE construct is a marvel of complexity,
>of which I have barely scratched the surface. But this very
>complexity and power raises two additional questions:
>
>1. Is it sound programming practice to utilize all the arcane
>variations of the EVALUATE verb? If I were bossing a programming
>shop today I would be cautious about allowing programmers to use
>every obscure variant of EVALUATE when there are other more
>familiar options that will handle the program logic equally well. 
>In other words in my view all these variations fall in the "nice
>to have" rather than the "got to have" category. The primary
>COBOL objective of writing useful and maintainable code might be
>compromised.
>
>2. More immediately, should we expect the maintainers of Tiny
>COBOL to implement each and every new variant? At what point
>does TC cease to be tiny? Remember that some standard texts on
>COBOL acknowledge EVALUATE TRUE in an appendix but do not attempt to 
>teach it in the main text. 
>
>It would be nice if the COBOL standard were broken down into
>required and optional features. Then COBOL shops could write to
>the standard subset and ensure both portablility across
>compilers and understandability by all programmers. Those who
>wanted to toy with every variant could find an appropriate
>compiler and play to their heart's content.
>
>Years ago I headed up a programming shop that was given control
>over the programmers in a newly acquired division in another
>state. They had with the help of IBM taught themselves and got
>working that monster PL/I. My internal standard already
>specified COBOL for business type tasks and FORTRAN for
>scientific/engineering work. I allowed them to continue with
>PL/I instead of rewriting everything in COBOL. But I would have
>been much happier if I had never been faced with the decision.
>Similarly we face the potential of the same sort of tower of
>babel in the COBOL community, IF THEN ELSE shops versus EVALUATE
>shops, structured programming shops a la Murach and Noll versus
>objective COBOl shops and so on.  
>
>But I digress...
>
>  
>