REORG

The REORG utility reorganizes a database by unloading data from one or more areas in one database and reloading it into one or more areas of another database.
idmscu19
The REORG utility reorganizes a database by unloading data from one or more areas in one database and reloading it into one or more areas of another database.
This article describes the following information:
2
2
Authorization
To
You Need This Privilege
On
Unload an area
DBAREAD
The area itself
Any area(s) with set connections to the area
Any area(s) containing an index defined on records in the area
Unload a segment
DBAREAD
All areas of the segment
Reload data into an area
DBAWRITE
The area itself
Any area(s) with set connections to the area
Any area(s) containing an index defined on records in the area
Reload data into a database
DBAWRITE
All areas into which the data is being reloaded
Any area(s) with set connections to target areas
Any area(s) containing an index defined on records in the target areas
Syntax
►►── REORG ─┬──────────────────────────────────────────────────┬──────────► ├─ setup-options ─┬─────────────────────────┬──────┤ │ │ setup-execution-options │ │ │ └ ESTIMATE workfile sizes ┘ │ │ │ ├─ execution-options ──────────────────────────────┤ ├─ CLEANUP ─┬──────────┬─┬──────────┬──────────────┤ │ │ NODELETE │ └ NOUNLOCK ┘ │ │ └ DELETEALL┘ │ │ │ ├─ STATUS REPORT ONLY ─────────────────────────────┤ └─ ESTIMATE workfile sizes ─────┬────────┬─────────┘ └ SUBMIT ┘
Expansion of
setup-options
►►──┬─ DBNAME source-db-name ───────── USING source-subschema-name ──┬────► │ │ └─ SEGMENT source-segment-name ┬───────────────────────────────┬─┘ └─ USING source-subschema-name ─┘ ►───┬────────────────────────────────────────────────┬───────────────────► │ ┌──────── , ──────┐ │ └── AREA ──▼── area-name ────┴───────────────────┘ ►── RELOAD INTO target-database-name ────────────────────────────────────► ►───┬─────────────────────────────────────────────────┬──────────────────► └─── USING target-subschema-name ─────────────────┘ ►───┬─────────────────────────────────────────────────┬──────────────────► └─── DMCL target-dmcl-name ───────────────────────┘ ┌─────────────────────────────────────────────────────────┐ ►─▼─┬─────────────────────────────────────────────────────┬─┴────────────►◄ ├─── DIVIDE PROCESSING ─┬─ 1 ◄──┬─┬─ WAY ──┬──────────┤ │ └─ n ───┘ └─ WAYS ─┘ │ ├─── REUSE workfiles ─────────────────────────────────┤ ├─── GENERATE DBKEYS files ───────────────────────────┤ ├─── as SORTEXIT ─────────────────────────────────────┤ ├─── SHARE ───────────────────────────────────────────┤ ├─── NOTIFY notify-interval ──────────────────────────┤ ├─── DELETE old workfiles ────────────────────────────┤ ├─── OVERFLOW PERCENT nnn ────────────────────────────┤ └─── OVERFLOW CACHE nnnnnnnn ──┬────┬─────────────────┘ ├ KB ┤ ├ MB ┤ └ GB ┘
Expansion of
setup-execution-options
┌─────────────────────────────────────────────────────────┐ ►►──▼┬──STOP AFTER ─┬─ CLEANUP ◄──┬────────────────────────┬──┴─────────►◄ │ ├─ SETUP ─────┤ │ │ ├─ UNLOAD ────┤ │ │ └─ RELOAD ────┘ │ └─── CREATE ──┬─ NO ◄────┬───────┬─────────────┬──────┘ ├─ UNLOAD ─┤ └─ WORKFILES ─┘ ├─ RELOAD ─┤ └─ ALL ────┘
Expansion of
execution-options
┌─────────────────────────────────────────────────────────┐ ►►──▼┬──STOP AFTER ─┬─ CLEANUP ◄──┬────────────────────────┬──┴─────────►◄ │ ├─ UNLOAD ────┤ │ │ └─ RELOAD ────┘ │ ├─── SUBMIT ──────────────────────────────────────────┤ └─── CREATE ──┬─ NO ◄────┬───────┬─────────────┬──────┘ ├─ UNLOAD ─┤ └─ WORKFILES ─┘ ├─ RELOAD ─┤ └─ ALL ────┘
Parameters
  • CLEANUP
    Specifies to perform a cleanup to delete work files and unlock target areas. You can use this option to complete a successful unload/reload operation if cleanup is not performed automatically. It can also be used to delete work files created by an incomplete unload/reload operation that is not being continued.
  • STATUS REPORT ONLY
    Specifies to produce a status report by reading the reorganization control file. This can be run while other REORG jobs are executing to obtain a current status of the entire REORG process.
  • ESTIMATE workfile sizes
    Directs REORG to estimate the size of work files by gathering statistics in a separate pass of the database. This option generates estimates for both UNLOAD and RELOAD work files.
    By default, statistics are collected during the unload phase that can be used for sizing RELOAD work files only. UNLOAD work files must be sized separately.
    If specified together with
    setup-options
    , statistics gathering starts as soon as the setup phase is complete and processing stops after the statistics have been gathered. Additional jobs are automatically submitted to help gather statistics and process the database by UNLOAD slice and index.
    If specified independently of
    setup-options
    , it must be specified in a separate execution of the REORG utility that occurs between the setup and UNLOAD phases. Multiple jobs are submitted to gather statistics only if the SUBMIT option is specified. Processing stops when file estimation is complete.
    When file estimation is complete, processing must be restarted by specifying a new STOP AFTER point.
    File size estimates are automatically used when dynamically allocating work files if no primary space value is specified for the file's DSMODEL.
  • source-db-name
    Specifies the database name the source subschema with be bound to. All bound areas will be unloaded, unless restricted with the area-name option. The source subschema name must be specified with this option.
  • source-segment-name
    Specifies the segment of the database whose areas are to be unloaded. The segment is referred to as the source segment, and the database is referred to as the source database.
  • source-subschema-name
    Specifies the subschema that describes the source database.
    By default, if the source-subschema-name is not specified, it indicates that an SQL-defined segment is to be unloaded. In this case, the REORG utility extracts the description of the database from the dictionary to which the session is connected.
  • area-name
    Specifies an area in the source segment to unload. Records in this area may target different areas in the target database.
    By default, if no areas are specified for a non-SQL defined database, all areas in the source segment that are also defined in the source subschema are unloaded. If no areas are specified for an SQL-defined database, all areas in the segment are unloaded.
  • Target-database-name
    Specifies the name of the database into which data is reloaded. This is referred to as the target database.
    If an SQL-defined database is being reorganized, the
    target-database-name
    must be the same as the
    source-segment-name
    specified in the SEGMENT clause.
    If a non-SQL-defined database is being reorganized,
    target-database-name
    must be the name of either a segment or a DBNAME identifying the database into which data is to be reloaded.
  • Target-subschema-name
    Specifies the subschema that describes the database into which the data is reloaded.
    Do not specify a target subschema if reorganizing an SQL-defined database.
    By default, if reorganizing a non-SQL-defined database and
    target-subschema-name
    is not specified, the source subschema is also the target subschema.
  • Target-DMCL-name
    Specifies the DMCL that defines the database into which the data is reloaded.
    By default, if a
    target-dmcl-name
    is not specified, the DMCL that describes the source database is used during the reload phase and therefore must also describe the target database.
    See the source/target DMCLs in Initiating a REORG Operation for additional information.
  • DIVIDE PROCESSING n WAYS
    Specifies the degree to which parallel processing is to be used to reduce elapsed time. The default is 1, which means that one job processes data and another processes system indexes.
    Use of this option exponentially increases the number of work files needed. For more information, see Work files and the n WAYS parameter.
  • REUSE workfiles
    Specifies to reuse work files as much as possible. Use of this option reduces the number of work files that are needed.
  • GENERATE DBKEYS files
    Specifies that each task that stores a record into the new database generates a DBKEYS file that maps the old db-key of the record with the new db-key of the record.
    For more information, see Generating db-key cross-reference information in Using the REORG Utility.
  • as SORTEXIT
    Specifies to process sorted output data directly from the SORT, instead of writing it to an intermediate work file. Use of this option reduces the number of files and the amount of disk space needed.
  • SHARE
    Specifies to not lock source areas to prevent concurrent update. By default, source areas are locked at the start of unload processing.
    When locked, the source areas are released at the completion of the unload phase. The reload phase resets the locks on all target and dependent areas that are updated during the reload phase.
  • notify-interval
    Specifies a time-interval in minutes. Each time this interval expires, a message is written indicating the current task being processed and the percentage of records processed to that point. This message is not produced while data is being sorted.
  • DELETE old workfiles
    Directs REORG setup to delete work files that may be left from a previous run. All existing work files that match the name of a new work file are deleted, including DBKEYS files. For more information see, Considerations for running REORG on VSE.
    By default, old work files are reused.
  • OVERFLOW PERCENT
    nnn
    Specifies the percentage used to estimate the size of SYSOF2 and SYSOF8 work files and all output work files for the two overflow tasks: RELOAD2 and RELOAD5. The size of these files cannot be predicted, so they are estimated to be a percentage of related work files.
    By default, 10% is used.
  • OVERFLOW CACHE
    nnnn
    Specifies a limit on the size of the overflow cache used to temporarily hold records that do not fit on their target page.
    nnn
    is the maximum size of the overflow cache specified in bytes, Kilobytes (2**10), Megabytes (2**20), or Gigabytes (2**30), depending on whether it is followed by no qualifier or by KB, MB, or GB respectively.
    A value larger than 2**31-1 is limited to 2**31-1 bytes.
    By default, 32 KB is used.
  • STOP AFTER
    Specifies the processing phase after which execution halts. The options are:
    • CLEANUP
      Continues processing until the entire reorganization operation is complete. CLEANUP is the default if
      setup-options
      are specified.
    • SETUP
      Terminates processing after setup is complete and before unload is initiated. This option is valid only if
      setup-options
      are specified.
    • UNLOAD
      Terminates processing after the unload phase is complete and before reload is initiated.
    • RELOAD
      Terminates processing after the reload phase is complete and before cleanup is initiated.
    If neither
    setup-options
    nor STOP AFTER is specified on a REORG statement, the processing stop point remains unchanged from that previously established.
    If STOP AFTER is specified, and the reorganization control file indicates that processing has already been initiated for a phase beyond that specified as a stop point, a warning is issued and processing is terminated.
  • SUBMIT
    Specifies to submit JCL for additional REORG jobs to the internal reader when a REORG operation is restarted.
    This option is not valid during the initial setup phase, because by default, if processing continues beyond the initial setup phase, JCL is automatically submitted before starting the unload phase.
    The JCL to be submitted is retrieved from the RORGJCL file. If no RORGJCL is present in the execution JCL, the SUBMIT option is ignored.
  • CREATE NO/UNLOAD/RELOAD/ALL WORKFILES
    Specifies whether to create work files and for which phases. The options are:
    • NO
      Does not dynamically create work files. This is the default.
    • UNLOAD
      Creates only the files used during unload processing.
    • RELOAD
      Creates only the files used during reload processing.
    • ALL
      Creates both unload and reload work files.
