Backup Best Practices for CA Scheduler Job Management Using CA Datacom
Article ID: 9516
Updated On:
Products
Issue/Introduction
All of CA Scheduler Job Management's data is stored in CA Datacom. This includes the scheduling database, the active workload, any staged JCL, and any documentation (text) stored in CA Scheduler Job Management.
CA Scheduler Job Management's data should be backed up periodically. "Periodically" must be defined by each data center, based on the number of changes being made to the scheduling database and disaster recovery plans.
For example, some shops make very few changes to the scheduling database, and plan to always start with an empty active workload during disaster recovery, while other shops make many daily changes to the scheduling database and plan on disaster recovery continuing from the point of failure. The type of backup needed differs based on why it is being taken.
Environment
Component:
Resolution
CA Technologies recommends that CA Datacom utilities be used to back up the CA Scheduler Job Management database. The CA Datacom utilities are very fast and will back up all CA Scheduler Job Management data in the physical database, regardless of how many logical copies of CA Scheduler Job Management may be present. CA Scheduler Job Management's CAJUTIL0 BACKUP and RESTORE commands are considerably slower than the CA Datacom utilities and can only be used against one logical copy of CA Scheduler Job Management. The CAJUTIL0 BACKUP command also does not "lock" the database against updates, so CAJUTIL0 backups taken while CA Scheduler Job Management is active are not guaranteed to be complete and accurate.
The simplest type of CA Datacom backup is provided in CA Scheduler Job Management SAMPJCL member DBNATIVE. This job backs up all of the records in the database in key (native) sequence. The resulting backup can be restored to the same physical database, or you can recreate the database to be larger (or smaller) or on a different device type.
A native backup requires exclusive access to the data, so all copies of CA Scheduler Job Management must be down and all users must exit the online before the backup can run. This guarantees the integrity of the data. Once the backup has completed then all of the CA Scheduler Job Management may be restarted.
Native backups are good for sites who make very few updates to the database, or who are not concerned with recovering data to the point of failure. For example, some sites, as part of their disaster recovery plans, take weekly native backups of the CA Scheduler Job Management. At the disaster recovery site, the data is restored via a CA Datacom utility (the DBUTLTY LOAD command). The CA Scheduler Job Management CAJUTIL0 utility is then executed with the commands FORMAT CAIJTRK. This command empty the active workload and staged JCL. When CA Scheduler Job Management is subsequently started, it immediately performs an autoscan and proceeds with the current day's processing.
Many sites either do not want to stop CA Scheduler Job Management for a backup or want a more "up to the minute" recovery. These sites can use CA Datacom's "backup-while-open," or "forward recovery," utility to obtain valid backups of the CA Scheduler Job Management data, even while CA Scheduler Job Management is up and users are making changes to the scheduling database.
Forward recovery uses "recovery files," which are sequential files (usually a GDG on tape) containing log records. (Recovery files are sometimes called RXX files.) Each log record has a specific change made to an CA Datacom database. Log records are always automatically created for every update and written to the log file (the LXX file).
The MUF (CA Datacom started task) option LOGRCV controls how, or if, log records are copied to recovery files. Many sites start using CA Datacom with a LOGRCV value of NEVER, which means that log records are never copied to recovery files. When LOGRCV is set to NEVER then a backup-while-open should never be performed.
Most sites, when they want to start creating recovery files, change the LOGRCV setting to NO. LOGRCV NO means that a dedicated tape drive is not going to be supplied for the recovery file. Instead, a SPILL job will periodically be run to copy the completed log records (the log records that the MUF no longer needs) to the recovery file. The CA Scheduler Job Management SAMPJCL member DBSPILL has some sample JCL for a SPILL job.
How often the SPILL must be run depends on the size of the log (LXX) file and the number of updates performed to the database. A single CA Scheduler Job Management job being added to the active workload and running generates many updates: the initial add to the workload, status changes from Schedule not Started to Submit in Progress, Submitted, Started, Completed, OS Purged, and finally being deleted (purged) from the workload. Of course, predecessors/successors being posted, staged JCL, virtual resources and flows all add to the number of updates to the database. The more jobs in the active workload, and the more relationships between those jobs, the more updates will be required during a day's processing.
The CA Datacom MUF LOGSPILL option can be used to indicate when a SPILL must be done.
IMPORTANT: If LOGRCV is set to NO and the log (LXX) file becomes full due to a SPILL not being run, then all CA Scheduler Job Management activity will stop until a SPILL has been successfully run. Because of this many shops tend to over-allocate the LXX file so that the SPILL job does not need to be run as often. Also, having the SPILL job defined in CA Scheduler Job Management may not make sense because CA Scheduler Job Management may not be able to submit the job when needed.
Once the recovery files are set up and being created, then the CA Datacom backup-while-open utility can be safely used. The CA Datacom program DBUTLTY is used with the following commands:
ACCESS STATUS=WRITE,DBID=430
*
BACKUP DBID=430,DDNAME=TAPEOUT,SEQBUFS=128,RECID=YES,
SEQ=PHYSICAL,UPDATE=NO,BLKSIZE=32760,AREA=ACH
(The ACCESS command makes sure all of the buffers have been written out to DASD so that the backup is as current as possible.)
This type of backup is called a physical backup. Unlike the native backup, a physical backup can only be restored to a database that is the same size and on the same device type as the original.
Should a forward recovery be necessary, the database would be restored (using the DBUTLTY LOAD command), then the recovery files would be processed. CA Scheduler Job Management SAMPJCL member DBRECOV can be used as a sample job to process the recovery files. Note that all of the recovery files created since the physical backup must be processed in time sequence.
Many shops may discover that they need both an occasional native backup for disaster recovery and a daily physical backup with forward recovery to protect against DASD problems.
Any discussion of backups would be incomplete without also talking about database reorganizations (reorgs). Reorgs in CA Datacom are only helpful when certain types of sequential processing are done by the application. CA Scheduler Job Management does not perform this type of sequential processing, so reorgs are never needed against the CA Scheduler Job Management data.
Additional Information
For more information on CA-Datacom startup options, such as LOGRCV and LOGSPILL, see the CA Datacom/DB Database Database and System Administrator Guide. This manual also has topics on Using Logging and Using Recovery.
For more information on the batch CA Datacom commands, such as BACKUP, LOAD, LOCK/UNLOCK, and SPILL, see the CA Datacom/DB Database for z/OS DBUTLTY Reference Guide.
Feedback
