Were the dumps produced using physical or logical processing? Are BACKAMSL datasets managed by SMS? How does DSS know that the four datasets being restored are part of a single multi-volume dataset? Is the full BACKAMSL DSN part of a GDG?
The manual contains a whole bunch of special remarks regarding restoring a multi-volume non-VSAM dataset. Do any of them apply to your situation? Have you considered performing four separate volume restores? You could then manually catalog the new dataset. Or you could then perform a logical dump, clean out the volumes, and perform a single logical restore with a catalog option. > -----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:IBM- > [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