For information about REORG's work files and using data set models to create them, see Work Files.
Usage
This section describes the reorganization process and provides section lines, and discusses considerations in the use of the REORG utility.
Submitting the REORG statement
You submit the REORG utility only through the batch command facility. You must run the batch command facility in local mode.
Processing Overview
The REORG utility unloads and reloads a CA IDMS database using parallel processing to reduce the amount of time it takes to reorganize data. To enable parallel operations, the utility divides the source and target databases into slices and groups of system-owned indexes. Each slice or index group can be processed (unloaded or reloaded) in parallel by concurrently executing jobs. The amount of concurrency is generally controlled by the DIVIDE PROCESSING n WAYS option; the higher the value specified, the more concurrency is possible.
A REORG operation is controlled through a control file that is built during operation initiation and is accessed by all jobs executing as part of the same REORG operation. The control file describes the specifics of the operation and is updated with status information reflecting the progress that has been made in operation execution. Each job that performs work on behalf of a REORG operation updates the control file. Operating system facilities are used to serialize these updates and to coordinate concurrently executing jobs.
A REORG operation is comprised of the following major execution phases:
  • Setup -- in which the specifics of the operation are determined and its control file built.
  • Unload -- in which the data is extracted from the source database and written to sequential files.
  • Reload -- in which the extracted data is loaded into the target database and inter-record relationships and indexes are built.
  • Cleanup -- in which work files may be deleted and target areas unlocked.
General Reorganization Procedures
Use the following procedures to reorganize a database. These procedures may vary slightly depending on the type of change being made and other operational considerations.
To REORG a database, take the following steps:
  • Create the new subschema, segments and/or DMCL reflecting the changes to be made.
  • Back up all areas that may be updated during the process.
    • Areas being unloaded that contain logically deleted records.
    • Areas being unloaded if data will be reloaded back into the same areas.
    • Areas physically linked to the unloaded areas through sets, linked constraints, or system indexes.
  • If necessary, execute the CLEANUP utility to eliminate any logically deleted records from the areas being unloaded.
  • If desired, execute the IDMSDBAN utility to ensure database integrity.
If the target database files are the same as the source database files, take the following steps:
  • Execute the REORG utility specifying STOP AFTER UNLOAD.
  • If the SHARE option was not specified, use the UNLOCK command to unlock all areas into which the data will be reloaded.
  • Format the areas into which the data will be reloaded.
  • Execute the REORG utility specifying STOP AFTER CLEANUP and SUBMIT.
  • Back up the updated areas. The new areas just loaded and any linked areas that were updated.
  • If desired, execute the IDMSDBAN utility to ensure database integrity.
If the target database files are different from the source database files, and the two are described by different segment definitions whose files have different DDNAMEs and data set names, take the following steps:
  • Format the areas into which the data will be reloaded.
  • Execute the REORG utility specifying STOP AFTER CLEANUP.
  • Back up the updated areas. The new areas just loaded and any linked areas that were updated.
  • If desired, execute the IDMSDBAN utility to ensure database integrity.
If the target database files are different from the source database files, but the two have the same DDNAMEs, take the following steps:
  • Format the areas into which the data will be reloaded.
  • Execute the REORG utility specifying STOP AFTER UNLOAD. Ensure that the REORG JCL and the JCL in the RORGJCL file reference the source database files, the files containing the data to be unloaded.
  • Execute the REORG utility specifying STOP AFTER CLEANUP and SUBMIT. Ensure that the REORG JCL and the JCL in the RORGJCL file reference the target database files, the files into which the data is to be loaded.
  • Back up the updated areas. The new areas just loaded and any linked areas that were updated.
  • If desired, execute the IDMSDBAN utility to ensure database integrity.
Reducing REORG elapsed time
You can substantially reduce the time it takes the REORG utility to unload and reload a database by using chained reads. This enables multiple pages to be read with a single I/O. Its use benefits both the unloading of data, which is primarily accomplished through an area sweep and the reloading of data, which REORG does by loading data in a forward direction. You will get the most benefit if you use chained reads for all areas being updated by the reload phase, which is most easily done using the PREFETCH facility. IDMSQSAM can be used instead, but because it applies to at most one area at a time, its benefit is limited.
Relative REORG performance
While in many cases REORG will require less time and resources to unload and reload a database than the UNLOAD/RELOAD utilities, this may not always be the case. For certain database structures, REORG will take longer to run and cost more in terms of CPU and I/Os. The best means of determining how REORG performs against a specific database is to do a trial run during a non-critical processing window. This should be done as part of planning a database reorganization.
Generating db-key cross-reference information
The REORG utility optionally creates a set of DBKEYS work files whose records relate the db-key of a record in the source database with its corresponding db-key in the target database. These files are not used by REORG, but can be used by a user-written application or a third-party product for the purpose of cross-referencing the old and new locations of a record. You may need to merge these files together prior to using the information.
For more information about and a description of the records in the DBKEYS files, see DBKEYS File Layout.
Efficiency of the reorganized database
The database resulting from a REORG operation should be as efficient as one reorganized through UNLOAD and RELOAD even though the two may not be identical.
A database processed by RELOAD is loaded back to front. CALC and VIA records that overflow are usually written to pages that have already been loaded and have room. A database processed by REORG is loaded from front to back. CALC and VIA records that overflow are saved in a memory cache so that they do not displace records targeting later pages. If the cache is not large enough, the records are written to an overflow file and loaded in a later step.
The resulting databases should be similar in terms of the number of records that are stored on their intended target page and the number of records that overflow, but the two databases will not be exactly the same.
You can use the IDMSDBAN utility to obtain a report of the number of page changes needed to traverse all occurrences of each CALC and VIA set. By executing this utility before and after reorganization, you can determine the effect that REORG has had on these statistics and therefore the relative efficiency of the resulting database.
Implementing Changes Through REORG
Changing an SQL-defined database
You use REORG on an SQL-defined database to modify the database based on changes made to its segment definition. These changes must be reflected in the target DMCL. The modified DMCL must be available during the entire REORG operation, including the setup and unload phases.
You can make the following changes using REORG:
  • Change area page ranges
  • Change page size
    See EXPAND PAGE for an alternative means of changing a page size.
  • Change the maximum number of records per page
    See CONVERT PAGE for an alternative means of changing the maximum number of records per page.
The names of the source and target segments for a REORG operation on an SQL-defined database must be the same. Consequently, if you are making any of the previous changes, you must specify a target DMCL whose name differs from that of the source DMCL. For more information about the DMCLs used by the REORG utility, see the source/target DMCLs in Initiating a REORG Operation.
You cannot make changes to table definitions in an SQL-defined database between the setup and reload phases of a REORG operation.
Changing a non-SQL-defined database
You use REORG on a non-SQL-defined database to modify the database based on changes made to its schema or segment definitions. These changes must be reflected in the target subschema and DMCL. The modified DMCL and subschema must be available during the entire REORG operation, including the setup and unload phases.
You can make the following changes using REORG:
  • Change area page ranges
  • Change page size
    See EXPAND PAGE for an alternative means of changing a page size.
  • Reassign records to different areas or page ranges
    The record names must match in the source and target subschemas.
  • Change record placements within an area
  • Change record location modes
  • Store VIA records by means of a different set (as long as they already participate in the set)
  • Change compression and INDEX BLOCK CONTAINS options for indexes
  • Change area and page-range assignments for system-owned indexes
  • Change the maximum number of records per page
    See CONVERT PAGE for an alternative means of changing the maximum number of records per page.
  • Add fields to an existing index key provided the fields already exist
  • Remove fields from an index
  • Change an index from unsorted to sorted provided the key fields already exist
    Duplicate key order is random.
  • Change an index from sorted to unsorted
Changes that cannot be implemented using REORG
The REORG utility cannot be used against native VSAM files.
During REORG processing, record formats and set relationships are preserved. This limits the modifications that you can make during a REORG operation. For example, you cannot use a REORG operation to:
  • Remove a set
  • Remove a record type
  • Insert new data fields into a record
  • Remove fields from a record
  • Change the order of a sorted chained set
  • Connect records to new chained or user-owned index sets
  • Change the size, location, or data type of sort or index keys
  • Change a chained set from unordered to ordered
