One more thing The board is at the end of the month? Sent from my iPhone
> On Mar 12, 2014, at 11:05 AM, "Joel C. Ewing" <[email protected]> wrote: > >> On 03/12/2014 06:53 AM, mf db wrote: >> Hello Group, >> >> Is there an exit which can help me to restrict a group of ID to access >> another Volume(Which has list of datasets). >> >> >> For example : JLAB001 must be restricted to access any dataset sitting on >> JPM009. >> >> >> I am at Z/OS 1.8 level >> >> Peter > > Your wording is unclear: Is the object (1) to only grant access to the > data sets on the specific volume to members of the specific group; or > (2) to only deny access to the specific volume to members of the > specific group, or (3) to allow members of the specific group access to > the volume and its data sets but restrict (deny) their access to any > other volume,...? And of course it makes a difference whether one is > discussing DASD volumes or tape volumes. > > Aside from that and assuming you are talking about DASD volumes and are > using SMS (you really should be), managing DASD data set security on a > volume level is not a good approach. Restricting new data set > allocation access on "system" volsers of course makes sense, but can be > done with SMS ACS routines and RACF. In an SMS world, access to > existing data sets should be a security attribute associated with the > data set and not dependent on the volume of residence, and restrictions > on target volumes for new data sets would typically be done by requiring > all non-system data sets to be under SMS and restricting access to the > SMS class or STORGRP associated with those volumes. > > Data sets typically need to move at some point during their lifetime and > their security requirements should go with them; DASD volume volsers > and unit addresses may need to change during DASD subsystem hardware > upgrades, and usually one would want the security of application and > system data on associated volumes to be unaffected by DASD hardware > changes. Data set naming conventions should be designed so that > security can be based on the data set name and not on the DASD volume of > residence. > > -- > Joel C. Ewing, Bentonville, AR [email protected] > > ---------------------------------------------------------------------- > 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
