I was pleased with the original email so I stashed it in a folder where I
keep useful explanations (sometimes mine, sometimes others'). It says here
I sent it 2013-02-23, it was to the TSO-REXX listserv and the subject line
was "sysdsn - dataset protected". It was strictly about RACF; I'll give TSS
some thought. A writer is never quite satisfied when rereading afterward,
so herewith a slight rewrite:
It's not true that ALL shops restrict the use of the RACF commands to the
RACF jocks, but I've been at some that do. Personally, as a RACF jock
myself, I side with the other folks; there's nothing wrong with non-RACF
people attempting to check their access ahead of time. But if your
installation has different ideas, all I can do is sigh sympathetically.
Still, IMO there's a good chance you'll be able to do it, using the LISTDSD
command. (That's assuming you're a RACF shop, of course.) LISTDSD is
abbreviated LD. For the following discussion, remember that the purpose of
the LD command, from RACF's point of view, is not for you to ask "do I have
access to this dataset?" but for ~me~ to ask "please show me the RACF
profile protecting this dataset". Still, you can use it to get your
information.
The syntax of the command is simple but there's a wrinkle to it. RACF has
both discrete and generic profiles. If you'll allow me to oversimplify a
bit, a generic profile is one with wildcard characters in it (perhaps
"SYS1.*"), and a discrete profile matches the exact DSN. RACF always picks
the most exact profile to protect a given dataset; but you may not know
ahead of time whether that profile will be discrete or generic.
Here's the basic form of the LISTDSD command as it might look in a REXX
program:
/* Let's say dsn="'HLQ.ISPF.ISPPLIB'" */
call outtrap 'LD.'
'LD DA('dsn')'
call outtrap 'OFF'
(Note that the DSN follows TSO conventions, ie single quotes around it if it
doesn't start with your prefix.) The wrinkle is this: The command above
asks for RACF to display a discrete profile, and if the best match is a
generic profile RACF will claim it couldn't find a matching profile. You
can get RACF to show you the most exact generic profile by adding the
GENERIC argument, like this:
'LD DA('dsn') GEN'
But if the profile that protects the dataset is discrete, again RACF will
come back empty.
Now, RACF is always willing to show me, as a security admin, any profile
that protects any dataset, so I can always see who has what access. But
most people can still try the command and get some information back. Here's
what the manual says: If you're not an admin, you can still get a response
if "You are on the profile's access list with at least READ authority". In
other words, if the profile that protects this dataset lets you read the
dataset, then you'll get a profile listing from the LD command. And if it
doesn't let you read it - I had to experiment a little to figure this out -
you can tell from the RC and the message you get back.
Here are the responses that I think your program needs to worry about:
RC=0, and LD. contains a listing: The listed profile applies to the dataset
you named, but you don't need to look at it; its mere presence proves that
it grants you at least READ access to the dataset. (But if you want to know
whether you have UPDATE access, see below.)
RC=4 and LD.1 contains message ICH35003I ("NO RACF DESCRIPTION FOUND
FOR..."): You didn't specify the GENERIC argument and there was no discrete
profile, or you did specify GENERIC and there was no generic profile.
RC=4 and LD.1 contains message ICH35002I ("NOT AUTHORIZED TO LIST..."):
RACF found a profile matching your command, but you don't have READ access
to the dataset.
So I'd write the program to ask the question twice, like this:
vr=AskRACF(dsn)
if vr=4 then vr=AskRACF(dsn 'GEN')
if vr=4 then /* the dataset is not protected; VERY unlikely */
MyAccessAllowed = (vr=0)
/* Now you can decide whether to try to read the DS. */
AskRACF:
parse arg dsn gen
call outtrap 'LD.'
'LD DA('dsn')' gen
call outtrap 'OFF'
if rc=0 then return 0 /* access allowed */
if rc=4 & abbrev(ld.1,"ICH35002I") then return 8 /* not allowed */
if rc=4 & abbrev(ld.1,"ICH35003I") then return 4 /* can't tell */
/* if some other outcome, diagnose error here */
---
Ok, that's about READ access. If you want to know whether you have UPDATE
access, it seems to me that you can still get there.
1) If you don't have READ access then you don't have UPDATE access. That's
a feature of RACF (one that is not shared by TSS and ACF2): In RACF, the
greater access automatically implies that you also have the lesser access.
2) If you do have READ access, then you get back RC 0 and the profile will
be in the OUTTRAP results; you can then read it to see what access you have.
Keep in mind, though, that the access may be assigned not to your ID
specifically but to a group, so you may have to know what groups your ID has
before you can interpret the results correctly.
---
As I said, this is RACF. Let me think about TSS; I may have to experiment a
bit to figure out what a non-admin can see when he tries to ask this
question.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* The way to keep a secret is to keep it. -Bob Bridges' advice to young
children */
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Farley, Peter
Sent: Tuesday, January 17, 2023 16:44
I don't know about Cameron, but I would be interested in a way to ask RACF
(or TSS if possible) from Rexx whether I have read access to a DSN.
Is that possible for a non-authorized "ordinary" user, or is that road the
kind that is normally blocked to prevent "insider snooping"?
If you posted here about it previously, can you pinpoint the date (or at
least the year and month) so one could effectively search the IBM-MAIN
archives?
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Bob Bridges
Sent: Tuesday, January 17, 2023 4:35 PM
....I'm remembering an explanation I sent once about how to ask RACF (and I
take it from your symptoms that you are running RACF) whether you have READ
access to a particular dataset. It seems to me it can be adapted to check
whether you have UPDATE access. It's more complicated than the below, but
if you're interested....
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
