I'm using the below CARLa to compare entitlements between 2 userids. I have been unable to exclude entries/profiles where the userids have an identical level of access. In other words, I'm looking for a report that only displays where the userids have different levels of access.

SUPPRESS REASON=( UACC ID(*) GLOBAL WARNING OWNER SELFCON CKGOWNER)
NEWLIST  REQUIRED TYPE=REPORT_SCOPE,
         TITLE="COMPARE PERMITS FOR IDS, INCLUDING GROUP PERMITS"
DEFINE   ACCESS_U1("UseridA",8,ACCESS_NZ) MAX(ACCESS) WHERE ID=userida
DEFINE   ACCESS_U2("UseridB",8,ACCESS_NZ) MAX(ACCESS) WHERE ID=useridb
SUMMARY  CLASS KEY(FIRSTONLY,) ACCESS_U1 ACCESS_U2
REPORT   SCOPE=userida SCOPE=useridb

I've tried adding the statement EXCLUDE ACCESS_U1=ACCESS_U2

I've tried updating the REPORT statement to be REPORT   SCOPE=userida SCOPE=useridb ACCESS_U1<>ACCESS_U2

I tried adding the following 2 statements
DEFINE   ACCESS_MATCH TRUE WHERE ACCESS_U1=ACCESS_U2
EXCLUDE  ACCESS_MATCH=TRUE

None of these 3 approaches worked.

Can you provide some pointers to help me find a way to exclude profiles where the 2 userids have the same level of access?

The underlying REPORT SCOPE information has a separate record for each combination of class/key/userid/access, and SUMMARY is used to group this information by class/profile.  This grouping (has to) disregard the access level, otherwise we could not combine the records for the 2 user IDs into 1 output line. The SELECT and EXCLUDE commands you tried work on the REPORT SCOPE information BEFORE the SUMMARY command has combined the info, so only one access value is available during SELECT/EXCLUDE processing.

We cannot add the ACCESS value on the main SUMMARY level, because this would break up the records for a single profile into separate lines, when the access levels are different.

However, you could add the ACCESS value on a second summary level, and hide the value.  This gives you an extra column with one or two entries for each profile. Then suppress the first summary level when there is only 1 value found for  the access level, like so:

DEFINE   ACCESS_LEVELS SUMCOUNT
SUMMARY  CLASS KEY(FIRSTONLY,) ACCESS_U1 ACCESS_U2 ACCESS_LEVELS(>1,ND) * ACCESS(ND)

Note, the access level in zSecure is stored as a binary number, and translated to the familiar 7 readable characters on output, but it may map several different binary values into a human readable access level, so in odd conditions you could see 2 user IDs with READ despite the SUMCOUNT threshold. This would be due to the way READ was encoded in R_SCOPE.  Not due to the CARLa code.

------------------------------
Rob van Hoboken
------------------------------

Thank you Rob for explaining the process logic and giving an example. This is a step forward. While testing I made 2 observations.

Observation #1

The CARLa report is including instances where ID(*) is on the conditional access list even though ID(*) is explicitly included in the SUPPRESS statement.

For example we have a dataset profile called PRDDM.#DMS.D*.** where neither userids are on the access list (directly or via a group connection). ID(*) has the following access

   ID     ACCESS
--------  -------
*          READ

and

   ID    ACCESS   CLASS                ENTITY NAME
-------- ------- -------- ------------------------
*        UPDATE  PROGRAM  DARCHIVE

The CARLA report is picking up the UPDATE conditional access via ID(*) and displays the following

Class    Profile key                                  UseridA  UseridB
DATASET  PRDDM.#DMS.D*.**                             UPDATE   UPDATE

Interestingly, the line command CKGRACF ACCESS <userid> DATASET PRDDM.#DMS.D*.** is picking up the READ standard access via ID(*) and returns the following for both userids

