Personally I am thinking yes because we ran the same backups without dumpconditioning and we were able to restore the same volumes with no problems.
Dean Nai On 11/15/19, 6:04 AMEST, "IBM Mainframe Discussion List on behalf of Richards, Robert B." <IBM-MAIN@LISTSERV.UA.EDU on behalf of 000001c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Does any of this apply and/or shed some light in this case seeing that you >used DUMPCONDITIONING? See below: > >DUMPCONDITIONING — Allows you to make a copy of the source volume in a full >volume copy operation—including volume index information—while keeping the >target volume online. Use this keyword when you want to create a copy of the >source volume for backup purposes, rather than to allow applications to use >the target volume. > >With DUMPCONDITIONING in effect, the volume serial number of the target volume >does not change, and the target volume remains online after the copy. The VVDS >and VTOC index names on the target volume do not change to match the target >volume serial number; they continue to match the source volume serial number. > >In Step 2 , for example, you can include the DUMPCONDITIONING keyword on the >full volume copy command to allow the target volume to remain online for >dumping. > >The target of a full volume copy operation using DUMPCONDITIONING is referred >to as a conditioned volume. A full volume dump of a conditioned volume appears >as if it were dumped from the original source volume of the copy operation. >However, if the conditioned volume is copied back using DUMPCONDITIONING, >conditioning is not performed on the original source volume. Instead, DFSMSdss >recognizes that it is copying from the target of a previous conditioned-backup >and recovers the original source volume. > >For example, suppose that you specify the DUMPCONDITIONING keyword when you >perform a full volume copy of volume VOL001 to volume VOL002. If you then >perform a full volume dump of VOL002 to tape, the output appears as if you had >dumped VOL001 directly. Now suppose that you copy VOL002 back to VOL001. Here, >the VOL002 volume serial number is not copied to VOL001's volume label, >because DFSMSdss treats VOL002 as a copy of VOL001. > >This example assumes that the source volume VOL001 has an indexed VTOC. If the >source volume does not have an indexed VTOC, a full volume dump of the >conditioned volume VOL002 would not look as if it was dumped from the original >source volume VOL001. Rather, it would be an exact image of the conditioned >volume. A subsequent full volume restore with the COPYVOLID keyword specified >results in the target volume having the same serial number as the conditioned >volume. > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Nai, Dean >Sent: Wednesday, November 13, 2019 3:44 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: DFDSS backup retore > >ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' >ADR109I (R/I)-RI01 (01), 2019.317 14:10:45 INITIAL SCAN OF USER CONTROL >STATEMENTS COMPLETED ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT >FOR THIS TASK ADR006I (001)-STEND(01), 2019.317 14:10:45 EXECUTION BEGINS >ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL >VOLUME FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION > 2 RELEASE 3 MODIFICATION LEVEL 0 ON 2019.287 01:30:53 > ADR808I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED WAS CREATED > FROM A CONDITIONED VOLUME ADR370E (001)-ZBLK (01), INVALID SEQUENCE NUMBER ON > DDNAME INDD1 LAST 00000020 NEXT 00000021 ADR006I (001)-STEND(02), 2019.317 > 14:11:06 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2019.317 14:11:07 TASK > COMPLETED WITH RETURN CODE 0008 ADR012I (SCH)-DSSU (01), 2019.317 14:11:07 > DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0008 FROM: > TASK 001 > >Dean Nai > > > > > > > >On 11/13/19, 3:22 PMEST, "IBM Mainframe Discussion List on behalf of retired >mainframer" <IBM-MAIN@LISTSERV.UA.EDU on behalf of retired-mainfra...@q.com> >wrote: > >> EXTERNAL: Do not open attachments or click on links unless you recognize >> and trust the sender. >> >>Please provide the complete error message. >> >>The error message does not address tape labels. (A wrong label would produce >>a system error before DFDSS got to the tape.) It says the sequence number of >>data records is wrong. This may indicate a corrupt file. >> >>What system level are you at. There is a 5 year old APAR that addresses this >>issue. >> >>> -----Original Message----- >>> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On >>> Behalf Of Nai, Dean >>> Sent: Wednesday, November 13, 2019 11:55 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: DFDSS backup retore >>> >>> Has anyone ever run into a problem where they have full volume >>> backups that produce a ADR370E message when trying to restore? That >>> message says the label and DSN on the tape don't match although I know they >>> do. Any thoughts? >>> >>> Control cards: >>> >>> Restore - >>> Admin - >>> Inddname(indd1) outddname(outdd1) - >>> Full purge copyvolid >>> >>> //indd1 dd >>> dsn=backup.dly.smflgb.g0449v00,label=(1,sl),unit=tape,disp=old,vol=se >>> r=tap001 >>> //outdd1 dd vol=ser=sc560c,unit=3390,disp=old >>> >>> Dean Nai >> >>---------------------------------------------------------------------- >>For IBM-MAIN subscribe / signoff / archive access instructions, send >>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
