I did not see this hit the list, so if it did, I apologize for the dup... Joel (and Radislaw) sp?
You have both moved me far more towards the center of this issue. Excellent points, both. It's just that I was "brought up" in a CENTRALIZED/MANAGED environment and that is hard to shake. How do you coordinate recovery from multiple groups, both in and outside the data center. Obviously, it can be done, but much harder IMO. There are products such as ABARS (ok... I know) and other 3rd party products that wrap up application backups on a point in time; then allow for recovery TO that point in time. Of course, that costs money, so I can see where you model, Joel, works and makes sense. All the best, Scott T. Harder On 5/12/09, O'Brien, David W. (NIH/CIT) [C] <obrie...@mail.nih.gov> wrote: > For that you need an add-on product like Mainstar's ABARs Manager. At least > that's what it was called a few years ago. > > Dave O'Brien > NIH Contractor > ________________________________________ > From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Joel > C Ewing [jcew...@acm.org] > Sent: Tuesday, May 12, 2009 5:22 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib] > > O'Brien, David W. [C] , NIH/CIT wrote: >> Why not use HSM ABAR Backups which include migrated datasets? > > Try figuring out how to recall a single dataset from an ABARS backup and > it becomes clear ABARS is really designed with recovery in mind, not > with providing easy access to archives of specific datasets. > JC Ewing >> >> Dave O'Brien >> NIH Contractor >> ________________________________________ >> From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of >> Mark Jacobs [mark.jac...@custserv.com] >> Sent: Tuesday, May 12, 2009 11:37 AM >> To: IBM-MAIN@bama.ua.edu >> Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib] >> >> R.S. wrote: >>> Roach, Dennis (N-GHG) pisze: >>>> As a sysprog, I agree. >>>> For the applprog, verify what happens when a data set is on ML1 or ML2 >>>> and a masked include is used. DSS used to skip these and still have a >>>> zero return code. This caused the application source to be left off of >>>> their DR tapes. >>> This is well-know and documented behavior. We shouldn't assume, that >>> applprog is less intelligent than sysprog. >>> And this "gotcha" is no justification to for denying ADRDSSU at all. >>> Applprogs (everyone) can make mistake without ADRDSSU as well. >>> Applprogs are probably allowed to use many tools which they don't >>> know well. >>> >> >> Jobstep 1 - HRECALL with wait option >> Jobstep 2 - DFDSS processing. >> >> It's not rocket science. > > A simpler and more fool-proof method: > Instead of a separate step, hang an unreferenced DD statement on the > actual DFDSS step for all datasets that "must" be dumped and which have > any possibility of being migrated. Step allocation will cause all > DD-referenced datasets to be recalled before step execution proceeds, > and there is no possibility of migration occurring before the dump > (which could happen if a separate recall step occurs just before DFHSM > interval migration, since the dataset is not opened to reset the > last-referenced date). If a dataset is migrated because it has not been > referenced as recently as the others in the backup step, it might also > make sense to question if it is appropriate for that dataset to be in > the same backup collection. > JC Ewing >> >> -- >> Mark Jacobs >> Time Customer Service >> Tampa, FL >> ---- > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- All the best, Scott T. Harder ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
