The dataset exists physically on the volume. I was able to access it via 3.4
I think I hit on something. I did a phyiscal backup and a logical backup of the dsn. The restore of the dsn using the logical backup worked. The dsn was replaced successfully. I tried another test with the logical backup. I specified another volser (other than where the source dsn resides) and the restore worked, the dsn was replaced. However I found a problem with the restore from the physical dsn backup. When I specified a volser other than that of the source dsn, the restore failed with the same error messages. However, when I specified the source volume volser the dsn was replaced. I think that DFDSS restore using a physical dsn backup will only be replaced if the dsn is being restored to the original source volume. If the dsn is not existing the restore would work if the dsn is restored to another volume other than the source volume. Please correct me if I am wrong. -------------------------------------------- On Thu, 9/18/14, retired mainframer <[email protected]> wrote: Subject: Re: DFDSS FAILED RESTORE To: [email protected] Received: Thursday, September 18, 2014, 1:58 PM According to the manual, if REPLACE is specified for an SMS managed dataset, the existing copy is located via the catalog. So the OUTDDNAME operand should be ignored. The manual also specifies that if the dataset is found, the SMS attributes are unchanged. So the STORCLAS operand should be ignored. Does the dataset (not just the catalog entry) really exist? Is it SMS managed? Is it catalogued? Is the dataset actually on the volume the catalog indicates? > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of esmie moo > Sent: Thursday, September 18, 2014 8:34 AM > To: [email protected] > Subject: DFDSS FAILED RESTORE > > Good Day Gentle Readers, > I am trying to trouble shoot the problem of a failed DFDSS restore. So far I am unable to > find the reason. The dsn (at the time of the restore) was allocated on a volume but I do not > know on which volser. However, the restore failed even though the REPLACE parm was > used. I was told that the dsn (which is SMS managed) was NOT in use at the time. > I have a suspicion that the dsn resided on another volume which was not in the same > STORCLAS/STORGRP which may be the cause of the failure. A colleague and I reviewed > the SMS ACS routines and all is in order. The bypass of STORAGE CLASS (via jcl is > permitted and is valid) and it is not GUARANTEE SPACE.I would appreciate your > thoughts in knowing the cause of the failure. > > PAGE 0001 5695-DF175 DFSMSDSS V1R13.0 DATA SET SERVICES > - RESTORE INDDNAME(TAPE01) - > DATASET(INCLUDE(DBU3705.SYSCICS.**)) - > OUTDDNAME(DASD01) - > STORCLAS(SYSP0101) - > REPLACE > ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND > 'RESTORE ' > ADR109I (R/I)-RI01 (01), 2014.256 09:53:27 INITIAL SCAN OF USER CONTROL > STATEMENTS COMPLETED > ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK > 0ADR006I (001)-STEND(01), 2014.256 09:53:27 EXECUTION BEGINS > 0ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS > IN PHYSICAL DATA SET FORMAT AND WAS CREATED BY > > DFSMSDSS VERSION > 1 RELEASE 13 MODIFICATION LEVEL 0 ON > 0ADR709E (001)-VDSS (01), AN ERROR OCCURRED IN THE STORAGE > MANAGEMENT SUBSYSTEM WHILE ALLOCATING DATA SET > > DBU3705.SYSCICS.BTCH. SMS > MESSAGES FOLLOW. > IGD01010I STORCLAS SYSP0101 - STORGRP=SYSP010 > IGD17101I DATA SET DBU3705.SYSCICS.BTCH > NOT DEFINED BECAUSE DUPLICATE NAME EXISTS IN CATALOG ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
