The following operational considerations for executing online and one-step batch reorgs of full function and HALDB databases (FFOR):
The /DBRECOVER or /DBR command is used to take the database offline during processing.
Downtime for the first /DBR is minimal. However, downtime for the second /DBR is more significant and involves the following main processes:
When the /DBR command is used to stop a database, the NOFEOV operand is used to suspend log switch. Suspending log switch prevents a performance degradation of the IMS control region.
Log switch helps verify that all required logs are available when a database recovery immediately follows an online reorg. If LOGSWITCH=YES is specified or left to default, the NOFEOV parameter is omitted on the last /DBR command issued.
If any error occurs during the building of the new database, the old database is reinstated and sufficient information to help with debugging the failure is produced.
Optionally the pointers of the reorganized database can be checked during online reorganization.
This is done by using execution option CHECK=Y in member DBCCOPY of the Global Options dataset (DD card IDIPARM).
Option CHECK=Y is used by DBCOPY to invoke CA Database Analyzer™ for IMS for z/OS to check the pointers, while the image copy backup file of the reorganized shadow database is created (which minimizes the time needed for pointer checking).
The SAFETYNET feature is invoked immediately before the newly built database is passed to IMS to verify that the database is logically identical to the old, disorganized database provided SAFETYNET=YES is specified.
If a difference is detected, the new database will not be used; instead, the old database will be given back to IMS. If this occurs, a trace file is created by the ITK STC, which will contain information to help with the debugging of the build failure.
To recover a database processed by Full Function Online Reorg (FFOR), both the image copy and the log data set must be available to the recovery utility. The log data set is needed even if there were no transactions replayed because FFOR has recorded the existence of the log in the recons.
The timestamp that is used to register the image copy is different from the timestamp in the image copy file header because the database is online at the time of the actual image copy. CA High Performance Recovery for IMS for z/OS is able to recover properly with this scenario.
If you are using the IBM recovery utility DFSURDB0 to perform the recovery using the image copy created by Full Function Online Reorg (FFOR), the utility fails with message DFS2804A because of a mismatch between the time registered in the recons and the time in the image copy header. You can avoid this failure by resolving different timestamps.
Follow these steps:
Put the IMS toolkit load library ahead of the SDFSRESL data set in STEPLIB.
Insert a DD card as follows:
//IBMREC DD DUMMY
During an online reorg, CA Database Organizer™ for IMS for z/OS allocates and specifies the new database data sets under the IMS standard ddnames from the DBD. Online reorg uses these specifications in building the new reorganized database data sets and allocates the old database data sets using DBRC-provided data set names and automatically generates the associated ddnames.
The following rules apply to the names of old and new database data sets during an online reorganization:
Allocate shadow database data set names using the format original.dsn.N. FFOR invokes the IDCAMS ALTER processing to rename the data sets and expects this naming convention to be followed.
Unlike the OLR facility, which can operate with dual data sets A-J and M-V, FFOR never uses the M-V data sets. The FFOR reorganization of a HALDB always results with a set of reorganized A-J data sets.
At the end of the FFOR reorganization of the M-V database data sets, the reorganized database is in the A-J data sets named dsn.N. FFOR then attempts to rename the dsn.N data sets to the A-J data sets. The A-J data sets already exist because of OLR dual data set operation and the rename fails.
The new database must be JCL-allocated under the ddnames of the database data sets being reorganized. For HALDB databases, these ddnames are only the partition data sets and primary indexes.
Specify the IDCAMS control statement for FFOR and BATCHREORG to allocate the shadow data sets dynamically and to avoid the need for their DD statements in the FFOR job.
The IDCAMS processing causes FFOR to read from the data set allocated under the ddname AMSPDS. The data set referenced by AMSPDS contains members with delete and define information for the shadow database partitions. For each data set in the HALDB database, a member with the same name as the database data set must exist.
FFOR uses IDCAMS=* processing to allocate the shadow databases or partitions for a reorganized HALDB database based on existing database data set information within DBRC (data sets must be cataloged or SMS managed).
Regardless of the method that is used, verify that at least a double DASD commitment for all database partitions is available.
IDCAMS=YES can be used when reorganizing the entire database with ALLPARTS=Y. IDCAMS=YES is not valid when one or several partitions will be reorganized with PARTITION=name. For FFOR examples of ALLPARTS, REORGSI, and IDCAMS specifications, see members JCLFFOR6, JCLFFOR7, and JCLFFOR8 in the hlq.CIMTSAMP library.
You can run multiple online reorgs simultaneously; however, there cannot be an overlap in DOPT PSB usage. A DOPT PSB can only be used by one job at a time.
For information about dynamic PSBs in IMS, see the following IBM guides: