ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Issue while writing into PF with incorrect RRN

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

  • Issue while writing into PF with incorrect RRN

    Hi There,

    I have one issue. Program is writing into PF with incorrect RRN.
    This is what it is happening.

    My PF has only 2 fields... Customer No (6 Char) & Comments (70 Char).
    RPGLE program takes the input for Comment (Char 70) field only and writing into this file. In this program user is adding comments to the existing customer then RPG chains with entered customer no and delete all existing records firstly and then write all input value i.e. present in comment field from screen in to mentioned PF.

    Now what is happening is when multiple comments are present on screen then while writing into PF it should write with next RRN, so if first record written with RRN (123) then next record should get written with RRN (124) ideally however second record is writing with RRN 122 therefore comments lines are misplacing when it gets read subroutine to display on screen.

    For example..
    User input on screen like below..
    Comment line 1
    Comment line 2
    Comment line 3

    It writes in PF
    RRN Comment
    123 Comment line 2
    124 Comment line 1 -> while writing this was the first record gets written in PF
    125 Comment line 3

    This when I read this file to show user comments on screen then Comment line 2 shows first then Comment line 1 and so on.. thus sequence is misplaced while displaying them on display screen.

    I tried to RGZPFM but did not work.
    Is there a way to this issue... Please let me know.

    Thanks,
    NIL
    Cheers...
    Nil

  • #2
    Why not add a line number to your file? This would allow you to retain sequencing without worrying about RRN.

    Comment


    • #3
      Is your file (table) create REUSEDLT(*YES)?
      If so, a new entry will replace a deleted row if one exists before writing a new one.
      The REUSEDLT option can be changed to REUSEDLT(*NO) with the CHGPF CL command.
      With REUSEDLT(*NO) deleted rows are not overwritten, but a new row is added at the end.
      In this way you'll write the rows in sequence.

      A better solution would be to include an identity column in your file.

      Birgitta

      Comment


      • #4
        I have to agree with Terry. One of the fundamental tenets of relational databases is that the order in which the rows are stored in the table cannot have any significance. I would add a line number and specify the primary key as customer number and line number.

        Comment


        • #5
          Thanks all for all the inputs here.
          I cannot add one more field as seq no because there are existing records for which to set seq no to each existing record is difficult.

          In my case PF has REUSEDLT(*YES), so as per the replies here I use CHGPF and set REUSEDLT(*NO) and it works...
          But I wonder, REUSEDLT(*YES) is default parm while compiling any PF then this issue does not come with other PF but why only with this particular PF was coming, is still a question?

          Thanks ALL once again for the inputs.

          Thanks,
          NIL
          Cheers...
          Nil

          Comment


          • #6
            Nil wrote:
            "But I wonder, REUSEDLT(*YES) is default parm while compiling any PF..."

            REUSEDLT defaults to *NO on our system's CRTPF command - perhaps someone changed the default on your system?

            Cheers,

            Emmanuel

            Comment


            • #7
              REUSEDLT( *NO ) is the default on my three systems, oldest one is a V5R3 model 170. I'm pretty sure I haven't done anything to change any of them.The Knowledge Center shows *NO as the default for i 7.3. AFAIK, that's been the default for DDS-created or program-described PFs from the start.

              SQL tables created with DML are REUSEDLT( *YES ).

              The default might be changed on any system where it should be expected/standard behavior. Perhaps most systems should be that way, since it's more appropriate for a relational database where physical "arrival" sequence shouldn't affect processing.
              Last edited by tomliotta; June 10, 2017, 03:18 AM.
              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
                Nil, did you code the RECNO keyword in your RPG program? The variable in the RECNO keyword controls which deleted record a WRITE operation goes to. As far as I know, this works with REUSEDLT *YES and *NO.

                To use this, you would have to keep track of the RRN of the records you deleted.

                Comment

                Working...
                X