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



Hi John,

Seems to me that you aren't really talking about a difference between RPG III and RPG IV. You are talking about a difference between checking the resutls using a BIF like %FOUND or %EOF vs. using an indicator.

In RPG IV (as well as RPG III) you can do this:

c xxkey chain xxfmt lr
c dow *inlr = *off
c* do the real work here.
c xxkey reade xxfmt lr
c enddo

Nothing has changed. RPG III and RPG IV are identical. But perhaps what you didn't think about is that the indicators on CHAIN and on READE don't mean the same thing. (And this has always been documented this way!)

The indicator on CHAIN is in the HI position, and it means "record not found".

The indicator on READE is in the EQ position and it means "end of file"

This, again, is the case in both RPG III and RPG IV.

When IBM gave us BIFs to replace the indicators, they gave us BIFs that match what the indicators do. They gave us %FOUND which we can check to see if a record was found (or not), and they gave us %EOF which we can check to see if we're at the end of the file (or not). So essentially, they gave us exactly what we had before. The difference, however, is that they don't have the same name as one another. in your RPG III example, and my indicator-driven RPG IV example, the name of the indicator is LR in for both "not found" and "end of file". However, %FOUND and %EOF always have different names from one another...

So you can't do what you posted and expect it to work!! here's what you coded:

c xxkey chain xxfmt
c dow not %eof(xxfile)
c* do the real work here.
c xxkey reade xxfmt
c enddo

Well, since the CHAIN op-code doesn't set the %EOF indicator (it sets %FOUND), this code doesn't make a lot of sense!! So of course this doesn't work. What you really wanted to do was this:


c xxkey chain xxfmt
c if %found(xxfile)
c dou %eof(xxfile)
c* do the real work here.
c xxkey reade xxfmt
c enddo
c endif

Or if you want it to work exactly like the RPG III example, you could do this instead:

c xxkey chain xxfmt
c eval *inlr = not %found
c dow not *inlr
c* do the real work here.
c xxkey reade xxfmt
c eval *inlr = %eof
c enddo

That would do (literally) what you did in RPG III using BIFs... but I find that ugly. This need to check a different BIF for different results has led a lot of people to stop using CHAIN to prime a loop, and instead use SETLL/READE:

c xxkey setll xxfmt
c xxkey reade xxfmt
c dow not %eof(xxfile)
c* do the real work here.
c xxkey reade xxfmt
c enddo

But, however you decide to proceed, I hope you at least understand the situation now.



jmmckee wrote:
Where I work, training is something of a dirty word.

To read multiple records using a partial key in RPG III, I do this:

xxkey chain xxfmt LR
*INLR doweq *OFF
xxkey reade xxfmt LR
enddo


On a project a few years ago, written in RPG IV, that code did not work.

The only way we found to make it work was to do this:

xxkey setll xxfmt
xxkey reade xxfmt dow not %eof(xxfile)


xxkey reade xxfmt
enddo


Doing a CHAIN to position and read the first record when multiple records were read just went to end of file, as I recall. Been too long.

Were we doing someting wrong that caused the RPG IV code to fail? This has really been bugging me for a long time. I couldn't find a reason for the bizarre behavior in my searching. It >may< have been an error when only one record with the matching subkey was found. Again, I just don't remember.
John McKee


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.