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:[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