CKG582I 00 userida has READ access to DATASET PRDDM.#DMS.D*.**
           profile DATASET PRDDM.#DMS.D.*

This sounds like one of the "odd conditions" you mentioned involving SUMCOUNT and translating binary values. We will watch for this. The report is removing lines where both userids have the same level of access based on direct and group entitlements- which is the vast majority of what we want to ignore- making the report shorter.

Observation #2

The CARLa report is omitting instances where 1 userid is on the access list and the other userid is not. We want this to be included in the report.

I removed the modifiers on ACCESS_LEVELS and ACCESS to see the output and get a better understanding of how the DEFINE and SUMMARY statements provided work. Here are a couple lines from the report to illustrate different scenarios.

Class    Profile key                                  UseridA  UseridB  ACCESS_L Access  Count
$BOOLE   BBM.MVDB2.*.*.OD*.**                         READ     READ            1                2
                                                                                 READ           2
$BOOLE   BBM.MVDB2.**                                          READ            1                1
                                                                                 READ           1
DATASET  PRDDM.#DMS.D*.**                             UPDATE   UPDATE          2               16
                                                                                 READ           2
                                                                                 UPDATE        14
DATASET  U828561.**                                   ALTER    READ            2                2
                                                                                 READ           1

I looked at the variable categories for DEFINE statements (table 6 in the CARLa command reference guide v2.5.0). SUMCOUNT is the only Kind that considers the lower level.

To include in the report scenarios where only one userid has access, I think I need to consider whether the ACCESS field is MISSING or EXISTS. I will try incorporating this into the summary and post an update if I find a solution. There is a lot of information here- probably too much- which I wanted to add to the discussion.

I was able to solve the "problem" in observation #2 and get a report to display when one userid is on the access list and the other userid is not.

Here is the finished product

SUPPRESS REASON=( UACC ID(*) GLOBAL WARNING OWNER CKGOWNER ALTER-M)

/* CAPTURE WHEN BOTH USERIDS ON ACCESS LIST W/DIFFERENT LEVELS ACCESS */
NEWLIST  REQUIRED TYPE=REPORT_SCOPE NOPAGE,
         TITLE="COMPARE PERMITS FOR IDS, INCLUDING GROUP PERMITS"
DEFINE   ACCESS_U1("U828561",8,ACCESS_NZ) MAX(ACCESS) WHERE ID=U828561
DEFINE   ACCESS_U2("U640022",8,ACCESS_NZ) MAX(ACCESS) WHERE ID=U640022
DEFINE   ACCESS_LEVELS  SUMCOUNT
SUMMARY  CLASS KEY(FIRSTONLY,) ACCESS_U1 ACCESS_U2,
       ACCESS_LEVELS(>1,ND) * ACCESS(ND)

/* CAPTURE WHEN ONE USERID IS ON ACCESS LIST AND ONE ISN'T */
NEWLIST  REQUIRED TYPE=REPORT_SCOPE NOPAGE,
         TITLE="COMPARE PERMITS FOR IDS, INCLUDING GROUP PERMITS"
DEFINE   ACCESS_U1("U828561",8,ACCESS_NZ) MAX(ACCESS) WHERE ID=U828561
DEFINE   ACCESS_U2("U640022",8,ACCESS_NZ) MAX(ACCESS) WHERE ID=U640022
DEFINE   ACCESS_LEVELS SUMCOUNT
DEFINE   ACCESS_CNT    COUNT
SUMMARY  CLASS KEY(FIRSTONLY,) ACCESS_U1 ACCESS_U2,
         ACCESS_LEVELS(<2,ND) ACCESS_CNT(<2,ND) * ACCESS(ND)

REPORT   SCOPE=U828561 SCOPE=U640022

Note that these cannot be merged using MERGELIST because there are multiple SUMMARY levels. I know several ways to merge and sort the data programmatically and do not need to cover it here. This solution provides the information we are looking for (ignoring the issue discussed in Observation #1 above).