IBM Security Z Security

I am trying to duplicate a report we had in Top Secret that listed all of our permissions (User/Group & Resource) along with last usage information and the system it was last used.

I went to AM.3 to let it generate my base Carla that was needed to report on permissions.   Then I edited the SORTLIST/SUMMARY to show the fields that I wanted to see.    In my environment there are many SYSPLEXs/Stand alone LPARs with RACF DB's that should be in sync via RRSF.    So in my batch job I included the AM Data, zSecure Unload, and CKFREEZE from each system.  The report will run creating one entry per permission with the last use information.

I want to add COMPLEX to the summary, because the requestors want to see where the permission was last used from.   When I added complex the summary, the report changed to show me each permission replicated for each system the permission was located, alone with the last use information on that particular system.   I opened case TS008663777 with zSecure, but so far they cannot tell me how to see the COMPLEX from the system the permission was last used.

In the case there was also a discussion if I need the CKFREEZE files from the different systems, and to me it appears that I do, for it to show the information properly.

Attached are 2 files:
JCL/Carla to Produce Report without Complex
JCL/Carla to Produce Report with Complex

I am willing to provide IBM sample reports, but I don't think I should attach to this discussion.   I am willing to provide the samples to IBM via email.

------------------------------
Linnea Sullivan
------------------------------

Hey, Linnea.
The SUMMARY command is designed to generate one output line for each set of unique values in all the summary key fields.  Fields like id, class, profile, access_lastuse are key fields, but also defined fields through DEFINE AS.  For each unique set of values, SUMMARY calculates statistics, such as lastuse, defined using DEFINE SUM( ), DEFINE MAX( ), DEFINE COUNT, etc.  If no statistic is specified on the SUMMARY command, the COUNT field is added (and defined) automatically.
If you want to include a field value in the output of SUMMARY, but you do not want to use is as a key field, you must use it as a statistic.  Sounds simple, no?
To morph a normal CARLa field into a statistic, you give it the overriding modifier (MAX) or (MIN).  This works for character fields, for booleans and for numbers.  MAX shows you the highest value for in the field, for set of key values, for a character field this is the highest, non-empty value.
I've used this successfully to print a field when the values in the set are either missing, blank or a set value, for example

newlist type=racf
  select class=user
  summary key(8, "Userid") name(max) owner(max) tmsize(max) uid(9,max)

In your example, this would show you a value of COMPLEX where the access was used, not the most recent value.  You could also use a DEFINE to show you a COMPLEX where access was granted in the last month:

define recent_complex(8) max(complex) where access_lastuse>=today-31

and using this in the SUMMARY command.

If you wanted to see ALL values of COMPLEX, sorted by date, you would have to add a second level of summary keys in the summary command

* lastuse(bw,np) complex

though, obviously, these would be printed BELOW the key fields, not on the same line.

I have not tried this out, without a z/OS system I'm working from memory only, so let us know when you had to fix any typos.

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

Rob, thanks for the information

I tried two runs:
One as define recent_complex(8) max(complex) where access_lastuse>=today-365 to show the most recent complex for any accesses with in the last year.
And I tried define recent_complex(8) max(complex) to show the most recent complex regardless of the last use.

In the report, if the permission was never used it seemed to default to a single system for the COMPLEX, so that could be misleading to the user looking at the report.
If the permission was used, it has 2 entries in the report.  The 1st entry is always unused, and the 2nd shows used.   From what I can tell looking at production users and production permissions, they complex reflects the a test system.

Let me re-phrase my question.

Let's say my user ID has access to the dataset ACCOUNTS.CUSTOMER.NAME on 5 different RACF systems (complexs).   Let's say on COMLEX(TST1) I accessed the file on Mar 1, on COMPLEX(PRD1) I accessed the file on Mar 3.    I would expect AM to show that my ID last accessed ACCOUNTS.CUSTOMER.NAME on Mar 3 from PRD1 because that was the last access and the last complex the dataset was accessed from.

Is that possible with the AM data?



------------------------------
Linnea Sullivan
------------------------------

Original Message:
Sent: Sat March 12, 2022 06:13 AM
From: Rob van Hoboken
Subject: Access Monitor report on Permissions with COMPLEX data

Hey, Linnea.
The SUMMARY command is designed to generate one output line for each set of unique values in all the summary key fields.  Fields like id, class, profile, access_lastuse are key fields, but also defined fields through DEFINE AS.  For each unique set of values, SUMMARY calculates statistics, such as lastuse, defined using DEFINE SUM( ), DEFINE MAX( ), DEFINE COUNT, etc.  If no statistic is specified on the SUMMARY command, the COUNT field is added (and defined) automatically.
If you want to include a field value in the output of SUMMARY, but you do not want to use is as a key field, you must use it as a statistic.  Sounds simple, no?
To morph a normal CARLa field into a statistic, you give it the overriding modifier (MAX) or (MIN).  This works for character fields, for booleans and for numbers.  MAX shows you the highest value for in the field, for set of key values, for a character field this is the highest, non-empty value.
I've used this successfully to print a field when the values in the set are either missing, blank or a set value, for example

newlist type=racf
  select class=user
  summary key(8, "Userid") name(max) owner(max) tmsize(max) uid(9,max)

In your example, this would show you a value of COMPLEX where the access was used, not the most recent value.  You could also use a DEFINE to show you a COMPLEX where access was granted in the last month:

define recent_complex(8) max(complex) where access_lastuse>=today-31

and using this in the SUMMARY command.

If you wanted to see ALL values of COMPLEX, sorted by date, you would have to add a second level of summary keys in the summary command

* lastuse(bw,np) complex

though, obviously, these would be printed BELOW the key fields, not on the same line.

I have not tried this out, without a z/OS system I'm working from memory only, so let us know when you had to fix any typos.

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

Linnea, I overlooked that you're using newlist type=RACF_ACCESS, and this shows up an observation for each access list entry in the profile(s), regardless of it having been used.  So your DEFINE RECENT_COMPLEX must have a WHERE ACCESS_LASTUSE<>NEVER or an equivalent, otherwise you will have a COMPLEX value popping up even when there was no reference to the observation.

