Re: Using RRN 0 to do Setll on arrival sequence file -- RPG400-L

Barbara Morris wrote:

   6. Re: Using RRN 0 to do Setll on arrival sequence file
      (Barbara Morris)

date: Fri, 20 Oct 2006 21:48:05 -0400

Alan Shore wrote:


Actually my theory is still correct.
As Charles previously mentioned
"Setll w/rrn = 0 means, position the file one record before the 1st
record, ie. before the beginning of the file."


I don't think that's the right interpretation of the RRN for SETLL;
SETLL doesn't say anything about "one record before".  SETLL positions
the file at the first record whose RRN is greater than or equal to the
specified RRN; if you have a file with three records whose RRNs are 14
200 431, and you specify SETLL RRN=2, it would position at record 14.

But if there _is_ a bug here with RRN=0, it's a bug in the RPG
documentation.  I think it would be too much of a compatibility issue if
SETLL were to change to be successful with RRN=0, or to issue an
exception.

I have always thought of SETLL setting the file pointer to the address(DASD track/sector, buffer block, whatever terminology is appropriate)for the RRN that was supplied regardless of what records exist. If RRNs1 through 5 are deleted and SETLL for RRN(1) is executed, then the filepointer is at the address of RRN(1). The first READ skips the deletedRRNs and finds RRN(6). I've also thought of a basic "deleted records"map that could be used to determine whether any non-deleted recordsexisted after the chosen RRN and whether %EOF() should be turned on.

From that perspective, a SETLL RRN(0) would try to position physicallyat the address of RRN(0), i.e., one full physical record _before_ thestart of RRN(1).

Alternatively, the positioning could begin at the start of RRN(1) andsubsequent records could be examined to see if they're marked as deletedor not until a non-deleted record was found.

Either way, the actual attempt to position at the beginning of RRN(0)would fail perhaps causing an exception within DB2 simply because RRN(0)cannot be the target.

That would perhaps mean that the wording in the documentation is mostly"logically" correct even though technically incorrect. It results in%EOF() coming on and positioning to EOF because the chosen positionitself doesn't exist.


Tom Liotta