The Reorganize function provides a simple mechanism for reorganizing a database or set of logically related databases. This automates the creation and running of separate Unload and Load functions. PtrUpdate steps are run automatically for any database containing logical children.
mfims imsdbu REOR {database-name|filename}
[[NO]CLS]
[ECHO(keyword,msglvl,stoplvl
[[NO]INI(filespec)]
[[NO]LIST(filespec)]
[LISTOPEN(disp)]
[[NO]LOG(filespec)]
[PROGRESS(no-of-segments)]
| Default: | NOCLS |
| Default: | ECHO(MSGS,4,8) |
| keyword | The category of information displayed. One of the following:
|
| msglvl | A value from 4 through 20 to indicate the severity of messages to display.1 |
| stoplvl | A value from 4 through 20 to indicate the severity of messages to stop for user input. 1 |
| Value | Category | Example Cause |
|---|---|---|
| 4 | General warning message | A minor coding error in DBD source which DBDGEN can make an assumption about and continue. |
| 6 | IMS specific warning message | A warning that a keyword or statement is not supported and is ignored - processing can continue. |
| 8 | General severe error | An incorrect coding in DBD source which cannot be compensated for, such as 'no DBD statement'. |
| 10 | IMS Option specific severe error | An unsupported feature was defined which cannot be compensated for, such as 'Exceeded some maximum'. |
| 12 | Severe error - possible temporary condition | A temporary I/O error such as a 'file locked' or 'database locked' status. |
| 16 | Severe error- permanent - likely installation problem | A permanent I/O error, such as an invalid data set name or member name, was input to a utility or an environment variable is not set correctly. |
| 20 | Severe error - permanent | An unrecoverable I/O error or some other unexpected error. |
| Default: | None |
| filespec | The name and location of the .INI file containing directives that override the IMSDBU programmed defaults. |
[IMSDBU] PROGRESS(1000) ;use local log LOG(C:\MYDIR\MYDB.LOG)
| Default: | LIST(*.LST) |
| filespec | The name and location to use for the listing file. |
| Default: | LISTOPEN(NEW) |
| disp | The disposition to use. One of:
|
| Default: | LOG(IMSDBU.LOG) |
| filespec | The name and location of the file to use as the IMSDBU activity log. |
| Default: | PROGRESS(200) |
| no-of-segments | A value between 0 and 9999 indicating the number of segments to process before displaying a progress message. 0 disables progress reporting. |
The database name input to the Reorganize function must be a primary physical database defined using DBDGEN. This DBD name must be a type of database which is supported by the Load function. See the Load Function for the database qualifications.
The database data files are read and updated by Reorganize using the Unload, Load, and PtrUpdate functions.
Secondary index databases do not need to be available when starting reorganization. They are recreated during the Load step.
The Unload function does not require the logical parent databases when unloading its logical child database. However, Reorganize uses Makelist to create Unload steps for each related database. All of the databases that are logically related must be available before starting Reorganize.
Database unload work files containing the segment data are created during this process. These files are named using the DBD name with a .org extension. They are created in the project listing directory. For reference, they are an Unload file created with the directives LAYOUT(D) and COMPRESSION(CBLDC001), and are deleted upon successful completion of the Reorganize.
A Runlist command file is created with the name DBUREORG.RUN. It contains the steps to perform the reorganization. It is always placed in the current directory and is not deleted upon successful completion. You can use this file as a model for creating your own reorganization scripts. Be sure to copy it to a new name as the next Reorganize function recreates it. You might need this file to recover from an incomplete reorganization.
When a segment is deleted, the space it occupied is reused by the next segment inserted which is not larger than the deleted segment. However, if new segments are not inserted which 'fit' this deleted space, the space is not reclaimed until you reorganize the database. Also, as a database is updated, the internal pointers can become fragmented which reduces performance. A reorganization will restore the performance to that of a newly loaded database.
The Reorganize function combines the functions of the Load, Unload, PtrUpdate, and Delete functions to perform the reorganization. It creates the required steps using an advanced feature of the Makelist function. This Makelist feature is only available when using the callable API interface to IMSDBU. The interactive and command-line interfaces for Makelist only support creating steps for loading databases. The callable interface adds the ability to create the steps for reorganizing databases.
The reorganization for a database with no logical children is simply to unload the database to a sequential file and load it using the sequential file.
Reorganizing a database containing logical children results in reorganizing it and all of its related databases. The steps to reorganize these databases are:
Identifying the related databases is done by Makelist. The process Makelist uses to create this list is the same for Reorganize as it is for Load.
The sequential unload files are not deleted until all of the Load and PtrUpdate processing is complete. Although this requires more disk space than deleting them after the Load, it provides for restarting if a subsequent Load or PtrUpdate step fails. If you need to conserve disk space, you can change the DBUREORG.RUN file to re-sequence the Delete commands and use Runlist to run the commands. You could also create your own Runlist command file or run the required functions in an operating system command file.
When the detailed report filename *.LST is used, a separate list file is created for each database involved in the reorganization. For a combined listing, specify the directives LIST(file-spec) and LISTOPEN(MOD).
The easiest way to recover from a failed Reorganize function is to restore the original database data files from a backup copy. In the event that a backup copy is not available, recovery can be performed using the files produced by the reorganization. Failures can occur for several possible reasons. One example is running out of disk space.
In the event of a failure, an error message is issued and the process is terminated. The sequential file unloads are kept. These files may be required to complete the reorganization.
The first thing step is to determine the cause of the failure and correct it. The error message issued from the reorganization is written to the detail report listing. This message should provide enough information to determine the cause of the failure. In some cases, the IMSMTO.LOG will provide additional information about the failure.
The IMSDBU activity log will indicate all of the steps which were successful and the step which failed. If the failing step was an Unload, database recovery is not necessary. Just restart the Reorganize function after correcting the cause of the failure.
Compare the functions listed in the log to the reorganization command file DBUREORG.RUN to identify which step in the command file failed. Use a text editor to modify the command file and remove or comment out all of the steps which completed successfully. A step is commented out by placing an asterisk (*) in column 1. Use Runlist with the modified command file to complete the reorganization.