Maybe we should prepare him for DELETION (FREEZE).
-----Original Message-----
From: mf db
Sent: Wednesday, March 12, 2014 11:26 AM Newsgroups: bit.listserv.ibm-main
To: [email protected]
Subject: Re: Volume Restriction Using an EXIT
"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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