These types of changes require other utilities, such as RESTRUCTURE, and possibly user-written programs.
Initiating a REORG Operation
Specifying setup options
A reorganization is initiated when a REORG statement is executed that specifies
setup-options
. The
setup-options
describe the segment to reorganize and the processing options to use. The first phase of the reorganization is called setup. During this phase, the parameters and the structure of both the source and target databases are analyzed to determine the tasks to perform and the work files that are needed. The result of this analysis is then written to the reorganization control file (RORGCTL). All subsequent reorganization jobs read the control file to determine what to do and how to do it.
Be sure that setup-options are specified only when you intend to initiate a new REORG operation. Their presence causes the RORGCTL file to be overwritten, which results in the failure of any in-progress REORG operation using that control file.
The source/target subschemas
The REORG utility uses information in the dictionary when processing an SQL-defined database. When processing a non-SQL-defined database, the description of the data is contained in the source and target subschemas.
The source subschema describes the data to be unloaded and must:
  • Include the areas being unloaded
  • Include all areas containing records with set connections to records in the areas being unloaded
  • Define all record types in the areas being unloaded
  • Define all sets in which the record types participate
  • Define all record types that can participate in the defined sets
The target subschema describes the data to be reloaded and must:
  • Define the same record names and sets as the source subschema
  • Include the areas into which data is to be reloaded and all areas containing records with set connections to those areas
  • Allow all included areas to be readied in exclusive update mode
The source subschema must be available during the setup and unload phases. The target subschema must be available during the setup, unload, and reload phases.
The source segment and the target database
The source segment, which is the segment named in the SEGMENT clause of the REORG statement, must include all areas being reorganized. If these areas are physically connected to other areas, either:
  • These other areas must be part of the source segment, or
  • These areas must be part of segments that are included in a DBNAME whose name is the same as that of the source segment
The target database, which is the database named in the INTO clause of the REORG statement, must include all areas into which data is to be reloaded as part of the REORG operation. If these areas are in different segments or are physically connected to areas in other segments, the target database must be a DBNAME that includes all of these segments.
For more information about inter-area considerations, see Cross-area dependencies and Cross-segment dependencies in Special Database Considerations.
The source/target DMCLs
The source DMCL must include the source segment and all segments with which the source areas are physically linked. The target DMCL must include the target segments and all segments with which the target areas are physically linked. Both the source and target DMCLs must be available during the setup and unload phases of the REORG operation. The target DMCL must also be available during the reload and cleanup phases.
The source DMCL is the DMCL specified in the SYSIDMS file. If no DMCL is specified in the SYSIDMS file, the DMCL named IDMSDMCL is used.
The target DMCL is the DMCL named in the INTO clause of the REORG statement. If no DMCL is specified in the INTO clause, the source DMCL is used as the target. If the same DMCL is used as both source and target, then either this DMCL must include both the source and target segments or no segment-related changes can be made to the data being reorganized.
Controlling REORG Execution
Specifying a stop point
By default, when a reorganization is initiated, it executes to completion or until a system failure or an unrecoverable error is encountered. However, you can break up execution into major processing phases by specifying a STOP AFTER parameter. You might want to halt processing after setup to examine the generated report to determine how much disk space is needed. Or, you might halt execution after the unload phase to delete the source database files before allocating the target files. Once a stop point has been established, which always occurs during setup, it remains in effect until another REORG statement is executed that specifies a different STOP AFTER value. The specified stop point must be the same as or later than the reorganization phase most recently processed.
Automatic job submission
The REORG utility relies on concurrently executing jobs for its parallel processing. To facilitate this, REORG has the ability to automatically submit jobs through the internal reader. It does this at the end of the setup phase unless STOP AFTER SETUP has been specified. It also does this anytime a REORG statement is executed that specifies SUBMIT. Typically, the SUBMIT keyword is used only when restarting a reorganization and no other jobs are active, such as when execution has been interrupted because a stop point has been reached or an error such as a system failure has caused all jobs to fail. If specified at other times, it may result in more jobs than there is work to perform, therefore needlessly tying up initiators.
JCL for jobs submitted automatically is retrieved from the RORGJCL file. The JCL should have the following characteristics:
  • The prefix of the included job name should be short enough to allow for appending one or more characters to make the job name unique.
  • The JCL should include a step that executes a REORG statement through the batch command facility. No parameters should be specified on the REORG statement.
  • The RORGJCL file should not be included.
  • The JCL should have the same considerations as listed in JCL Considerations.
The JCL or the DMCL(s) being used should either allow simultaneous access to both the source and target files or you must stop execution between the unload and reload phases and may need to change the RORGJCL contents so that instead of referencing the source files, it references the target files. Failure to do this can result in corruption of the source database as REORG may attempt to reload into the source files.
For more information about the JCL needed to execute a REORG statement, see the JCL Considerations.
REORG submits one job for each slice and each index group up to two times the number of slices. If there are two slices and one index group, three jobs are submitted. If there are two slices and three index groups, four jobs are submitted.
Manual job submission
Once a REORG operation has been initiated, you can separately submit as many REORG jobs as you want. Each job examines the control file to determine if there is any work to do on behalf of the reorganization. If no such work exists, perhaps because pre-requisite tasks have not yet completed, the job waits until some other job completes a task before re-examining the control file. If it finds work to do, it begins to perform that work provided no other job claims it first.
While section job submission is possible, automatic submission should normally be used to avoid having either too few or too many jobs active at one time. Manual job submission can be used to resubmit one or more failed jobs.
Restarting REORG
If a REORG job fails, other REORG jobs try to automatically restart the task that failed after they have completed the task they were processing. If the problem was a temporary environment-related problem, and the task successfully completes, nothing additional needs to be done. Although, you may want to submit another REORG job to make up for the one that failed.
If the problem was not temporary, for example, a work file was too small; the remaining REORG jobs also fail when they try to restart the task, and at some point all jobs end. In this case, if the problem can be corrected, REORG can be restarted simply by resubmitting one or more REORG jobs. If the first one specifies the SUBMIT option, it submits the additional jobs.
REORG automatically restarts at the failing task or in some cases on a prior task if that is what is needed to recover from the failure. Depending on the requirements of the failing task, a portion of the database may be automatically formatted, or an index may be deleted as part of the restart process.
Restarting REORG from the beginning
Some problems may be severe enough to require restarting REORG from the beginning, such as if the wrong subschema was specified causing REORG to fail because the data did not match its description. Should it be necessary to restart REORG processing from the beginning, take the following actions:
  • Format the target database if it had been partially loaded
  • Delete any automatically created work files by executing a REORG statement that specifies CLEANUP
  • Restart the REORG operation by executing a REORG statement that specifies
    setup-options
    , corrected if necessary.
Recovering from an out-of-space condition on a work file
You can recover from an out-of-space condition on a work file by taking the following actions:
  • Manually delete the work file and reallocate it with more space
  • Resubmit one or more REORG jobs. If all previously active jobs failed, submit only one job and specify the SUBMIT option to enable the automatic submission of the remainder of the jobs. If some jobs are still active, you can separately submit a job for each one that failed.
REORG serialization in a multi-image environment
Serialization is used to coordinate execution between jobs concurrently executing a REORG operation. These jobs serialize access to various internal resources by using a SYSTEMS ENQ with a QNAME of IDMSUT. In a multi-image environment, the SYSTEMS ENQ allows REORG jobs running on different images to serialize properly. However, if a multi-image manager is used, a SYSTEMS ENQ may be converted to a SYSTEM ENQ, which would only serialize REORG jobs running on the same image. In this environment, either restrict REORG jobs to run on one image or configure the multi-image manager to exempt REORG ENQ requests from being converted.
Special Database Considerations
Reorganizing a dictionary
When reorganizing a dictionary, the source and target subschemas are always the same and are determined by the areas of the dictionary being reorganized.
  • Use the IDMSNWKU subschema for all areas, except DDLCAT, DDLCATX, and DDLCATLOD.
  • Use the IDMSCATZ subschema for the DDLCAT and DDLCATX areas.
  • Use the IDMSCATL subschema for the DDLCATLOD area.
Before reloading the DDLCATLOD area in a segment defined for SQL, you must install stamps either by formatting by area or using the INSTALL STAMPS utility.
REORG an ASF database
If you want to run the REORG utility against an ASF data or definition area, see the
CA IDMS ASF User Section
for more information. The
CA IDMS ASF User Section
refers specifically to the UNLOAD and RELOAD utilities for unloading and reloading an ASF database, but REORG may be substituted for UNLOAD/RELOAD in this case.
Logically deleted records
You must remove any logically deleted records from the areas being unloaded before executing the REORG utility. To determine if an area has logically deleted records, use PRINT SPACE with the FULL option. If logically deleted records exist, use the CLEANUP utility to remove them from the area.
SQL-defined databases and synchronization stamps
Area and table synchronization stamps in SQL-defined segments are unloaded and reloaded by the REORG utility. For this reason, you must format the target areas using the FILE option so that the format operation does not also store synchronization stamps.
The one exception to this is when unloading and reloading the DDLCATLOD area in a segment defined for SQL. In this case, use the AREA option of the FORMAT statement or use the INSTALL STAMPS utility so that the format operation stores synchronization stamps.
Cross area dependencies
Areas that have physical connections to the areas being reorganized are referred to as
dependent areas
. You can reorganize an area that has physical connections to other areas without also unloading and reloading its dependent areas. Physical connections include:
  • Sets that cross area boundaries
  • Indexes that cross area boundaries
  • Linked constraints in which the referenced and referencing tables reside in different areas
