Utilizing the DBAS CPUFAIL command during Disaster Recovery

Products

• CA-11

Issue/Introduction

For sites that choose not to initialize the  Workload Automation Restart Option for z/OS Schedulers (CA 11) Databases to start fresh at the disaster recovery site, consideration should be given to utilize the DBAS CPUFAIL command.

 

.

Resolution

For integrity, CA 11 will lock a batch job in the U11RMS step and unlock the job at job termination. Since Database backups can and are taken in an ongoing processing environment, any number of batch jobs may be on the backup file that were executing at the time the backup file was written. This would also be true for any  Datacom/AD spill files that may be written after a backup is taken. When backup and/or spill file(s) are used for Disaster Recovery, any number of jobs/members will be restored in a LOCK condition which can result in job(s) receiving U11-011 with a CRQRC: 0010 on their next run. Part of the lock record key is the CPUID, where the job was locked.  CA 11 provides a DBAS command to unlock all jobs on a specified CPU.  This command must be done on a CPUID different than the one that generated the lock for a particular job.  For Disaster Recovery, the assumption is made that recovery will be on CPU IDs different than those where the initial processing and backup are done.  Thus, the command(s) can be entered on one or more of these systems to perform an  unlock , for all batch jobs after backup/spill file restoration and before beginning any processing. The command is the CPUFAIL command and the command format is as follows:

comchar CPUFAIL CPUID=xxxx,ALL

Where comchar is the value specified in the configuration file and xxxx is the CPU ID for the failed CPU.

Example:  A four CPU SYSPLEX with IDs: SYS1, SYS2, SYS3 and SYS4 where the backup was done and disaster recovery systems of DRS2 and DRS4. At system DRS2 enter the command for each of the four SYSPLEX CPUs: SYS1, SYS2, SYS3, and SYS4.

Example: (if testing in-house and there is a test/development system SYT1) then enter the command for each of the four systems on this system.

NOTE:
This command should never be entered on a single CPU to unlock jobs on that CPU, otherwise unpredictable and undesirable results will occur. This command requires a CPUID different from the one where the command is issued.