Something wonderful happened in OS/400 V4R2. IBM removed the requirement for resulting indicators from all opcodes except TEST and LOOKUP.
Why? Because IBM introduced a set of built-in functions that replaced the function of those old resulting indicators and opened RPG IV up to much more readable code. In fact, if IBM hadn't done this, creating the /FREE syntax would have been very difficult.
But time after time after time, I see new code being written that looks like this:
C CustNo Chain CustMast 31
C *IN31 DowEQ *OFF
** Blah, blah, blah
C CustNo ReadE 31
C enddo
Excuse me a second....
I'm sorry, I just gagged a little. It happens when I see this happening in new code today.
First, why DOWEQ? Is this 1985? No, it is 2005, so write 2005 code.
C DOW *IN31 = *OFF
** Blah, blah, blah
C CustNo ReadE 31
C enddo
Next, why use this silly trick with the resulting indicators? So many times, people put them in the wrong column or test for the wrong condition. In V4R2, the %FOUND and %EOF built-in functions were introduced.
C CustNo Chain CustMast
C if %Found()
C DOU %EOF()
** Blah, blah, blah
C CustNo ReadE
C enddo
C endif
When you CHAIN to a file, you can test for a "found" condition rather than the "not found" condition traditionally tested for when using indicators.
With any of the READ opcodes--READ, READE, READP, READPE--you can test for %EOF (end-of-file) condition.
Unfortunately, someone at IBM was a bit too anal when designing this, and the %FOUND built-in is not changed by any of the READ opcodes. So in a CHAIN followed by a READE, both %FOUND and %EOF have to be tested, as in my example above.
The point here is that there is absolutely no reason to continue to use resulting indicators. Use the built-in functions and make your code more readable.
Bob Cozzi is a programmer/consultant, writer/author, and software developer of the RPG xTools, a popular add-on subprocedure library for RPG IV. His book The Modern RPG Language has been the most widely used RPG programming book for nearly two decades. He, along with others, speaks at and runs the highly-popular RPG World conference for RPG programmers.



Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online