The REORG utility keeps track of the inter-area linkages and rebuilds them during the RELOAD phase. For this reason, not only must the target areas be updatable by REORG, but their dependent areas must also be updatable.
Cross segment dependencies
A source area can have physical connections to an area in another segment. To reorganize all related areas, the DBNAME setup option must be used, and it must include all segments with physical connections. When the SEGMENT setup option is used, only areas in the name segment can be reorganized. Areas in connected segments will be processed as dependent areas. Their pointers will be adjusted, but they will not be reorganized. To use the SEGMENT option, the segment named on the setup clause of the REORG statement must also be the name of a DBNAME that includes both the source segment and all segments whose areas are physically connected to the areas being reorganized.
A target area can have physical connections to an area in another segment. To reorganize into such an area, the INTO clause of the REORG statement must identify a DBNAME whose segments include all of the target areas and all of their dependent areas.
Mixed page groups
Mixed page groups are supported. A source DBNAME may include segments with different
page-group
and different maximum
records-per-page
values. A segment may have physical connections to segments with a different
page-group
and/or maximum
records-per-page
value. Cross segment chained sets must have the same
page-group
and maximum
records-per-page
.
Ignoring the order of CALC duplicates
By default, when REORG unloads a CALC record for which duplicates are allowed, it preserves the order of duplicate entries by walking the CALC set in a prior direction and determining the relative position of the record with respect to others with the same CALC key value.
This processing can result in significant overhead. If preserving the order of duplicate entries is not important, you can eliminate this processing by turning on the OPT00093 bit in the RHDCOPTF module.
Processing of DIRECT records
Because DIRECT records have been placed on a specific page by a user, the REORG utility may have difficulty in determining where they should be placed in the target area. If a DIRECT record's old page exists in its target page range, REORG attempts to place the occurrence on the same page. However, if the old page does not exist in the target page range, the record is stored in the target area proportionally to its position in the source area.
If this is not acceptable, you may need to write a user-written program to unload the database and the FASTLOAD utility to reload it.
DCMT VARY PERMANENT considerations
If you run the REORG utility to change an area's low page number and Change Tracking is not used, it is recommended that you remove any permanent status on the affected area before making the new DMCL active within the CV.
When Change Tracking is not used, the PERMANENT feature is implemented by carrying the area's low page number in the journals across cycles of the CV. Changing an area's low-page prohibits future cycles of the CV from properly identifying the area once the new page range is implemented.
If a DCMT VARY SEGMENT/AREA PERMANENT command is still in effect when the new page range is implemented, the area's usage-mode at startup is determined by the value specified in the DMCL. The entry in the journals for the old area's page range remains until the next format of the journals.
The journal entry for the old starting page can be removed without formatting the journal by doing a non-permanent DCMT VARY AREA command against the area prior to changing the DMCL definition in the CV.
Work Files
The REORG process requires many work files. These files can be dynamically created and allocated for you by the REORG utility, or you can separately assume these responsibilities. This section discusses considerations associated with the creation and use of work files.
Work files and the n WAYS parameter
The number of work files required by REORG can grow exponentially as the value in the DIVIDE PROCESSING n WAYS parameter is increased. Therefore, you should exercise care in choosing this parameter.
For example, a REORG that specifies DIVIDE PROCESSING 2 WAYS usually results in 2 unload slices, 2 reload slices, and 4 SYS002 work files. If 3 WAYS were specified, this usually results in 3 unload slices, 3 reload slices, and 9 SYS002 work files. A similar expansion exists for each RELOAD phase.
REBUILD phases use fewer work files, but the number of index work files generated by RELOAD1 increases with the number of reload slices.
Reducing the number of work files
There are two ways to reduce the number of work files needed by the REORG utility other than reducing the n-WAYS parameter. You can direct REORG to:
  • Reuse work files, which allows work files that are no longer needed to be reused for other purposes during later phases of processing
  • Execute as a sort exit, which eliminates the use of sorted output files
It is recommended that both of these options be used to reduce the number of work files, and the amount of disk space needed.
Work file creation
REORG can create work files dynamically or you can separately create them prior to beginning the unload and/or reload phases of REORG execution. Regardless of how the files are created, it is a good idea to halt execution after setup to determine what work files are needed by examining the report produced by REORG.
If using dynamic work file creation, you must specify the attributes of the work files using one or more CREATE DSMODEL statements. REORG creates the files either as directed by the CREATE WORKFILE clause or at the time they are first accessed. Dynamically created work files, other than DBKEYS files, are deleted automatically during the cleanup phase.
If you want to use REORG's size estimates to create a file, code a DSMODEL without a primary SPACE allocation. You can code a SPACE parameter with just a unit type (TRK, CYL, or blksize) and no value for primary allocation.
You must code a primary space allocation value or delay creating work files until estimates are available. This means, for example, that you cannot direct REORG to create RELOAD work files during the setup phase unless the DSMODEL contains a primary allocation value.
If you code a zero primary space allocation value and a non-zero secondary value, the secondary value is replaced by a value derived from the estimated primary value.
For more information, see Considerations for running REORG on VSE.
Work file allocation
REORG can allocate work files dynamically or you can reference them separately by including an appropriate DD statement in the REORG job's JCL and in the JCL included in the RORGJCL file if automatic job submission is used.
If using dynamic work file allocation, you must specify the data set names of the work files using one or more CREATE DSMODEL statements. REORG allocates the files as they are needed. If a DD card for a given work file is included in the execution JCL, it is used, and that file is not dynamically allocated.
If not using dynamic work file allocation, you must include a DD statement for every work file in every REORG job and in the RORGJCL file.
Work file deletion
By default during the cleanup phase, REORG deletes all work files created during the current operation other than DBKEYS files. It deletes only those files for which a matching data set model was specified either at setup or when the file was created. If a matching model is detected, REORG attempts to dynamically allocate the file thereby determining its data set name which may be derived from the model or overridden by a DD statement in the JCL. Regardless of how the data set name is determined, if the file is created during the execution of a REORG statement, it will be deleted during the cleanup phase of the operation unless the file is subsequently overridden with a different data set name in some later job. You can determine which files cleanup will delete by examining the work file summary sections of the REORG Status Report.
Should it be necessary to restart a REORG operation from the beginning, you should first execute a REORG statement that specifies CLEANUP to delete any work files created by the interrupted operation. If you do not do this, none of the work files created during the first operation execution will be deleted by REORG even if they are reused during the second execution.
If REORG is restarted without first cleaning up the old work files, you can still direct REORG to delete them using one of the following methods:
  • You can allow REORG to reuse the old files and then after REORG has ended normally, run a REORG CLEANUP job with the DELETEALL option. This option directs REORG to delete all work files, other than DBKEYS files, whether they were created by the most recent REORG operation or not
  • You can delete the old work files during the setup phase of the restarted run. Specify DELETE OLD WORKFILES during setup and REORG checks for and deletes any files it finds that match the file names it plans to use. This includes DBKEYS files. This approach is preferable when the old files may be too small to be reused.
    For more information, see Considerations for running REORG on VSE.
Using DSMODELs with REORG
Data set models (DSMODELs) are used to specify a set of attributes for data sets. REORG can use DSMODELs to specify the attributes for its work files, thereby eliminating the need for coding DD statements for every work file used by the utility.
The REORG utility checks for the presence of DSMODELs during the setup phase. If they are present, REORG saves the model information in the control file for later use. This saved information is used by subsequent tasks and by other jobs. No additional DSMODEL statements need to be specified in any submitted or subsequent job.
When REORG creates a work file, either because a CREATE WORKFILE clause has been specified or because a file does not exist at the time it is accessed, REORG uses the saved model information unless another CREATE DSMODEL statement has been specified in the same session as the one in which the file is being created. If another CREATE DSMODEL statement has been specified, it overrides the previously saved information. REORG updates the control file with the new information and uses it to create the work file.
To use a data set model's attributes for a given work file, the model's name must match the file's DDNAME according to the rules discussed in the CREATE DSMODEL statement. The REORG utility uses the following DDNAME prefixes:
  • WU -- Unload/Reload work files
  • WI -- Index REBUILD work files
  • WS -- Sort output work files
  • WD -- DBKEYS work files
Each prefix is followed by a generated number. To use a model for a work file, the model name must match the file's DDNAME. If more than one DSMODEL matches that of a work file, the one that most closely matches is used. For information about how to specify model names that match character strings such as a DDNAME, see CREATE DSMODEL.
For the REORG utility to dynamically allocate a work file, its matching model must minimally specify a DSN attribute so that the name of the data set can be determined. Symbolic parameters in the DSN value can be used to generate different names for each work file.
For the REORG utility to create a work file, the DSMODEL must also include information to identify where to create the file, the space to allocate, and a block size to use.
When specifying a DSMODEL for a DBKEYS file, the BLKSIZE must be a multiple of 16. All other work files are variable length. The BLKSIZE for these files must be four bytes larger than the largest work record.
If a block size is not coded or BLKSIZE 0 is coded in the DSMODEL for a REORG file, REORG chooses one based on the device type. If the device type can not be determined, a 3390 will be assumed. Normally, 1/2 track blocking is used for a 3390 device.
Sizing work files
The simplest way to size work files is to let REORG do it for you. REORG automatically estimates the size of all files after making a pass of the database and gathering statistics. This occurs by default when the data is unloaded. While this does not require an extra pass of the data, the estimates that are generated can only be used for allocating RELOAD work files because the UNLOAD files have already been created and used.
To use REORG-generated estimates for allocating UNLOAD work files, use the ESTIMATE WORKFILE SIZES option. This directs REORG to make a preliminary pass of the data without opening or writing to any work files. The generated file estimates are stored in the control file and can be used to allocate both UNLOAD and RELOAD work files when the REORG operation is resumed.
For REORG to more accurately estimate the size of overflow files, it may be necessary to specify an OVERFLOW PERCENT parameter. REORG assumes that 10% of the records to be stored in the database will overflow. If this assumption is not valid for a particular database, you may need to specify a different overflow percent value so that REORG can generate better estimates for the size of overflow files.
While REORG attempts to accurately estimate the size needed for work files, it may not always be able to do so. In certain cases, it may be necessary to separately estimate the size needed for one or more work files.
Estimating the size needed for work files is difficult for two reasons: many classes of files contain different types of records, and the number of records written to each file within a class varies depending on how REORG chooses to divide the page ranges into slices. Consequently, there are no simple formulas that can be used to estimate work file sizes. There are however, some techniques that can be used to facilitate file sizing and allocation.
In planning for a reorganization, do one or more trial runs to determine the actual file sizes needed for a given n-WAY value. This can be done during a non-critical time against a copy of the source database. This is the easiest way to obtain accurate size estimates. If it is impractical to do a trial reorganization on a full copy of the database, do it on a reasonably-sized sample that is representative of the original and then scale up the work file sizes proportionately. Be sure that the sample database is large enough relative to the n-WAY parameter so that the slicing algorithm does not reduce the number of slices due to their small size. Size estimates determined using a sample database will not be as accurate as those determined using a full copy of the database and so should be increased to account for this.
The following is a list of additional techniques that may prove helpful in allocating work files under z/OS:
  • Specify a relatively modest primary allocation and a large secondary allocation. This allows the file to extend to handle large amounts of information without wasting unneeded space.
  • Use IBM's Storage Management Subsystem (SMS) to determine where files are to be allocated rather than trying to separately place files on specific volumes. SMS can automatically spread the files across volumes wherever there is available space. Use the DATACLAS and STORCLAS options to allow files to extend across multiple volumes.
  • If SMS is not available, allow the files to be allocated across multiple volumes by specifying multiple volume serial numbers. There must be enough space across all listed volumes to satisfy the space needs of all of the work files. The order of the entries in the list is not important.
  • Consider using extended format data sets for large work files. Although this adds 32 bytes of overhead to each block, extended format data sets can have more extents across more volumes than a basic format data set.
