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



Paul,

We're talking two different things here.  I'm not talking about whether a
CHAIN should or should not set any given BIF, like %EOF.

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.

(YES!  I actually DO understand the semi-logic of setting off %EOF if a
record is found, because the file is obviously NOT at EOF.  But then you
introduce one of two inconsistencies:  You either treat the %EOF BIF
different than indicators have been treated for decades, or you set %EOF
*OFF when you really DON'T KNOW whether EOF has been reached by the CHAIN.
Neither inconsistency is appealing.)

Btw, bringing up the question of how the pointer to file positioning works
is a red herring, Paul.  I'm talking a bit-wise operand like a %EOF or
whatEVER should behave as a bit-wise operand indicator normally does.

| -----Original Message-----
| [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Paul Tuohy
| Sent: Wednesday, March 31, 2004 1:09 PM

| 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>
| Sent: Tuesday, March 30, 2004 12:57 AM

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