Running CA Disk Archive for specific datasets, it can happen to get the error: ADSST011*0387 dsname ON volume BYPASSED, REASON: RECENTLY RESTORED, GRACE PERIOD STILL VALID and the Archive fails for the involved dataset.
search cancel

Running CA Disk Archive for specific datasets, it can happen to get the error: ADSST011*0387 dsname ON volume BYPASSED, REASON: RECENTLY RESTORED, GRACE PERIOD STILL VALID and the Archive fails for the involved dataset.

book

Article ID: 7518

calendar_today

Updated On:

Products

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

Issue/Introduction

 

CA Disk provides comprehensive, efficient, common processing of mixtures of non-VSAM data sets and VSAM clusters. Within a single execution, you can back up, archive, delete and expire partitioned (PO), partitioned extended (POE), physical sequential (PS), physical sequential extended (PSE), direct access (DA), indexed sequential (ISAM), and OS CVOL catalog non-VSAM data sets. You can also back up, archive, delete and expire VSAM clusters, and back up ICF catalogs.

 

You can do the backups and archives in either an immediate mode, or in a deferred mode in which the back up or archive is actually done at a later time.

 

You can also direct the output to different media types. For instance, by default backups and archives are written to tape. However, by overriding a couple of sysparms, they can easily be directed to disk. For details, see the step-by-step instructions in Archiving to Disk: Requirements and Recommendations in the Systems Guide.

 

In addition, the CA Disk restore function allows you restore DA, PO, POE, PS, PSE, and ISAM data sets and OS catalogs without the need for pre-allocation. You can also restore VSAM clusters and ICF catalogs. In most cases, you can even restore to a device type other than that from which the data set was backed up or archived.

 

It can happen that, due to space problems on dasd, an end-user asks for an explicit Archive of a dataset which has just been restored and the Archive fails with error message :

 

ADSST011*0387 dsname ON volume BYPASSED , REASON: RECENTLY RESTORED, GRACE PERIOD STILL VALID

 

How to bypass this error ?

 

Environment

CA Disk

Cause

 

Here the explanation we provide in the CA Disk 12.5 Backup and Restore Message Reference Guide for the error message:

 

0387

(ddd) ON (vvv) BYPASSED, REASON = (rrr)

 

Reason:

 

Data set (ddd) on volume (vvv) was not processed as requested for the reason indicated. Processing continues with the next data set. If the reason is DISK ARCHIVES NOT ALLOWED, the file was rejected from processing because it is a CA Disk disk archive data set. CA Disk does not allow processing of these files with RETAIN.

 

Note: For techniques on managing these files, see the section FDS Managment in the User Guide.

 

 

 

Resolution

 

In our case the error reason is:

 

RECENTLY RESTORED, GRACE PERIOD STILL VALID

 

In fact, an installation option exists that assigns a grace period to any restored data set, during which time it is exempt from processing by archive (this process does not affect BACKUP). The grace period applies, as a default, no matter what volume the data set resides on, even if it is moved after restore.

 

The involved option is:

 

RETEXCLDn

Valid for RESTORE, RECOVER, and VRECOVER

 

Specifying this sysparm with a value of Y causes a grace period record to be placed in the RETEXCLD subfile each time a data set is restored. The presence of such a record prevents retention control from automatically disposing of a restored data set until the grace period of 30 days has elapsed. The default value of N disables this facility. The default grace period is controlled by sysparm RESRETPD.

 

So, to bypass the error:

 

ADSST011*0387 dsname ON volume BYPASSED , REASON: RECENTLY RESTORED, GRACE PERIOD STILL VALID

 

it is necessary to run the Archive job with RETEXCLD this set to N, using the following override SYSPARMS DD:

 

//SYSPARMS DD * 
SMSMCBYPY 
RETEXCLDN 

 

so that CA Disk will not look at the grace period in the Dsnindex record at all and the data set can be re-archived correctly. 

If, after this suggestion, the abend occurs again, please open a Case with CA Support.