Under z/VSE it is recommended to not specify a primary space value, and let REORG calculate one. If this value is not large enough, or will not fit on the specified volume, a DLBL and EXTENT for the individual file should be separately coded to override the generated label.
Work file restrictions
You cannot use tape or virtual tape for work files.
For more information about the types of work files used by the REORG utility, see the Classes of work files in REORG Processing Details.
Control File Allocation for Block Size
REORG uses the block size that the control file (RORGCTL) is created with. A RORGCTL file is a fixed length unblocked file that is initialized during setup and read and updated by subsequent and parallel jobs. On z/OS, the default block size is 8192 when the file is allocated without a block size. When specified, the minimum block size supported is 2048. On z/VSE, the block size is 8192.
REORG Processing Details
How the unload phase works
During the unload phase, most record types are unloaded as part of an area sweep. Certain database structures necessitate exceptions to this general processing flow.
  • A record that is stored VIA a System Index in which sequence order cannot be determined from the member record (such as an unsorted index or one in which duplicates are FIRST or LAST), is offloaded by walking its index.
  • Members of a VIA set are unloaded at the time their owner is unloaded by walking the VIA set. If the VIA member in turn owns VIA members, they too are unloaded in a similar fashion.
  • When unloading a CALC record for which duplicates are allowed, the CALC set is walked in the prior direction to determine the relative position of the record with respect to its duplicates.
Records that are unloaded are assigned a target page number during the unload phase. Target page numbers are assigned as follows:
  • CALC records are assigned a target page based on their CALC key and target page range
  • VIA records that are members of their VIA set are assigned a target page based on their owner's assigned or target page. If a VIA record is in the same target page range as its owner, it is assigned the same target page plus any VIA displacement. If in a different page range, it is assigned a target page in its range proportional to its owner's page in its assigned or target page range plus any VIA displacement.
  • VIA records that are not members of their VIA set are assigned a target page that is proportional to their position in their source page range.
  • DIRECT records are assigned a target page that is the same as their source page if the page is in both the source and target page ranges; otherwise, DIRECT records are assigned a target page that is proportional to their position in their source page range.