Also, the MAX(COMPLEX) finds the complex name with the highest (EBCDIC) string value, NOT the complex with the most recent usage.  There is no way to get the complex name corresponding to the most recent usage, you will get a complex where usage matches the WHERE condition.

The only way to view the most recent complex is by adding * lastuse(noprop,descending) complex at the end of the summary command, and (visually?) taking the first entry.

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

Original Message:
Sent: Mon March 14, 2022 03:58 PM
From: Linnea Sullivan
Subject: Access Monitor report on Permissions with COMPLEX data

Rob, thanks for the information

I tried two runs:
One as define recent_complex(8) max(complex) where access_lastuse>=today-365 to show the most recent complex for any accesses with in the last year.
And I tried define recent_complex(8) max(complex) to show the most recent complex regardless of the last use.

In the report, if the permission was never used it seemed to default to a single system for the COMPLEX, so that could be misleading to the user looking at the report.
If the permission was used, it has 2 entries in the report.  The 1st entry is always unused, and the 2nd shows used.   From what I can tell looking at production users and production permissions, they complex reflects the a test system.

Let me re-phrase my question.

Let's say my user ID has access to the dataset ACCOUNTS.CUSTOMER.NAME on 5 different RACF systems (complexs).   Let's say on COMLEX(TST1) I accessed the file on Mar 1, on COMPLEX(PRD1) I accessed the file on Mar 3.    I would expect AM to show that my ID last accessed ACCOUNTS.CUSTOMER.NAME on Mar 3 from PRD1 because that was the last access and the last complex the dataset was accessed from.

Is that possible with the AM data?



------------------------------
Linnea Sullivan

Original Message:
Sent: Sat March 12, 2022 06:13 AM
From: Rob van Hoboken
Subject: Access Monitor report on Permissions with COMPLEX data

Hey, Linnea.
The SUMMARY command is designed to generate one output line for each set of unique values in all the summary key fields.  Fields like id, class, profile, access_lastuse are key fields, but also defined fields through DEFINE AS.  For each unique set of values, SUMMARY calculates statistics, such as lastuse, defined using DEFINE SUM( ), DEFINE MAX( ), DEFINE COUNT, etc.  If no statistic is specified on the SUMMARY command, the COUNT field is added (and defined) automatically.
If you want to include a field value in the output of SUMMARY, but you do not want to use is as a key field, you must use it as a statistic.  Sounds simple, no?
To morph a normal CARLa field into a statistic, you give it the overriding modifier (MAX) or (MIN).  This works for character fields, for booleans and for numbers.  MAX shows you the highest value for in the field, for set of key values, for a character field this is the highest, non-empty value.
I've used this successfully to print a field when the values in the set are either missing, blank or a set value, for example

newlist type=racf
  select class=user
  summary key(8, "Userid") name(max) owner(max) tmsize(max) uid(9,max)

In your example, this would show you a value of COMPLEX where the access was used, not the most recent value.  You could also use a DEFINE to show you a COMPLEX where access was granted in the last month:

define recent_complex(8) max(complex) where access_lastuse>=today-31

and using this in the SUMMARY command.

If you wanted to see ALL values of COMPLEX, sorted by date, you would have to add a second level of summary keys in the summary command

* lastuse(bw,np) complex

though, obviously, these would be printed BELOW the key fields, not on the same line.

I have not tried this out, without a z/OS system I'm working from memory only, so let us know when you had to fix any typos.

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

I've been thinking about this requirement, and I agree with Rob that there currently is no way to find the complex associated with max(access_lastuse).

I can think of an ugly method with an external deftype file, and running multiple passes of the ACCESS file to match a timestamp to a complex (and that only works if your events don't occur on the same TOD-stamp). But I won't recommend that unless you are really desperate.

------------------------------
Guus Bonnes
------------------------------

Original Message:
Sent: Fri March 11, 2022 02:05 PM
From: Linnea Sullivan
Subject: Access Monitor report on Permissions with COMPLEX data

I am trying to duplicate a report we had in Top Secret that listed all of our permissions (User/Group & Resource) along with last usage information and the system it was last used.

I went to AM.3 to let it generate my base Carla that was needed to report on permissions.   Then I edited the SORTLIST/SUMMARY to show the fields that I wanted to see.    In my environment there are many SYSPLEXs/Stand alone LPARs with RACF DB's that should be in sync via RRSF.    So in my batch job I included the AM Data, zSecure Unload, and CKFREEZE from each system.  The report will run creating one entry per permission with the last use information.

I want to add COMPLEX to the summary, because the requestors want to see where the permission was last used from.   When I added complex the summary, the report changed to show me each permission replicated for each system the permission was located, alone with the last use information on that particular system.   I opened case TS008663777 with zSecure, but so far they cannot tell me how to see the COMPLEX from the system the permission was last used.

In the case there was also a discussion if I need the CKFREEZE files from the different systems, and to me it appears that I do, for it to show the information properly.

Attached are 2 files:
JCL/Carla to Produce Report without Complex
JCL/Carla to Produce Report with Complex

I am willing to provide IBM sample reports, but I don't think I should attach to this discussion.   I am willing to provide the samples to IBM via email.

------------------------------
Linnea Sullivan
------------------------------

Thanks Guus and Rob for the assistance.

So 2 questions.
1.  In all my ALLOC statements for the UNLOAD, CKFREEZE, and Access Monitor Data, I separated them all by complex, hoping that would help report on the complex in the report.   (See my attached JCL).  Since that is not possible, do I even need the COMPLEX on the ALLOC statements?      I could create 3 DD's in my JCL, one for the UNLOADs, one for CKFREEZE, and one for AM files.   And just list all the files under each type. 

2.  I guess another way of accomplishing what I want is to run the report on each individual complex and create an output file.   Then have a separate process that reads in the multiple files and analyzes the data to determine the last use date/complex information.     That analysis step may not be a carla step, but something to read in the records and determine which is the last use record.

Honestly, I am not sure providing the complex for the last access is all that important, just that the user's we used to seeing it in their current reports.    I will try to steer them away from needing that data.

------------------------------
Linnea Sullivan
------------------------------

Original Message:
Sent: Tue March 15, 2022 10:13 AM
From: Guus Bonnes
Subject: Access Monitor report on Permissions with COMPLEX data

I've been thinking about this requirement, and I agree with Rob that there currently is no way to find the complex associated with max(access_lastuse).

I can think of an ugly method with an external deftype file, and running multiple passes of the ACCESS file to match a timestamp to a complex (and that only works if your events don't occur on the same TOD-stamp). But I won't recommend that unless you are really desperate.

------------------------------
Guus Bonnes

Original Message:
Sent: Fri March 11, 2022 02:05 PM
From: Linnea Sullivan
Subject: Access Monitor report on Permissions with COMPLEX data

I am trying to duplicate a report we had in Top Secret that listed all of our permissions (User/Group & Resource) along with last usage information and the system it was last used.

I went to AM.3 to let it generate my base Carla that was needed to report on permissions.   Then I edited the SORTLIST/SUMMARY to show the fields that I wanted to see.    In my environment there are many SYSPLEXs/Stand alone LPARs with RACF DB's that should be in sync via RRSF.    So in my batch job I included the AM Data, zSecure Unload, and CKFREEZE from each system.  The report will run creating one entry per permission with the last use information.

I want to add COMPLEX to the summary, because the requestors want to see where the permission was last used from.   When I added complex the summary, the report changed to show me each permission replicated for each system the permission was located, alone with the last use information on that particular system.   I opened case TS008663777 with zSecure, but so far they cannot tell me how to see the COMPLEX from the system the permission was last used.

In the case there was also a discussion if I need the CKFREEZE files from the different systems, and to me it appears that I do, for it to show the information properly.

Attached are 2 files:
JCL/Carla to Produce Report without Complex
JCL/Carla to Produce Report with Complex

I am willing to provide IBM sample reports, but I don't think I should attach to this discussion.   I am willing to provide the samples to IBM via email.

------------------------------
Linnea Sullivan
------------------------------

1) Yes, you'd better supply a matching CKFREEZE, or use ACCESS_FALLBACK_DEFAULT. Otherwise unmatched ACCESS records are discarded.
And no, you can't really concatenate CKFREEZE files onto a single DDNAME.
2) Hmm, in that case creating an external timestamp->complex lookup file in pass-1 and referring to it in pass-2 would seem simpler (although I previously recommended against it).

