ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

READP problem

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

  • READP problem

    Hi, I have subfile single page at time. PGDOWN works fine, but when PGUP, when I use readp to read previous records, READP indicates EOF and variables values are from last record all the time, so READP doesnt work. This happens in my logical file. (when I checked another logical file with another physical file, made by another person, PGUP works, EOF is 0)
    What could be problem?

  • #2
    Re: READP problem

    Originally posted by michal2442
    What could be problem?
    Many, many things could be wrong. Far too many to try to list. Most likely, it's coded incorrectly. Without seeing the relevant code, it's impossible to make a useful guess.

    Show us how the code looks.
    Tom

    There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

    Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

    Comment


    • #3
      Re: READP problem

      {Edit: Double-posted after '500 Server error'}

      Originally posted by michal2442
      What could be problem?
      Many, many things could be wrong. Far too many to try to list. Most likely, it's coded incorrectly. Without seeing the relevant code, it's impossible to make a useful guess.

      Show us how the code looks.
      Last edited by tomliotta; February 1, 2015, 04:42 PM. Reason: 500 Server error
      Tom

      There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

      Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

      Comment


      • #4
        Re: READP problem

        But as I said earlier, for another logical file (to another physical file) pgup works. Only for my, created by me it doesnt work.
        here's code:
        dspf:
        Code:
        A                                      SFLCTL(LI050SF)
             A N32                                  ROLLUP(34)
             A                                      ROLLDOWN(35)
             A  30                                  SFLCLR
             A N30                                  SFLDSPCTL
             A N31                                  SFLDSP
             A  32                                  SFLEND(*MORE)
             A                                      SFLSIZ(12)
             A                                      SFLPAG(12)
        indicators:
        Code:
             D  iCzyscSF              30     30N
             D  iUkryjSF              31     31N
             D  iKoniecSF             32     32N   INZ(*ON)
             D  iPokazPola            33     33N
             D  iPageDown             34     34N
             D  iPageUp               35     35N
        pgm:
        Code:
         WHEN pTyp = -1; //---------------------pTyp = -1  is when PAGEUP
                     FOR tI = 1 TO IloscRekSubFile + WLKSUBFILEA;   //wlksubfilea = subfile size = 12, pozycjao = rrn
                        EXSR CofnijRekord;
                        IF eok;
                           LEAVE;
                        ENDIF;
                     ENDFOR;
                  WHEN pTyp = 1; //----------------------pTyp = -1  is when PAGEUP
               ENDSL;
               //======================================================================== Wczytanie SubFilea
               FOR PozycjaO = 1 TO WLKSUBFILEA;    //wlksubfilea = subfile size = 12, pozycjao = rrn
                  EXSR PobierzRekord;
                   IF eok;
                     iKoniecSF = *ON;
                     IF PozycjaO = 1;
                        EXSR CofnijRekord;
                        RETURN *ON;
                     ENDIF;
                     PozycjaO += 1;
                     LEAVE;
                  ENDIF;
                  IF PozycjaO = 1;
                     iCzyscSF = *ON;
                     WRITE LI050SC;
                     iUkryjSF = *OFF;
                     iCzyscSF = *OFF;
                  ENDIF;
                WRITE LI050SF;
               ENDFOR;
               //============================================================ Ustawienie końcowych zmiennych
               IloscRekSubFile = PozycjaO - 1;
               PozycjaO = 1;
               RETURN *ON;
               //============================================================== Ustawienie odpowiedniej bazy
               BEGSR UstawRekord;
                  SELECT;
                     WHEN pKlucz = 1;                //key to search in PF
                        SETLL XXPERIOD LI50L1;
                     WHEN pKlucz = 2;
                        SETLL @INVTYP LI50L2;
                     ENDSL;
               ENDSR;
               //================================================================ read records
               BEGSR PobierzRekord;
                  SELECT;
                     WHEN pKlucz = 1;
                        READE(n) XXPERIOD LI50L1;
                        eok = (PERIOD = XXPERIOD);
                     WHEN pKlucz = 2;
                        READ LI50L2;
                        eok = (INVTYP = @INVTYP);
                        //eok = *on;
                              ENDSL;
                  eok = NOT eok OR %eof;
               ENDSR;
               //======================================================== read previous records
               BEGSR CofnijRekord; 
                  SELECT;
                     WHEN pKlucz = 1;
                        READPE(n) (XXPERIOD:PACKID) LI50L1;
                        eok = (PERIOD = XXPERIOD);
                     WHEN pKlucz = 2;
                        READP LI50L2;
                        eok = (INVTYP = @INVTYP);         
                  ENDSL;
        
                  eok = NOT eok OR %eof;      // here I get %eof = 1, and after readp I have still values of last record in PF
               ENDSR;
              /END-FREE

        Comment


        • #5
          Re: READP problem

          Can you explain what you expect this logic to do?
          Code:
                    SELECT;
                       WHEN pKlucz = 1;
                          READPE(n) (XXPERIOD:PACKID) LI50L1;
                          eok = (PERIOD = XXPERIOD);
                       WHEN pKlucz = 2;
                          READP LI50L2;
                          eok = (INVTYP = @INVTYP);         
                    ENDSL;
          
                    eok = NOT eok OR %eof;
          In the first WHEN clause, eok will always be *ON; so there is no reason to make the comparison. You might as well just set it to *ON or set it to %EOF(). (That is, it will be *ON if any matches previously set it to *ON for the current search key regardless of whether "end of key" is reached or not.) In the second WHEN, it will be *ON as long as the key remains the same. When the key changes, it will be *OFF. It won't work the same way in the two WHEN clauses.

          Also, if "eok" means "end of key", it might be better to code this way:
          Code:
                          eok = ([B]INVTYP <> @INVTYP[/B]);         
          ...and...
                    eok = ( [B]eok[/B] OR %eof );
          Use a "not equal" test and eliminate the "NOT" from the final statement. As you have it coded, eok takes the value of "same key" rather than "end of key" and you negate its meaning in the final statement.

          But it's not totally clear why you have it coded this way. I'm pretty sure I know what's intended, but an explanation could make it more certain. It might also help if you explain why you are mixing READP and READPE in the same logic paths. They won't always give the same logical results.
          Tom

          There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

          Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

          Comment


          • #6
            Re: READP problem

            In first WHEN I was testing different ways to make it work and I didnt go back to the READP, so it should be READP LI50L1 (with this it also doesnt work). Sorry for that.

            About the logic, eok = (INVTYP = @INVTYP); After read the record, I check if @INVTYP typed by the user is equal to INVTYP field in PF. IF it is, eok = 1
            Then, to read next previous record, eok must be = 0. So I compare NOT eok to eok = (INVTYP = @INVTYP) (it should be 0) but %eof = 1, so eok gets 0 (*off). I dont know why %eof takes *ON - I have another records equal to key in my LF


            Ill try the "not equal", but if it won't help, I'll be glad to see another solution to read previous 12 records (12 per page).


            PS. There is also case when I tried this solution to another fields, from LF to another PF, and it worked.
            Last edited by michal2442; February 2, 2015, 04:20 PM.

            Comment


            • #7
              Re: READP problem

              Originally posted by michal2442 View Post
              In first WHEN I was testing different ways to make it work and I didnt go back to the READP, so it should be READP LI50L1 (with this it also doesnt work). Sorry for that.
              That makes a little more sense.

              Ill try the "not equal", but if it won't help, I'll be glad to see another solution to read previous 12 records (12 per page)
              It won't help. That was a comment about making code do what it says. You named the variable "eok" but it wasn't actually marking an "end of key" condition. The value was the opposite of what it's name seemed to indicate, and that makes it harder to read the code and understand the logic.

              Now, it's not clear what the actual problem is. If you were not using READPE, the code that you posted is incorrect, confusing or misleading. That's especially true for these lines:

              Code:
                              SETLL XXPERIOD LI50L1;
              ...and...
                              READPE(n) (XXPERIOD:PACKID) LI50L1;
              ...and...
                              eok = (PERIOD = XXPERIOD);
              You use only XXPERIOD in the SETLL, but you have both XXPERIOD and PACKID in the READPE. And your eok test only tests a mismatch on XXPERIOD. With READPE, that might actually work since you include %EOF() in the final setting of eok. But it won't work well for READP if you really need both XXPERIOD and PACKID. It would also be a problem for SETLL.

              In any case, the logic seems incomplete. It looks like it possibly has most or all that is needed, but the control structure doesn't show how. For example, it's not shown how or when UstawRekord is executed. And does the first FOR/ENDFOR loop attempt to roll back through the file to the beginning of the current subfile page? That's needed so that the next READP would get a record for the previous page when PAGEUP is pressed.

              When you read the records after PAGEUP, do you READP and write each one to the subfile? That would put the records into the subfile in reverse order. If you want them in the forward order, you'd need to go back 24 records with READP instead of only 12, or some number that goes back however far you want to go. It's not clear what should happen if you press PAGEUP on the first page of the subfile. (Is that why you use (IloscRekSubFile + WLKSUBFILEA) for the FOR/ENDFOR loop? Is IloscRekSubFile always set to the number of current records in the subfile minus 1?) Then you'd READ 12 records and write them to the subfile instead of using READP when writing to the subfile.

              Anyway, the actual problem isn't clear. You have a comment in your code that says:
              here I get %eof = 1, and after readp I have still values of last record in PF
              Why would you expect not to get %EOF()?

              Also, when you do get %EOF(), the values of "last record" should be still there. That isn't an error. The record values don't change when %EOF() is reached.
              Tom

              There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

              Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

              Comment


              • #8
                Re: READP problem

                Originally posted by tomliotta View Post
                That makes a little more sense.
                You use only XXPERIOD in the SETLL, but you have both XXPERIOD and PACKID in the READPE. And your eok test only tests a mismatch on XXPERIOD. With READPE, that might actually work since you include %EOF() in the final setting of eok. But it won't work well for READP if you really need both XXPERIOD and PACKID. It would also be a problem for SETLL.
                It should be READP LI50L1, as I said earlier, dont bother with this test READPE + 2 keys
                UstawRekord is executed while making the key, so if first field isnt blank, the key is 1 (first WHEN setll), if the 2nd field isnt blank, the key is 2(second WHEN setll).


                Yes, I add number of current records on subfile page + WLKSUBFILE (const 12) so I can go back to max 24 records. So I wanna READP this number of records (x + 12) and then write to subfile in forward order.
                Yes, IloscRekSubFile is always set to the number of current records in the subfile minus 1.


                About my comment: "here I get %eof = 1, and after readp I have still values of last record in PF ", Its weird, that if I use few following READP, it still sits in %EOF.

                Comment


                • #9
                  Re: READP problem

                  Originally posted by michal2442 View Post
                  Its weird, that if I use few following READP, it still sits in %EOF.
                  That's how it works. If you hit %EOF(), it's "EOF". You can reposition the file and start somewhere else to get away from "EOF"; but from the code that is shown, it's not clear how nor even if that is done.

                  Once you reach "EOF", what would you expect another READP to do? If you are attempting to reposition the file, please show how the repositioning is controlled.
                  Tom

                  There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

                  Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

                  Comment


                  • #10
                    Re: READP problem

                    Originally posted by michal2442 View Post
                    Its weird, that if I use few following READP, it still sits in %EOF.
                    That's how it works. If you hit %EOF(), it's "EOF". You can reposition the file and start somewhere else to get away from "EOF"; but from the code that is shown, it's not clear how nor even if that is done.

                    Once you reach "EOF", what would you expect another READP to do? If you are attempting to reposition the file, please show how the repositioning is controlled.
                    Tom

                    There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

                    Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

                    Comment


                    • #11
                      Re: READP problem

                      I thought that I hit EOF, with READP I will read previous (last) record, another READP will read another previous record etc.
                      Im not doing reposition, in attachement I enclose whole program code, please look on it.
                      Attached Files

                      Comment


                      • #12
                        Re: READP problem

                        If you specify %EOF without file, you need to check the %EOF Keyword immediately after the read operation.
                        Otherwise a different read/reade may change the %EOF value.

                        If you want to check the end or beginning of a specific file is reached always use %EOF(FileName).

                        An other solution might be to dump the result of %EOF into a named indicator variable immediately after the read operation and check the content of this variable somewhere sometime later.

                        Birgitta

                        Comment


                        • #13
                          Re: READP problem

                          Deleted - double post

                          Birgitta

                          Comment


                          • #14
                            Re: READP problem

                            Originally posted by michal2442 View Post
                            I thought that I hit EOF, with READP I will read previous (last) record
                            Once you reach EOF from READ, READP, etc., you have to reposition the file pointer.

                            This is from the RPG manual for READP:

                            if there is any other error or a beginning of file condition, you must reposition the file (using a CHAIN, SETLL, or SETGT operation).

                            Comment


                            • #15
                              Re: READP problem

                              Originally posted by michal2442 View Post
                              I thought that I hit EOF, with READP I will read previous (last) record, another READP will read another previous record etc.
                              Since the file has been read to EOF (end-of-file, "end", no more records), there is no such thing as "another previous record". There are no records after the end.

                              However, be aware that there is a difference between reaching "EOF" with READP and reaching it with READ. When you use READP and you reach "EOF", it actually means that you reached the beginning of the file (that is, the first record). So, for READP, it means that there is no record previous to the first record. Files have two 'ends', the first record is at one end and the last record is at the other end. Both ends can result in "EOF" depending on which direction you are moving through the file.
                              Tom

                              There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

                              Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

                              Comment

                              Working...
                              X