ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Downtime estimation for RGZPFM LOCK *SHRUPD

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

  • Downtime estimation for RGZPFM LOCK *SHRUPD

    Hi all,
    I'm new here posting question for the first time.

    I'm working on an I V6R1 and currently planning a reorganize on a huge file (>500GB). It is a log file, PF with 1 member, 1 LF (1 member as well).
    I tried restored a copy of the file to another library and perform reorg with LOCK *EXCL. The process took 12 hours and it's not a time frame that allowed (for downtime).
    I'm aware that I can use LOCK *SHRUPD, which in case RGZPFM cannot obtain an exclusive lock, it will not purge the deleted record. So can I confirm that, even with *SHRUPD, it still need to have exclusive lock to the file (for a small amount of time)?
    1. My question is that how can I know how short is the time frame? Is there any way to estimate that or else how should I handle that (this file log transaction record thus I can't tell when will it be used)?
    2. Beside that, if the REORG can obtain exclusive lock and proceed to purge the deleted record, and at this moment if any program try to access the PF will hit error?

    Another additional question is, in what situation I need to specify RBDACCPTH *YES, *NO or **OPTIMIZE? what are their impact?

    Thank you.

  • #2
    Re: Downtime estimation for RGZPFM LOCK *SHRUPD

    i want to go back a step. what % deleted records do you have? Is the file set to reuse deleted records? If this is the case then a reorg become mute. Its odd to hear that a log file has many deleted records.
    Hunting down the future ms. Ex DeadManWalks. *certain restrictions apply

    Comment


    • #3
      Re: Downtime estimation for RGZPFM LOCK *SHRUPD

      Not sure if this will help?

      1. Start journalling on the file.
      2. Create a new file which has *REUSEDLT set on it.
      3. Copy the records from the original file to the new one.
      4. go through the journal to update and changes to the file.
      5. move the new file into play when no activity.

      Number of requirements need to be understood, but in simple terms its doing what REORG does while not touching the original file.

      Chris...

      Comment


      • #4
        Re: Downtime estimation for RGZPFM LOCK *SHRUPD

        Originally posted by DeadManWalks View Post
        i want to go back a step. what % deleted records do you have? Is the file set to reuse deleted records? If this is the case then a reorg become mute. Its odd to hear that a log file has many deleted records.
        Hi,
        We haven't start the archiving process yet. We keep the records for years and plan to remove some from production and are expecting 30-40% deleted records. No the file does not reuse deleted records. We are thinking to set this as well. The file has several key field and no program read it by arriving sequence, so there should be no impact applying this right?

        Originally posted by chris_hird View Post
        Not sure if this will help?

        1. Start journalling on the file.
        2. Create a new file which has *REUSEDLT set on it.
        3. Copy the records from the original file to the new one.
        4. go through the journal to update and changes to the file.
        5. move the new file into play when no activity.

        Number of requirements need to be understood, but in simple terms its doing what REORG does while not touching the original file.

        Chris...
        The plan look great except step 3, the copying is a pain. I tried CPYF last time and it took 100 mins to copy 5% of the total records.
        The file already journaled and best part is it is a append only log file. I actually planned similar approach with little bit changes:
        3. Backup, restore the file to another library. Reorg the restored filed.
        4. Stop all applications, copy new records (after the backup) into the reorged file.
        5. move the new file into play
        6. Start all applications.
        Is this workable?

        Comment

        Working...
        X