Backup Best Practices for Jobtrac Job Management Using Datacom.

Products

• Jobtrac

Issue/Introduction

 

All of  Jobtrac's data should be backed up periodically. "Periodically" must be defined by each customer, based on the number of changes being made to the scheduling database and any disaster recovery plans.

 

Environment

Release:
Component: JOBTRC

Resolution

All of  Jobtrac's data should be backed up periodically. "Periodically" must be defined by each customer, based on the number of changes being made to the scheduling database and any 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.

Broadcom recommends that  Datacom utilities be used to back up the Jobtrac database. The  Datacom utilities are very fast and will back up all Jobtrac  data in the physical database, regardless of how many logical copies of Jobtrac may be present.

The simplest type of Datacom backup is provided in Jobtrac  SAMPJCL member DBBKSTAT. 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 Jobtrac 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  Jobtrac(s) 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 Jobtrac  data. At the disaster recovery site, the data is restored via a  Datacom utility. This utility is provide in the  Jobtrac  SAMPJCL member DBLOAD.

Many sites either do not want to stop Jobtrac  for a backup or want a more "up to the minute" recovery. These sites can use Jobtrac  SAMPJCL member DBBKHOT which will allow you to backup Jobtrac  databases while still processing. This backup will allow you to obtain valid backups of the  Jobtrac  data, even while  Jobtrac  is up and users are making changes to the scheduling database.

DBBKHOT can be run while Jobtrac  is active, creating a hot or fuzzy backup. DBBKSTAT must be run while Jobtrac is inactive and the Jobtrac database is closed to create a static backup.

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 a  Datacom database. Log records are always automatically created for every update and written to the log file (the LXX file). The Forward recovery files can are used with either the static or hot backup to bring your database current if you need to restore your database.

The MUF (DATACOM started task) option LOGRCV controls how, or if, log records are copied to recovery files. Many sites start using  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 no recovery files are being created and a Forward recovery will not work.

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  Jobtrac  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 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 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 Jobtrac 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.  Jobtrac AMR function can be used to trigger a spill job when it starts to fill up.

Should a forward recovery be necessary, we strongly suggest that you contact Datacom Level1 support before attempting to run Jobtrac SAMPJCL member DBRECOV which is used load your database and process your 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 STATIC backup for disaster recovery and a daily Hot 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 Datacom are only helpful when certain types of sequential processing are done by the application. Jobtrac  does not perform this type of sequential processing, so reorgs are never needed against the Jobtrac data.

For more information on  Datacom startup options, such as LOGRCV and LOGSPILL, see the  Datacom/DB Database Database and System Administrator Guide. This manual also has topics on Using Logging and Using Recovery.

For more information on Jobtrac BACKUP and RECOVERY, see the Jobtrac Reports and Maintenance Guide, Chapter 5.