Re: Para1 THRU Para2 (was: Infinite Loops and Explicit Exits

On 16 Nov 2004 13:51:50 -0800, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <spamblocker-robert@wagner.net> wrote
> 
>
>Which is _only_ relevant to users of MicroFocus and those that do not
>care that it locks them in to that compiler.   One of the advantages of
>Cobol is that the code should be portable between implementations.
>This is why it was developed originally, this is why the first word of
>its name is _Common_.

EXIT PARAGRAPH is in the current ISO Cobol standard .. where Common
features are defined.
 
>
>Then cease from criticising programmers who have to care about IBM
>mainframes for not using it.

I criticize them for ancient style, not for avoiding syntax that won't
compile.
 
>
>It would be _extremely_ bad programming to not do this consistently.
>While I dislike THRU and find no need for it, a consistent style of
>using THRU ~exit on _every_ PERFORM is far better than mixing THRU and
>not THRU.

If they most have consistancy, don't use THRU. It's never necessary.

>With a consistent style an exception to the rule can be found more
>easily, a PERFORM without the THRU will be noticable.  OTOH if the
>styles are mixed a PERFORM without its required THRU would be
>unremarkable, it may even mostly work, as long as the GO TO is not
>done from that particular PERFORM.

It's impossible for a program to go into free-fall when there is no GO
TO nor THRU, and the main paragraph exits.

>will work perfectly well until an empty file happens because of some
>transfer error or somesuch.
>
>Detecting this error only possible by following every reference.

The error can be detected by searching for 'GO or THRU'.

>You need to move beyond the '70s. A little bit of 'bloat', a small
>amount of 'inefficiency' in compiled code is trivial compared to the
>huge cost of programmers dealing with inconsistencies.

You said programmer time was expensive, rapid development the goal.
Those wasting time typing THRU -EXIT are stuck in the '70s, not me.

>Personally, I prefer my consistency to be 'no THRU', 'no SECTION', and
>also no 'EXIT PARAGRAPH' because that is currently non-portable.

Personally, I prefer CALL for big chunks and in-line for small. All
compilers have EXIT PROGRAM.
 
>
>Given that most Cobol programs in a mainframe environment will be
>limited by their I/O requirements, I seriously doubt your assertions
>about 'speed increase'.

I measured it. My rewrites did more than restructure programs, they
restructured job streams as well. For example, three batch programs
that copy a file and compute something might be changed into one main
program that copies the file and three callable programs that do
computations. Three reads and three writes were replaced by one read
and one write.

>It may well be that different styles of coding may show some
>differences when compared in small benchmark programs.  It is even
>possible that changes in style may allow the optimiser to work, but I
>have doubts about these, _in_themselves_ making, say, a live batch job
>run in 66% of the time.

I didn't measure one batch job nor a small benchmark program; I
measured all the batch jobs in a shop, running production data.