OVRDBF, RRN and record deletion

510 pts.
AS 400
I have a CL program where I'm overriding file to qtemp based on *CALLLEVEL. In RPGLE program, I build the qtemp file with some records. After completion of RPGLE, I perform DLTOVR in CL.
Now, in RPGLE program, I'm performing an activity of building the file again and again. (I perform something like below) -
  1. Build 500 records
  2. Read them and do some task
  3. Delete the 500 records
  4. Build new set of 600 records
  5. Read them and do some task
Now, in step 3, when I perform Deletion, the RRN in file is not sequenced properly. So, when I build new set of 600 records again, RRN doesn't start from 1.
I have 2 queries with regarding to this -
Question 1. for now, this is the logic i am applying in my RPGLE. Works fine for me. But, let me know if this is fine
C If ClearFile = 'Y'
C Monitor
C Close File
C QCMDEXC to perform 'CLRPFM FILE(QTEMP/file)'
C Open File
C On-Error
C EndMon
Question 2. When I don't perform above step, and if I build records into the overridden Qtemp file, records are written from say (RRN 200 - 600) and then records are built for RRN 1 - 199. When I debug this, I see that RRN 200 is written, then RRN 201, goes on till RRN 600. And then, the next written record pertains to RRN 1 and it goes on till RRN 200. What causes records to be written like this? (I mean, how does the program know that once RRN of 600 is reached, it should start building RRN 1-199)?

Answer Wiki

Thanks. We'll let you know when a new response is added.

When deleting records from a file , they are still there in a soft delete state and can be recovered with a 3rd party utility. If you want the RRN to be reset you need to do a RGZPFM if I remember correctly… It’s been a while 

Discuss This Question: 6  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TheRealRaven
    Not enough info to be sure -- the file creation statement isn't shown, the OVRDBF isn't shown, the OS version/release isn't shown.

    Why does it matter what RRNs are used? Maybe a minor change can make a difference if we know what the objective is. How are you determining what the physical order is of the records?

    The answer probably has to do with how deleted record space is re-used, but there's not enough shown to make a good guess.
    36,025 pointsBadges:
  • sri8707
    1. Command for Create file

    CRTPF      FILE(QTEMP/FlNm) RCDLEN(32766) +    

    2. OvrDbf based on Call Level

    3. I am trying this on V7R2 as well as V7R3 releases

    As REUSEDLT is set as *Yes, i understand that the unused spaces are reused. However, my only doubt is while writing records to the file, how does it automatically point to RRN 1 after building some records?
    510 pointsBadges:
  • Splat
    If you're creating the file in QTEMP with MAXMBRS(*NOMAX) why not just use a different member for each stage? ADDPFM is easy & the EXTMBR file specification keyword parameter can be a variable.
    12,915 pointsBadges:
  • GregManzo
    1) When reusing deleted record space, I don't recall IBM ever making any guarantees about what order they would get re-used. That would explain why 200-600 then 1-199.
    2) You could use RGZPFM to compress out all the deleted record space or, if you are deleting all records anyway, just use CLRPFM. It's faster than 600 deletes and doesn't leave any deleted records behind.
    3) Relying on RRN for the sequencing of records is considered poor design. If you need to read the records back in a particular order then write a sequential key field in the record & read by that.
    2,970 pointsBadges:
  • TheRealRaven
    And the actual OVRDBF command still isn't shown. Info requested so far isn't sufficient to get to a clear answer, but it should allow us to ask one or two additional questions that could give possible answers. As it is, there are too many variables that could have too many answers.
    36,025 pointsBadges:
  • MissionMan
    If the relative record number is important to you, add a key. Relative record numbers should not be used as a cast-iron method of reading something in sequence when sequence is important. So instead of a flat file (if that's what you're using), use an SQL CREATE TABLE command and add a column you can order on (SELECT ... ORDER BY columnname). Then read it in sequence. If the table gets too big, add an index.
    20 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: