× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Taken at the most basic level, yes, the cycle is not hard to understand. But my objective as a developer is to be absolutely explicit in my implementation of the requirements set forth in my assignment. I do not want to obfuscate my intent by leaving out something as important as an I/O operation.

To me, this is very much the same issue as badly named variables, or the use of numeric indicators. When I review code using variables like a, a1, b, i, i2, and so forth, it fails my review. Why? Because "a" does not tell me anything about this variable. Using descriptive names for variables adds value to the application code simply because it describes intent in a useful way.

When I desire to loop through an entire file (rare case these days), I would much rather see an explicit declaration of that, using a DO construct. Its obvious and self documenting, unlike most of the cycle code I've seen and/or written over the years.

Thoughtful design eliminates most of the arguments about "alternative code" being unweildy. Take the level break. Some have argued that these are hard to manage without the cycle, but whats so hard about creating a few procedures to manage them for you?

SetLL keyval MYFILE;
ReadE MYFILE;
// Error trap
SetLevelBrk('PrimaryKeys' : mykey1 + mykey2 );
SetLevelBrk('SequenceValue' : mykey1 + mykey2 + editc(myseq1:'X') );

DoW not %eof(MYFILE);
if ChkLevelBrk('PrimaryKeys' : mykey1 + mykey2 );
PrtNewPage();
endif;

if ChkLevelBrk('SequenceValue' : mykey1 + mykey2 + editc(myseq1:'X') );
PrtNewSeq();
endif;
// do stuff
PrtDetail();

ReadE MYFILE;
EndDo;

I certainly do not know how everyone else writes their applications, but I can't remember the last time I had to read every record in a file. Mostly, I write code to process a transaction, which usually involves only a small subset of records in my table. Aside from using OPNQRYF to subset your data, the use of Input Primary does not match this design requirement at all. IMO, OPNQRYF certainly does NOT make for a more maintainable application.....

Eric

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of James Lampert
Sent: Wednesday, December 19, 2007 12:43 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: RPG Cycle (was Multi-Occurring DS)


It might take me weeks to understand how to use control breaks or
matching records, as built into The Cycle. More trouble than it's worth
for me, which is why I do handle such things with my own code.

But understanding the basic premise that an RPG program will repeat
itself, implicitly reading from a file designated as "primary," until
either the LR indicator is set, or it encounters a RETURN statement (in
the latter case, terminating but remaining active)? If a programmer
needs more than two minutes to grasp that basic concept, the only one
you actually need in order to write and maintain the more basic sorts of
Cycle programs (especially the unconventional ones), then maybe he or
she is in the wrong line of work.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.