Hi Dave,
You're probably right... I just sort of made that up as I went along, but I was simply trying to illustrate that constructs such as level breaks are easily reproduced in the modern paradigm.
I'd like to clarify that I do not necessarily think cycle dependent programs are inherently evil, but rather that it takes siginicantly more effort to understand the implications of cycle dependent features. First and foremost, the cycle forces the developer to make use of indicators to drive their logic. Now, I'll admit that as far as indicators go, the Lx and Mx indicators are pretty descriptive as to their function, but one must still have a full understanding of when and how those indicators get flipped. There is no opcode that describes these activities, so clarity of intent is not expressed in the resulting code.
Additionally, I personally find doing MR logic in the cycle to be counter-intuitive. When I want to know if fileB has record subset matching the key from fileA, it feels much more natural to me to use chain or setll to determine if this relationship exists. It feels UNnatural for me to have logic in my program that says: If I've read from fileA, but not from fileB yet, then do nothing. The cycle has forced me into a design that feels awkward and counterintuitive.
FWIW, I'm not trying to take anything away from anyone. If the cycle works for you and your shop, then good for you. Just don't be surprised if someday you can't find seasoned veterans of RPG who can maintain this code....
JMO,
Eric
-----Original Message-----
From: rpg400-l-bounces+edelong=sallybeauty.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+edelong=sallybeauty.com@xxxxxxxxxxxx]On Behalf
Of Dave Kahn
Sent: Thursday, December 20, 2007 5:45 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: RPG Cycle (was Multi-Occurring DS)
On 19/12/2007, DeLong, Eric <EDeLong@xxxxxxxxxxxxxxx> wrote:
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?
I would have said that the concept of level breaks within a single
iteration is itself a hangover from the cycle. Would the structured
approach not be to handle them as nested iterations? This would give
something like.
setll keyval MYFILE;
reade MYFILE;
dow not %eof(MYFILE);
storeKey('PrimaryKey' : mykey1 + mykey2 );
prtNewPage();
dow not %eof(MYFILE) and
not keyChange('primaryKeys' : mykey1 + mykey2 );
storeKey('sequenceValue' : mykey1 + mykey2 + editc(myseq1:'X') );
prtNewSeq();
dow not %eof(MYFILE) and
not keyChange('primaryKeys' : mykey1 + mykey2 )
not keyChange('sequenceValue' : mykey1 + mykey2 +
editc(myseq1:'X') );
prtDetail();
reade MYFILE;
enddo;
enddo;
enddo;
Maybe I have been over-influenced by Jackson Structured Programming.
midrange.com