------------------------------
Guus Bonnes
------------------------------

Original Message:
Sent: Tue March 15, 2022 10:36 AM
From: Linnea Sullivan
Subject: Access Monitor report on Permissions with COMPLEX data

Thanks Guus and Rob for the assistance.

So 2 questions.
1.  In all my ALLOC statements for the UNLOAD, CKFREEZE, and Access Monitor Data, I separated them all by complex, hoping that would help report on the complex in the report.   (See my attached JCL).  Since that is not possible, do I even need the COMPLEX on the ALLOC statements?      I could create 3 DD's in my JCL, one for the UNLOADs, one for CKFREEZE, and one for AM files.   And just list all the files under each type. 

2.  I guess another way of accomplishing what I want is to run the report on each individual complex and create an output file.   Then have a separate process that reads in the multiple files and analyzes the data to determine the last use date/complex information.     That analysis step may not be a carla step, but something to read in the records and determine which is the last use record.

Honestly, I am not sure providing the complex for the last access is all that important, just that the user's we used to seeing it in their current reports.    I will try to steer them away from needing that data.

------------------------------
Linnea Sullivan

Original Message:
Sent: Tue March 15, 2022 10:13 AM
From: Guus Bonnes
Subject: Access Monitor report on Permissions with COMPLEX data

I've been thinking about this requirement, and I agree with Rob that there currently is no way to find the complex associated with max(access_lastuse).

