"The board is at the end of the month?" ??
On Wed, Mar 12, 2014 at 8:55 PM, Micheal Butz <[email protected]>wrote: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
