× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



jt

Of course the position of the file pointer  SURE doesn't have ANYthing to do
with the KNOWN STATE of either %FOUND or the  *IN. But it does have
something to do with the KNOWN STATE of %EOF.

I have not said a thing about the %FOUND BIF. I have been talking about the
%EOF BIF.

I'll ignore the personal snipe - sorry you got upset, although I'm at a loss
as to why you are.

This thread is ended

Paul
----- Original Message -----
From: "jt" <jt@xxxxxx>
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
Sent: Wednesday, March 31, 2004 10:02 PM
Subject: RE: Loop code


> | -----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.
>
>
> _______________________________________________
> 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.
>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.