Skip to content

Operational Considerations for FFOR

Last update January 2, 2017

The following operational considerations for executing online and one-step batch reorgs of full function and HALDB databases (FFOR):

Database Downtime

The /DBRECOVER or /DBR command is used to take the database offline during processing.

  • The first time the database is taken offline is to create an initial checkpoint from which the call intercept code can safely start recording updates.
  • The second time the database is taken offline is to activate the newly built database.

Downtime for the first /DBR is minimal. However, downtime for the second /DBR is more significant and involves the following main processes:

  1. Call replay takes the last of the interim updates and completes the construction of the new database.
  2. The SAFETYNET feature is invoked. This feature does a logical comparison of the two databases to verify that they are identical. It is optional and driven by the SAFETYNET control statement.
  3. A data set renaming process occurs.
Note: To allow /DBR commands to complete, any active BMPs accessing the database must be quiesced. If BMPPAUSE=YES is specified or defaulted, CA Database Organizer™ for IMS for z/OS online reorganization automatically pauses and resumes the active BMPs at both ends of the reorganization process. If BMPPAUSE=NO, these BMPs are detected and you are prompted to shut them down.


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.

Database Recovery after an Online Reorganization

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.

Important! If you specify DBRC=N, you can recover a database using only the image copy. However, the recovered database may be incomplete.
Note: DBRC=N cannot be used with HALDB databases.

Image Copy Timestamps after an Online Reorganization

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.

Resolve Different Timestamps when Recovering with DFSURDB0

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:

  1. Put the IMS toolkit load library ahead of the SDFSRESL data set in STEPLIB.

    Note: All data sets should be APF-authorized.
  2. Insert a DD card as follows:

    //IBMREC    DD    DUMMY

    Note: If the IBMREC DD card is omitted, CA High Performance Recovery for IMS for z/OS is invoked.

Database Data Set Specification and DSN Renaming

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:

  • The DBRC-defined data set name must be 42 characters or less.
  • The shadow database allocations are given the existing data set name with .N appended. When the online reorganization is complete, FFOR renames the new database data sets from .N to DBRC-defined name.
  • The old database data sets are renamed to their existing DBRC-defined name with .O appended.

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.

Note: If FFOR abends before the shadow database is renamed, the next execution of the job fails because FFOR is trying to rename old database to original.dsn.N but the data set with the same name is already allocated. To prevent this abend, include the delete step for the shadow database in your JCL before the HPO step.

Processing M-V Data Sets

Important! The FFOR rename processing fails when you use FFOR to reorganize a database that was previously reorganized using the IMS Online Reorganization (OLR) facility and has M-V data sets.

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.

IDCAMS Processing and Dynamic Allocation of Data Sets for HALDB

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.

Executing Multiple Online Reorgs

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:

  • IMS Database Administration Guide: System
  • IMS Utilities Reference: System
Was this helpful?

Please log in to post comments.