This looks to be interesting : http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.idai600%2Fauthcls.htm
On Wed, Mar 12, 2014 at 8:56 PM, mf db <dbajava...@gmail.com> wrote: > "The board is at the end of the month?" > > ?? > > > On Wed, Mar 12, 2014 at 8:55 PM, Micheal Butz <michealb...@optonline.net > >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" <jcew...@acm.org> 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 jcew...@acm.org > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