I can think of an ugly method with an external deftype file, and running multiple passes of the ACCESS file to match a timestamp to a complex (and that only works if your events don't occur on the same TOD-stamp). But I won't recommend that unless you are really desperate.

------------------------------
Guus Bonnes

Original Message:
Sent: Fri March 11, 2022 02:05 PM
From: Linnea Sullivan
Subject: Access Monitor report on Permissions with COMPLEX data

I am trying to duplicate a report we had in Top Secret that listed all of our permissions (User/Group & Resource) along with last usage information and the system it was last used.

I went to AM.3 to let it generate my base Carla that was needed to report on permissions.   Then I edited the SORTLIST/SUMMARY to show the fields that I wanted to see.    In my environment there are many SYSPLEXs/Stand alone LPARs with RACF DB's that should be in sync via RRSF.    So in my batch job I included the AM Data, zSecure Unload, and CKFREEZE from each system.  The report will run creating one entry per permission with the last use information.

I want to add COMPLEX to the summary, because the requestors want to see where the permission was last used from.   When I added complex the summary, the report changed to show me each permission replicated for each system the permission was located, alone with the last use information on that particular system.   I opened case TS008663777 with zSecure, but so far they cannot tell me how to see the COMPLEX from the system the permission was last used.

In the case there was also a discussion if I need the CKFREEZE files from the different systems, and to me it appears that I do, for it to show the information properly.

Attached are 2 files:
JCL/Carla to Produce Report without Complex
JCL/Carla to Produce Report with Complex

I am willing to provide IBM sample reports, but I don't think I should attach to this discussion.   I am willing to provide the samples to IBM via email.

------------------------------
Linnea Sullivan
------------------------------

CKRSPROF already contains a simulate access_fallback_default command.

Normally, zSecure looks at the SYSTEM field in ACCESS records to match the event/observation to a CKFREEZE.  Next it uses the COMPLEX value specified on the ALLOC TYPE=CKFREEZE COMPLEX=cccc to identify the matching RACF database or UNLOAD.  When there is no COMPLEX specified in ALLOC commands, the SYSTEM value inside the CKFREEZE is matched with the SYSTEM name in the UNLOAD data set.

The CARLa syntax manual (ALLOC command section) describes how SMF and ACCESS records are processed:

The SYSID is always first searched in the CKFREEZE sources, and each individual record is assigned to the matching COMPLEX. If the SYSID cannot be matched, a specified COMPLEX name is used. If no COMPLEX name has been specified, the SYSID is used as default for the COMPLEX.

Of course, the SYSID assignement is overriden using the SIMULATE ACCESS_FALLBACK_DEFAULT command.  Look at message CKR0615 to see the match of input data sets and complexes. 

I wonder if there are any error messages complaining about concatenated CKFREEZE data sets.  For example CKR0135.  I think only the first system in the concatenation is recognized.  That suggests that many ACCESS records are mapped to the default system and complex, and consequently associated with the wrong RACF database.

You need a separate ALLOC TYPE=CKFREEZE COMPLEX=cccc DSN=ddddd or DD=ddddd for each CKFREEZE dsname

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

Hi Rob,

> I wonder if there are any error messages complaining about concatenated CKFREEZE data sets.  For example CKR0135. 

I would expect this to usually result in CKR0135. The CKFREEZE files are read in multiple phases. If a "start" record is found in the last phase, and that does not look like an additional snapshot for the same system, the result is CKR0135. Other error (or informational) messages are also possible.

> I think only the first system in the concatenation is recognized.  

That is correct. You need to allocate CKFREEZE files separately. And they are then actually read in parallel.

Regards,

------------------------------
Jeroen Tiggelman
Software Development and Level 3 Support Manager IBM Security zSecure Suite
IBM
Delft
------------------------------

Original Message:
Sent: Wed March 16, 2022 09:35 AM
From: Rob van Hoboken
Subject: Access Monitor report on Permissions with COMPLEX data

CKRSPROF already contains a simulate access_fallback_default command.

Normally, zSecure looks at the SYSTEM field in ACCESS records to match the event/observation to a CKFREEZE.  Next it uses the COMPLEX value specified on the ALLOC TYPE=CKFREEZE COMPLEX=cccc to identify the matching RACF database or UNLOAD.  When there is no COMPLEX specified in ALLOC commands, the SYSTEM value inside the CKFREEZE is matched with the SYSTEM name in the UNLOAD data set.

The CARLa syntax manual (ALLOC command section) describes how SMF and ACCESS records are processed:

The SYSID is always first searched in the CKFREEZE sources, and each individual record is assigned to the matching COMPLEX. If the SYSID cannot be matched, a specified COMPLEX name is used. If no COMPLEX name has been specified, the SYSID is used as default for the COMPLEX.

Of course, the SYSID assignement is overriden using the SIMULATE ACCESS_FALLBACK_DEFAULT command.  Look at message CKR0615 to see the match of input data sets and complexes. 

I wonder if there are any error messages complaining about concatenated CKFREEZE data sets.  For example CKR0135.  I think only the first system in the concatenation is recognized.  That suggests that many ACCESS records are mapped to the default system and complex, and consequently associated with the wrong RACF database.

You need a separate ALLOC TYPE=CKFREEZE COMPLEX=cccc DSN=ddddd or DD=ddddd for each CKFREEZE dsname

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

I looked at my SYSPRINT, I do not see any CKR0135 messages.

Hopefully this is the last question.   Attached is my JCL and sample report.    It looks like all permissions that are unused only appear once in the report.   But any permission that is used appears twice (once with no activity, once with a last use date)   For example look at Class CTCICCMD Resource PROGRAM*.**



































































































------------------------------
Linnea Sullivan
------------------------------

Original Message:
Sent: Wed March 16, 2022 09:35 AM
From: Rob van Hoboken
Subject: Access Monitor report on Permissions with COMPLEX data

CKRSPROF already contains a simulate access_fallback_default command.

Normally, zSecure looks at the SYSTEM field in ACCESS records to match the event/observation to a CKFREEZE.  Next it uses the COMPLEX value specified on the ALLOC TYPE=CKFREEZE COMPLEX=cccc to identify the matching RACF database or UNLOAD.  When there is no COMPLEX specified in ALLOC commands, the SYSTEM value inside the CKFREEZE is matched with the SYSTEM name in the UNLOAD data set.

The CARLa syntax manual (ALLOC command section) describes how SMF and ACCESS records are processed:

The SYSID is always first searched in the CKFREEZE sources, and each individual record is assigned to the matching COMPLEX. If the SYSID cannot be matched, a specified COMPLEX name is used. If no COMPLEX name has been specified, the SYSID is used as default for the COMPLEX.

Of course, the SYSID assignement is overriden using the SIMULATE ACCESS_FALLBACK_DEFAULT command.  Look at message CKR0615 to see the match of input data sets and complexes. 

I wonder if there are any error messages complaining about concatenated CKFREEZE data sets.  For example CKR0135.  I think only the first system in the concatenation is recognized.  That suggests that many ACCESS records are mapped to the default system and complex, and consequently associated with the wrong RACF database.

You need a separate ALLOC TYPE=CKFREEZE COMPLEX=cccc DSN=ddddd or DD=ddddd for each CKFREEZE dsname

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

In the sample output, ACCESS_USED is only filled in for the lines with a LASTUSE date.  This column is actually access_intent_max_suc, a field you can find in the CARLa field reference, so it acts as a summary key field.  That means, a separate line is shown for the missing value of access_intent_max_suc, and another for the accessed value.
If you want to combine these lines together, you could change this column into a statistic (add the MAX modifier).  Though that kills the distinction between READ and ALTER access on the profile, so you've got to realize what MAX will do.

About CKR0135, have you looked at the output of CKR0615 in your SYSPRINT, and do you see all the systems whose CKFREEZE you allocated?  Are there any other messages with severity 16?

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

Original Message:
Sent: Wed March 16, 2022 02:53 PM
From: Linnea Sullivan
Subject: Access Monitor report on Permissions with COMPLEX data

I looked at my SYSPRINT, I do not see any CKR0135 messages.

Hopefully this is the last question.   Attached is my JCL and sample report.    It looks like all permissions that are unused only appear once in the report.   But any permission that is used appears twice (once with no activity, once with a last use date)   For example look at Class CTCICCMD Resource PROGRAM*.**



































































































------------------------------
Linnea Sullivan

Original Message:
Sent: Wed March 16, 2022 09:35 AM
From: Rob van Hoboken
Subject: Access Monitor report on Permissions with COMPLEX data

CKRSPROF already contains a simulate access_fallback_default command.

Normally, zSecure looks at the SYSTEM field in ACCESS records to match the event/observation to a CKFREEZE.  Next it uses the COMPLEX value specified on the ALLOC TYPE=CKFREEZE COMPLEX=cccc to identify the matching RACF database or UNLOAD.  When there is no COMPLEX specified in ALLOC commands, the SYSTEM value inside the CKFREEZE is matched with the SYSTEM name in the UNLOAD data set.

The CARLa syntax manual (ALLOC command section) describes how SMF and ACCESS records are processed:

The SYSID is always first searched in the CKFREEZE sources, and each individual record is assigned to the matching COMPLEX. If the SYSID cannot be matched, a specified COMPLEX name is used. If no COMPLEX name has been specified, the SYSID is used as default for the COMPLEX.

Of course, the SYSID assignement is overriden using the SIMULATE ACCESS_FALLBACK_DEFAULT command.  Look at message CKR0615 to see the match of input data sets and complexes. 

I wonder if there are any error messages complaining about concatenated CKFREEZE data sets.  For example CKR0135.  I think only the first system in the concatenation is recognized.  That suggests that many ACCESS records are mapped to the default system and complex, and consequently associated with the wrong RACF database.

You need a separate ALLOC TYPE=CKFREEZE COMPLEX=cccc DSN=ddddd or DD=ddddd for each CKFREEZE dsname

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

I was actually using access_intent_max_suc in my code, just heading was set as "Access_Intent".      I did add the MAX modifier and that seemed to have resolved my issue.    So if the user attempted to access the "dataset" at different times with READ and other times as UPDATE, it would show me the MAX intent would be UPDATE.    Correct?


I looked at my SYSPRINT again, I am getting no RC16's.    My CKR0615 message is a RC00.   I attached my SYSPRINT.

------------------------------
Linnea Sullivan
------------------------------

Original Message:
Sent: Wed March 16, 2022 04:08 PM
From: Rob van Hoboken
Subject: Access Monitor report on Permissions with COMPLEX data

In the sample output, ACCESS_USED is only filled in for the lines with a LASTUSE date.  This column is actually access_intent_max_suc, a field you can find in the CARLa field reference, so it acts as a summary key field.  That means, a separate line is shown for the missing value of access_intent_max_suc, and another for the accessed value.
If you want to combine these lines together, you could change this column into a statistic (add the MAX modifier).  Though that kills the distinction between READ and ALTER access on the profile, so you've got to realize what MAX will do.

About CKR0135, have you looked at the output of CKR0615 in your SYSPRINT, and do you see all the systems whose CKFREEZE you allocated?  Are there any other messages with severity 16?

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

Original Message:
Sent: Wed March 16, 2022 02:53 PM
From: Linnea Sullivan
Subject: Access Monitor report on Permissions with COMPLEX data

I looked at my SYSPRINT, I do not see any CKR0135 messages.

Hopefully this is the last question.   Attached is my JCL and sample report.    It looks like all permissions that are unused only appear once in the report.   But any permission that is used appears twice (once with no activity, once with a last use date)   For example look at Class CTCICCMD Resource PROGRAM*.**



































































































------------------------------
Linnea Sullivan

Original Message:
Sent: Wed March 16, 2022 09:35 AM
From: Rob van Hoboken
Subject: Access Monitor report on Permissions with COMPLEX data

CKRSPROF already contains a simulate access_fallback_default command.

Normally, zSecure looks at the SYSTEM field in ACCESS records to match the event/observation to a CKFREEZE.  Next it uses the COMPLEX value specified on the ALLOC TYPE=CKFREEZE COMPLEX=cccc to identify the matching RACF database or UNLOAD.  When there is no COMPLEX specified in ALLOC commands, the SYSTEM value inside the CKFREEZE is matched with the SYSTEM name in the UNLOAD data set.

The CARLa syntax manual (ALLOC command section) describes how SMF and ACCESS records are processed:

The SYSID is always first searched in the CKFREEZE sources, and each individual record is assigned to the matching COMPLEX. If the SYSID cannot be matched, a specified COMPLEX name is used. If no COMPLEX name has been specified, the SYSID is used as default for the COMPLEX.

Of course, the SYSID assignement is overriden using the SIMULATE ACCESS_FALLBACK_DEFAULT command.  Look at message CKR0615 to see the match of input data sets and complexes. 

I wonder if there are any error messages complaining about concatenated CKFREEZE data sets.  For example CKR0135.  I think only the first system in the concatenation is recognized.  That suggests that many ACCESS records are mapped to the default system and complex, and consequently associated with the wrong RACF database.

You need a separate ALLOC TYPE=CKFREEZE COMPLEX=cccc DSN=ddddd or DD=ddddd for each CKFREEZE dsname

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

> if the user attempted to access the "dataset" at different times with READ and other times as UPDATE, it would show me the MAX intent would be UPDATE.
That is correct.

The number of dsnames reported in CKR0132, CKR2438 and, for better overview, CKR0615 is significantly smaller than the dsnames listed in the JCL that you included in JCL Carla.TXT.  In fact, when I look at the first ddname in the JCL:

//C3IOC01   DD DSN=SYSSA.#ZSECURE.XDS3630A.S0100.CKFREEZE,DISP=SHR              
//          DD DSN=SYSSA.#ZSECURE.XDS3631A.S0400.CKFREEZE,DISP=SHR              
//          DD DSN=SYSSA.#ZSECURE.XDS3632A.S0600.CKFREEZE,DISP=SHR              
//          DD DSN=SYSSA.#ZSECURE.XDS3633A.S1000.CKFREEZE,DISP=SHR              
//          DD DSN=SYSSA.#ZSECURE.XDS3634A.SPRDC.CKFREEZE,DISP=SHR              
//          DD DSN=SYSSA.#ZSECURE.XDS3635A.SPRDF.CKFREEZE,DISP=SHR              
//          DD DSN=SYSSA.#ZSECURE.XDS3636A.SPRD2.CKFREEZE,DISP=SHR              
//          DD DSN=SYSSA.#ZSECURE.XDS3637A.SPRD3.CKFREEZE,DISP=SHR              
//          DD DSN=SYSSA.#ZSECURE.XDS3638A.SPRD5.CKFREEZE,DISP=SHR              
//          DD DSN=SYSSA.#ZSECURE.XDS3639A.SPR1G.CKFREEZE,DISP=SHR              
//          DD DSN=SYSSA.#ZSECURE.XDS3644A.SPR17.CKFREEZE,DISP=SHR              
//          DD DSN=SYSSA.#ZSECURE.XDS3645A.SPR18.CKFREEZE,DISP=SHR              

and find the matching messages

 CKR0132 00 Reading configuration for system PR18 iplvol SPRSU1 from C3IOC01  SYS621 SYSSA.#ZSECURE.XDS3645A.SPR18.CKFREEZE                                                                                                                                    
            running IBM CORP z/OS 2.4.0 DFSMS 2.4.0 JES2 HJE77C0 RACF HRF77C0 TSO 4.4.0 HSM  2.4.0 on z/Architecture                                                                                                                                           
            created by program CKFCOLL 2.4.0 4Z196 210503021 job XDS3645A at 17 Mar 2022 08:12:15.87 (APF)                                                                                                                                                     

 CKR2348 00 System 13 identification for system (SMF id) PR18 C3IOC01  SYS621 SYSSA.#ZSECURE.XDS3645A.SPR18.CKFREEZE                                                                                                                                           
            Sysname SPR18 sysplex PRDPLEX clone 8C hw OASYS lpar OAPR18 rrsf PRD nje NWOC                                                                                                                                                                      

 CKR0615 00 Input system structure overview (default system PR18 complex PRD):                                                                                                                                                                                 
       Ver  Complex  Func  Prod System   Timestamp         Filename Volser Dsname                                                                                                                                                                              
            PRD      Main  RACF PR18     17 Mar 2022 00:01 C2UNL11  SYS013 SYSSA.RACF.PRDPLEX.ZSECUNLD.DAILY.G0038V00                                                                                                                                          
                           RACF PR18     17 Mar 2022 08:12 C3IOC01  SYS621 SYSSA.#ZSECURE.XDS3645A.SPR18.CKFREEZE                                                                                                                                              

It looks like the last data set of the concatenation was processed (only).  Did you strip down the allocations in this last job, down to one dsname per DD?  If not, you should add ALLOCs for the individual CKFREEZE data sets.

If you had reduced the JCL before, then that is fine, and I would not have expected error messages about the now absent concatenations.

Going forward, you want to keep an eye out for messages that indicate a mismatch between ACCESS and CKFREEZE data:

 CKR2251 00 Simulating system PLEX with complex TST default DV21 because no CKFREEZE file matching C1ACC01  SYS603 SYSSA.#ZSECURE.SSZ                                                                                                                          
 CKR1444 00 Complex TST used for system PLEX records in C1ACC01  SYS603 SYSSA.#ZSECURE.SSZSECAM.TSTPLEX.R18MON                                                                                                                                                 

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

Hi Linnea, While I am surprised you are not getting any error messages regarding the concatenation of CKFREEZE files you can clearly tell from the messages that only the first one in each concatenation is being recognised/used.

You need to use unique DDnames per CKFREEZE, and individual ALLOC statements for each one.. multiple CKFREEZE with same complex= value is not an issue (it is UNLOADs, by definition, for which you can only have 1 per complex).

It would be useful to see SYSPRINT again results after you have adjusted JCL/Allocs.

------------------------------
Regards,
Simon Dodge
------------------------------

Original Message:
Sent: Thu March 17, 2022 05:39 PM
From: Linnea Sullivan
Subject: Access Monitor report on Permissions with COMPLEX data

I was actually using access_intent_max_suc in my code, just heading was set as "Access_Intent".      I did add the MAX modifier and that seemed to have resolved my issue.    So if the user attempted to access the "dataset" at different times with READ and other times as UPDATE, it would show me the MAX intent would be UPDATE.    Correct?


I looked at my SYSPRINT again, I am getting no RC16's.    My CKR0615 message is a RC00.   I attached my SYSPRINT.

------------------------------
Linnea Sullivan

Original Message:
Sent: Wed March 16, 2022 04:08 PM
From: Rob van Hoboken
Subject: Access Monitor report on Permissions with COMPLEX data

In the sample output, ACCESS_USED is only filled in for the lines with a LASTUSE date.  This column is actually access_intent_max_suc, a field you can find in the CARLa field reference, so it acts as a summary key field.  That means, a separate line is shown for the missing value of access_intent_max_suc, and another for the accessed value.
If you want to combine these lines together, you could change this column into a statistic (add the MAX modifier).  Though that kills the distinction between READ and ALTER access on the profile, so you've got to realize what MAX will do.

About CKR0135, have you looked at the output of CKR0615 in your SYSPRINT, and do you see all the systems whose CKFREEZE you allocated?  Are there any other messages with severity 16?

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

Original Message:
Sent: Wed March 16, 2022 02:53 PM
From: Linnea Sullivan
Subject: Access Monitor report on Permissions with COMPLEX data

I looked at my SYSPRINT, I do not see any CKR0135 messages.

Hopefully this is the last question.   Attached is my JCL and sample report.    It looks like all permissions that are unused only appear once in the report.   But any permission that is used appears twice (once with no activity, once with a last use date)   For example look at Class CTCICCMD Resource PROGRAM*.**



































































































------------------------------
Linnea Sullivan

Original Message:
Sent: Wed March 16, 2022 09:35 AM
From: Rob van Hoboken
Subject: Access Monitor report on Permissions with COMPLEX data

CKRSPROF already contains a simulate access_fallback_default command.

Normally, zSecure looks at the SYSTEM field in ACCESS records to match the event/observation to a CKFREEZE.  Next it uses the COMPLEX value specified on the ALLOC TYPE=CKFREEZE COMPLEX=cccc to identify the matching RACF database or UNLOAD.  When there is no COMPLEX specified in ALLOC commands, the SYSTEM value inside the CKFREEZE is matched with the SYSTEM name in the UNLOAD data set.

The CARLa syntax manual (ALLOC command section) describes how SMF and ACCESS records are processed:

The SYSID is always first searched in the CKFREEZE sources, and each individual record is assigned to the matching COMPLEX. If the SYSID cannot be matched, a specified COMPLEX name is used. If no COMPLEX name has been specified, the SYSID is used as default for the COMPLEX.

Of course, the SYSID assignement is overriden using the SIMULATE ACCESS_FALLBACK_DEFAULT command.  Look at message CKR0615 to see the match of input data sets and complexes. 

I wonder if there are any error messages complaining about concatenated CKFREEZE data sets.  For example CKR0135.  I think only the first system in the concatenation is recognized.  That suggests that many ACCESS records are mapped to the default system and complex, and consequently associated with the wrong RACF database.

You need a separate ALLOC TYPE=CKFREEZE COMPLEX=cccc DSN=ddddd or DD=ddddd for each CKFREEZE dsname

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

Gentlemen,

I did update the JCL and the Carla ALLOC statements as suggested.    You will notice in the JCL and the ALLOC some are commented out because those LPARs are still TSS, and have not migrated to RACF.    Even though we produce CKFREEZE files on those TSS, systems I felt they would not be relevant to this Access Monitor process.

The question I have is the CKR2251 messages.  The 1st set is for LPAR PR18, which at this time is the only LPAR in that plex that has migrated to RACF.  But it does have its own CKFREEZE file which I have referenced with C3IOC00  DD name.    The 2nd set (seems to be over 3000 msgs) is for DV26 LPAR.  All the LPARs in that plex have migrated to RACF.   The TST complex consists of 4 LPARs which I have set up DD   C3IOC20-23 which should also map to Access Monitor data for the plex C1ACC20 DD name.

Attached are the files if you need them.

As far as I can tell I think I am getting a valid report from the JCL.

------------------------------
Linnea Sullivan
------------------------------

Original Message:
Sent: Fri March 18, 2022 08:58 AM
From: Simon Dodge
Subject: Access Monitor report on Permissions with COMPLEX data

Hi Linnea, While I am surprised you are not getting any error messages regarding the concatenation of CKFREEZE files you can clearly tell from the messages that only the first one in each concatenation is being recognised/used.

You need to use unique DDnames per CKFREEZE, and individual ALLOC statements for each one.. multiple CKFREEZE with same complex= value is not an issue (it is UNLOADs, by definition, for which you can only have 1 per complex).

It would be useful to see SYSPRINT again results after you have adjusted JCL/Allocs.

------------------------------
Regards,
Simon Dodge

Original Message:
Sent: Thu March 17, 2022 05:39 PM
From: Linnea Sullivan
Subject: Access Monitor report on Permissions with COMPLEX data

I was actually using access_intent_max_suc in my code, just heading was set as "Access_Intent".      I did add the MAX modifier and that seemed to have resolved my issue.    So if the user attempted to access the "dataset" at different times with READ and other times as UPDATE, it would show me the MAX intent would be UPDATE.    Correct?


I looked at my SYSPRINT again, I am getting no RC16's.    My CKR0615 message is a RC00.   I attached my SYSPRINT.

------------------------------
Linnea Sullivan

Original Message:
Sent: Wed March 16, 2022 04:08 PM
From: Rob van Hoboken
Subject: Access Monitor report on Permissions with COMPLEX data

In the sample output, ACCESS_USED is only filled in for the lines with a LASTUSE date.  This column is actually access_intent_max_suc, a field you can find in the CARLa field reference, so it acts as a summary key field.  That means, a separate line is shown for the missing value of access_intent_max_suc, and another for the accessed value.
If you want to combine these lines together, you could change this column into a statistic (add the MAX modifier).  Though that kills the distinction between READ and ALTER access on the profile, so you've got to realize what MAX will do.

About CKR0135, have you looked at the output of CKR0615 in your SYSPRINT, and do you see all the systems whose CKFREEZE you allocated?  Are there any other messages with severity 16?

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

Original Message:
Sent: Wed March 16, 2022 02:53 PM
From: Linnea Sullivan
Subject: Access Monitor report on Permissions with COMPLEX data

I looked at my SYSPRINT, I do not see any CKR0135 messages.

Hopefully this is the last question.   Attached is my JCL and sample report.    It looks like all permissions that are unused only appear once in the report.   But any permission that is used appears twice (once with no activity, once with a last use date)   For example look at Class CTCICCMD Resource PROGRAM*.**



































































































------------------------------
Linnea Sullivan

Original Message:
Sent: Wed March 16, 2022 09:35 AM
From: Rob van Hoboken
Subject: Access Monitor report on Permissions with COMPLEX data

CKRSPROF already contains a simulate access_fallback_default command.

Normally, zSecure looks at the SYSTEM field in ACCESS records to match the event/observation to a CKFREEZE.  Next it uses the COMPLEX value specified on the ALLOC TYPE=CKFREEZE COMPLEX=cccc to identify the matching RACF database or UNLOAD.  When there is no COMPLEX specified in ALLOC commands, the SYSTEM value inside the CKFREEZE is matched with the SYSTEM name in the UNLOAD data set.

The CARLa syntax manual (ALLOC command section) describes how SMF and ACCESS records are processed:

The SYSID is always first searched in the CKFREEZE sources, and each individual record is assigned to the matching COMPLEX. If the SYSID cannot be matched, a specified COMPLEX name is used. If no COMPLEX name has been specified, the SYSID is used as default for the COMPLEX.

Of course, the SYSID assignement is overriden using the SIMULATE ACCESS_FALLBACK_DEFAULT command.  Look at message CKR0615 to see the match of input data sets and complexes. 

I wonder if there are any error messages complaining about concatenated CKFREEZE data sets.  For example CKR0135.  I think only the first system in the concatenation is recognized.  That suggests that many ACCESS records are mapped to the default system and complex, and consequently associated with the wrong RACF database.

You need a separate ALLOC TYPE=CKFREEZE COMPLEX=cccc DSN=ddddd or DD=ddddd for each CKFREEZE dsname

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

First CKR2251 message is

 CKR2251 00 Simulating system PLEX with complex PRD default PR18 because no CKFREEZE file matching C1ACC00  SYS611 SYSSA.#ZSECURE.SSZ                                                                                                                          

You could get the whole dsname of the ACCESS data set by increasing the LRECL for SYSPRINT, but from the ddname C1ACC00 we see it is reading

 CKR1412 00 Started processing TYPE=ACCESS file C1ACC00  SYS611 SYSSA.#ZSECURE.SSZSECAM.PRDPLEX.R18MON                                                                                                                                                         

Now, lets find the ALLOC commands

      1 |  /* zSecure Unload: Daily - All Systems */                                                                                                                                                                                                           
      2 |  ALLOC TYPE=UNLOAD DD=C2UNL00 COMPLEX=PRD                                                                                                                                                                                                            
     18 | /* zSecure CKFREEZE Daily - All Systems */
     19 | alloc type=CKFREEZE DD=C3IOC00 COMPLEX=PRD
     20 | /* alloc type=CKFREEZE DD=C3IOC01 COMPLEX=PRD
     21*| alloc type=CKFREEZE DD=C3IOC02 COMPLEX=PRD
     22*| alloc type=CKFREEZE DD=C3IOC03 COMPLEX=PRD
     23*| alloc type=CKFREEZE DD=C3IOC04 COMPLEX=PRD
     24*| alloc type=CKFREEZE DD=C3IOC05 COMPLEX=PRD
     25*| alloc type=CKFREEZE DD=C3IOC06 COMPLEX=PRD
     26*| alloc type=CKFREEZE DD=C3IOC07 COMPLEX=PRD
     27*| alloc type=CKFREEZE DD=C3IOC08 COMPLEX=PRD
     28*| alloc type=CKFREEZE DD=C3IOC09 COMPLEX=PRD
     29*| alloc type=CKFREEZE DD=C3IOC0A COMPLEX=PRD
     30*| alloc type=CKFREEZE DD=C3IOC0B COMPLEX=PRD */
     81 | ALLOC TYPE=ACCESS DD=C1ACC00 COMPLEX=PRD

The asterisks in the line number indicate you commented out the majority of CKFREEZE allocations, and this is reflected in CKR0615, because it only shows 1 CKFREEZE for the complex:

 CKR0615 00 Input system structure overview (default system PR18 complex PRD):                                                                                                                                                                                 
       Ver  Complex  Func  Prod System   Timestamp         Filename Volser Dsname                                                                                                                                                                              
            PRD      Main  RACF PR18     21 Mar 2022 00:00 C2UNL00  SYS002 SYSSA.RACF.PRDPLEX.ZSECUNLD.DAILY.G0042V00                                                                                                                                          
                           RACF PR18     21 Mar 2022 08:08 C3IOC00  SYS004 SYSSA.#ZSECURE.XDS3645A.SPR18.CKFREEZE                                                                                                                                              

Back to CKR2251.  It suggests that a record was found in SYSSA.#ZSECURE.SSZSECAM.PRDPLEX.R18MON with the value PLEX in the position where the system ID is expected.  Obviously, there is no CKFREEZE collected on an LPAR called PLEX, but luckily you specified COMPLEX=PRD on the ALLOC TYPE=ACCESS command, so CKR2251 tells you the faked system is mapped to PR18, the only system in complex PRD.

Next bunch of CKR2251 messages shows that another ACCESS data set also contains this same fake system id:

 CKR2251 00 Simulating system PLEX with complex TST default DV26 because no CKFREEZE file matching C1ACC20  SYS603 SYSSA.#ZSECURE.SSZ                                                                                                                          

and when we look up the ALLOC command for C1ACC20 we see this is indeed mapped to complex TST.

     86 |  ALLOC TYPE=ACCESS DD=C1ACC20 COMPLEX=TST  

CKR0615 shows that this complex has several CKFREEZEs allocated, but none of them is PLEX:

 CKR0615 00 Input system structure overview (default system PR18 complex PRD):                                                                                                                                                                                 
       Ver  Complex  Func  Prod System   Timestamp         Filename Volser Dsname                                                                                                                                                                              
            TST      Main  RACF DV22     21 Mar 2022 00:08 C2UNL20  SYS602 SYSSA.RACF.TSTPLEX.ZSECUNLD.DAILY                                                                                                                                                   
                           RACF DV21     21 Mar 2022 06:32 C3IOC20  SYS623 SYSSA.#ZSECURE.XDS3646A.SDV21.CKFREEZE                                                                                                                                              
                           RACF DV22     21 Mar 2022 06:44 C3IOC21  SYS618 SYSSA.#ZSECURE.XDS3647A.SDV22.CKFREEZE                                                                                                                                              
                           RACF DV25     21 Mar 2022 06:54 C3IOC22  SYS621 SYSSA.#ZSECURE.XDS3650A.SDV25.CKFREEZE                                                                                                                                              
                           RACF DV26     21 Mar 2022 07:05 C3IOC23  SYS611 SYSSA.#ZSECURE.XDS3651A.SDV26.CKFREEZE                                                              

Why DV26 is assigned, and not DV20, is not documented, really, but it is the last ALLOC command for the complex.

Now for the reason we see CKR2251 at all.  zSecure reads the allocated ACCESS data sets in parallel.
For each ACCESS record, it finds the corresponding system anchor, that was populated from CKFREEZE data sets.  If there is no corresponding system, it uses the complex from the ALLOC command to fake map the system name.
When this mapping process was first written, a slew of CKR2251 messages was produced, so the algorithm was improved to test if the same mapping was applied in the previous record, and if so, to suppress CKR2251.  With 1 input data set this simple algorithm resulted in 1 visible message.
However, if you have a mix of input data sets, the previous system processed field will frequently have something other than PLEX, in which case the messages "I found a record for PLEX that I couldn't map" is issued, over and over.

You could add a SUPPRESS MSG=2251, but then you will be unaware of missing CKFREEZE data sets.
You could stop faking the system ID with PLEX, and allocate (small) CKFREEZEs for all LPARs.
Of zSecure could be improved to prevent an avalanche of CKR2251.

However, I see that a complex is assigned to each ACCESS data set, so I would expect your report to be ok.

For light reading and keeping perspective I recommend https://thedailywtf.com/
------------------------------
Rob van Hoboken
------------------------------