Enqueue on GDG new level allocation while CA Disk is managing GDG BASE

Products

• Disk Backup and Restore - MVS

Issue/Introduction

A contention problem could occur between a batch job that tries to create a GDG +1 level and a batch DISK Archive/Backup job managing the old levels of that GDG because it holds the GDG BASE.

Is there a way to bypass this problem? 

 

Environment

Release : All

Component : CA Disk Backup and Restore

Resolution

The solution to this enqueue problem depends on the DATA MOVER used for the GDG Archive/Backup:

1. When the GDG is archived/backed up by DISK Data Mover :

The following SYSPARMS are involved and should be set appropriately:

*** ENQGDGBYn

Valid for ARCHIVE, BACKUP, BACKUPCC, RESTORE, RECOVER, VBACKUP, VRECOVER, and SECURITY

This sysparm affects the enqueuing on GDG data sets. It allows you to optionally bypass the enqueue on the base name of a GDG.
The default value for this sysparm is N. Regarding IBM integrity conventions for generation data groups, CA Disk enqueues on the base name before enqueuing on the full data set name. Therefore the enqueue on the base name, whether by CA Disk or another application, can prevent other jobs from accessing any generation within the group; for example, CA Disk will bypass all generations within the group until the other task releases (dequeues) the base name.
If you specify this sysparm with a value of Y, CA Disk will bypass the enqueue on the base name of the GDG data set and process individual generations, based upon their enqueue status. Because IBM conventions are not being used, unpredictable integrity exposures can arise for which CA Disk is no longer responsible.
 JES3 customers must specify this sysparm with a value of Y because the CA Disk JES3 enqueue allocation technique automatically causes an enqueue of the GDG base.
Review the RECATMIG, GDGRECAT, and ENQGDGBY sysparms. Because CA Disk uses absolute names to allocate and catalog GDGs, set the ENQGDGBY sysparm to N unless you are using JES3. To avoid potential data set loss, set the GDGRECAT sysparm to N. Review the use of CREATE for Restore. Create date is another factor that is used at restore time to determine generation sequence. If an older generation is restored with a new creation date and later re-archived, it can be selected for recovery out of sequence later.

 *** SYNCDEVS .

This is because  the enqueue by DISK job is held for the time needed by the  setting for sysparm SYNCDEVS. It determines when a SYNCDEV command will be issued to the device.  
The default value of N99 for sysparm SYNCDEVS causes CA Disk to defer the disposition processing by queuing up to 99 data sets. After the data sets that are in the buffer that is in the tape control unit has been written to the media, disposition processing will be performed for all queued data sets that are now complete. If Sysparm SYNCDEVS is set to N01, a SYNCDEV command will be issued during cartridge processing after every data set and this will limit the enqueue time to the GDG BASE by DISK.

So, setting sysparm SYNCDEVSN01 should solve the problem that the enqueue on the GDG base is kept so long,  at the cost that SYNCDEVSN99 would improve throughput when small data sets are involved during backup or archive on high density tapes. It can  also be considered running separate Archive steps for these GDG with sysparm SYNCDEVSN01 set if it occurs  that the Archive run time increases with SYNCDEVSN01.

Otherwise ENQGDGBYY can be set but this is not recommended having DISK doing the ENQUEUE.

 2. When the GDG is archived/backed up by DFDSS  Data Mover :

if PTF SO07293 is applied, then DFDSS performs serialization and thus ENQGDGBYY does not prevent the ENQ on the GDG Base.

In this case the resolution is to remove LARGE from USEDSSIO to use the DISK Data Mover, having DISK managing the enqueue as reported before.