Hi Bruno
Pulling ACCESS files through zEDC may alleviate DASD space usage, but definitely doesn't reduce the CPU time needed to skip millions of extra lines in these data sets, due to UNIX files with random names. Remember, each unique file name, even if it is accessed by only 1 user, generates a unique record for each type of UNIX action (event code). This penalty is incurred by every AM report.
Due to the utter lack of mapping support for UNIX file names, we have decided not to roll out UNIX file access monitoring.
We dabbled with filtering of the file names, using rules like this:
/* /shared/zosmf/data/app/zwlm/.izu7278164675141999.tmp */
/* QUALn( ) splits the filename on the dot(s) */
conv type=access u_zosmf1,
replchar((substr(qual2,4,20),'x')),
where rectype=unix,
UNIX_Pathname=/shared*/.izu%*.**
/* /SAND/tmp/acDHBHCcA */
conv type=access u_tcp1,
replchar((substr(qual1,11,9),'x')),
where rectype=unix,
userid=TCP,
UNIX_Pathname=/%%%%/tmp/%*
/* CKFCOLL scans whole filesys */
define type=access UNIX_Pathname(conv(u_zosmf1,u_tcp1)),
as unix_pathname,
where rectype=unix,
not(jobname=(C2POLICE,C2PCOLL),
unix_event=(chdir,lstat,opendir,pioctl))
The first conversion attempt only works on filenames that happen to contain a dot, and still produces many distinct records because the semi-random part is replaced by a variable number of x-es.
The third attempt present a much more rigorous (and promising) approach: for given combinations of user ID, filename and event code we simply blank out the whole unix_pathname; the value of unix_pathname is only recorded when the WHERE condition results in TRUE. If we ever decided to put this into use outside the Sandbox, I would delete the CONV definitions and reference, and only use this conditional field-value capability.
The filter approach was especially useful with zSecure Collect scanning the whole filesystem, issuing 4(!) calls for each directory (and file). We don't really care to see those reflected in AM reports. Note, when you run these lines from C2PAMMAP in C2PACMON, the JOBNAME field is still available, so you can use it in the WHERE condition. In the daily ACCESS files, the jobname is usually missing to conserve DASD space (and CPU time).
It is annoying that zSecure has this super-powerful data collection capability, but lacks management (out of the box filtering/mapping) in CARLa to make it acceptable for use.
------------------------------
Rob van Hoboken
------------------------------
Original Message:
Sent: 08/12/26 12:10 AM
From: Bruno Charon
Subject: Access Monitor and Unix events
Thanks for starting this thread, I'm also starting to implement that Access Monitor feature and also noticed an increase of access files size by x10 on the sandpit with the same pattern as Rob mentioned in the first post. In order to mitigate that issue, I've started to compress the daily and monthly files using zEDC and that works very well with zSecure, but I reckon some filtering at the daily collection would be more effective and thanks to Brian, I'll start exploring that way as well.
Now, I'm wondering how it would translate on systems which have more USS activity like WAS LPARs. Would there be any existing communication from IBM, similar of what was discussed about FSACCESS class preventing using that Access Monitor feature on WAS filesystems?
Beware of FSACCESS when WAS filesystems are involved. Java byte I/O causes an enormous amount of racroutes to the FSACCESS profile
Regarding the comment from Brian above, just confirming it is referring to the daily collection via C2PAMCOL?
Thanks.
------------------------------
Bruno Charon
------------------------------
Original Message:
Sent: 11/26/25 03:09 AM
From: Rob van Hoboken
Subject: Access Monitor and Unix events
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
------------------------------