Protected Datasets in ISPF
eve_...@my-deja.com
How can I protect a single dataset with a password?
I allocate a new dataset (PDS) in 3.3 (Utilities) in the ISPF
Primary Option Menu.
No problem. But now I would like to set a password for that and I
cannot find any point in the allocate menue to set a password.
(But in the dataset information panel,
I have a point: "Data Set Password .. (If password protected)"
Any ideas?
Many thanks in advance
Eve
Sent via Deja.com http://www.deja.com/
Before you buy.
Doug Nadel
>How can I protect a single dataset with a password?
Most shops don't support password protection anymore. The way to
protect a data set is through RACF (from IBM) or 3rd party ACF/2 or
TopSecret (CA?)
The password field on the panel is basically there for the very few
shops that still use such things. We would like to remove it, but
always hear one or 2 places say they have a use for it, so it has
remained on the panels and service call interfaces years past what I
would think was a reasonable time.
There have been requirements to make that field optional. So far IBM
has considered it too large a maintanence problem to maintain 2 sets
of panels, for this small functional change, and other options
(non-display, conditional compiles, etc) have other problems.
Doug Nadel
----------------------------------------
ISPF & OS/390 Tools & Toys page:
http://www.mindspring.com/~somebody/
Eve Beck
thanks a lot for your quick answer, so I see, there is no way in TSO to
protect a single dataset, (except to log off).
Unfortunately, my TSO had also no QW function, so I cannot look for my
self for any help informations. And to find the requested informations
in the Internet IBM Books, is very a painful thing.
A couple of days ago I looked for the syntax to generate GDG files.
Mean I looked for the IDCAMS function. There are 8 IBM books with
thousands of pages about JCL, but after researching DAYS in those
books, I could not find any Information about that.
Thank God, there is an ISFP Newsgroup and your very informative ISPF &
OS/390 site in the internet. Thanks for that.
Best Regards
Eve Rosina Beck
In article <6ajf5so2i74860hkj...@4ax.com>,
McKown, John
to be brutally honest, that "password" is using a very old-style facility in MVS. I would bet that it is not even available at your shop. I know that I removed that facility a LONG time ago. Today, most shops use a security package such as RACF, ACF2, or Top Secret to secure their datasets. Most of the time, the security people take a very dim view of users protecting their own datasets. They generally want you to ask them and give a fairly good reason. However, there is a possibility that you can do it yourself. Try the ADDSD command in option 6. Something like:
ADDSD ('my.dataset.name') GENERIC NOSET UACC(READ)
You might want UACC(NONE) if you don't want people even reading the dataset.
If you can do this, you might still get a nastygram from the security staff. This method does not require you to use a password to access the dataset.
-----Original Message-----
From: eve_...@MY-DEJA.COM [SMTP:eve_...@MY-DEJA.COM]
Sent: Wednesday, December 15, 1999 10:39 AM
To: ISP...@listserv.nd.edu
Subject: Protected Datasets in ISPF
Hi Friends,
How can I protect a single dataset with a password?
I allocate a new dataset (PDS) in 3.3 (Utilities) in the ISPF
Primary Option Menu.
No problem. But now I would like to set a password for that and I
cannot find any point in the allocate menue to set a password.
(But in the dataset information panel,
I have a point: "Data Set Password .. (If password protected)"
Any ideas?
Many thanks in advance
Eve
Kalinich, John
John, don't use this facility, use your external security package instead.
Hi Friends,
Any ideas?
Sent via Deja.com http://www.deja.com/ <http://www.deja.com/>
Before you buy.
Metz, Seymour
he said "Most shops don't support password protection anymore." You didn't
ask how to protect the data set, but rather how to do it with a password.
Now, I don't know what software you've got installed at your shop, but at
most shops a TSO user can protect a single data set as long as that does not
conflict with installation policy. The details depend on what security
software the installation is running. We're running RACF, so I use PERMIT
(or the ISPF panels for RACF), but there are equivalent facilities in, e.g.,
ACF2.
Actually, in the bad old days RACF *only* let you protect single
data sets, and SKK gave that as one of the reasons to use ACF-2 instead of
RACF. Somewhat later IBM allowed you to use generic profiles, which are
normally much more convenient.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Eve Beck [SMTP:eve_...@MY-DEJA.COM]
> Sent: Wednesday, December 15, 1999 4:57 PM
> To: ISP...@listserv.nd.edu
> Subject: Re: Protected Datasets in ISPF
>
> Hi Doug,
> thanks a lot for your quick answer, so I see, there is no way in TSO to
> protect a single dataset, (except to log off).
>
> Unfortunately, my TSO had also no QW function, so I cannot look for my
> self for any help informations. And to find the requested informations
> in the Internet IBM Books, is very a painful thing.
>
> A couple of days ago I looked for the syntax to generate GDG files.
> Mean I looked for the IDCAMS function. There are 8 IBM books with
> thousands of pages about JCL, but after researching DAYS in those
> books, I could not find any Information about that.
>
> Thank God, there is an ISFP Newsgroup and your very informative ISPF &
> OS/390 site in the internet. Thanks for that.
>
> Best Regards
> Eve Rosina Beck
>
> In article <6ajf5so2i74860hkj...@4ax.com>,
> Doug Nadel <some...@mindspring.com> wrote:
> > On Wed, 15 Dec 1999 16:38:32 GMT, eve_...@my-deja.com wrote:
> >
> > >How can I protect a single dataset with a password?
> >
> > Most shops don't support password protection anymore. The way to
> > protect a data set is through RACF (from IBM) or 3rd party ACF/2 or
> > TopSecret (CA?)
> >
> > The password field on the panel is basically there for the very few
> > shops that still use such things. We would like to remove it, but
> > always hear one or 2 places say they have a use for it, so it has
> > remained on the panels and service call interfaces years past what I
> > would think was a reasonable time.
> >
> > There have been requirements to make that field optional. So far IBM
> > has considered it too large a maintanence problem to maintain 2 sets
> > of panels, for this small functional change, and other options
> > (non-display, conditional compiles, etc) have other problems.
> >
> > Doug Nadel
> > ----------------------------------------
> > ISPF & OS/390 Tools & Toys page:
> > http://www.mindspring.com/~somebody/
> >
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
DP...@uk.ibm.com
Duncan!!!!!!
Eve Beck
it is now clear to me, that the password protection depends on the
installation. It was the point "password" in the allocate display,
which made to me that mistake.
So my problem is, that the RACF protects ALL of my datasets, but
sometimes (frankly speaking) I let check up some of my programms from
an other one, to detect maybe an error, so this person had now access
to ALL of my datasets. But I store also in TSO all of my privat datas
(my labor time records, telefonnumbers from friends, etc,...)
You see my problem ??
Bye, Eve
In article
<0D93FE5CA0BED11194CB...@nsfmail01.nsf.gov>,
Auger, Richard C
OK, not sure what your installation prefers in the way of RACF
dataset profiles - discrete or generic. If it's discrete, you can create
your own profile for just one dataset, specify a volser, and then grant
people access to just that dataset. If it's generic, it's just the same,
but you don't have to specify a volser.
For example, assume that your userid is USER1. All of your datasets start
with USER1 as the high level qualifier. You want to grant just one
programmer (uerid = 'Fred') access to your panel library, let's say it's
called USER1.MY.ISPPLIB. No one else is to even see it.
You then just issue the following commands:
AD 'USER1.MY.ISPPLIB' UACC(NONE) GENERIC
PE 'USER1.MY.ISPPLIB' GENERIC ACCESS(READ) ID(FRED)
If you don't know what RACF profiles you already have for your datasets,
enter:
SR
Cheers,
Richard Auger,
RACF Adminstrator
Jeremy C B Nicoll
Eve Beck <eve_...@my-deja.com> wrote:
> OK Shmuel,
> it is now clear to me, that the password protection depends on the
> installation. It was the point "password" in the allocate display,
> which made to me that mistake.
> So my problem is, that the RACF protects ALL of my datasets, but
> sometimes (frankly speaking) I let check up some of my programms from
> an other one, to detect maybe an error, so this person had now access
> to ALL of my datasets. But I store also in TSO all of my privat datas
> (my labor time records, telefonnumbers from friends, etc,...)
> You see my problem ??
> Bye, Eve
The big problem here (if you approach your data/computer security people)
is that most sites formally prohibit use of their computer systems for
users' personal data. Putting that another way, is there a single
*business reason* why one user should limit access to 'their' datasets?
Usually access is controlled per team/dept/function.
You might be better keeping this data on a floppy for your PC, or if you
must keep it on the company mainframe, protect it with some simple
encryption (ie you keep the data scrambled up & your programs know how to
unscramble it). Having said that I've worked in a site where that would
have been a quick way of getting an interview with the boss...
--
Jeremy C B Nicoll - my opinions are my own.
Eve Beck
I have a total other view to that.
With 'privat' I do not mean only the telefonnumbers from my friends or
my mother in law, etc,
There is also a todo list for the next few days for my company, meeting
results, access codes to some other programs, my next scheduls and so
on. And if I work for a company, I should have at least the possibility
to store these datas!
Everyone which have a computer have at least a schedul or a mail
programm! Instead of that, I use a simple TSO file.
And as I do not trust our PC operating system, I decided to store my
datas in the TSO. This is surely the best of all computer systems. (run
since decades, permanetly backup, etc,..). And I can tell you, my boss
is happy, that I like (trust) TSO more than other PC operating systems!
Newertheless I thank you for your opinion!
Eve Rosina (TSO) Beck ;)
In article <49715e00...@omba.demon.co.uk>,
Metz, Seymour
DATA SET PROFILES", create a profile for the data set 'userid.**' with a
UACC of NONE and profiles for the data sets that you want to share with a
UACC of READ or whatever. If your installation does not use enhanced
generics the you'll have to call your initial profile 'userid.*' rather than
'userid.**'. Check the archives for the RACF list; there's a discussion of
the tradeoffs between discrete and generic profiles for individual data
sets.
If you don't have access to the RACF panels then you will have to use the
TSO commands ADDSD and PERMIT.
The bottom line is that RACF allows you to do exactly what you want, but
that the solution does not involve password protection for your data sets.
Whether your installation policy allows it is a question that I can't
address.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Eve Beck [SMTP:eve_...@MY-DEJA.COM]
> Sent: Thursday, December 16, 1999 4:17 AM
> To: ISP...@listserv.nd.edu
> Subject: Re: Protected Datasets in ISPF
>
Metz, Seymour
had data sets that I was required to protect from unauthorized access. And I
have yet to have a manager that wanted to act as my personal security
administrator; they've always taken the position that I had the authority to
issue my own permits, so I could damn well do so without bothering them
every time that I created a new data set. As for team function, I have never
seen low level security decisions made by committee. The person working with
the data is expected to know the rules and to protect them in accordance
with those rules.
BTW, at some shops those rules prohibit keeping critical data on your PC.
Shmuel (Seymour J.) Metz