But there is no record with RRN zero. If I issue the SETLL operation the
pointer is set prior to the row with the same key. No record has key
zero, so SETLL 0 fails, there is a record 1 so the pointer can be set just
prior to that record. IDK, seems right to me. I have used SETLL, READ
and CHAIN on RRN files a lot over the years (subfiles are RRN files).
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Brian
Parkins
Sent: Tuesday, December 08, 2015 3:38 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
<rpg400-l@xxxxxxxxxxxx>
Subject: Re: Possible intereting SETLL behavior
Vern said:
So it may be - but this has been a digression - I was not checking other
than the error indicator when using *START, while I DO use the %found()
indicator when using 0 as the search-arg.
I wonder if someone else will be able to verify the behavior.
It does still seem odd that SETLL 0 file; for an arrival-sequence file
sets %found() to *off - there ARE records whose RRN > 0 (18 of them in the
file I'm reading), and this satisfies the definition of SETLL, unless
there is some unspoken special processing here.
--------------------------
FWIW, (just tested to double check):
SETLL 0 - %FOUND is *OFF
Subsequent READ will not retrieve a row
SETLL *START - %FOUND is *OFF
Subsequent READ _will_ retrieve the first row
SETLL 1 - %FOUND is *ON
Subsequent READ _will_ retrieve the first row
Curious that the use of *START does _not_ affect %FOUND.
Brian.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
