Possible idea to keep track of the ACF2 backup process
Article ID: 130571
CA ACF2CA ACF2 - DB2 OptionCA ACF2 for zVMCA ACF2 - z/OSCA ACF2 - MISC
ACF2 databases are VSAM files. Using the BACKUP record in GSO, ACF2 can trigger a backup process to that copies the Primary databases into the sequential backup files as defined in the ACFFDR. In the BACKUP record, there is a field called STRING. When ACF2 finishes the backup process, the command in the STRING is issued. Most shops use that to fire off a started tack called ACFBKUP that deletes the alternate databases, creates them again, and then copies the newly updated sequential backup files into the new Alternate databases. At that point in time, all three are in synch. What should be done if the ACFBKUP fails for a JCL error or something else?
Release: Component: ACF2MS
ACF2 was not designed to keep track of jobs and started tasks problems, only the security related to it, even if started by ACF2. Other products are designed to do that. A possible solution to keeping track of a successful run of ACFBKUP is let one of these other products to the process. You can leave the STRING blank in the BACKUP record. Then have your job scheduler look for a message from ACF2 that the backup from the Primaries to the backup files was successful.
Then the job scheduler can fire off the started task ACFBKUP. Job schedulers are designed to keep track of the successful or failure of jobs it runs. Job schedulers can also notify the proper personnel if ACFBKUP worked or failed, so something can be done to correct it.
Sample ACFBKUP procedure that deletes/defines the Alternate database and REPROs the backup files into the Alternates is placed into SYS1.PROCLIB during the install process. Here is the documentation link that describes this: