The client received an ACF2 violation, ACF99913, when attempting to auto-enable a rule:
OPSMAIN ACF99913 ACF2 VIOLATION-04,00,BPXOINIT,OPSMB1,SYS2.OPSMVS.QUAL.STATEMAN.RULES,N/A
OPSMAIN IEF196I ACF99913 ACF2 VIOLATION-04,00,BPXOINIT,OPSMB1,
OPSMAIN IEF196I SYS2.OPSMVS.QUAL.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?
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:
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.