ACF99910 ACF2, VIOLATION EXCESSION, CANCELLED
IEF196I ACF99910 ACF2, VIOLATION EXCESSION, CANCELLED
IEA989I SLIP TRAP ID=X222 MATCHED. JOBNAME=OMVS , ASID=0010.
*BPXI019E OMVS DETECTED A SEVERE INTERNAL ERROR THAT WILL REQUIRE A RE-IPL TO CORRECT
NOMAXVIO was added to OMVS logonid so it will not get cancelled again.
What caused the violations in the OMVS address space?
Release : 16.0
Component : CA ACF2 for z/OS
The way ACF2 MAXVIO processing works is that as soon as a dataset violation occurs, ACF2 will check the violation counter that keeps track of all violations (resource and access violations) for the life of the job/address space. DS and RV reports would need to be ran against the SMF active for the entire time the OMVS address space is running to count the amount of violations up to the number specified in GSO OPTS MAXVIO field.
The violations for the OMVS address space are usually for the mount of requested file systems that OMVS does not have access to. In order to find out who is attempting to mount the file system, the troubleshooting steps below would need to be implemented.
It is highly recommended to put the NOMAXVIO attribute on the OMVS logonid as OMVS is often a mission critical, long running task that should not be subject to cancellation with MAXVIO processing.
IBM troubleshooting details on how to find who is issuing a mount request:
Having a dump with the SYSOMVS CTRACE running would show who requested the mount that is performed by the OMVS address space. Then take a console dump after the dataset violation occurs.
Note: SYSOMVS CTRACE wraps around in a few minutes on an active system.
Follow these instructions to get the trace of OMVS activity: