Be sure you understand the installation's security rules. I can't
believe that there wouldn't be naming conventions in place that would
allow datasets to be named so as to get appropriate access protection
even for test/training/non-production datasets. If you are somehow
dealing with a special test or development environment where everyone
has access to everything, that sounds like a disaster waiting to happen.
RACF by default gives a user ALTER access (CREATE/UPDATE/READ/DELETE) to
any dataset with a high-level-qualifier (HLQ) of his own userid. These
datasets should be private to that user by default, unless the
installation has deliberately granted access to many others by explicit
PERMITS or by giving an exceptional number of users OPERATIONS authority
to access all datasets not explicitly denied. Either of those actions
seems highly unreasonable, but that doesn't mean some installations
might not have done it. Normally data that should be considered
"private" to one user would have his userid as HLQ.
Datasets that are to be shared by multiple users would normally be given
a HLQ that is not a userid, and explicit access would be granted to
specific RACF groups or users as required. There is no reason why
additional groups cannot be established (by a Security Admin) if new
access patterns arise.
RACF protects at the dataset level, not at the PDS member level. If you
have members with different security requirements, they will have to be
kept in distinct PDS libraries with different access permissions.
If your real goal is to prevent unauthorized updates to a specific
database, the UPDATE authority to that database should be restricted,
whether other users can get to your JCL or not. In z/OS, protection by
ignorance (of constructing functional JCL) is not an acceptable practice.
J C Ewing
Ram Balaji wrote:
Hi Anton/john,
John your assumptions are correct,
1)Iam just a programmer.
2)Sensitive data (I should have clearly explained this point).
My sensitive datas are training datasets which I have created dealing with
training database. Many times I see?people trying to explore my dataset and run
them. I dont mind ppl using my dataset but these program point?Training DB, Iam
bit worried about this.
I cant ask SAF to Protect since its my training dataset.
Moreover keeping it in a notepad file is good option. But cant we make it bit
easier(within Mainframes
3) Database should be visible to me alone.
4) Iam using Z/OS.
Hey JOHN
Thanks a lot for all your valuable suggestion.
I tried using TSO PROTECT , this is no more a working command.
Any other solution?
Hope I made it clear. Sorry for delayed response.
Regards,
Ram Balaji.S.
(Dying Hard to explore MainFrames)
-----Original Message-----
From: John McKown <[EMAIL PROTECTED]>
To: IBM-MAIN@BAMA.UA.EDU
Sent: Tue, 7 Oct 2008 6:08 pm
Subject: Re: PDS LOCk
On Tue, 7 Oct 2008, Anton Britz wrote:
Hi Ram,
Do not get confused with all these technical discussions that you received but
lets start at the very beginning :
a) Are you a User , a Systems programmer or just a programmer
For some reason, I just ASSuMEd that he was likely a programmer.
b) If you say "sensitive" data .. what do you mean by that
Good point. If it is personal data, then I'd strongly suggest that it does
not belong on a company machine.
c) Who should be able to see this data ? ex. Only you, Your Department
Again, on a company machine, "only you" should not be an option, IMO.
Reminds me of some foolish print operators at a place that I used to work.
The printer was a Xerox 8700 laser. The operators placed "sensitive
personal" information in a file on it, thinking that nobody else would
ever see it. Management was not amused when the machine was audited by a
Xerox person. They were quickly shown the error of their ways, and the
door. Any wonder that I'm paranoid? <grin>.
d) What operating system are you using
Do PDS'es exist on anything other than z/OS? I know that z/VSE has
something similar, but the name is different. At least according to my
fading memory.
Anton
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
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
