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



Soryy jt, you're loosing me here.

The CHAIN operation NEVER set an EOF indicator - it set a Record Not Found
Indicator, which now equates to the %FOUND BIF.

The %EOF BIF is exactly the same as the EOF indicator that you would specify
on a READ, READE etc. - which was the indicator that related to the FILE
POINTER.

What is "new" is that CHAIN will set off the %EOF BIF if a record was found.
If it's not found it, it leaves it alone - because the status of %EOF will
be the exact same as it was before the Chain.

Paul

----- Original Message -----
From: "jt" <jt@xxxxxx>
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
Sent: Tuesday, March 30, 2004 12:57 AM
Subject: RE: Loop code


> Thx Paul,
>
> But:  For the same reason that a CHAIN, or a READ, or a READE, or a READC
> sets the indicator(s) on or off.  Iow, every single one of these opcodes
> either sets an indicator on or off.  (And, not coincidently, it works the
> same way if you're using the < indicator for errors on these opcodes, and
in
> fact, every single opcode I can think of off the top of my head.)  To me,
> intuitively, it would make as much sense to leave %EOF *unchanged* after
> code is executed, as it would to leave the indicator specified on a LOOKUP
> *unchanged*, unless there was a match and ONLY THEN you set the indicator
> on.  Otherwise it just stays the same it was.  Now THAT makes no sense to
me
> (and I would suspect most-all everybody who has actually used RPG,
although
> there will be exceptions 'course).
>
> So I'm afraid I don't see a close relationship at all between how a FILE
> POINTER is used, but a great deal of relationship (like near-identical)
> between indicators and the %EOF built-in.  Except that's not how the %EOF
> works.  So, as far as making "perfect sense", very obviously this is not
the
> case.  And I'm not even sure it makes even a LITTLE sense, from the
> discussion I've seen so far.
>
> (Btw, I never found out if you can set these built-ins, like you can
> indicators, in DBG??)
>
> | -----Original Message-----
> | [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Paul Tuohy
> | Sent: Monday, March 29, 2004 5:07 PM
>
> | Sorry jt, but I think this makes perfect sense.
> |
> | If a CHAIN is successful, it means you got a record, so you are
> | not at EOF,
> | so %EOF(filename) is set off.
> |
> | If a CHAIN is unsuccessful, the file pointer is left where it was, so
> | %EOF(filename) is unchanged.
> |
> | An unsuccessful chain does not position the file pointer at EOF - so why
> | would it set on %EOF?
> |
> | Paul Tuohy
> |
> | ----- Original Message -----
> | From: "jt" <jt@xxxxxx>
> | Sent: Friday, March 26, 2004 7:35 PM
>
> | > This part seems ENTIRELY UNintuitive.  Is there some benefit or
> | Reason WHY
> | > it would NOT change??  What logic went into this decision, if I may
ask?
> | > (Obviously, I may ask, but it might never get posted nor answered, of
> | > course...;-)
> | >
> | > | -----Original Message-----
> | > | [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Paul Tuohy
> | > | Sent: Friday, March 26, 2004 12:37 PM
> | >
> | > | "The following operations, if successful, set %EOF(fielname)
> | off. If the
> | > | operation is not successful, %EOF(filename) is not 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.
>
>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.