Skip to main content

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.
Labels:

Comments

Post a Comment

Popular posts from this blog

All about READ in RPGLE & Why we use it with SETLL/SETGT?

READ READ is one of the most used Opcodes in RPGLE. As the name suggests main purpose of this Opcode is to read a record from Database file. What are the different READ Opcodes? To list, Below are the five Opcodes.  READ - Read a Record READC - Read Next Changed Record READE - Read Equal Key Record READP - Read Prior Record READPE - Read Prior Equal Record We will see more about each of these later in this article. Before that, We will see a bit about SETLL/SETGT .  SETLL (Set Lower Limit) SETLL accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Corresponding Record (or Next Record if exact match isn't found).  SETGT (Set Greater Than) SETGT accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Next Record (Greater Than the Key value). Syntax: SETLL SEARCH-ARGUMENTS/KEYFIELDS FILENAME SETGT  SEARCH-ARGUMENTS/KEYFIELDS FILENAME One of the below can be passed as Search Arguments. Key Fiel
4 comments
Read more

What we need to know about CHAIN (RPGLE) & How is it different from READ?

CHAIN READ & CHAIN, These are one of the most used (& useful) Opcodes by any RPG developer. These Opcodes are used to read a record from file. So, What's the difference between CHAIN & READ?   CHAIN operation retrieves a record based on the Key specified. It's more like Retrieving Random record from a Database file based on the Key fields.  READ operation reads the record currently pointed to from a Database file. There are multiple Opcodes that start with READ and all are used to read a record but with slight difference. We will see more about different Opcodes and How they are different from each other (and CHAIN) in another article. Few differences to note.  CHAIN requires Key fields to read a record where as READ would read the record currently pointed to (SETLL or SETGT are used to point a Record).  If there are multiple records with the same Key data, CHAIN would return the same record every time. READE can be used to read all the records with the specified Ke
Post a Comment
Read more

Extract a portion of a Date/Time/Timestamp in RPGLE - IBM i

%SUBDT Extracting Year, Month, Day, Hour, Minutes, Seconds or Milli seconds of a given Date/Time/Timestamp is required most of the times.  This can be extracted easily by using %SUBDT. BIF name looks more similar to %SUBST which is used to extract a portion of string by passing from and two positions of the original string. Instead, We would need to pass a value (i.e., Date, Time or Timestamp ) and Unit (i.e., *YEARS, *MONTHS, *DAYS, *HOURS, *MINUTES, *SECONDS or *MSECONDS) to %SUBDT.  Valid unit should be passed for the type of the value passed. Below are the valid values for each type. Date - *DAYS, *MONTHS, *YEARS Time - *HOURS, *MINUTES, *SECONDS Timestamp - *DAYS, *MONTHS, *YEARS, *HOURS, *MINUTES, *SECONDS, *MSECONDS Syntax: %SUBDT(value : unit { : digits { : decpos} }) Value and Unit are the mandatory arguments.  Digits and Decimal positions are optional and can only be used with *SECONDS for Timestamp. We can either pass the full form for the unit or use the short form. Below i
2 comments
Read more