Utility Statements › REORG › Usage › Controlling REORG Execution

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.

Important! 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.

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