|
JT, Just pointing out something here.... I hear programmers getting confused about this, and (IMO) usually it's because they never paid very close attention to what the indicators are really representing. Take a look at CHAIN in the good ol' ILE RPG Reference, and you see the indicators columns are labeled NR (no record), ER (error), and --. READ, and all it's cousins, labels them as --, ER, and EOF. SETLL is NR, ER, and EQ. In practice, I think most RPG programmers just wait for SEU to tell them they need an indicator wherever SEU placed the cursor, and never really develop a feel for what the indicators are really telling them. Its just simply "there" (indicator off) or "not there" (indicator on). As I recall, some of these "rules" about the compiler setting off the %eof indicator after a chain was PTFd recently, because too many programmers missed out on how to use the new BIFs. Eric DeLong Sally Beauty Company MIS-Project Manager (BSG) 940-898-7863 or ext. 1863 -----Original Message----- From: jt@xxxxxx [mailto:jt@xxxxxx] Sent: Monday, March 29, 2004 5:57 PM To: RPG programming on the AS400 / iSeries 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 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.