Enhancements to Access Monitor Option 3 and Option 8

When using Option 3 or Option 8 to perform inactive permission reporting we are suggesting the following enhancements to Access Monitor.

• Access Monitor AM.8.1, AM.8.2, and AM.8.3 all produce commands to cleanup profiles, permissions, or connections. Using AM.8.2 as an example you get commands created to delete inactive permissions and commands to restore those permissions. However, what is missing is a report of what is being proposed to being deleted. A possible solution is to use the reporting from AM.3 and select permissions with a zero count. However, the number of PERMIT delete commands generated with AM.8.2 does not agree with the output from the report in AM.3.

When you have an environment of multiple RACF DB’s that are kept insync via RRSF you need to analyze inactivity across the environment. So, you need to use as input the Access Monitor data from all the systems in the environment, all the CKFREEZE files, and Access Monitor requires a RACF DB or Unload from each system in the Access Monitor data.

• The AM.8 options do not handle environments with multiple RACF DB’s. The ISPF screens limit you to one RACF DB/Unload as an input file, but you can select multiple AM Data files / CKFREEZE files. But this results in a CKR0617 message because you do not have a RACF DB/UNLOAD from those systems.

• To bypass the limitation of AM.8 of one RACF DB/UNLOAD, we tried accessing the RACF Primary or Backup via the zSecure Server in hopes it would see it as a single instance. The AM.8 Options do not allow usage of a RACF Db as an input source if the ALLOC statement uses ZSECNODE. You get a CKR3005 message. I would assume this restriction is removed in version 3.1 since it is our understanding that you can read Access Monitor data over the zSecure Server.

• The AM.3 option does allow for inputs from all the impacted systems however when you specify zero counts, a permission is written to the report if the permission has a zero on Successes, Violations or Unknowns. And if its zero on at least one of the RACF DB’s. This would mean if you intended to keep your RACF DB’s in sync, any inactivity on any single RACF DB could cause the permission to be deleted. The permission needs to show a zero count on all systems.

• We have also noticed that the run time for a job running AM.3 versus AM.82, the AM8.2 jobs run significantly longer and both are reading in the same input files. It appears it has to do with what is pre-selected.