RE: Loop code -- RPG400-L

I have to agree with Paul here. The problem is that the EOF indicator is
broken, or at least misnamed. It should reflect the state of the file
pointer, on if the pointer is pointing to the end of the file, or off if
the file pointer is not pointing to the end of the file. Unfortunately
since the EOF indicator is not set during a CHAIN or SETxx, it will not
always be accurate, and would be more accurately called a "read
successful" indicator. 
The %EOF BIF on the other hand can correctly reflect the current state
of the file pointer. If the file pointer is at the end of the file %EOF
is on, otherwise it is off. Since a successful CHAIN will move the file
pointer to somewhere other than the end of the file, it MUST set %EOF
off. Likewise since an unsuccessful CHAIN does not move the file
pointer, it MAY NOT change the state of %EOF. 

The %FOUND BIF on the other hand reflects the success of the last
attempt to find a specific item, a record in the case of CHAIN or
SETxx.

There are no inconsistencies, except that %EOF actually reflects the
current location of the file pointer in the file. What you appear to
want is a %FILEOPPERATIONSUCCESSFUL BIF that was on if CHAIN, SETxx,
READx, WRITE, UPDATE, or DELETE succeeded, and off if they didn't.

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.
If a READx is successful you know that you are not at the end of the
file, therefore %EOF will be off.
If a READx is unsuccessful, you know that you are at the end of the
file, therefore %EOF will be on. 
If a CHAIN or SETxx operation is successful, it is because you have
found a matching record, therefore %FOUND will be on.
If a CHAIN or SETxx operation is unsuccessful, it is because you have
not found a matching record, therefore %FOUND will be off.

Joe Lee

>>> jt@xxxxxx 03/31/2004 13:02:58 >>>
| -----Original Message-----
| From: rpg400-l-bounces@xxxxxxxxxxxx 
| [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Paul Tuohy
| Sent: Wednesday, March 31, 2004 3:25 PM
| To: RPG programming on the AS400 / iSeries
| Subject: Re: Loop code
|
|
| jt,
|
| <snip>
| > I'm talking that a BIF should be IN A KNOWN STATE.  It's either
| on or off,
| > and that SIGNIFIES the known state.  So it would be a case of
either the
| > CHAIN should do nothing whatsoever with the %EOF, which makes a
lotta
| sense
| > to me.  Or it should set it one way or the other.
| <end snip>
|
| The KNOWN STATE that the %EOF BIF reflects is the status of the file
| pointer - it is or isn't at EOF.
|
| A READ etc. moves the pointer, therefore it can change the state of
EOF.
| A CHAIN can only move the pointer IF the record was found. Only a
| successful
| CHAIN can change the state of EOF.
|
| If the %EOF BIF is to reflect the KNOWN STATE then this is the way it
must
| work.
|
| Paul

You're working backwards from your conclusion to your facts, Paul.

On a CHAIN, and using EITHER the %FOUND or an *IN..  It's either *ON
or
*OFF.  It is NOT left unchanged under any circumstances (unless I'm
very
sadly mistaken, which is slightly possible in this case).  And the
position
of the file pointer after an unsuccessful CHAIN??  Dunno, but it SURE
doesn't have ANYthing to do with the KNOWN STATE of either %FOUND or
the
*IN.

Frankly, Paul, I believe if Hans or Barbara or any number of other
people
were saying the Exact Same Thing I've been saying here..  Well I
believe
you'd be agreeing with them quicker 'n anything.  I think it's because
I
disagreed with your post early on, why you're not seeing the blatant
inconsistencies inherent with the usage of BIF, as it is currently
defined.