Re: Multi- Occurrence Data Structure

Hi James,

<snip>
Why not? If they're writing a program that performs a given operation on
every single record of a file (or, at the very least, looks at every single
record, and performs the operation where it's needed), you have the perfect
situation for a "conventional" Cycle program. If they're writing an
interactive "do-until-the-user-tells-it-to-stop" program, that's the perfect
situation for an "unconventional" Cycle program. Either way, adding an
explicit do-loop and (in the first case) explicit file reads just adds
unnecessary complexity.
</snip>

I will not expect them to write programs which USE the cycle because it is
not a relevant construct for us.

I contest the idea that putting explicit do-loops for explicit file reads
adds unnecessary complexity to a program. On the contrary, I believe it
removes the obfuscation that the cycle introduces. The whole point of doing
something explicitly is to make it clear to the next developer what the
program is doing. They can see clearly because it is constructed right
before their eyes.

I do understand what you are saying about the cycle and the benefits it
brings when reading a whole large file. But hey, I haven't written a program
like that in 10 years. I spend more time writing RPG service programs to run
on the web, work with xml, stream files, sockets, use system API calls, etc.
For me the cycle is an unnecessary lump of code I have to drag around with
my programs.

I am the most expensive part of the program's whole lifetime. The time I
spend on a program will probably be more than the total runtime of the
program for all the times it runs. If I ever do have to write a program
which reads a large file overnight and performs some processing I'm not
going to worry too much about the few seconds longer it took because I
defined a full procedural file, or used SQL. If it is too slow when it runs
in production then I'll change it and put a primary file in. But I have
never had to do that - ever. Premature optimization, and all that... :-)

If reading primary files works for you then great, but I certainly don't
need it - it just simply isn't relevant to the way I work. Another
cycle-related construct, *PSSR subroutine, is also totally useless to me.
The exit verbs available when leaving the subroutine are points in the
cycle! thats no use to me - especially when the error occurred within a
subprocedure in a service program. Add that to the fact that you can't
resume after handling an unhandled exception - pah! Why even consider using
*PSSR when you have direct monitors and condition handlers? Its an old tool
for the old school. ;-)

Anyway, thankfully the RPG church is a broad one. At least IBM caters for
all of our tastes. I'm happy with RPG, but I wouldn't mind a PGM equivalent
of NOMAIN - maybe NOCYCLE. :-)

Cheers, and have a great weekend

Larry Ducie