The CA Datacom DBUTLTY Online Reorg (OLREORG) is a database maintenance function, and we want to know how often Datacom is taking checkpoints under the covers with this function.
CA Datacom/DB 15.0
CA Datacom/DB 15.1
z/OS
OLREORG does not need to take checkpoints because it is a row processor with each row a stable point. You can interrupt or stop the execution of OLREORG without any risk to your environment by issuing a COMM REQABORT. The rows that have been moved will stay as is and the rows not searched yet will not be done.
The use of this function is to allow the reorganization to take place alongside other work. Also, OLREORG runs at a lower priority than the regular workload. According to the documentation:
Applications are allowed to maintain rows in the specified table while OLREORG is running. The [exclusive control conflicts] number printed in the report represents rows that OLREORG chose for movement but skipped because some other task currently had either primary or secondary exclusive control on the row. These rows are skipped for performance reasons.
In the event that you would cancel the job, you should note the LASTKEY processed, and then later in the day, you can restart the OLREORG, using this value in the FIRSTKEY parameter. Otherwise, it will start over from the beginning, and reprocess the rows already processed.
As always, please contact Broadcom Support for any CA Datacom questions you might have