If a DBSPACE reorganization job is scheduled to be run on a repetitive
basis (such as each week on Thursday night), be aware that an SQMPARM file record is created when the REORG job is scheduled. This record contains parameters used by the REORG process. The same record will be used each time the DBSPACE is reorganized. If an intervening REORG job for the same DBSPACE is scheduled from Control Center, a new SQMPARM record will be generated based upon the parameters chosen at that time. These may be different from the ones previously chosen for the scheduled job. This means that the new |SQMPARM record will be used for all subsequent executions of the scheduled job. If this is not what you want, delete the scheduled job from the VSE/POWER reader queue and schedule a new one.
The job listing from your Control Center jobs will indicate whether the job
ended successfully. Return code checking and conditional JCL are used to support failure restart. If a DBSPACE reorganization fails prior to the reload step, the DBSPACE has not been changed and the job can be restarted from the beginning. If the failure occurs during the reload step, the function can be restarted using RELOAD DBSPACE (Option 4).
In all cases, view the output job listing to determine the cause of the error and whether it requires fixing. In many cases, minor errors occur but the job is able to complete successfully.
During DDL generation, SQL statements are used to capture information
from the database manager system catalogs. If a serious database error is encountered, a descriptive error message and all pertinent information from the SQL Communication Area is displayed on the job listing.
The DBSPACE REORGANIZATION tools use a DBSU command file to execute the UNLOAD DBSPACE portion of the job. Detailed output from the UNLOAD portion is displayed on the job listing. Examine the listing to determine the reason for failure.
During RELOAD processing, DBSPACE REORGANIZATION jobs invoke a DBSU RELOAD. Detailed output of this process is displayed in the job listing. If a failure occurs during the RELOAD, the listing can be examined to determine the cause of failure.
One common problem to be aware of is a possible LOG FULL condition that may occur during RELOAD processing. The DBSU RELOAD TABLE command executes as a single LUW, meaning that the entire RELOAD could be rolled back if an error occurs. The database server would then have to record the LUW in the LOG. If the target table is large, or the database LOG file was nearly full when the reload began, the possibility of a LOG FULL condition exists. Depending on logmode, the database server will attempt to perform a database archive, a log archive, or a checkpoint in the LOG. If the RELOAD process continues until the LOG is completely full, the database server will begin to ROLLBACK the entire RELOAD.
Since the DROP DBSPACE has already been COMMITTED, the target DBSPACE will be in an incomplete state if this occurs. There are several possible solutions to this problem.