I think the reason he's running multiple steps is because of the format of his dump tapes. I got the picture he did full volume dumps on a volume-by-volume basis, and now he's trying to recover a multi-volume dataset at the dataset level.
Rex -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of retired mainframer Sent: Friday, August 08, 2014 12:26 PM To: [email protected] Subject: Re: Restoration of Multivolume GDG from Physical Dump Backup If you are restoring a single dataset, why are you running multiple jobs? One job with ODY specifying four target volumes or omitting ODY completely would seem to be the way. After the partial restore you are experiencing, what does the catalog say about the BACKAMSL dataset? > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Rajesh Janakiraman > Sent: Friday, August 08, 2014 5:01 AM > To: [email protected] > Subject: Re: Restoration of Multivolume GDG from Physical Dump Backup > > * You are trying to restore a dataset but you say it already exists. Are > you referring to the VPP1 dataset or the BACKAMSL dataset? > -- I'm referring to BACKAMSL dataset > > You say the original consumed four volumes but you are trying to > restore it to one. Will it fit? Have you tried letting DSS decide where to > place the dataset? > -- I've used four different volumes to restore. i.e. each ODY has different > volumes while restoration > > You say that three volumes were restored successfully but 3.4 shows 0%. > That appears to be allocation without any restoration. What makes you think > any data was restored? > -- For succeeded three volumes has some values, but last one has 0% used. I > just gave the info > > Your description implies that you ran four jobs and three succeeded. > Since there is only one dataset, what were the other jobs? > -- i ran all 4 in same JCL, in which 3 volumes were restored and one showed > this issue. Later i tried with restoring the dataset which shows the issue > in single JCL even though it shows the same. > > Are there any SMS conflicts between the original dataset attributes (when it > was backed up) and the default attributes for the BACKAMSL HLQ? > -- Nope there was no such conflicts. > > The error message addresses deleting a dataset which should not currently > exist since you did not specify replace. Is this the first attempt to > restore the dataset? If not, you may be dealing with residue from previous > attempts. > -- My colleague tried restoring and even he faced the same issue. > > > > On Fri, Aug 8, 2014 at 12:55 PM, retired mainframer < > [email protected]> wrote: > > > Your details are a little confusing: > > > > You are trying to restore a dataset but you say it already exists. > > Are > > you referring to the VPP1 dataset or the BACKAMSL dataset? > > > > You say the original consumed four volumes but you are trying to > > restore it to one. Will it fit? Have you tried letting DSS decide where > > to > > place the dataset? > > > > You say that three volumes were restored successfully but 3.4 shows > > 0%. > > That appears to be allocation without any restoration. What makes you > > think > > any data was restored? > > > > Your description implies that you ran four jobs and three succeeded. > > Since there is only one dataset, what were the other jobs? > > > > Are there any SMS conflicts between the original dataset attributes (when > > it > > was backed up) and the default attributes for the BACKAMSL HLQ? > > > > The error message addresses deleting a dataset which should not currently > > exist since you did not specify replace. Is this the first attempt to > > restore the dataset? If not, you may be dealing with residue from previous > > attempts. > > > > > -----Original Message----- > > > From: IBM Mainframe Discussion List [mailto:IBM- > [email protected]] > > > On Behalf Of Rajesh Janakiraman > > > Sent: Thursday, August 07, 2014 6:18 PM > > > To: [email protected] > > > Subject: Restoration of Multivolume GDG from Physical Dump Backup > > > > > > Hi All, > > > > > > Please help on restoring multi-volume GDG dataset. I've used the below > > > JCL. > > > > > > //MULTPS JOB 'DUMP',CLASS=A,NOTIFY=&SYSUID, > > > // REGION=0M > > > //REST EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' > > > //TAPE7 DD UNIT=892,VOL=SER=ZZZ167, > > > // LABEL=(157,SL),DSNAME=DUMPFULL.XXX325, > > > // DISP=OLD > > > //SYSPRINT DD SYSOUT=* > > > //SYSIN DD * > > > RESTORE DATASET (INCLUDE(VPP1.CMS.GDG.FASL.G0236V00)) - > > > INDDNAME(TAPE7) RENAMEU(BACKAMSL) - > > > ODY(YY1336) > > > > > > > > > We are getting the below Error Code msg, > > > > > > ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE > DELETING > > > DATA SET > > > BACKAMSL.CMS.GDG.FASL.G0236V00. RETURN CODE IS 008, > > > REASON CODE IS EG-042 > > > ADR415W (001)-TDDS (02), NO DATA SETS WERE COPIED, DUMPED, OR > > > RESTORED > > > FROM ANY > > > > > > The mentioned GDG is present in 4 volumes while trying to restore 3 > > > volumes were restored successfully and this one has an issue. > > > > > > While checking the dataset using volser in option 3.4 it allocated tracks > > > and it is 0% Used. But when dataset was backup to the tape, volume was > > 99% > > > Used. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
