When executing an Online Reorg, CA Database Organizer, may on occasion, fail in the rename process.
HPO0B03E ERROR WHILE RENAMING original.dsn to original.dsn.O
HPO1D00I TRYING TO REINSTATE THE ORIGINAL DATABASE
HPO0B04I TRYING TO REVERSE RENAMING PROCESS DUE TO PRIOR ERROR
HPO0B01I RENAMING original.dsn.O to original.dsn
HPO0B03E ERROR WHILE RENAMING original.dsn.O to original.dsn
HPO1D02E UNABLE TO REINSTATE THE ORIGINAL DATABASE
We would only expect failures in the IDCAMS rename process if duplicate files existed from a previous execution of this FFOR, or if a duplicate FFOR was being executed for the same database at the same time. Note that we do not support duplicate FFORs running in parallel.
When there is a failure, for whatever reason in the IDCAMS rename process, then some action is required to ensure that the files are in the correct state. This is required both when the failure is in the IDCAMS rename process after a successful FFOR and also after a failure in the IDCAMS rename process after the database is reinstated after an unsuccessful FFOR.
To assist with ensuring that the correct files are available to a FFOR and to prevent failures due to duplicate datasets, control statement DELETEOLD=Y can be specified in the FFOR so that the old database datasets are deleted after the reorg completes.
Additionally, it is recommended that you include a delete step for the '.N' database datasets before the FFOR step.
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.