RE: Cycle programs and control level breaks

I switched to the RPG world in 1985, and some flavor of RPG has been my
primary language ever since.  Suffice it to say that there were a lot of
"cycle" programs around back then.  And of course they were mostly
6000-line behemoths, 500+ lines of which were GOTOs!

People new to RPG are often fascinated by the cycle, as no other common
language has anything similar, at least to my knowledge.  And rightly
so.  What language designer in his/her right mind would include
something like this?!  This is a vestige of the old report-design world,
when RPG wasn't a so-called "real" 3GL language.

You may save a few lines of code and a few minutes of your precious time
by coding a cycle pgm that, at least initially on the surface, looks
pleasingly elegant to the untrained eye.  But just try making a 3-line
change to that sucker 4 years later after a dozen other programmers have
been mucking around with it!  As we all know, the initial investment in
coding a pgm pales in comparison to the maintenance costs.

And lastly, if a pgm does something, I want to  S E E  it doing
something!  The words "programming" and "implicit" should not be uttered
in the same breath!   


Randy Dunfee
Dunfee Business Automation, Inc.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Ken Sims
Sent: Thursday, December 21, 2006 10:54 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Cycle programs and control level breaks

Hi James -

For the specific conversion program that you described,
personally I would not have given any serious
consideration to trying to do it with the cycle
and cycle-based level breaks.

But the two concepts are by no means inseparable. By using
The Cycle in an interactive program that doesn't use a
primary file, I get an implicit "do until finished" loop
that can effectively become the program's main event loop.
And if (as in the present case) there is a primary file, I
no longer have to care about explicitly reading the file
and looping on EOF, as that's all implicit.

Personally ...

1. I would not use the cycle in place of a loop.  If the program isn't 
going to have a primary file, I wouldn't write it as cycle-based.  That 
makes it harder to figure out what's going on for no particular benefit 
that I see.

2. I would not write a program with a primary (and possibly secondary) 
file(s) unless that gives me some significant benefit over coding it 
explicitly.  I have a couple of standard ways of handling level breaks
so I 
don't need the cycle for that.

The only things I can think of that are significantly easier with the
cycle 
are things that involve looking ahead at the next record(s) in the
file(s), 
which is matching records and look-ahead fields.  Since look-ahead
fields 
can only be used with program-described fields, that greatly limits
their 
usefulness, and makes matching records to be, in my opinion, the one
reason 
to use a cycle-based program.

Ken
http://www.kensims.net/
Opinions expressed are my own and do not necessarily represent the views
of my employer or anyone in their right mind.