ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

READ works for a few records then stays on same record

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

  • READ works for a few records then stays on same record

    Good morning,

    wrote a simple update program to populate the number of records a certain combination of records has. I Setll, then read the file. It's a logical file. It goes fine for about 10 records, then reads the same record repeatedly. No clue why this is happening. Please review what I have and if there is something I am missing please advise. I had it all at free format but then changed it and added indicators, but no issues with any of that.

    Thank you and have a good day.

    Code:
    *================================================= ============
    *
    FINLDEPF UF E K Disk
    *================================================= ============
    
    /Free
    // *================================================= =============
    
    Exsr $Main;
    Exsr $Exit;
    
    // *================================================= =============
    // * $MAIN - Collect Data and Write
    // *================================================= =============
    BegSR $Main;
    
    ExSR WriteRec;
    
    *InLR = *On;
    
    EndSr ;
    
    // *================================================= ================
    // WRITEREC - Write Record
    // *================================================= ================
    
    BegSR WriteRec;
    /End-free
    *Loval Setll INLDEPF
    DOW *in88 = '0'
    READ INLDEPF 88
    If *in88 = *off
    
    eval @Count += 1
    
    IF SAVPORT <> @port or
    SAVComp <> @Cocde or
    SAVPayt <> @paytp
    eval SAVPORT = @port
    eval SAVComp = @Cocde
    eval SAVPayt = @paytp
    eval @count = 1
    Endif
    
    eval @DEPNO = @Count
    
    Update INPDEPFR
    Clear INPDEPFR
    Endif
    Enddo
    /Free
    EndSr;
    
    // *================================================= ================
    // * EXIT - Exit program
    // *================================================= ================
    
    BegSR $Exit;
    
    *InLR = *On;
    Return;
    
    EndSr;
    
    // ================================================== ================
    // Initialize Subroutine...
    // ================================================== ================
    BegSr *InzSr ;
    EndSr ;
    Last edited by gcraill; December 1, 2016, 08:10 PM. Reason: [ code ]

  • #2
    Are you updating one or more key fields? If you update a key field to a higher value, the system will read the same record again.

    Comment


    • #3
      Good afternoon, no I am just incrementing the counter for each record that Port/Paytp/Comp has, I am updating another field, @DEPNO.

      thank you.

      Comment


      • #4
        Hey Ted, I am looking at this again, I am updating the 4th key on this logical, the count amount for that 3pc combination. So I think you are correct, going to create a new logical and try it out.

        Thank you.

        Comment


        • #5
          Gave that a try, still reading to a point than reads the same record over and over. RRN stays the same.

          Comment


          • #6
            Do you need to read the file in keyed order? Looks like you're just reading all records in the file so I wouldn't have thought a key was necessary?

            Comment


            • #7
              Say you have two logical files, file LF1 with keys (K1, K2, K3, K4) and file LF2 with keys (K1, K2, K3).

              If you create LF1 first, then LF2 will share the same access path since the keys for LF2 are the same as the first keys for LF1. When you update K4 using file LF2, the access path will get updated even though K4 isn't a key in LF2.

              If you create LF2 first, then LF1 and LF2 won't share the same access path.

              It looks like there might be a way way to force LF2 to have its own access path even if it is created after LF1 by adding the FIFO, LIFO, or FCFO keyword to the second logical file. http://www.ibm.com/support/knowledge...rbafoshrap.htm. It says

              If the FIFO, LIFO, or FCFO keyword is not specified, the new file can have fewer key fields than the existing access paths. That is, a new logical file can share an existing access path if the beginning part of the key is identical. However, when a file shares a partial set of keys from an existing access path, any record updates made to fields that are part of the set of keys for the shared access path might change the record position in that access path.
              But adding one of those keywords might have unwanted side effects. I'm not very knowledgeable in how logical files work. (I only know about this issue because I once worked on a customer problem reported against the RPG compiler regarding this exact same thing.)

              Comment


              • #8
                Good morning Barbara,

                wow, this looks like what is going on, I will recompile the logicals in the order you describe and give it a shot.

                thanks so much for your input. I will let you know how it goes. Have a good day.

                Comment


                • #9
                  Good morning,

                  Barbara you were correct on this, would never know this without your help. Thanks again and have a good day.

                  Comment


                  • #10
                    I'm glad that Barbara solved your problem, but I wouldn't count on that behavior. Someday the files might get rebuilt and the problem show up again.

                    John.sev99 made a good point. If you don't have to access that file in keyed sequence, then I wouldn't do it. If you do have to access it in keyed sequence, I'd rethink the program.

                    Comment

                    Working...
                    X