REORG slicing
A database is divided into slices based upon the value coded in the DIVIDE PROCESSING n WAYS parameter. Generally, each area is divided symmetrically, but if an area contains a subarea and no outside records span that subarea, REORG divides the subarea independently of the rest of the area.
If dividing an area or subarea produces a piece that is too small, smaller than 100 pages, that area or subarea is divided again into fewer, but larger pieces. If an area or subarea is less than 200 pages, it is not divided at all.
After all areas and subareas have been divided into pieces, each piece is assigned to a slice. Each slice typically ends up with approximately the same number of pages.
Usually, the number of slices equals the n-WAYS value, but if the total number of pages being processed is small, there may be fewer slices. If the total size of all areas is less than 200 pages, all pages are assigned to one slice, regardless of the n-WAYS value.
Dependent areas are areas with physical linkages to the areas being processed. They are also divided and assigned to slices.
Areas and subareas that contain only system indexes are not divided and are not assigned to a slice.
The source and target database are sliced independently of one another and consequently may not be divided into the same number of slices.
Index groups
A user-owned index occurrence is processed with the slice to which its owner record is assigned. System-owned indexes are assigned to groups and processed independently of slices. System indexes that have the same or overlapping target page ranges are assigned to the same group; otherwise, they are assigned to different groups. If an index has a distinct (non-overlapping) target page range, it is assigned its own index group. Index groups are processed independently of each other and therefore can be processed in parallel. Once assigned to a group, an index is in that group for the duration of REORG processing.
REORG tasks and phases
REORG processing is divided into tasks and grouped into phases. Each phase processes a type of work needed to unload or reload a database or rebuild an index. Each task processes a slice or index group within a phase.
For example, if a database were divided into two unload slices and had three index groups, the unload phase could have up to five tasks: one for each slice and possibly one for each index group. All unload tasks must successfully complete before REORG can begin to process tasks in the RELOAD or REBUILD phases.
RELOAD contains six phases numbered 1 through 6. These phases reload slices, rebuild user indexes, and reconnect pointers. Each reload task in a given phase must successfully complete before processing can move to the next RELOAD phase.
REBUILD can contain up to three phases numbered 1 through 3. Each index group has one task per phase, but each index group can run independently of the others and independently of RELOAD phases 3 through 5.
If a system index related page range conflict exists between tasks in RELOAD and REBUILD, or between REBUILD tasks, updates of the page range are serialized.
The phases are:
Phase
Description
SETUP
Analyzes syntax, subschemas, and DMCLs to initialize the REORG process. It decides how to divide the source and target databases for parallel processing. It creates tasks and decides what work files are needed to support those tasks. It builds the RORGCTL file.
UNLOAD
Consists of Unload Slice and Unload Index tasks.
Slices are offloaded through area sweeps and by walking VIA sets.
If an index needs its sequence preserved, the index is walked to determine the relative sequence number of each member. The sequence data is merged with information extracted from the loaded record in REBUILD2.
If VIA System Indexes exist and their sequence needs to be preserved, the member records are offloaded by walking the index.
VIA members are offloaded when their owners are offloaded regardless of how the owners are offloaded.
REBUILD1
This phase exists only when there is a VIA SYSTEM INDEX that spans multiple reload slices. If needed, it runs prior to RELOAD1. It sorts VIA INDEX member records into index order and assigns the records to target slices.
RELOAD1
Loads data into the target database.
Set connection and index key data is generated and processed by later phases.
If a task in this phase fails, when restarted, it formats only the page ranges assigned to its slice and restarts processing from the beginning.
RELOAD2
This is an overflow phase. If a reload slice fills up, the data is saved and processed by this phase. There is only one task in this phase, and it updates across slices.
It generates the same set connection and index key data as RELOAD1 for records it stores.
If an area fills up during this phase, processing stops.
If the task in this phase fails, when restarted, REORG starts over by reprocessing all RELOAD1 tasks. Each formats its slice and restarts.
RELOAD3
Merges user-owned index data generated by UNLOAD, RELOAD1, and RELOAD2. Member keys and/or sequence numbers are merged in owner sequence and generated records are passed to RELOAD4.
RELOAD4
Merges data produced by RELOAD1 and RELOAD2 about old and new db-keys for chained sets and passes it to RELOAD6.
If data is passed from RELOAD3, it rebuilds user indexes using that data. INDEX and OWNER pointer data is generated and passed to RELOAD6.
If a task in this phase fails, when restarted, it reprocesses data from the beginning. It erases and rebuilds all user index occurrences in its slice.
If a target slice fills before all data is processed, unconnected data is passed to RELOAD5.
Tasks in this phase serialize on system index related page ranges.
RELOAD5
This is an overflow phase for RELOAD4. Data that would not fit into a slice is processed here. There is only one task in this phase, and it updates pages across all slices.
If an area fills up during this phase, processing stops.
Index key connection begins with the key that failed in RELOAD4.
If the task in this phase fails, when restarted, REORG reprocesses all tasks in RELOAD4. User indexes that were already built are rebuilt.
Tasks in this phase serialize on system index related page ranges.
RELOAD6
Updates prefix pointers using data generated by RELOAD phases 4 and 5; and REBUILD phase 3.
RELOAD7
Updates prefix pointers using data generated by RELOAD phases 4 and 5; and REBUILD phase 3.
This phase processes those records that were relocated out of their target slice and could not be processed during a RELOAD6 phase. There is only RELOAD7 phase which processes across slice boundaries.
REBUILD2
This phase merges sequence data from an UNLOAD INDEX task with member data from RELOAD1 and RELOAD2.
It is only generated for groups that have indexes for which sequence must be preserved.
It can run in parallel with all REBUILD phases 2 through 4 for other index groups and in parallel with RELOAD phases 3 through 6.
REBUILD3
This phase uses member data from RELOAD1, RELOAD2, and REBUILD2 to rebuild system indexes.
Tasks in one group can run in parallel with reload tasks and index tasks from other groups as long as there are no page range conflicts.
Tasks in this phase serialize on system index related page ranges.
CLEANUP
There are no tasks in this phase. When all other processing has successfully completed, this phase optionally unlocks the reload areas and deletes work files created by the REORG utility.
Classes of work files
Each phase of REORG processing can produce different classes of work files. A task can produce one or more occurrences of a given class of work file. Each work file is read by a task in a later phase along with similar work files from other tasks.
The following table describes each class of work file. When discussing how many work files are generated, sometimes a task's phase name is referenced and sometimes the number of reload or unload slices is referenced. For each unload slice, there is one UNLOAD SLICE task and one RELOAD3 task. For each reload slice, there is one RELOAD1, RELOAD4, and RELOAD6 task. The number of reload slices is the same as the number of RELOAD1 tasks. Sometimes these terms are interchanged when it is thought to clarify a description.
The classes of work files are:
Work File Classes
Description
SYS002
Contains offloaded record and set information.
Output: UNLOAD SLICE and UNLOAD INDEX
Input: RELOAD1
One is created for each unload slice times the number of reload slices.
One is created for each index group that contains a VIA system index where all members target one reload slice.
SYSX02
Contains offloaded record and set information for members of a VIA index.
Output: UNLOAD SLICE and UNLOAD INDEX
Input: REBUILD1
One is created for each unload slice times the number of index groups that contain VIA system indexes that target multiple reload slices.
One is created for each index group that contains VIA system indexes that target multiple reload slices
SYSIX2
Contains sorted record and set information for members of a VIA index.
Output: REBUILD1
Input: RELOAD1
One is created for each index group that contains VIA system indexes that target multiple reload slices times the number of reload slices.
SYSOF2
Contains record and set information for records that overflowed their target slices.
Output: RELOAD1
Input: RELOAD2
One is created for each reload slice or RELOAD1 task.
SYS003
Contains offloaded index sequence information for user indexes.
Output: UNLOAD SLICE
Input: RELOAD3
One is created for each unload slice.
SYSX03
Contains offloaded index sequence information for system indexes.
Output: UNLOAD INDEX
Input: REBUILD2
One is created for each index group that contains system indexes that are not VIA and where member sequence is not being preserved.
SYS004
Work file containing sorted record and set information.
Not created when SORTEXIT is specified.
One is created for each RELOAD1 and RELOAD2 task.
SYS005
Contains old and new db-key values for chained sets.
Output: RELOAD1 and RELOAD2
Input: RELOAD4
One is created for each (RELOAD1 and RELOAD2 task) times the number of RELOAD4 tasks.
SYS006
Contains user index owner and member db-key and symbolic key information.
Output: RELOAD1 and RELOAD2
Input: RELOAD3
One is created for each reload slice times the number of unload slices.
SYSX06
Contains system index member db-key and symbolic key information.
Output: RELOAD1 and RELOAD6
Input: REBUILD2
One is created for each reload slice times the number of index groups that contained a non-VIA system index where sequence was being preserved.
SYS007
Work file containing sorted user index owner and member work record information.
Not created when SORTEXIT is specified.
One is created for each RELOAD3 task.
SYSX07
Work file containing sorted user index owner and member work record information.
Not created when SORTEXIT is specified.
One is created for each REBUILD2 task.
SYS008
Contains user index information that is used to rebuild indexes.
Output: RELOAD3
Input: RELOAD4
One is created for each unload slice times the number of reload slices.
SYSX08
Contains system index information that is used to rebuild indexes.
Output: RELOAD1, RELOAD2, and REBUILD2
Input: REBUILD3
One is created for each REBUILD2 task that is generated. Also, one is created for each index group (that contains a VIA system index or a non-VIA system index where sequence was not being preserved) times the number of RELOAD1 and RELOAD2 tasks.
SYS009
Work file containing sorted user index work records and sorted old/new db-keys for chained sets.
Not created when SORTEXIT is specified.
One is created for each RELOAD4 and RELOAD5 task.
SYSX09
Work file containing sorted system index work records.
Not created when SORTEXIT is specified.
One is created for each REBUILD3 task.
SYS010
Contains new db-key information for updating record prefixes.
Output: RELOAD4, RELOAD5, and REBUILD3.
Input: RELOAD6
One is created for each (RELOAD4 and RELOAD5) task times the number of RELOAD6 tasks, and one is created for each index group (that contains indexes where the member contains UP or OWNER pointers) times the number of RELOAD6 tasks.
SYS011
Work file containing sorted prefix pointer information for all records.
Not created when SORTEXIT is specified.
One is created for each RELOAD6 task.
SYSOFA
Contains new db-key information for updating record prefixes
Output: RELOAD6
Input: RELOAD7
One is created for each RELOAD6 task.
DBKEYS
A file created when the DBKEYS option is specified.
Output: RELOAD1 and RELOAD2
One is created for each RELOAD1 and RELOAD2 task. All should be concatenated together when processed.
Considerations for Running REORG on VSE
Work File Creation and Deletion
REORG on VSE does not support creating and deleting work files. It will create and delete user labels, but the work files will not be created, a VTOC entry will not be created, until the file is opened for output. When REORG processing is complete, work files must be separately deleted, or overwritten to reclaim the space. The options: DELETE OLD WORKFILES, CREATE WORKFILES, and DELETEALL,only apply to user labels for the current job. Automatic deletion of work files during the CLEANUP phase will only delete user labels.
CA DYNAM/D is required to create labels
The extent of a generated label will have a relative starting track of 1 for the number of tracks based onthe primary space values. These labels require CA DYNAM/D to convert them to an actual track address at open time.
If CA DYNAM/D is not installed, labels for work files must be coded separately. The recommended procedure in this case, is to use the ESTIMATE FILE SIZES option, which does not use any work files. Code the JCL statements based on the reported file sizes; and include them in all REORG jobs.
SYSIDMS
REORG requires the RORGCTL and RORGJCL files to be defined in SYSIDMS using FILENAME= parameters:
FILENAME=RORGCTL RECFM=F BLKSIZE=8192 FILENAME=RORGJCL RECFM=F BLKSIZE=NNNN LRECL=80 DLBLMOD=ON
Where NNNN is the block size of the JCL file and must be a multiple of 80.
The SYSIDMS DLBLMOD=ON option must be specified to allow for sequential and random processing of the RORGCTL file. Either a DA or SD label m may be used for RORGCTL.
DSMODEL
The only options which apply to z/VSE are: DSN; BLKSIZE; the allocation unit value and primary value for the SPACE option; and the first volume of the VOLSER Option. The rest can be coded, but is ignored.
REORG generates labels using track sizes. If CYL is coded for a space allocation unit, the primary value is converted to tracks, but there is no cylinder alignment. If a block size is coded for an allocation unit, the coded value is used to calculate the number of tracks required.The coded value must match the BLKSIZE value, otherwise the calculated number of tracks may not be accurate.
An example of a DSMODEL follows; note that the primary space value was not coded. This allows REORG to generate the value for each file, using file size estimates. If a primary space value had been coded, this value would be used for all files regardless of the estimated size.
CREATE DSMODEL W* DSN 'USERID.EMPDB.WORKFILE.&DD'. BLKSIZE 4096 SPACE TRK VOLSER IDMS05 ;
RORGJCL
JCL submitted by REORG is read from the RORGJCL file. This must be a sequential file built on disk and contain all the JECL and JCL statements for the submitted job. However the JECL and some JCL statements cannot be directly copied to this file using normal JCL because POWER will try to interpret these statements when the copy job is run. These statements must be hidden from power by changing the first characters as follows:
  • * $$ statements must be coded as $ $$ statements
  • // JOB statements must be coded as #/ JOB statements
  • /* coded as #*
  • /& coded as #&
  • Any statement starting with a "/" may be coded as starting with a "#"
This is the same method used by the IESINSRT program to hide JCL, which is documented in the
z/VSE Administration Section
.
The JCL will get stored on disk in the format it is coded. REORG will convert the hiding characters back to their correct values prior to submitting the job to POWER. For example the JCL to copy a job to the RORGJCL file can look like this:
// DLBL RORGJCL,'USERID.EMPDB.RORGJCL',1,SD // EXTENT SYS020,CULLD9,,,1,5 // ASSGN SYS020,DISK,VOL=CULLD9,SHR // EXEC IDCAMS,SIZE=386K REPRO INFILE(SYSIPT) - OUTFILE(RORGJCL ENV( BLKSZ(4080) RECFM(FB) RECSZ(80) ) ) $ $$ JOB JNM=RORGJOB,CLASS=B,DISP=D $ $$ LST CLASS=R,DEST=(,USERID),JSEP=0 $ $$ PUN CLASS=R,DEST=(,USERID) #/ JOB RORGJOB * JCL THAT REORG SUBMITS #/ DLBL SYSIDMS,'#SYSIPT' #/ EXEC IDMSBCF,SIZE=256K ECHO=ON JOURNAL=OFF DLBLMOD=ON DMCL=IDMSDMCL DBNAME=EMPDEMO FILENAME=RORGCTL RECFM=F BLKSIZE=8192 #* REORG; #* #& $ $$ EOJ /* EOF for REPRO
The statements starting with $ $$ JOB and ending with $ $$ EOJ are copied to RORGJCL and are submitted by REORG.
JCL Considerations
The REORG command must be submitted through the batch command facility. The JCL to execute the facility must include statements to define:
  • The standard BCF JCL statements.
  • A RORGCTL file. A fixed length unblocked file that is initialized during setup and read and updated by subsequent and parallel jobs. On z/OS, the default block size is 8192 when the file is allocated without a block size. When specified, the minimum block size supported is 2048. On z/VSE the block size is 8192.
  • An optional RORGJCL file that references a card-image file containing JCL that is automatically submitted by REORG. This file must be fixed or fixed blocked with an LRECL of 80.
  • The files containing the source areas and their dependent areas for the unload phase if dynamic database allocation is not being used to reference them through the source DMCL.
  • The files containing the target areas for the RELOAD and REBUILD phases if dynamic database allocation is not being used to reference them through the target DMCL.
  • The journal file(s), which can be dummied.
  • The work files if dynamic work file allocation is not being used to reference them.
If performing parallel processing, do not specify any syntax that would cause the jobs to serialize.
  • Do not specify DISP=OLD or DISP=NEW for database or work files. Specify DISP=SHR instead. If a file is new and must be created, create it prior to submitting any REORG jobs.
  • DISP=OLD or DISP=NEW is acceptable for a file that is unique to a job. For example SYSLST, SYSOUT, or SYSJRNL are unique to a job. Sort files such as SORTWK01 and SORTMSG are also unique to a given job.
If you define the same DDNAMEs for the source and target database files, the database cannot be unloaded and reloaded in the same job. You must halt processing after the unload phase and then restart processing ensuring that the target files and not the source files are being referenced. Follow these general steps:
  • Submit JCL for the unload phase. The source database files must be referenced in the REORG JCL and in JCL submitted from RORGJCL, unless using dynamic database file allocation.
  • Use the STOP AFTER UNLOAD option to halt the REORG process after the unload phase.
  • After all unload jobs have ended and the unload phase has completed, format the target database files if they have not already been formatted.
  • Submit JCL for the reload phases. The submitted job and JCL submitted from RORGCTL must reference the target database files, unless using dynamic database file allocation.
  • The submitted job must say STOP AFTER CLEANUP or STOP AFTER RELOAD to allow tasks in the reload phases to run.
Work files can be manually or dynamically allocated. Considering the number of work files needed, the use of dynamic work file allocation is recommended. A CREATE DSMODEL must be coded in the SETUP job, or in the job that allocates the files to use dynamic allocation.
When using CREATE DSMODEL statements, it is recommended that you force the batch command facility to terminate if an error is encountered. You do this by specifying a SET OPTIONS statement with the ON ERROR END clause. By forcing a termination, it ensures that REORG will not execute with incomplete data set models due to an error in a CREATE DSMODEL statement.
When manually allocating work files, you should run a preliminary REORG with the STOP AFTER SETUP option. This produces a report of all required work files. You must allocate these files prior to restarting the REORG process and include the necessary DD statements with DISP=SHR in the JCL that is submitted to restart processing and in the JCL in the RORGJCL file.
The RORGCTL file should be created prior to submitting the first REORG job, unless STOP AFTER SETUP is specified. REORG jobs running in parallel must specify DISP=SHR on this file, or they will serialize with each other on the DSNAME. If processing is stopped after SETUP, the SETUP job can create the file, but subsequent jobs must specify DISP=SHR.
For more information about the generic JCL used to execute the batch command facility, see the section for your operating system in this section.
Examples
Example 1
The following example reorganizes the EMPDEMO database. To speed execution, the data is divided into three slices that can be processed in parallel. All work files are dynamically allocated because data set model information is present. Because no STOP AFTER parameter is specified, the reorganization runs to completion.
Create dsmodel w* … Reorg segment empdemo using empss01 reload into empdemo dmcl newdmcl divide processing 3 ways reuse workfile;
Example 2
The following example separates the setup phase from the later phases. After executing setup multiple times, database reorganization is begun using the second REORG statement. Again, work files are allocated dynamically. The SUBMIT directive submits multiple jobs to to process the work in parallel.
Create dsmodel w* … Reorg segment empdemo using empss01 reload into empdemo dmcl newdmcl divide processing 3 ways reuse workfiles stop after setup; Reorg submit stop after cleanup;
Example 3
The following example restarts a reorganization that was interrupted by a system failure. It too submits multiple jobs to process the work.
Reorg submit;
Example 4
The following example shows an extra DSMODEL being specified for a DBKEYS file. The DBKEYS file DDNAME starts with WD so it matches on the WD* DSMODEL. The SPACE and BLKSIZE attributes are taken from this model and remaining attributes are taken from the W* DSMODEL because of the FROM syntax. The remaining REORG work files match on the W* DSMODEL and take attributes directly from it.
CREATE DSMODEL W* DSN 'IDMS.REORG.WORKFILE.&DD'. UNIT SYSDA SPACE TRK(5,5) BLKSIZE 12004 ; CREATE DSMODEL WD* FROM W* SPACE TRK(2,2) BLKSIZE 16000 ; REORG SEGMENT REOGSMAL USING REOGSUB RELOAD INTO REOGSMAL DIVIDE PROCESSING 4 WAYS STOP AFTER UNLOAD CREATE ALL WORKFILES GENERATE DBKEYS NOTIFY 10 ;
Example 5
The following example shows the syntax required for a job submitted through RORGJCL. DSMODEL and other options are not coded because they are taken from the control file and are not needed by this job. A job with this syntax can also be submitted separately, and it also uses existing options from the control file and looks for tasks to process.
REORG;
Sample Output
When a REORG job completes, it prints a status report of the current REORG process. This report can also be produced using the REORG STATUS REPORT ONLY option. The report is made up of several sections, which contains an analysis of the current REORG operation and a status of the REORG tasks.
REORG Status Report - Section 1
The first section of the REORG Status Report identifies an overall status of the REORG operation.
****************************************************************************** * * * REORG Status Report * * Identifying time stamp: 2005-11-17-13.44.06.388141 * * Unload subschema=EMPTSS01 Unload segment=EMPDEMO Unload DMCL=EMPTDMCL * * Reload subschema=EMPTSS01 Reload segment=EMPBDEMO Reload DMCL=EMPBDMCL * * * ****************************************************************************** Options in effect ----------------- Divide processing 3 ways Notify interval=1 Job submission=YES SHARE=YES STOP AFTER CLEANUP CREATE ALL WORKFILES reuse workfiles=NO SORTEXIT=NO Overflow Percentage=10 Concurrent jobs=5 GENERATE DBKEYS FILES=YES Current status -------------- SETUP=completed UNLOAD=completed RELOAD=completed CLEANUP=completed total tasks=23 tasks completed=23 reload areas are not locked
REORG Status Report - Section 2
The next section identifies all the records and sets being processed by the REORG operation. The sequence numbers are assigned by REORG and are used to identify RECORDS and SETS in REORG work files. They have no relation to record or index IDs that are assigned to database records.
System indexes are assigned to groups. All indexes in the same group are offloaded and rebuilt together. Indexes are assigned to the same group when they share a common page range.
Records and Sets ---------------- Set=EMP-NAME-NDX Sequence=1 Index group=1 Set=JOB-TITLE-NDX Sequence=2 Index group=2 Set=SKILL-NAME-NDX Sequence=3 Index group=2 Set=COVERAGE-CLAIMS Sequence=4 Set=DEPT-EMPLOYEE Sequence=5 Set=EMP-COVERAGE Sequence=6 Set=EMP-EXPERTISE Sequence=7 Set=EMP-EMPOSITION Sequence=8 Set=MANAGES Sequence=9 Set=REPORTS-TO Sequence=10 Set=JOB-EMPOSITION Sequence=11 Set=OFFICE-EMPLOYEE Sequence=12 Set=SKILL-EXPERTISE Sequence=13 Record=COVERAGE Sequence=1 Record=DENTAL-CLAIM Sequence=2 Record=DEPARTMENT Sequence=3 Record=EMPLOYEE Sequence=4 Record=EMPOSITION Sequence=5 Record=EXPERTISE Sequence=6 Record=HOSPITAL-CLAIM Sequence=7 Record=INSURANCE-PLAN Sequence=8 Record=JOB Sequence=9 Record=NON-HOSP-CLAIM Sequence=10 Record=OFFICE Sequence=11 Record=SKILL Sequence=12 Record=STRUCTURE Sequence=13
REORG Status Report - Section 3
The next section of the report identifies unique page ranges within the source and target databases. All records in the same page range share one or more pages and do not overlap with records outside the page range. These ranges are used by REORG setup to determine how to slice up a database.
Page ranges that contain only indexes are also identified.
Areas and Slices ---------------- Unload area=EMPDEMO.EMP-DEMO-REGION low page=175001 high page=175400 Records only area subrange low page=175021 high page=175400 Index only area subrange low page=175002 high page=175017 Unload area=EMPDEMO.INS-DEMO-REGION low page=175401 high page=175600 Records only area subrange low page=175421 high page=175600 Records only area subrange low page=175402 high page=175419 Unload area=EMPDEMO.ORG-DEMO-REGION low page=175601 high page=175800 Records only area subrange low page=175621 high page=175800 Index only area subrange low page=175602 high page=175619 Reload area=EMPBDEMO.EMP-DEMO-REGION low page=275001 high page=275800 Records only area subrange low page=275041 high page=275800 Index only area subrange low page=275002 high page=275033 Reload area=EMPBDEMO.INS-DEMO-REGION low page=276001 high page=276400 Records only area subrange low page=276041 high page=276400 Records only area subrange low page=276002 high page=276037 Reload area=EMPBDEMO.ORG-DEMO-REGION low page=277001 high page=277400 Records only area subrange low page=277041 high page=277400 Index only area subrange low page=277002 high page=277037 Index only area subrange low page=277002 high page=277037
REORG Status Report - Section 4
The next section reports the portions of each page range assigned to each slice.
Unload slice=1 Unload slice range low page=175021 high page=175147 Unload slice range low page=175421 high page=175520 Unload slice range low page=175402 high page=175419 Unload slice range low page=175621 high page=175720 Unload slice=2 Unload slice range low page=175148 high page=175274 Unload slice range low page=175521 high page=175600 Unload slice range low page=175721 high page=175800 Unload slice=3 Unload slice range low page=175275 high page=175400 Reload slice=1 Reload slice range low page=275041 high page=275294 Reload slice range low page=276281 high page=276400 Reload slice range low page=277161 high page=277280 Reload slice=2 Reload slice range low page=275295 high page=275547 Reload slice range low page=276041 high page=276160 Reload slice range low page=276002 high page=276037 Reload slice range low page=277281 high page=277400 Reload slice=3 Reload slice range low page=275548 high page=275800 Reload slice range low page=276161 high page=276280 Reload slice range low page=277041 high page=277160
REORG Status Report - Section 5
The next section describes the status of each task and the work files assigned to the task. The data set name is displayed only if dynamic work file allocation is used.
Tasks and Work File Usage ------------------------- Task#=1 Task=UNLOAD type=S slice=1 status=completed SYS002 O/P DDNAME=WU00001 DSN=USERA01.EMPDEMO.WORKFILE.WU00001 SYS002 O/P DDNAME=WU00002 DSN=USERA01.EMPDEMO.WORKFILE.WU00002 SYS002 O/P DDNAME=WU00003 DSN=USERA01.EMPDEMO.WORKFILE.WU00003 SYS003 O/P DDNAME=WU00010 DSN=USERA01.EMPDEMO.WORKFILE.WU00010 Task#=2 Task=UNLOAD type=S slice=2 status=completed SYS002 O/P DDNAME=WU00004 DSN=USERA01.EMPDEMO.WORKFILE.WU00004 SYS002 O/P DDNAME=WU00005 DSN=USERA01.EMPDEMO.WORKFILE.WU00005 SYS002 O/P DDNAME=WU00006 DSN=USERA01.EMPDEMO.WORKFILE.WU00006 SYS003 O/P DDNAME=WU00011 DSN=USERA01.EMPDEMO.WORKFILE.WU00011 Task#=3 Task=UNLOAD type=S slice=3 status=completed SYS002 O/P DDNAME=WU00007 DSN=USERA01.EMPDEMO.WORKFILE.WU00007 SYS002 O/P DDNAME=WU00008 DSN=USERA01.EMPDEMO.WORKFILE.WU00008 SYS002 O/P DDNAME=WU00009 DSN=USERA01.EMPDEMO.WORKFILE.WU00009 SYS003 O/P DDNAME=WU00012 DSN=USERA01.EMPDEMO.WORKFILE.WU00012
REORG Status Report - Section 6
The next section shows the work file summary. This example shows the general-purpose files used during the unload and reload phases. Other sections show index files, sorted data files, and DBKEYS files.
All work file summary reports show the estimated size of each file and the attributes used in determining those sizes. BPT is Blocks Per Track; TPC is Tracks Per Cylinder; and *3390* indicates that attributes were based on a generic 3390 device, as opposed to a specific volume.
An asterisk (*) following a DDNAME indicates that the file was created by a REORG job executing as part of the current operation and therefore will be deleted automatically during cleanup.
Unload/Reload work file summary ------------------------------- DDname DSN Estimated Size ------ --- -------------- WU00001 * USERA01.EMPDEMO.WORKFILE.WU00001 1 Trk Estimate based on: VOLSER=*3390* BLKSIZE=27998 BPT=02 TPC=15 UNIT=SYSDA SPACE=Trk PRI=1 SEC=1 WU00002 * USERA01.EMPDEMO.WORKFILE.WU00002 1 Trk Estimate based on: VOLSER=*3390* BLKSIZE=27998 BPT=02 TPC=15 UNIT=SYSDA SPACE=Trk PRI=1 SEC=1 &vellip. WU00039 * USERA01.EMPDEMO.WORKFILE.WU00039 1 Trk Estimate based on: VOLSER=*3390* BLKSIZE=27998 BPT=02 TPC=15 UNIT=SYSDA SPACE=Trk PRI=1 SEC=1 Total primary space: 0 Cyl 39 Trk 0 Blk
REORG Status Report - Section 7
The next section is a recap of tasks that have completed in task order. It shows when the task was started, when it was completed, and the job that processed the task.
****************************************************************************** * * * Recap of TASK activity * * * ****************************************************************************** Task#=1 Task=UNLOAD type=S slice=1 status=completed jobname=USERA01Y jobid=JOB01048 UT019000 Task 1 UNLOAD slice 1 starting at 2005-11-17-13.44.35.255392 UT019003 Task 1 UNLOAD slice 1 completed at 2005-11-17-13.44.35.884474 Task#=2 Task=UNLOAD type=S slice=2 status=completed jobname=USERAXXA jobid=JOB05591 UT019000 Task 2 UNLOAD slice 2 starting at 2005-11-17-13.44.35.752587 UT019003 Task 2 UNLOAD slice 2 completed at 2005-11-17-13.44.36.077111
REORG Status Report - Section 8
The next section shows the tasks processed by each job in job name sequence.
****************************************************************************** * * * Recap of JOB activity * * * ****************************************************************************** jobname=USERA01Y jobid=JOB01048 UT019000 Task 1 UNLOAD slice 1 starting at 2005-11-17-13.44.35.255392 UT019003 Task 1 UNLOAD slice 1 completed at 2005-11-17-13.44.35.884474 jobname=USERAXXA jobid=JOB05591 UT019000 Task 2 UNLOAD slice 2 starting at 2005-11-17-13.44.35.752587 UT019003 Task 2 UNLOAD slice 2 completed at 2005-11-17-13.44.36.077111 jobname=USERAXXB jobid=JOB05592 UT019000 Task 3 UNLOAD slice 3 starting at 2005-11-17-13.44.35.826364 UT019003 Task 3 UNLOAD slice 3 completed at 2005-11-17-13.44.36.103013
REORG Status Report - Section 9
The last section shows task activity in chronological order. When completed, it shows the elapsed time from when REORG was started to when it completed.
****************************************************************************** * * * Recap of activity by time of day * * * ****************************************************************************** USERA01Y JOB01048 UT019000 Task 1 UNLOAD slice 1 starting at 2005-11-17-13.44.35.255392 USERAXXA JOB05591 UT019000 Task 2 UNLOAD slice 2 starting at 2005-11-17-13.44.35.752587 USERAXXB JOB05592 UT019000 Task 3 UNLOAD slice 3 starting at 2005-11-17-13.44.35.826364 USERAXXC JOB05593 UT019002 Task 4 UNLOAD index group 1 starting at 2005-11-17-13.44.35.866943 USERA01Y JOB01048 UT019003 Task 1 UNLOAD slice 1 completed at 2005-11-17-13.44.35.884474 USERAXXC JOB05593 UT019005 Task 4 UNLOAD index group 1 completed at 2005-11-17-13.44.35.985660 USERAXXA JOB05591 UT019003 Task 2 UNLOAD slice 2 completed at 2005-11-17-13.44.36.077111 USERAXXB JOB05592 UT019003 Task 3 UNLOAD slice 3 completed at 2005-11-17-13.44.36.103013 USERA01Z JOB01069 UT019000 Task 5 RELOAD1 slice 1 starting at 2005-11-17-13.46.56.274321 USERA01Z JOB01069 UT019003 Task 5 RELOAD1 slice 1 completed at 2005-11-17-13.46.57.381739 . . . USERAXXA JOB05622 UT019005 Task 22 REBUILD4 index group 1 completed at 2005-11-17-13.47.21.060599 USERA01Z JOB01069 UT019005 Task 23 REBUILD4 index group 2 completed at 2005-11-17-13.47.21.228884 USERA01Z JOB01069 UT019014 All REORG phases have been completed at 2005-11-17-13.47.48.448372 USERA01Z JOB01069 UT019015 REORG elapsed time: 0 days 0 hours 3 minutes 42 seconds
RELOAD Statistics Report - Section 1
The following example shows standard database statistics as returned from an ACCEPT DATABASE STATISTICS command. The values reflect the processing done by the current RELOAD1 or RELOAD2 task.
UT005002 DATABASE LOAD STATISTICS DATABASE LOADED ON 01/15/08 AT 21:24:53 PAGES READ ................... 62 PAGES WRITTEN ................ 59 PAGES REQUESTED .............. 86 CALC RCDS IN TARGET PAGE ..... 268 CALC RCDS OVERFLOWED ......... 0 VIA RCDS IN TARGET PAGE ...... 3,869 VIA RCDS OVERFLOWED .......... 0 LINES REQUESTED BY IDMS ...... 1,742 RCDS MADE CURRENT OF R/U ..... 4,137 CALLS TO IDMS ................ 4,144 FRAGMENTS STORED ............. 0 RECORDS RELOCATED ............ 0
RELOAD Statistics Report - Section 2
The following example shows additional statistics produced by REORG when reloading a database. The values reflect the processing done by the current RELOAD1 or RELOAD2 task.
RELOAD STATS RCDS READ .................... 4,380 RCDS STORED IN DATABASE ...... 4,137 RCDS STORED ON TARGET PAGE ... 3,998 RCDS STORED TARGET PERCENT ... 96 RCDS WRITTEN TO OVERFLOW ..... 243 RCDS CACHED .................. 357 RCDS STORED FROM CACHE ....... 139 RCDS OVERFLOW FROM CACHE ..... 218 CACHE STORAGE USED ........... 16,384 CACHE STORAGE LIMIT .......... 16,384
The fields reported are the following:
  • RCDS READ
    The total database records read from a work file. This does not include pointer and other work records
  • RCDS STORED IN DATABASE
    The number of database records stored in the database.
  • RCDS STORED ON TARGET PAGE
    The number of database records stored on the intended target page.
  • RCDS STORED TARGET PERCENT
    The percentage of database records stored on their target page.
  • RCDS WRITTEN TO OVERFLOW
    The number of database records written to a SYSOF2 file, to be processed by the RELOAD2 overflow task.
  • RCDS CACHED
    The number of database records written to the memory cache.
  • RCDS STORED FROM CACHE
    The number of database records that were written to memory cache and then stored in the database.
  • RCDS OVERFLOW FROM CACHE
    The number of database records that were written to memory cache and then written to the overflow work file.
  • CACHE STORAGE USED
    The amount of allocated cache storage at the end of task. If this is the same as the storage limit, the cache reached its limit and records may have been written to the overflow file.
  • CACHE STORAGE LIMIT
    The maximum storage allowed for the overflow cache. This can be changed using the OVERFLOW CACHE option.
DBKEYS File Layout
This section describes the contents of the record written to a DBKEYS cross reference file. The layout matches the DBKEYS file generated by CA IDMS/DB Reorg.
Field Name
Element Description
Explanation
OLDDBKEY
PIC S9(8) COMP
Old db-key
NEWDBKEY
PIC S9(8) COMP
New db-key
SR3DBKEY
PIC S9(8) COMP
SR3 db-key if the old record was relocated
RECORDID
PIC S9(4) COMP
Record ID in the source subschema
SR3RECID
PIC S9(4) COMP
Original record ID if relocated
The logical record length is 16 bytes. The BLKSIZE is determined by what is coded in the JCL or matching CREATE DSMODEL statement.
Each task that loads data generates a DBKEYS file for the data it loads. Depending on their intended use, these files may need to be merged together and sequenced before being used by another application.