× 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.



Eric,

I agree with your methodology. With a normalized database,
appropriately keyed files and valid logic, there should never be a
reason to read every record in a file. This is an old method which
requires high I/O and introduces entirely too many logic errors for
which to compensate. It also reduces the extensibility of the end
result.

The issue with the "old school" methods of RPG and COBOL is that it
relies on wrappers extend the functionality into other platforms. To
me, this seems like double duty. This approach is fine if you intend
for all of your clients to utilize a single interface to access the
application; however, if the application is ultimately intended to be
platform independent, programming methods that require native access
also require wrapper experts to translate the methods. This is where IT
shops get into overhead and budgetary problems.

DB2/400, in the end, is just another database. System I provides a
multitude of compilers for a reason. IBM realizes that the demand for
"old school" methods of data processing is waning. Bear in mind that
IBM owns the Eclipse source code, which is a Java IDE. Web Sphere
relies heavily on Apache and Java to function at an optimum level.
Although I suspect that support for the legacy compilers will continue
for some time, IBM is clearly focused on keeping pace with the
competition by integrating the newer technologies. I believe there will
come a time when IBM, as it has done in the past, will ultimately
dictate to conform or perish.

Tom Armbruster

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

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.