Utility Statements › REORG › Usage › Using the REORG Utility

Using the REORG Utility

How to submit the REORG statement

You submit the REORG utility only through the batch command facility. You must run the batch command facility in local mode.

The REORG utility is currently supported only in z/OS environments.

REORG 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.

More Information

• For more information about the use of the RORGJCL file, see Automatic job submission in Controlling REORG Execution.
• For more information about the JCL needed to execute the REORG utility, see JCL Considerations.
• For more information about general guidelines and considerations on database reorganization, see the CA IDMS Database Administration Guide.

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.

Note:

• For more information about using chained reads, see the CA IDMS Database Administration Guide.
• For more information about PREFETCH and IDMSQSAM related SYSIDMSparameters, see the CA IDMS Common Facilities Guide.

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.

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