We're looking to collect Unix event information through Access Monitor, but the size of the daily collect file seems to explode.  So I'm wondering what experience you all have with Option CaptureUSSEvents.  Have you managed to rein in the size of the data sets, and did you get any useful reporting?

When I use AM.U, it tells me the largest (most frequent) users of Unix system calls:

Occurrence Userid

    124282 DBDC  
     90104 IZUSVR
     31674 PFAUSER
     96159 TCP   

No surprises there, this is a sysprog system, no production workload, but this does not tell me how many records there are.  I checked the first user ID, there are only 15 records!  So we need a way to list the number of records in the input data set.

After hitting F3 on the summary, we get back into the AM.U query panel.  Type RESULTS in the command line and edit the COMMANDS entry.  These are the CARLa commands that produce the summary.  Add the field name COUNT into the SUMMARY command, right after tot_count:

dsummary userid(nd),
         tot_count(descending,noprop) count userid userid:name ,
                                      unix_uid, unix_gid ,
                                      "        ",
                  first_tod_sum last_tod_sum,                  

Type GO in the command line, and your modified CARLa produces a summary with the record count added:

Occurrence Count Userid

    124282    15 DBDC
     90104 20750 IZUSVR
     31674   890 PFAUSER
     96159 22402 TCP   

Now we're getting somewhere, ZOSMF and TCP are the main culprits.  So lets see what they're doing.  I added a further COUNT and SUMCOUNT field in the next summary level (after defining DEFINE SUMCOUNT(6,"Unique") SUMCOUNT):

    Occurrence Count Userid   Name                 Uid      
         90104 20750 IZUSVR   ZOSMF STARTED TASK U

    Occurrence Count Unique Int  Event            Return code
            23    23     23 --w- access           EOK       
             1     1      1 -r-- access           ENOENT    
          2908  2905   2905 ---- chmod            EOK       
         22999    74     74 ---- lstat            EOK       
          3318  3014   3014 ---- lstat            ENOENT    
             5     5      5 ---- mkdir            EOK       
             4     4      4 ---- mkdir            ENOENT    
            26     4      4 ---- opendir          EOK       
          2947  2937   2935 -rw- open             EOK       
          2920  2917   2916 --w- open             EOK       
            86    38     38 -r-- open             EOK       
          2912  2909   2909 ---- rename           EOK       
         49032  3001   3001 ---- stat             EOK       
             4     3      3 ---- stat             ENOENT    
            11    10     10 ---- unlink           EOK       
          2908  2905   2905 ---- chattr           EOK       
 ********************************************************* Bo

This tells us those 2908 records on the 3rd line are due to 2905 unique path names.  And most other system calls show the same: most records are for unique file names, so we drill down (I mean, enter the S line command) to see the unique names:

Occurrence UNIX pathname                                                
         1 /shared/zosmf/data/app/zwlm/.izu1000368875842778747.tmp      
         1 /shared/zosmf/data/app/zwlm/.izu10005579781983731015.tmp     
         1 /shared/zosmf/data/app/zwlm/.izu1002243325420227564.tmp      
         1 /shared/zosmf/data/app/zwlm/.izu10027328262551102643.tmp     
         1 /shared/zosmf/data/app/zwlm/.izu10051405768477937176.tmp     
         1 /shared/zosmf/data/app/zwlm/.izu10057705955302454195.tmp     
         1 /shared/zosmf/data/app/zwlm/.izu10059854027794648582.tmp     
         1 /shared/zosmf/data/app/zwlm/.izu10061623973062270072.tmp     
         1 /shared/zosmf/data/app/zwlm/.izu10065452097376927103.tmp      

and the same with user ID TCP:

         Occurrence Count Userid   Name                 Uid      
     96159 22402 TCP      NETWORK                         0
     
Occurrence Count Unique Int  Event            Return code
      5599  5593   5593 ---- access           ENOENT    
      
Occurrence UNIX pathname                                
         1 /S001/tmp/aabcehffA                          
         1 /S001/tmp/aabBEdEBA                          
         1 /S001/tmp/aacgbGFBA                          
         1 /S001/tmp/aacHeGhgA                          
         1 /S001/tmp/aafhEGHgA                          
         1 /S001/tmp/aafDAbhdA                          
         1 /S001/tmp/aafDAddAA                          
         1 /S001/tmp/aageGaFgA                          

We see that system applications are creating temporary files (in various ways) and syscalls for these consume (the majority? of) space and CPU in C2PACMON. 

1. Have any of you found ways to suppress (or reduce) these events in C2PACMON?  Without EDITING or replacing the members in SCKRCARL?
2. If you also like to see better tuning support in the Access Monitor panels, vote for Add AM.1 option to see number of ACCESS records found

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

Rob,

I have the following conversion rules in place for Access monitor consolidation

unix001 result using a rolling year of data.

(Note: the entries with a digit last has been corrected and replaced by an "n", and these "errors" will eventually roll off)

I hope that this is helpful to you.

Regards

Brian

 can use thisHpefully th

This is immensely helpful, Brian, thank you.

I have created similar conversion rules for dsname resources, reducing traditional ACCESS record count by 80% or better.  The QUAL( ) function is designed for RACF resources, with a period separating the qualifiers.  That means your rule UNIX001 (only) works by virtue of the ZOSMF filenames starting with a period.  We must hope that ZOSMF does not stop using hidden file, eh?

It would be helpful if CARLa had a similar REPLCHAR target referring to the nodes in the pathname value.

Or better still, if C2PACMON had a filter function.  You know, when the syscall exit is called, it does not receive the path name as such, but it has to stitch the path name together from all the node names down to root (/).  So essentially, this could be the place where a filter would reduce the random file names for specific directories at the source, saving CPU and storage even more, without having to parse the complex pathname value.

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