Manage the Database Load Utility for CA Cleanup for RACF

You can execute the database load utility anytime against an existing and active tracking file to add, reload, or delete items as follows:
cleanup121
You can execute the database load utility anytime against an existing and active tracking file to add, reload, or delete items as follows:
  • When updating an existing tracking database, add statements like the following to the JCL used for the database load utility:
    //DBASE DD DSN=CAI.AT8.DB,DISP=SHR //DBBACKUP DD UNIT=SYSDA,SPACE=(CYL,(20,20))
    The DBBACKUP file automatically restores the DBASE file when an error or failure during database load or update processing.
  • Newly added items begin tracking at the midnight nightly reload or whenever the main task is restarted (see main task). These items are flagged with an asterisk (*) to denote them as newly added. The asterisk flag clears upon first use.
  • Reloading resynchronizes the tracking and security database. Reloading an item does not affect its original load date or lose existing tracking information. Once a CA Cleanup tracking database has been established, we recommend that you schedule a weekly or monthly reload using *ALL* or *RELOAD*.
  • The WEBADM and IMWEB users are automatically excluded from the tracking database. These default names are used for HTTP Server administration but often show no usage. If HTTP Server is configured to use different names, we recommend excluding those names from the tracking database.
You can share the CA Cleanup database across systems. Sharing should match that of the security database itself.
If an error or abend occurs while being updated by the #DBU program, CA Cleanup tries to preserve the original DBASE. However, some abends, such as Sx22 (S122, S222, S322, S722), do not allow the recovery routine to perform 'retry' processing, only 'cleanup' or percolation. The file I/O required to restore the DBASE from the internal DBACKUP file is not allowed. Any attempt to perform such a restoration can result in an unsatisfied WAIT, causing the job to hang.
For this reason, we recommend the following best practices for the #DBU job:
  • Never cancel the job.
  • Do not specify the TIME parameter.
  • Do not specify the OUTLIM parameter.
  • Consider referencing a GDG+1 data set on the DBBACKUP DD.