Reason for ACF99910 ACF2, VIOLATION EXCESSION, CANCELLED . OMVS Address Space cancelled.

Products

• ACF2
• ACF2 - z/OS
• ACF2 - MISC

Issue/Introduction

 ACF99910 ACF2, VIOLATION EXCESSION, CANCELLED                        
 IEF196I ACF99910 ACF2, VIOLATION EXCESSION, CANCELLED              
 IEA989I SLIP TRAP ID=X222 MATCHED.  JOBNAME=OMVS    , ASID=00nn.     
*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?

Environment

Release : 16.0

Component : CA ACF2 for z/OS

Resolution

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:

Scenario:

• The mount request is occurring almost at the same time every day.
• There is a probability that a DCOLLECT Batch job running at that time. ( DFSMS IDCAMS DCOLLECT)
• When DCOLLECT sees an HFS, it tries to automatically mount and then unmount it afterwards trying to get Space Usage. 
• When DCOLLECT gathers information about an HFS, an implicit mount is issued to gather the statistics, and then the filesystem
  gets unmounted.

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:

1. Turn on the SYSOMVS CTRACE
   
   TRACE CT,64M,COMP=SYSOMVS
   Reply: R XX,OPTIONS=(FILE),END
   
   
2. Wait for the dataset violation
   
   
3. Take a console dump
   
   DUMP COMM=(DUMP OF OMVS)
   R nn,JOBNAME=(OMVS),DSPNAME=('OMVS'.B*,'OMVS'.S*),CONT
   R rn,SDATA=(CSA,LPA,TRT,RGN,SUM,SQA,ALLNUC,PSA,XESDATA,COUPLE), CONT
   
   
4. Turn off SYSOMVS CTRACE
   
   TRACE CT,OFF,COMP=SYSOMVS