In the log there is
ACF01004 LOGONID KRAJE40 NOT FOUND
After that there are MAT initialization and monitoring messages for that userid.
The client wonders with that kind of ACF2 error, that MAT continues to process...
I'm seeing a ton of these for KRAJE40 in the MATUNER log:
04.14.44 STC00088 ACF99900 ACF2 LOGGING-08,06,MATUNER,,KRAJE40.YMGPDPBF.D201633
04.14.44 STC00088 ACF99900 ACF2 LOGGING-08,05,MATUNER,TEST19,KRAJE40.YMGPDPBF.D
04.14.44 STC00088 ACF99900 ACF2 LOGGING-04,00,MATUNER,TEST19,KRAJE40.YMGPDPBF.D
These are ACF2 messages and not CA MAT messages. There is a section that deals with configuring security for the major products, and the one concerned with ACF2 for CA MAT 10.0 is at the following link:
For the ACF2 message ACF99900 I see in the message description:
ACF2 LOGGING - rc, val, lid, vol, name, exit
The CA ACF2 access security logs a request because of access rule
designations, but access is allowed. If this access is for input, the
access is only logged to SMF and no message is issued to the user.
Is one of the reason codes defined below:
Read access was attempted.
Write access was attempted.
A DADSM ALLOCATE, SCRATCH, RENAME, or AMS/Catalog operation was attempted.
So, the error has occurred but ACF2 has "allowed access". Next to consider are security rules based on the dataset HLQ. I don't see ACF2 errors for violating a rule for this, so that is why this user is able to do it.
If one wants to stop the ACF2 error messages, one must delete everything associated with the ID.
CA MAT is not checking for this error, which is why the monitoring was able to occur even with that error message produced.