Circumventing unresolved LOCK functions when making SEQ=PHYSICAL backups with DBUTLTY

Products

• Datacom
• DATACOM - AD

Issue/Introduction

When running backup jobs for my CA 11 database files using CA Datacom/AD, I have had problems with a job failure leaving a LOCK command in place, which then causes the rerun of that backup job to wait. This seems to be a problem to me, and it is also a confusion, because it seems like CA 11 processing continues doing updates. I thought that the LOCK command stops further update activity.

How can I understand the LOCK functionality better, or is there a way to change this process?

 

Resolution

First, the LOCK function was originally designed, and works well for locking or preventing updates to data records that could be moved to a new physical location in the area. The records that move are those that use compression in the database, such that they might have a record length "x" now, but after update, a record length "y" that will not fit where it was originally. In this case, the record needs to find a new home, and if this happens while a backup is running, it is possible that the record can be backed up from its old location before the update, and then backed up again from its new location after the update, resulting in an incorrect backup file. Therefore, the purpose of the LOCK function is not to inhibit all updates, but only to hold up any update that would result in a record being moved to a new location in the area.

Now, regarding CA 11 data areas, CA 11 does not use compression or have variable length records that would be moved within an area. Therefore, this functionality of the LOCK is not used with CA 11, and normal updates would not be held up by using the LOCK function.

Next, the nature of the LOCK processing is such that the Lock stays in place until an UNLOCK is issued, and often, when a Backup job fails and is rerun without an intervening UNLOCK, the subsequent job will sit and wait, because there is an active Lock in place. To circumvent this, some clients have to go through some interesting JCL coding or job schedule coding to conditionally issue the UNLOCK. This processing is not needed and the problem of the unresolved LOCK can be remediated by the steps shown below.

The only other function of the LOCK that would benefit CA 11 applications is to flush any data that is in buffers out to the physical disk files. This is important for jobs running a SEQ=PHYSICAL backup, so that they can take a backup with the most current data. However, there are other ways to accomplish this that are less problematic, and that is what is proposed here. The easiest way is to use the COMM OPTION=STATS function, which does not outwardly affect processing, but which flushes the buffers to disk as desired.

If you are using the AL7BKUP job from the CA 11 SAMPJCL you might have something that looks like this in your job:

//SYSIN    DD *                             
 LOCK OPTION=MOVER,DBID=601,AREA=JOB        
 LOCK OPTION=MOVER,DBID=601,AREA=STP        
 LOCK OPTION=MOVER,DBID=601,AREA=DSN        
 LOCK OPTION=MOVER,DBID=601,AREA=JHF        
 BACKUP DBID=601,                            
       RECID=YES,                           
       SEQ=PHYSICAL,                        
       UPDATE=NO,                           
       SEQBUFS=128,                         
       DDNAME=BACKUP                        
 UNLOCK OPTION=MOVER,DBID=601,AREA=JOB      
 UNLOCK OPTION=MOVER,DBID=601,AREA=STP      
 UNLOCK OPTION=MOVER,DBID=601,AREA=DSN      
 UNLOCK OPTION=MOVER,DBID=601,AREA=JHF      
/*

In addition, you might have a second step that follows this, using COND=EVEN that has input:

//SYSIN    DD *                             
 UNLOCK OPTION=MOVER,DBID=601,AREA=JOB      
 UNLOCK OPTION=MOVER,DBID=601,AREA=STP      
 UNLOCK OPTION=MOVER,DBID=601,AREA=DSN      
 UNLOCK OPTION=MOVER,DBID=601,AREA=JHF      
/*

We recommend that you add a COMM OPTION=STATS,DBIC=601 function to your input file, and remove the LOCK-related commands. This means your input would be

//SYSIN    DD *                             
 COMM OPTION=STATS,DBID=601
 BACKUP DBID=601,RECID=YES,SEQ=PHYSICAL,UPDATE=NO,
        SEQBUFS=128,DDNAME=BACKUP                        
/*

Then, if you are using a second step with the UNLOCK commands, you can remove this step, as it is no longer needed.

With these changes, your job will no longer have problems with unresolved LOCK functions, and will more easily flush the buffers so that your backups have the same currency of data.

 

Additional Information

For more information about the DBUTLTY functions LOCK, UNLOCK and COMM OPTION=STATS, please refer to the DBUTLTY Reference Guide.