Re: Loop code

["Paul Tuohy" <tuohyp@xxxxxxxxxxxxx>]

Hi Rick,

I hate to disagree but I'm afraid you are mistaken. An unsuccessful CHAIN
does not move the file pointer. Here is a sample program

I have a file with the following keys:-

0000001
0000003
0000008
0000009
0000010
0000011
0000012
0000020

I have the following program (apologies for formatting)

Fproduct1  IF   E           K Disk
D Key             S              7    Inz('0000007')
 /Free
       SetGT *HiVal Product1;
       Read Product1;                            // At EOF
       Dsply %EOF(Product1);
       Chain Key Product1;                    // Record doesn't exists
       Dsply %Found(Product1);
       Read Product1;                            // Where is the file
pointer?
       Dsply %EOF(Product1);
       *InLR = *On;
 /End-Free

The program positions at EOF, CHAINS a record that isn't there, then READs
the next record. If the CHAIN repositioned the file pointer it would READ
key 0000008 - but it doesn't - it is still at EOF.

Change the SETGT *HIVAL to a SETLL *LOVAL and the last read will read key
0000003 - again, the file pointer has not moved on an unsuccessful CHAIN.

%EOF reflects the status of the file pointer - it is not the same as the RPG
indicator specified in the low position on a Read.

Paul Tuohy

----- Original Message -----
From: <rick.baird@xxxxxxxxxxxxxxx>
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
Sent: Thursday, April 01, 2004 2:45 PM
Subject: RE: Loop code


>
> Joe,
>
> I'm in agreement with most of what you said, except for this little
> quibble:
>
> I'm confused by your definition of 'successful' or 'unsuccessful'
> operation.
>
> If you chain to a file, with say, key 4, and only key 1,2, 6 and 7 are in
> the file, the chain was unsuccessful at retrieving the record, but success
> was achieved in moving the file pointer to record 6 for a subsequent read,
> or 2 for a readp.  the file pointer has changed, and we are no longer at
> %eof.
> if you chain with an 8, your file pointer may or may not have changed, but
> you still can't test for %eof until you do a read.
>
> Same goes for a SetLL -
> If you setll with a 4, you've successfully changed your file pointer, you
> are no longer at %eof (if you were before).
> If you setll with an 8, the operatio was a success, and your pointer is at
> the end of the file, but you aren't at %eof yet - you must do a subsequent
> 'read'
>
> I find this wholy consistant - %eof IS for testing the result of a 'read'
> operation, not the position of a file pointer.  The fact that any chain or
> setxx operation sets this off is makes it even more consistant.
>
> Rick
>
>
> ---Joe Lee said-----
> If a CHAIN or SETxx operation is successful you know that you are not
> at the end of the file, therefore %EOF will be off.
> If a CHAIN or SETxx is unsuccessful, you do not know if you are at the
> end of the file, therefore %EOF should not be changed.
>
>
> _______________________________________________
> This is the RPG programming on the AS400 / 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.
>