Sponsored Links
Sponsored Link

sponsored links

Collapse

Announcement

Collapse
No announcement yet.

%EOF and %FOUND

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • %EOF and %FOUND

    Hi again,
    Correct me please if I got this wrong:
    %EOF simply means 'has end of file been reached' - correct?
    %FOUND simply means 'successful chain' - correct?

    Now,
    What if I want to do a "DO" loop, would this work?
    KSoDetSo setll SoDetSo
    DoU Not %Eof
    KSoDetSo ReadE SoDetSo
    If Not %Eof(SoDetSo)

    (Sorry about the formatting. Haven't figured out how to do code insertions yet)

    Mike
    Everyday's a school day, what grade are you in?

  • #2
    Essentially - if you're trying to find a specific record (CHAIN) you are testing to see if it's %FOUND. If you're reading through a set of records you're checking to see if you've reached %EOF(). You are correct that %FOUND simply means a successful CHAIN.

    Your do loop is incorrect - assuming you're wanting to read through the file for all SoDetSo records.

    Code:
      SETLL KSoDetSo SoDetSo;         
      DOU %EOF();                     
          READE KSoDetSo SoDetSo;     
          IF %EOF() = *ON;            
              ITER;                   
          ENDIF;                      
          //       body of code       
      ENDDO;
    You want to read through the set UNTIL (DOU) the end of file (%EOF) is found.

    Comment


    • #3
      Perfect, thank you.
      Working much better now.
      Everyday's a school day, what grade are you in?

      Comment


      • #4
        Code like this makes me nervous, because if anything after the READE changes the value of %EOF, the loop will not work as expected.

        I prefer to code it like this:
        Code:
         
           SETLL KSoDetSo SoDetSo;            READE KSoDetSo SoDetSo;   DOU %EOF();          // body of loop                      READE KSoDetSo SoDetSo;   ENDDO;
        The code is slightly shorter, and there's nothing between the READE and checking %EOF. Just my opinion.

        Comment


        • #5
          Another suggestion:
          Code:
           
           // SETLL, if successful, sets %EOF(filename) off.  //   (%EOF in the RPG Reference; you must specify filename.)  SETLL KSoDetSo SoDetSo;          DOW NOT %EOF(SoDetSo);                        // <code>   READE KSoDetSo SoDetSo; ENDDO;

          Comment


          • Jerry G
            Jerry G commented
            Editing a comment
            Oops:
            // SETLL, if successful, sets %EOF(filename) off.
            // (%EOF in the RPG Reference; you must specify filename.)

            SETLL KSoDetSo SoDetSo;
            DOW NOT %EOF(SoDetSo);
            // <code>
            READE KSoDetSo SoDetSo;
            ENDDO;

            (? Can we no longer edit posts?)

        • #6
          Ugh, what is going on with the code formatting?! I'll try again:

          Code:
            SETLL KSoDetSo SoDetSo;         
            READE KSoDetSo SoDetSo;     
            DOU %EOF();                     
              //       body of code       
              READE KSoDetSo SoDetSo;     
            ENDDO;

          Comment


          • #7
            That would be better as a DOW NOT &EOF(); which is probably what you meant anyway.

            Comment


            • #8
              Originally posted by Scott Klement View Post
              Code like this makes me nervous, because if anything after the READE changes the value of %EOF, the loop will not work as expected.

              I prefer to code it like this:
              Code:
              SETLL KSoDetSo SoDetSo; READE KSoDetSo SoDetSo; DOU %EOF(); // body of loop READE KSoDetSo SoDetSo; ENDDO;
              The code is slightly shorter, and there's nothing between the READE and checking %EOF. Just my opinion.
              Scott,
              I don't understand - while it's not necessarily how I would code it either, I don't see how it would cause the problem you refer to. The DOU isn't tested until the ENDDO - the line after the DOU is a READE which will set the %EOF - if the %EOF is set it does an ITER, which tests the status of %EOF causing it to end.

              Comment


              • #9
                Originally posted by Rocky View Post
                I don't understand - while it's not necessarily how I would code it either, I don't see how it would cause the problem you refer to. The DOU isn't tested until the ENDDO - the line after the DOU is a READE which will set the %EOF - if the %EOF is set it does an ITER, which tests the status of %EOF causing it to end.
                Rocky,

                I'm referring to something like this:

                Code:
                  SETLL KSoDetSo SoDetSo;         
                  DOU %EOF();                     
                      READE KSoDetSo SoDetSo;     
                      IF %EOF() = *ON;            
                          ITER;                   
                      ENDIF;       
                
                      //   ... lots of code here...
                      READ XYZFILE;
                      //   .. lots of code here ...   
                
                  ENDDO;
                This is especially likely if there's a lot of code inside the loop, or if it calls subroutines or subprocedures. Somewhere in that loop, it could do something that sets %EOF, such as READ XYZFILE in that example. Since %EOF is no longer the value from the original READE, there'd it could screw up the loop. I've seen this happen 100 times when people are modifying code and sticking somethign new in the middle... and sometimes it's hard to catch during testing.

                My example, above, was screwed up, too... I forgot to change the DOU to DOW. It should've read like this:

                Code:
                  SETLL KSoDetSo SoDetSo;         
                  READE KSoDetSo SoDetSo;     
                
                  DOW %EOF(); 
                
                    //  ... lots of code here ...
                    READ XYZFILE;
                    //  ... lots of code here ...
                
                    READE KSoDetSo SoDetSo;     
                  ENDDO;
                In this case, the READ XYZFILE does change %EOF, but it does nto affect the flow of the loop because the correct READE is immediately before the condition is checked.

                Comment


                • #10
                  In either way I'd never use %EOF() with an empty parethesis, but always including the file to be checked, i.e. %EOF(MyFile)
                  Birgitta

                  Comment


                  • #11
                    Scott,
                    Ok - I see where you're coming from. In the rare instances where I don't have the %EOF test right after the READ/READE statement I specify the file name, eliminating that problem. Thank you for the clarification.

                    Rocky

                    Comment


                    • #12
                      Just for clarity, %EOF could also mean you hit the logical beginning of file for a READE or READPE.

                      Ringer

                      Comment


                      • #13
                        I meant READP not READE. Doh.

                        Comment


                        • #14
                          With DOU the same condition is tested twice. In my opinion that is a drawback.

                          Comment


                          • #15
                            This has already been said a couple of times in this thread, but I just want to sort of underline it.

                            SETLL doesn't change the value of %EOF without a parameter. It only changes the value of %EOF(filename) where "filename" is the name of the file used in the SETLL operation.

                            Or, to put it another way, if you want to test %EOF immediately after a SETLL, you must specify %EOF(filename), not simply %EOF.

                            Comment

                            sponsored links

                            Collapse

                            Working...
                            X