RE: Midrange Knowledge test -- MIDRANGE-L

>James H. H. Lampert:
>And RPG, as a language, has exactly one thing to 
>recommend it, and it happens to be the one feature 
>that far too many RPG programmers either
>avoid like the plague, or have never learned to use: 
>"The Cycle."
>...In my opinion, anybody who is unable to write or 
>understand a cycle program, whether it's controlled 
>by a primary file, or by the user, or by nothing at 
>all, (or who can't tell at a glance what's controlling
>"The Cycle" in any given program) has no business 
>using RPG in the first place.

In the late days of the System 38 there was a document circulated among RPG
shops concerning optimizing RPG code.  Around 1988 I saw it at three
different companies and heard it discussed by many folks at local user group
meetings.  The document included points about odd length packed numeric
fields instead of even length, placement of more frequently used subroutines
immediately after the main routine, and lots of other stuff.  Much of it is
probably irrelevant in today's AS/400 environment.

Circumventing the cycle was covered in a major section of the document.  The
document suggested that the RPG compiler would add all the cycle components
to any RPG executable where an input primary file was defined.  If there
were no primary or secondary file definitions the cycle components would be
omitted from the executable.  If you wrote a simple input primary program to
list a file, and rewrote the program using a fully procedural file with your
own read and output loop the input primary program would take longer to
compile, and produce a much larger and longer-running program.  The message
was clear -- don't use the cycle.

Around the same time or earlier some of the same shops were migrating from a
data processing mentality to applications programming.  Structured
programming and readable code were emphasized.  I ran across a few managers
and senior analysts who believed that many of RPG's unique characteristics
were at odds with standards for readable code.  Condition calculations,
testing indicator values, and the entire cycle were considered voodoo.

I know of many shops where standards were developed around fully procedural
logic for batch processing.  I wrote a skeleton program for fully procedural
emulation of primary and secondary input processing, including level breaks.
Another skeleton program was written for matching records.  As I interviewed
RPG programmers in the early 90's I encountered a lot of programmers who
were trained to avoid the cycle at all costs.  Others didn't have to be
trained to avoid the cycle -- they didn't know what it was because they were
trained on other techniques.

I always thought the cycle was pretty cool.  Now I understand that it's
basically an ISAM processing engine.  The logic for such an engine is fairly
easy to build on your own, and reuse.

If I were still managing developers these days I'd still avoid the cycle.
The cycle is powerful, but I think it's better suited to the days when
development environments could be AS/400 shops or RPG shops.  These days
it's hard to find a single-platform environment.  When you've got developers
moving from platform to platform I think it's better to expose the database
processing logic in the code than to depend on discrete characteristics of
the compiler.

-Jim

James P. Damato
Manager - Technical Administration
Dollar General Corporation
<mailto:jdamato@xxxxxxxxxxxxxxxxx>