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.
Dennis Roach GHG Corporation Lockheed Martin Mission Services Flight Design and Operations Contract NASA/JSC Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax: (281)336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Farley, Peter x23353 > Sent: Tuesday, May 12, 2009 10:16 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib] > > Thank you from this applications programmer for the most sensible and > reasonable answer and attitude I have yet seen. > > It would be terrific if every systems programmer and storage > administrator and auditor and management were so enlightened. > > Peter > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > > Behalf Of Joel C Ewing > > Sent: Tuesday, May 12, 2009 10:58 AM > > To: IBM-MAIN@bama.ua.edu > > Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib] > > > > Obviously some shops must be radically different. In a full SMS > shop, > > applications programmers of course have no business doing volume- > level > > or volume-specific operations, and to prevent override of RACF access > > restrictions ADRDSSU ADMIN authority must be tightly restricted to > those > > authorized to perform DASDAdmin functions; but for us to deny > > applications access to DFDSS for dataset level backup/restore > functions > > on their own application datasets would be counterproductive. > > > > We find that SMS configuration and conventions can reasonably be used > to > > handle a few backups, but are completely inadequate for many others > > where the only kinds of backups that make sense are driven by > > application-level events, with sets of related datasets that must be > > handled as a consistent group, and/or with archival retention > > requirements that don't fit within the rather simplistic SMS > management > > capabilities. > > > > As a SysProg it is part of my responsibility to see that we can > recover > > the data center as a whole to a point-in-time in the event of a data > > center failure. But, I do not have the time, the inclination, or the > > responsibility to determine what additional backups many different > > individual application areas may need in order to recover from > > mini-disasters caused by application program failures, to reprocess > old > > data because of changed end-user requirements, or to meet data > archival > > requirements imposed by management or law specific to that > application > > area. > > > > Given that there are of necessity backups that must be designed by > and > > maintained by non-SysProg, applications people who are the ones in > the > > best position to understand their archival requirements, to deny them > > ADRDSSU, effectively limiting them to sequential file backups and > > awkward and inefficient file stacking on tape backups, makes little > sense. > > JC Ewing > > > This message and any attachments are intended only for the use of the > addressee and > may contain information that is privileged and confidential. If the > reader of the > message is not the intended recipient or an authorized representative > of the > intended recipient, you are hereby notified that any dissemination of > this > communication is strictly prohibited. If you have received this > communication in > error, please notify us immediately by e-mail and delete the message > and any > attachments from your system. > > > ---------------------------------------------------------------------- > 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
