Re: Possible intereting SETLL behavior

Thanks, Kevin

Interesting thread - lots of statements about how SETLL works that seem not to really agree with each other - several kind of making SETLL into a kind of READ operation, which it is not.

And these are statements from several of our star submitters!! (I don't think I got into that one, not enough star power!)

But I am glad to have confirmed what I see - and I don't think I'll talk to the data management folks - who wants to change what has been this way for, what? 40 years?

As I think Charles said there, enough on how many angels...

Cheers
Vern

On 12/8/2015 1:43 PM, Kevin Bucknum wrote:

A long discussion about this behavior took place back in 2006. The TLDR
is everyone confirming the exact behavior you are seeing, and Barbara
noting that she doesn't have any insight. RPG passes the RRN to data
management and this is what is returned.
Start of thread -
http://archive.midrange.com/rpg400-l/200610/msg00411.html
Barbara's response -
http://archive.midrange.com/rpg400-l/200610/msg00468.html




Kevin Bucknum
Senior Programmer Analyst
MEDDATA/MEDTRON
Tel: 985-893-2550
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
Vernon Hamberg
Sent: Tuesday, December 08, 2015 1:29 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Possible intereting SETLL behavior

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.

Vern

On 12/8/2015 1:13 PM, CRPence wrote:

On 08-Dec-2015 12:49 -0600, CRPence wrote:

On 08-Dec-2015 11:51 -0600, Vernon Hamberg wrote:

<<SNIP>>

*START was, so far as I know, a pretty late addition - came out at
7.1, I believe. I don't recall anything about using a value for
this, rather, that the file is positioned "...to the beginning of
the file...", with no regard for actual values. <<SNIP>>

Been around longer than that. I retain actual code, functional on
v5r3, that uses the _special values_ on SETLL for Arrival sequence.

Perhaps telling however, is that the indicators other than the
/error/ indicator are not allowed when using a _special value_ on
SETLL using fixed-format.? That would seem to suggest that, in the
past anyhow, that SETLL had no intention of ever setting the %found()
[or of course the %eof()] indicator _with either special values

specified_.?

Argh! Of course I meant /special values/ [i.e. *END and *START] in
the above reply, rather than the /figurative constant/ I had written.
Each was corrected, inline to the quoted text, and I added an addendum
to emphasize that my final comment [softened with a question mark] was
applicable only to those _special values_ about which I was

commenting.