Re: SETGT and end-of-file - documentation incorrect?

Chuck

I believe I spoke wrongly - When SETGT is done with the last RRN or larger, %found() is *OFF, as one expects, because there is no record with an RRN higher than that of the last RRN (in order) - that also matches the part of the documentation I quoted.

My apologies - so let's do a restart on this - and I have been thinking about it.

The manual says the file is positioned to the end of the file - it doesn't say that %eof() is set *ON. There is a similar statement, I think, with SETLL *END - the position is set to the end of the file but EOF is not turned on.

A READP that follows either SETGT returns the last record - RRN 18 in this case.

Am I on a better path this time???

Regards
Vern

On 12/6/2015 2:19 PM, CRPence wrote:

On 06-Dec-2015 08:57 -0600, Vernon Hamberg wrote:

The ILE RPG Reference says this in the section on SETGT - RPG/400
reference says the same thing

If the SETGT operation is not successful (no-record-found
condition), the file is positioned to the end of the file.

I've a situation where I'm using SETGT with relative record numbers.
If I have an RRN = last RRN (or greater than that last one),
%found() is *ON, %eof() is *OFF.

The literal "last RRN" or perhaps just the "last _active_ RRN"? If the latter, then that would explain the %found()=*ON as the effect.

So this seems to say that the docs are incorrect. Any verification
or refutation, please?

The docs look [sufficiently] accurate. The effect from the run-time however, that could be suspect. If a row was /found/ using the alluded positioning request, then what matters\elucidates, is the specific RRN that was found.

The statement I'm using is in free format, as here -

setgt(e) 18 file-name;

What does the RRN of the INFDS for the Database Specific Feedback Information suggest, when %found()=*ON for that request; perhaps 19?