Hi everyone,

On an ACF2 system I am hoping to report on modifications made to the security database using zSecure. Below is my existing CARLA:

define type=smf acf2_chg_field(8,"field") as,
 acf2_changes
define type=smf acf2_chg_old(32,'old-value') as,
 substring(acf2_changes,9,32)
define type=smf acf2_chg_new(32,'new_value') as,
 substring(acf2_changes,42,32)

n type=smf name=smfsel outlim=0
 s exists(acf2_subtype) (((acf2_subtype=(e,l,r),
 acf2_eventtype<>update)))
 list type
mergelist
newlist type=smf name=smfdesc header=csvt
  select   likelist=smfsel
  sortlist date(12,eudate) time smfdd(nd) recno(nd),
           user(8) jobname(8) recorddesc(80),
           acf2_chg_field acf2_chg_old,
           acf2_chg_new acf2_event
endmerge

For resource or dataset rule updates it reports something like the following in the recorddesc field:

'ACF2 id XYZLID replace resource R-ITR-MQ#345'

Is there a way using zSecure that I can report on the specific changes made to the rule?

------------------------------
Nathan Shrive
------------------------------

Hi Nathan,

you have got to be aware that zSecure using the CARLa programming language you can only report on information that is part of its input resources. An SMF record does not store the original version of a rule and only contains information about the rule after the change to the rule occurred. So, I do not see a way to use SMF records for reporting more specific details about changes that occurred to ACF2 rules. 
However, you might have backups of your ACF2 security database. I am not an ACF2 expert on the content of ACF2 rules, but perhaps you could investigate the use of the CARLa COMPAREOPT command to compare the rules of let's say yesterday's ACF2 backup database against the ACF2 backup database of a week or month ago, to report differences in the rule contents over time.
For more information about COMPAREOPT statement: https://www.ibm.com/docs/en/szs/3.1.0?topic=language-compareopt

And some notes about the CARLa code that you shared.

• Why do you code the first newlist with name smfsel? Why not just code the select statement of your first newlist in the second newlist and omit the first newlist?
• There's only 1 newlist in your mergelist - endmerge sequence, thus there's no need for merging the results of muliple newlists in one report. You can remove the mergelist and endmerge statements.

Hope this helps, best regards Tom 

------------------------------
Tom Zeehandelaar
z/OS Security Enablement Specialist - zSecure developer
IBM
------------------------------

Hi Nathan,

Yes, there is a way to do this, although it is probably less convenient than you'ld like.

ACF2 writes two SMF records for updates to rule sets, one with ACF2_EVENTTYPE=UPDATE that contains the rule set's record image as it was before the change, and one with ACF2_EVENTTYPE=REPLACE that contains the after-image. So, one possible approach would be to split out the relevant data using something like this:

ALLOC ACTIVE SMF                                 
N TYPE=SMF                                       
 S ACF2_SUBTYPE=(E,R) ACF2_EVENTTYPE=UPDATE      
 UNLOAD DD=BEFORE                                
N TYPE=SMF                                       
 S ACF2_SUBTYPE=(E,R) ACF2_EVENTTYPE=REPLACE     
 UNLOAD DD=AFTER                                 

Then, you can format the interesting part of the SMF records (i.e., the rule sets) wit the following CARLa:

newlist type=smf nopage          
  sortlist ,                     
        / acf2_rule_header,      
        / acf2_rule_entry        

If you direct the output to two different data sets, you can then use your favourite comparison tool (e.g. SuperC) to spot the differences.

There are many different approaches that vary only in details, but this is the basic idea.

------------------------------
ERIK van der NAT
------------------------------

Thanks very much to you both for your replies. 

• Why do you code the first newlist with name smfsel? Why not just code the select statement of your first newlist in the second newlist and omit the first newlist?

There's only 1 newlist in your mergelist - endmerge sequence, thus there's no need for merging the results of muliple newlists in one report. You can remove the mergelist and endmerge statements.

Thanks for the suggestions Tom, those extra bits were generated by zSecure and i hadn't removed them from my code. I've done that now and its working, thanks :)

Erik, I'll give that a go and see if its suitable for my situation. Cheers. 

------------------------------
Nathan Shrive
------------------------------

Original Message:
Sent: Fri September 20, 2024 08:41 AM
From: ERIK van der NAT
Subject: ACF2 SMF reporting

Hi Nathan,

Yes, there is a way to do this, although it is probably less convenient than you'ld like.

ACF2 writes two SMF records for updates to rule sets, one with ACF2_EVENTTYPE=UPDATE that contains the rule set's record image as it was before the change, and one with ACF2_EVENTTYPE=REPLACE that contains the after-image. So, one possible approach would be to split out the relevant data using something like this:

ALLOC ACTIVE SMF                                 
N TYPE=SMF                                       
 S ACF2_SUBTYPE=(E,R) ACF2_EVENTTYPE=UPDATE      
 UNLOAD DD=BEFORE                                
N TYPE=SMF                                       
 S ACF2_SUBTYPE=(E,R) ACF2_EVENTTYPE=REPLACE     
 UNLOAD DD=AFTER                                 

Then, you can format the interesting part of the SMF records (i.e., the rule sets) wit the following CARLa:

newlist type=smf nopage          
  sortlist ,                     
        / acf2_rule_header,      
        / acf2_rule_entry        

If you direct the output to two different data sets, you can then use your favourite comparison tool (e.g. SuperC) to spot the differences.

There are many different approaches that vary only in details, but this is the basic idea.

------------------------------
ERIK van der NAT
------------------------------

When I last looked at ACF2 logging, that must have been in 2020, I had limited success in tracking updates to resource rules.  That is probably due to documented behavior of the ACF2_CHANGES field, only supporting infostor and lid records:

However, with Erik's observation, the following should put the REPLACE and UPDATE events more or less together.  It relies on the TIME field in SMF records to have 0.01 second granularity and ACF2 updates being faster.  If that's not the case, you could remove the TIME field from the SUMMARY command and move it into the SORTLIST:

n type=smf 
  S ACF2_SUBTYPE=(E,R) ACF2_EVENTTYPE=(REPLACE,UPDATE)
  sortlist date(12,eudate) time smfdd(nd) recno(nd),
           recorddesc(80),
         / acf2_rule_entry
  summary date(12,eudate) time user(8) jobname(8) acf2_rulekey count(nd) /

There seems to be a disconnect between Erik's statement

and the manual that suggests UPDATE only occurs for L records

the manual probably needs a fix, right?

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