Joes (and Radoslaw), You both have moved me more towards the center, certainly, of this issue. Excellent points. I just was brought up in a centralized environment, where CONTROL and MANAGED storage were the words of the day. How do you coordinate recovery well when there are multiple groups, both in and outside the data center, responsible for recovering everything? Obviously, it can be done, but much harder IMO.
Products such as ABARS (ok... I know) and other 3rd party DR backup products can group application data set backups together - on a point in time - and allow for proper recovery. That, of course, takes money though and I can see where your model would make sense and work. All the best, Scott T. Harder On 5/12/09, Joel C Ewing <[email protected]> wrote: > 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 > > Obviously > Scott T. Harder wrote: >> I can see where IF you have ALL the appropriate security profiles set up >> properly, then I suppose I see your point. For me, though, I would rather >> cut off access completely. I would ask "Why do they need it?" If your >> SMS >> constructs and ACS routines, and your backups, are all set up properly, >> why >> do they need to be moving data around or backing it up with DSS??? >> >> I think my mom *did* say that once or twice, btw. ;-) >> >> All the best, >> Scott T. Harder >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]]on Behalf >> Of R.S. >> Sent: Wednesday, May 06, 2009 4:28 AM >> To: [email protected] >> Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib] >> >> Scott T. Harder pisze: >>> Sorry, guys. In my world, Application Programmers have no business >>> having >>> access to Storage Management utilities like DSS. Period. That needs to >>> remain a centralized function. >> >> Why? >> Because mama said that? >> Poor justification. >> >> In my shop appliccation prgrammers have access to any tool they want, >> UNLESS it is dangerous, i.e. bypasses regular security checking. >> That's why DSS is available to everyone, but STGADMIN.ADR.STGADMIN.** is >> not. >> >> -- >> Radoslaw Skorupka >> Lodz, Poland > ... > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] 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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
