Sounds like a good idea. I will give it a try. Thanks.
________________________________ From: "McKown, John" <[email protected]> To: [email protected] Sent: Thursday, 6 September 2012 1:30 PM Subject: Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS And, if you do option #2 (data set restore syntax), then you can do PARM='TYPRUN(NORUN)' which will read the tape and list the data set names on it, but not attempt to restore them. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Pommier, Rex R. > Sent: Thursday, September 06, 2012 11:54 AM > To: [email protected] > Subject: Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS > > John, > > It depends on what you're actually trying to accomplish here. If all > you want to do is verify that the COPYDUMP will restore successfully > and the output is throw-away, you can do one of these (I'm sure there > are many other things you could do as well): > > 1. Do the full volume restore. I am pretty certain that DFDSS will > knock the volume you just restored offline and leave the original > source online. Clip the offline volume to a different volser. Bring > the renamed volume online. Verify the files are all there and look > good. Take the volume offline and initialize it to throw the data > away. > > 2. Do a dataset level restore using INCLUDE and/or EXCLUDE parameters > to just bring back a subset of the data on the volume (you will > possibly need to put some RENUNC statements in there as well due to the > SMS versus non-SMS issue). If you can pull datasets off the full > volume COPYDUMP, is that enough of a test to make sure you can use the > COPYDUMP output? > > Rex > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of John Dawes > Sent: Thursday, September 06, 2012 11:44 AM > To: [email protected] > Subject: Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS > > Rex. > > I did the backup myself (used COPYDUMP) and it is from a full volume > backup. I used RESTORE FULL INDDNAME(TAPE1) OUTDDNAME(DASD1). > I cannot put the original volume offline because these contain all our > pds libs. This is why I am trying the exercise of restoring the volume > (physically) to a non-sms managed volume. This way no dsns weill b > cataloged etc. I am using BYPASSACS because I thought I could bypass > SMS. > > > > > ________________________________ > From: "Pommier, Rex R." <[email protected]> > To: [email protected] > Sent: Thursday, 6 September 2012 12:30 PM > Subject: Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS > > John, > > I'm going to take your word that the original DUMP that you created the > COPYDUMP from was a full volume dump. That being said, the BYPASSACS > parameter you have in your RESTORE attempt is only valid for dataset > level restores, not full restores. You will need to use a restore > parameter similar to what John McKown mentioned below. You will need > something like this instead of the restore you are using: > > RESTORE FULL INDDNAME(TAPE1) OUTDDNAME(DASD1) > > If you leave the keyword FULL off, DFDSS is looking for a dataset level > restore. I don't see NOCOPYVOLID in the manual, but there is a blurb > that says for an SMS managed source volume 9or a source volume with a > VSAM dataset on it), you must use COPYVOLID. You will probably need to > restore the full volume with the original volser, which will knock it > offline, clip the volser to something else, then if you really want it > non-SMS, run a convertv routine to make it non-SMS. > > Rex > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of John Dawes > Sent: Thursday, September 06, 2012 10:37 AM > To: [email protected] > Subject: Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS > > I am trying to do a full volume restore to a non-SMS volume. The > backup which was created is of a SMS managed volume. I want to > validate the backup which was made using DFDSS COPYDUMP. > > > > ________________________________ > From: "McKown, John" <[email protected]> > To: [email protected] > Sent: Thursday, 6 September 2012 11:08 AM > Subject: Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS > > Are you trying to do a full volume restore, or a logical data set > restore? Looks like the latter. In which case, as the messages > indicate, you have not specified which data set names/pattern to > restore. You'd need a DATASET(INCL(**)) to restore all the data sets. > If you want to do a full volume restore, then change the RESTORE to be > something like: > > RESTORE INDDNAME(TAPE1) OUTDDNAME(DASD1) NOCOPYVOLID > > ________________________________________ > From: IBM Mainframe Discussion List [[email protected]] On > Behalf Of John Dawes [[email protected]] > Sent: Thursday, September 06, 2012 9:42 AM > To: [email protected] > Subject: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS > > G'Day, > > I am trying to perform a full volume restore of a SMS volume to a spare > volume which is not SMS managed. I am encountering a problem and tried > several things: > The output volume has a different VOLSER. The reason for this is that > I want to ensure that the tape which is being used to perform the > restore could be read because it was created by a DFDSS COPYDUMP. > Below is the restore parm and the error messages. We are running > RELEASE z/OS 01.11.00 > > RESTORE INDDNAME(TAPE1) OUTDDNAME(DASD1) PURGE - > BYPASSACS(**) - > NULLSTORCLAS - > NULLMGMTCLAS > ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND > 'RESTORE ' > ADR109I (R/I)-RI01 (01), 2012.250 10:34:33 INITIAL SCAN OF USER CONTROL > STATEMEN ADR138E (001)-RI01 (02), REQUIRED (SUB)PARAMETER OF 'DATASET ' > IS MISSING ADR139E (001)-RI01 (01), INCONSISTENT PARAMETERS INVOLVING > 'BYPASSACS ' > ADR138E (001)-RI01 (02), REQUIRED (SUB)PARAMETER OF 'DATASET ' IS > MISSING ADR139E (001)-RI01 (01), INCONSISTENT PARAMETERS INVOLVING > 'NULLSTORCLAS ' > ADR138E (001)-RI01 (02), REQUIRED (SUB)PARAMETER OF 'DATASET ' IS > MISSING ADR139E (001)-RI01 (01), INCONSISTENT PARAMETERS INVOLVING > 'NULLMGMTCLAS ' > ADR131E (001)-RI03 (01), ABOVE TEXT BYPASSED UNTIL NEXT COMMAND ADR017E > (001)-CLTSK(01), 2012.250 10:34:33 TASK NOT SCHEDULED DUE TO ERROR. > TASK ADR012I (SCH)-DSSU (01), 2012.250 10:34:33 DFSMSDSS PROCESSING > COMPLETE. HIGHEST > SYNTAX > TASK 001 > > Can this be done i.e. restore a SMS managed volume to a NON-SMS volume? > > Thanks. > > ---------------------------------------------------------------------- > 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 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN > > The information contained in this e-mail may contain confidential > and/or privileged information and is intended for the sole use of the > intended recipient. If you are not the intended recipient, you are > hereby notified that any unauthorized use, disclosure, distribution or > copying of this communication is strictly prohibited and that you will > be held responsible for any such unauthorized activity, including > liability for any resulting damages. As appropriate, such incident(s) > may also be reported to law enforcement. If you received this e-mail in > error, please reply to sender and destroy or delete the message and any > attachments. Thank you. > > ---------------------------------------------------------------------- > 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 > > The information contained in this e-mail may contain confidential > and/or privileged information and is intended for the sole use of the > intended recipient. If you are not the intended recipient, you are > hereby notified that any unauthorized use, disclosure, distribution or > copying of this communication is strictly prohibited and that you will > be held responsible for any such unauthorized activity, including > liability for any resulting damages. As appropriate, such incident(s) > may also be reported to law enforcement. If you received this e-mail in > error, please reply to sender and destroy or delete the message and any > attachments. Thank you. > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
