If I am using RA.3.4, and I am listing a USERIDA using option 2 (which should list any direct permissions and permissions via group connections) and USERIDA is connected to 3 groups.    What should I see?

Should I see every permission to the direct User ID and any permission granted to the connected groups?

What about if two of the three groups are granted to the same resource at the same access level? Will that permission appear twice under each group, or will it be listed only once?

I think I am seeing it list only once, but how do we know which group its going to pick?    Anyway, to tell it to show the permissions from both groups?

Hi Linnea

The basis of RA.3.4 was built 30 years ago, with an aim of providing condensed information.  A multitude of groups providing the same access was not as important as saving a line of output on the 24 line screen, or worse, taking up more columns.  Since then, REPORT PERMIT was morphed into a proper NEWLIST structure with ISPF support, but the basis tenet stayed: the access of a user, with one (of possibly several) group(s) that provided the access, or the user ID itself, if the ID was directly permitted.

If you wish to see if there is only 1 group causing the access, go to RA.D, call up the DATASET profile, do an EXPLODED ACL (ACL X in the command line).  Or run a CARLa with ACL(EXPLODE).

If you are a patient person, open an Idea.

If you are keen to write two-pass CARLa: 

newlist scope=userid nopage retain dd=flatfile
  s class=dataset seg=base
  sortlist profile acl(explode)

In pass 2, you read the flatfile, single out the user ID, ACL ID and ACCESS columns, do some select magic.  Huh.

In the last months I've been writing python code to massage the output of IRRDBU00, and I enjoy the speed of writing reports that work.  Report permit and report scope are (interactive) parts already.  Yay python, and open source!  However, it is no zSecure on the active RACF db ;-).

Thanks, I may open an idea.    I had a user that requested that I run RA.3.4 on his ID showing his access.    He expected to see GROUPA with some DB2 access but did not see it in the report.    It was because GROUPB had the same access and the report showed GROUPB having the access.    He thought we had removed the access from GROUPA since it was not in the report.    I had to list the DB2 profile to show him that both groups were on the access list.     So he was wondering why the report did not reflect both groups that was connected to his ID, did not appear in the report.

If there is no way to tweak the existing carla, I can submit an idea.   Just was not sure if it was a simple modification.