Additional information about HIPER PTF SO11899

Products

• Disk Backup and Restore - MVS
• DISK BACKUP AND RESTORE- ADD-ON OPTIO
• DISK BACKUP AND RESTORE

Issue/Introduction

Additional information about
HIPER PTF SO11899 - CA DISK DOESN'T HANDLE THE ADR415W RETURN CORRECTLY 

 ****   HIGH IMPACT NOTIFICATION ALERT   ****                                 
                                                                         
PROBLEM DESCRIPTION:                                                          
When using the DFdss data mover to archive a data set and the archive fails with the ADSR415W message, the data set may be backed up as empty and not restorable.                                                                   
                                                                              
SYMPTOMS:                                                                     
ARCHIVE MSGPRINT shows the following messages -                                  
ADSDF102 4106 ADR383W (001)-DTDSC(01), DATA SET dsn NOT SELECTED, 05          
ADSDF102 4106 ADR415W (001)-DTDSC(04), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED FROM ANY VOLUME                                                   
                                                                              
IMPACT:                                                                       
The archived data set cannot be restored.      

Environment

Release : 12.5

Component : CA Disk r12.5

Resolution

FAQ's about HIPER PTF SO11899 - CA DISK DOESN'T HANDLE THE ADR415W RETURN CORRECTLY 

Q: What are the triggering conditions for this issue?
A: The problem has occurred only once and for one customer so far.
   They were using a FIND and a SCAN REALVOLS command in one ARCHIVE step that selected the same data set as they were overlapping. 
   Due to the timing with data set disposition because of SYNCDEVS, the data set was still on DASD for the second archive.  
   The archive started and that kicked off the disposition which deleted it.   
   The DSS archive failed, however we treated it as an empty data set and incorrectly completed the archive. 

Q: How to avoid the problem?
A: Do not mix SCAN REALVOLS and FIND in one ARCHIVE step.
   It is only the mix of SCAN REALVOLS and FIND that can fail as it  would allow the overlap. 
   Even if SELECTs overlap, they won’t cause the problem.   

Q: We do have a mixture of FIND and SCAN REALVOLS within the same step that may overlap, however we have set sysparm SYNCDEVS to N01 (default is N99). 
Are we exposed as SYNCDEVSN01 implies there is no delay in the disposition processing?
A: You should not be exposed with sysparm SYNCDEVS set to N01.
A value of 'Y' or 'N01' or 'N00' causes CA Disk to issue the SYNCDEV during cartridge processing after every data set.

Q: When the DSS move failed, what will happen to the DSN in DASD? 
A: The data set on DASD is gone already.

Q: How to identify if we hit this issue or not?
A: You need to compare the data set listed in the ADR* error messages to the archive report.
   The key is whether the concerned data set has NO asterisk (*) in the report indicating it was processed despite the DSS error.
   If the Archive report shows the data set as bypassed (with an asterisk), then no error.
   You only hit the problem if the DSS messages show that the dsn has failed, but in the report the data set shows as processed (without asterisk).

   For example, if the ARCHIVE MSGPRINT shows the following message                             
   ADSDF102 4106 ADR383W (001)-DTDSC(01), DATA SET dsn NOT SELECTED,       
   ADSDF102 4106 ADR415W (001)-DTDSC(04), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED FROM ANY VOLUME
   then you need to check that data set in the archive report.
   If the Archive report shows the data set as bypassed (with an asterisk), then no error:
   * dsname ...
   You only hit the problem if the DSS messages show that the dsn has failed, but in the report the data set shows as processed (without asterisk):
     dsname ...

Q: How to recreate the issue?
A: This is a timing issue and difficult to reproduce.
   We were able to reproduce the problem by turning off ENQS and holding the data set in EDIT.  
   Once the Backup started, we deleted the data set and DSS failed just like the double archive.