Pages

Wednesday, May 20, 2020

RGZPFM Usage & Important Parameters

Reorganize Physical File Member (RGZPFM):

RGZPFM command is used to remove the deleted records from Physical file member and reorganizes the member.

Some of the Key points to remember.
  • Only one member can be Reorganized at a time.
  • Key file can be mentioned (either Physical File or Logical File with Key fields) to Reorganize the data with Keyed Sequence.
  • Rebuild Access Path for the Physical file and associated logical files. This can be done either Synchronously or Asynchronously to help save the time and/or improve performance.
Below are some of the key parameters to note. 

FILE - Name of Physical File

MBR - Name of the Physical File Member to be Reorganized. Defaults to '*FIRST', Member Name can be entered.

KEYFILE - Used to specify whether file needs to be Reorganized and Key File to be used to Reorganize records. Below are the possible values for this parameter. 
  • *NONE (Default) - No Reorganization will happen and Deleted records will be removed from the Member.
  • *RPLDLTRCD - Reorganization will happen by replacing Deleted records at the starting of the Member.
  • *FILE - Reorganization will happen based on the Physical File's Key Sequence.
  • Logical File - Reorganization will happen based on the mentioned Logical File's Key Sequence.
RBDACCPTH (Rebuild Access Path) - Used to specify if the Access paths need to be Rebuild and how. Below are the possible options.
  • *YES (Default) - Access path will be rebuilt synchronously at the end of the Reorganization. This option may cause the RGZPFM to run for longer depending the size of the member and number of logical fiiles.
  • *OPTIMIZE - Access paths will either be rebuilt asynchronously at the end of the reorganize operation, or maintained during the reorganize, based on which method will result in the access paths being rebuilt the fastest. We need to be careful while choosing this option as Rebuild might still be running after the RGZPFM is completed causing the Member locks making the member not available for any other operations. However, this would save the processing time if this is part of Reorganization activity across application or library.
  • *NO - Access paths will be maintained during the reorganize. If *NO is specified, ALWCANCEL(*YES) must also be specified.
ALWCANCEL (Allow Cancel) - Used to specify whether to allow the Reorganization to be cancelled or not. 
  • *NO (Default) - The Reorganization cannot be cancelled. If Job is ended, Any changes upto the cancellation will be discarded.
  • *YES - The Reorganization can be cancelled. If a Reorganization is cancelled or ended, Subsequent Reorganize (with same parameters) will continue from where it was cancelled.

No comments:

Post a Comment

Popular Posts