Not a good idea. :) I don't do DFHSM full volume dumps anymore, as they once on a while caused extended enqueue difficulties. I run DFHSM backup and migration at the logical dataset level for user and my convience. We use FDRABR for DR backup at the volume level.
> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Rajesh Janakiraman > Sent: Friday, August 08, 2014 11:39 AM > To: [email protected] > Subject: Re: Restoration of Multivolume GDG from Physical Dump Backup > > Rex, > Yes! tat's right. > > > On Fri, Aug 8, 2014 at 11:14 PM, Pommier, Rex > <[email protected]> > wrote: > > > 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:IBM- > [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 > > > > > > -- > Regards, > *Rajesh Janakiraman* > > ---------------------------------------------------------------------- > 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
