CA OPS/MVS - ACF2 Violation When Auto-Enabling a Rule

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

The client received an ACF2 violation, ACF99913, when attempting to auto-enable a rule:

OPSMAIN ACF99913 ACF2 VIOLATION-04,00,BPXOINIT,OPSMB1,hlq.STATEMAN.RULES,N/A 
OPSMAIN IEF196I ACF99913 ACF2 VIOLATION-04,00,BPXOINIT,OPSMB1, 
OPSMAIN IEF196I hlq.STATEMAN.RULES,N/A 
OPSMAIN ACF90913 -DATASET CANNOT BE OPENED; AUTHORIZATION IS REQUIRED. 
OPSMAIN IEF196I ACF90913 -DATASET CANNOT BE OPENED; AUTHORIZATION IS REQUIRED.

Why was there a security violation for OPS before the recycle and not after?
 

Environment

CA OPS/MVS

Resolution

Changing the EUID, using SuperUser authority, is designed to be a temporary exercise. 

From IBM documentation on switching in and out of superuser authority: 

 . This activity should not be done in a multiprocess address space (which is what OPSMAIN is). 
 . Also, there is a 'rotation' of UID values when switching between the UID, the effective UID (EUID), and the real UID. 
 . This is why the UserID of the ASID in which this occurs does not change upon the first switch of a UID. 
 . If superuser authority is needed in a piece of automation, the switch/change should be done in an OSF/USS server ASID (to isolate OPSMAIN). 
 . If switching/changing the UID/EUID, the change should be reverted to what the values were before the change was needed, in the same piece of executing code. 

Reference doc URL: 

Switching in and out of superuser authority 

The client will find all occurrences of this changing/switching of the UID in their automation, and ensure that the UID is changed back to the necessary value and/or move the automation, so that the code is not executing in the OPSMAIN ASID.