Having problems such as SC03 abends when restoring encrypted/compacted files with Faver. Sometimes a RC8 is experienced with Duplicate Dataset Name Exists messages during the define.
Using DEFINED DDNAME= parm in the GVRESTORE statement
RESTORE REMP PURGE
CLUSTER
CL=user.cluster.name DEFINED DDNAME=ddname pointing to the model cluster name
z/OS any level 2.1 and above
Faver 4.5 and above
In previous releases of Faver (r4.1, 4.2, 4.3) there was not a DFSMS environment in existence. There was occasionally a requirement/need to change the DEFINE allocations of a specific cluster(s) during the restore process to new media, sand box systems, or a new application requirement.
In today's DFSMS environment, these types of allocation controls are totally automated and require no manual assistance. Even the Faver restore process when the DEFINE is performed is an IDCAMS process and intercepted by DFSMS and allocations are altered under the covers. Faver has no idea these changes were made and continues with the restore process. These processes are always external to Faver.
Faver, in the latest environments, still has the "DEFINED DDNAME=" parameter documented in the Faver User Guide (page 123).
Although the documentation has yet to be updated, this feature is no longer required or supported. The feature is simply no longer a viable or applicable feature.
Best practice going forward is to remove the control statement and the DD reference from your production JCL and Faver control statements.
You can experience SC03 abends produced from the DFDSS interface when restoring encrypted/compacted clusters.
IN non-encrypted/compacted restores you could experience the following:
GV901 - VSAM REQUEST ERROR R15=08 RC=008
IDC3013I DUPLICATE DATA SET NAME
Sample control statements you may locate and remove in the GVRESTOR steps of your Faver jobstream:
RESTORE REMP PURGE
CLUSTER
CL=test.cluster.name DEFINED DDNAME=ddname
in the JCL
//ddname DD DISP=SHR,DSN=other.cluster.name.to use