Possible idea to keep track of the ACF2 backup process

Products

• ACF2
• ACF2 - DB2 Option
• ACF2 for zVM
• ACF2 - z/OS
• ACF2 - MISC

Issue/Introduction

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?

Environment

Release:
Component: ACF2MS

Resolution

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.
 
ACF79041 ACF2 VSAM CLUSTER BACKUP COMPLETED SUCCESSFULLY 
 
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.

Additional Information

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.