Re: Difference bet. Primary and Full procedural file.

Mike,

>No I don't avoid it because of fear of the unknown, but because I can write
>the same code myself which will immediately be understandable to any other
>competent RPG programmer.

Any "competent RPG programmer" *will* immediately understand a cycle program, or
he/she is not "competent" IMHO.

Used correctly, the cycle is *very* easy to understand and maintain.  A program
using multiple level breaks should be *immediately* grasped by the maintenance
coder.   You can see at a literal glance exactly what is happening, and rest
assured it acts exactly as designed.

On the other hand, manually coded level breaks can *not* be verified with a
literal glance at the code.  It of course helps if there is a strict shop
standard and everybody codes it the same way.  But if you do that, what is wrong
with a shop standard which uses level breaks to accomplish the same thing?

Level breaks are *not* hard to understand -- or maintain.  They are *faster* to
code initially, *faster* to comprehend when perusing the code, *faster* to
modify when additional level breaks are needed, and have *faster* execution
performance.  What is wrong with that picture??

Manually coded level breaks -- particularly if not coded in a uniform shop
standard method -- must be examined to ensure that level breaks propagate to all
lower levels correctly.  And it also means your field contents have already been
destroyed by the next record so you can't use them for "total time" processing
unless you are performing an inner loop via READE (which only is possible in
some scenarios).

I have never understood the disdain some folks have for the cycle.  Sure there
is some ugly code where people did things they should not have, and tried to
make the cycle do things it shouldn't.  (When I started in RPG II, a program
*had* to have a primary file or it wouldn't compile!  It was *not* optional.)

But mis-guided, ugly cycle code is no reason to throw the baby out with the bath
water.  You can write ugly code without the cycle too -- I'm sure we've all seen
our share.

Here is an example using (gasp!) left-hand indicators -- another "cardinal sin"
which in this case *promotes* readability.   Now lets's say you have a new hire
who has never seen the cycle used, and comes across this code:

     FMaster    IP   E           K Disk

     IMasterRec
     I                                          Division      L4
     I                                          Zone          L3
     I                                          Territory     L2
     I                                          Salesman      L1

     C   L4               Exsr     NewDivision
     C   L3               Exsr     NewZone
     C   L2               Exsr     NewTerritory
     C   L1               Exsr     NewSalesman

     C                    Exsr     Detail

     CL1                  Exsr     EndSalesman
     CL2                  Exsr     EndTerritory
     CL3                  Exsr     EndZone
     CL4                  Exsr     EndDivision
     CLR                  Exsr     EndProgram

If the person *can't* be trained what that means -- in very short order -- then
what are they going to do with pointers, user spaces and indexes, various APIs,
knowing when to use CONST vs VALUE vs not, *NoPass vs *Omit vs not, service
program signatures and bindery language, yada, yada, yada.

I defy you to take the above code and show me how it is more readable in your
Do-It-Yourself level breaks.  Oh, and by the way, the "End..." subroutines must
have the original field values (the group just ending) available for printing
and other calculations.

Go ahead -- show me how you would code the same thing as above.

For those of you who have never seen a cycle program: now you have.  Even if you
have never seen Lx level break indicators, can you really tell me you have *no
idea* what the above code is doing?

The above is *exactly* how I code the mainline of cycle programs.  Everything
else is in subroutines.  It is *trivial* to add level breaks or make other
changes, and I can see *at a glance* exactly what the intent is and feel 100%
confidence in how it does it.

Somebody prove me wrong and show me an equivalent mainline which is *faster* to
code, *faster* to comprehend, *faster* to change when the need arises, and
executes *faster*.

Doug