Access Monitor provides a highly efficient method to store information about RACF access decisions. The services monitored by Access Monitor are RACHECK and FRACHECK, RACROUTE REQ=AUTH and FASTAUTH. Logon and job initiation are logged from RACINIT calls and RACROUTE REQ=VERIFY. Reports from Access Monitor data allow you to find the resources needed by one or more RACF user id(s), in any class, even when SMF logging for the class was not activated. You can also find all users whom RACF allowed access a to resource, of were failed in their access attempt. Access Monitor can be used to correlate access events with profiles in the RACF database, and show users and/or groups that required access on a profile, and profiles that were unused. Even helps you find group connections that were never used.
In order to store RACF decisions, Access Monitor counts all events that have identical characteristics, such as, user id, class, resource, intent, RACF return code and a few more, in the observation interval. It stores the identifying characteristics in a record, adds the time stamp of the last occurrence and a count of these events, and writes the record into a sequential data set. The size of this data set is at least an order of magnitude smaller than SMF data of the same interval because the individual events are not stored, but only a single record for the set of key identifiers.
The Access Monitor started task (C2PACMON) creates daily data sets for events that occurred the day before. In most production systems, activity on one day will be similar to the events on any other working day. Production jobs run with the same RACF user id and access the same databases. The dsname of log or backup data sets may be different, when they contain a generation number or the date when the log was created, but otherwise... repetitive.
In a single LPAR of a production system, with Access Monitor newly installed, the daily data set contained 140,000 to 165,000 Access Monitor records, describing approx. 2 million RACF access decisions per day. Adding up all daily data sets in a month, the number of records was 5,920,000.
However, the same production user ids access the same data sets, day after day. When we combined all daily data sets, using a consolidation job, the number of records in the resulting monthly consolidation data set was only 1,429,000; consolidation resulted in 75% space savings. Consolidation stores the same information about user behavior in a quarter of the number of tracks. However, it is not just a saving in DASD storage size, since a quarter of the tracks, compared to the daily data sets, have to be read, processing is about 4 times as fast. And you allocate 1 data set instead of 30 for a month.
Normally, installations consolidate their daily Access Monitor data sets into a monthly, right after the month ends. Since the monthly contains the same information, with exception of the exact date(s) when access was needed, most installations subsequently delete the dailies.
Some installation combine the 12 most recent monthlies into a 12 month running consolidation, in the same job that constructs the monthly, using JCL in SCKRSAMP(C2PJCONM). Others have jobs that maintain a yearly for the last year and a year to date for the current year, using JCL based on SCKRSAMP(C2PJCOND). However you choose, you have to arrange for these jobs to run, C2PACMON only creates dailies. The sample job are described in more detail in Sample consolidation jobs.
When browsing through a monthly you will see many similar data set names, containing a date, time or sequence number in a qualifier. Access Monitor automatically detects generation and version numbers for Generation Data Groups (GDG), and replaces these with the literal string "GnnnnVnn." It also changes the job number and sysout data set id in JESSPOOL resource names. This concept is called data reduction and is detailed in Data reduction of Access Monitor records. When we constructed a C2PAMMAP member with CONVERSION commands, the size of the monthly Access Monitor data set was further reduced to 635,000 records, i.e., 11% of the original size. C2PACMON uses the data reduction directives from C2PAMMAP while it collects events into its collection data set, and subsequently also in the daily consolidation.
| events | records | |
| 30 daily data sets | 65,000,000 | 5,920,000 |
| 1 monthly | 65,000,000 | 1,429,000 |
| after data reduction | 65,000,000 | 635,000 |
Data reduction not only reduces the size of the data, but also drastically reduces the run time, CPU and storage needed to generate reports from Access Monitor information.
Below is a screen print of an installation that has been running Access Monitor since May 2015, they consolidate all LPAR dailies into PRODPLEX data sets, keep their monthlies for ad-hoc reporting needs, and use YTD and MTD for most of their reporting:
Data set name tracks used IBMZSEC.PRODPLEX.DATA.C2PACMON.D160301 8715 99 IBMZSEC.PRODPLEX.DATA.C2PACMON.D160302 8535 99 IBMZSEC.PRODPLEX.DATA.C2PACMON.D160303 8490 99 IBMZSEC.PRODPLEX.DATA.C2PACMON.D160304 8685 100 IBMZSEC.PRODPLEX.DATA.C2PACMON.D160305 8055 99 IBMZSEC.PRODPLEX.DATA.C2PACMON.D160306 8130 99 IBMZSEC.PRODPLEX.DATA.C2PACMON.D160307 8730 99 IBMZSEC.PRODPLEX.DATA.C2PACMON.D160308 8655 99 IBMZSEC.PRODPLEX.DATA.C2PACMON.D160309 8580 99 IBMZSEC.PRODPLEX.DATA.C2PACMON.D160310 9000 97 IBMZSEC.PRODPLEX.DATA.C2PACMON.MTD 52650 54 IBMZSEC.PRODPLEX.DATA.C2PACMON.M1505 IBMZSEC.PRODPLEX.DATA.C2PACMON.M1506 IBMZSEC.PRODPLEX.DATA.C2PACMON.M1507 IBMZSEC.PRODPLEX.DATA.C2PACMON.M1508 IBMZSEC.PRODPLEX.DATA.C2PACMON.M1509 IBMZSEC.PRODPLEX.DATA.C2PACMON.M1510 IBMZSEC.PRODPLEX.DATA.C2PACMON.M1511 IBMZSEC.PRODPLEX.DATA.C2PACMON.M1512 67125 99 IBMZSEC.PRODPLEX.DATA.C2PACMON.M1601 55275 99 IBMZSEC.PRODPLEX.DATA.C2PACMON.M1602 52650 99 IBMZSEC.PRODPLEX.DATA.C2PACMON.YTD 276000 32 IBMZSEC.PRODPLEX.DATA.C2PACMON.Y15 269865 99
Additional information: