IBM Mainframe Forum

Hi!

I need to find to which profiles a particular ID(similar to STCUSER) has access to..

How do i do this in

• RACF
• ACF2

Thank you!

anyone...??

The first question is, do you have access to RACF (ACF2) to allow you to enter the command? If not, then why go any further? Most sites severely restrict access to these commands since there is the potential for misuse.

For RACF, the LU command will tell you. I have no idea what the command would be for ACF2.

anyone...??

do not pester...
we reply on our own time and free of charge,
based on the interest of the topic.
so if You do not get a reply You should find an alternative way to satisfy Your thirst for knowledge!

Other problems with this question -

• You are asking for expertise in both RACF and ACF2; something that is very rare.
• Are you looking for RACF profiles for datasets starting with the userid, or for profiles that explicitly specify the userid in an access list, or for profiles where the user is specified directly or specified by the membership in a group?

@Robert
yes, I have access in both RACF, and ACF2.

@enrico,
I didn't mean to pester. Sorry about that. I just thought the experts here would be knowing the answers without a doubt.

@steve,
I was hoping that whoever knows each product, would respond; instead of looking for both in the same person.

We're in the process of upgrading INCONTROL products. So I would like to know the dataset naming conventions I should stick to. Wouldn't the started tasks' access list be a good place to start for that..?
EDIT: The previous upgrade was done a very long time back, and the person who did it isn't a part of the company anymore.

So I would like to know the dataset naming conventions I should stick to. Wouldn't the started tasks' access list be a good place to start for that..?

Why on earth would you think that? The site documentation should be your FIRST place to start. The started task access list could be nothing but genric profiles, so what good would that do you? And even if discrete profiles are included, all that tells you is what data set names are in use -- not necessarily what the standards are for creating those data set names. You're not going to find conventions on the mainframe, in many cases, since they may have been placed in a Word (or Word Perfect or Wang or ...) document on the internal network -- probably even most sites have such external (to the mainframe) documentation.

What kind of access do you want to see? Just dataset access? How about other resource class profiles? This sounds like a question an auditor would ask who has no idea what they're saying and definitely no idea what they're going to get. Please let us know what you think it is you're trying to solve.

Other things you might want to consider (somebody above mentioned some of these already):
Do you want just the access where the ID is on the ACL?
Do you want their access through groups?
Do you want their access via UACCs?
Do you want their access via OPERATIONS (system or group level where they aren't specifically denied on the profile)?
Do you want to filter out "noise"? (profiles that protect nothing such as discrete profiles w generics or generics that protect nothing. also connects that are revoked or are about to revoke)?
Do you care about Unix System Services access and subsystems level access like DB2, CICS, IMS where your site may have detailed internal security tables based on various potential exits?
Do you care to see id-level attributes such as class authorities, other segments on the ID, system special, etc that could allow the ID to potentially get more at any time?
Do you care about SURROGAT profiles the ID could use to submit on behalf of another user with their full authority?
Do you care to understand FIRECODE and how it could potentially increase their access (especially SPECIAL and OPERATIONS)?

In general, you will likely either need a full RACF unload or some vendor tool w a reporting capability if you want anything non-trivial. For ANY of the above you will need a deep understanding of your installation to actually grasp what on earth you're even looking at to begin with.

If you can't understand why people are frustrated and are hesitant to answer it's because you are so glib it's asinine. We could spend hours giving you RACF 101 classes up through an over 9000 level to really figure out what you want. We don't have time for that and you seem to want some oversimplified answer that doesn't exist.

Robert Sample wrote:

So I would like to know the dataset naming conventions I should stick to. Wouldn't the started tasks' access list be a good place to start for that..?

Why on earth would you think that? The site documentation should be your FIRST place to start. The started task access list could be nothing but genric profiles, so what good would that do you? And even if discrete profiles are included, all that tells you is what data set names are in use -- not necessarily what the standards are for creating those data set names. You're not going to find conventions on the mainframe, in many cases, since they may have been placed in a Word (or Word Perfect or Wang or ...) document on the internal network -- probably even most sites have such external (to the mainframe) documentation.

There is no site documentation. That's the reason this is getting complicated.

angrybeaver wrote:What kind of access do you want to see? Just dataset access? How about other resource class profiles? This sounds like a question an auditor would ask who has no idea what they're saying and definitely no idea what they're going to get. Please let us know what you think it is you're trying to solve.

I want to see ANY access that 3 to 4 started task IDs have. They are used by CONTROL-M, O, and CTM Application Server. During the installation of 'Security' for INCONTROL products, there's even a step for creating a FACILITY class for IOA products and protecting them, at the QNAME level. So my intention here is to find out what naming conventions I should stick to, without creating a violation, that could cause a major setback in the production environment. There is no prior documentation that I can refer to. I have looked for it before I began the installation myself.

Again, this ID does not have a password. Its an STC userid.