One of the variables for OPSAOF security events is SEC.AUAORSNA.
When somebody is using Dynamic Rules, SEC.AUAORSNA or the current rule set name string is set to *DYNAMIC.
But RACF doesn't like qualifiers as *DYNAMIC:
Defining the profile
/* OPS/MVS OPSAOF */ RDEFINE XFACILIT OPSMVS.OPSAOF.*DYNAMIC.RULE1 + OWNER(G$PSYS) UACC(NONE) RALT XFACILIT OPSMVS.OPSAOF.*DYNAMIC.RULE1 + AUDIT(ALL(READ)) RALT XFACILIT OPSMVS.OPSAOF.*DYNAMIC.RULE1 + DATA('OPS/MVS AOF DYNAMIC RULES')
IKJ56702I INVALID ENTITY, OPSMVS.OPSAOF.*DYNAMIC.RULE1IKJ56702I INVALID ENTITY, OPSMVS.OPSAOF.*DYNAMIC.RULE1IKJ56702I INVALID ENTITY, OPSMVS.OPSAOF.*DYNAMIC.RULE1
It's possible to circumvent the problem, changing the SEC.AUAORSNA *DYNAMIC to something as @DYNAMIC in the AOF security rule before using OPSECURE to reach following RACF-definition :
RDEFINE XFACILIT OPSMVS.OPSAOF.@DYNAMIC.RULE1 + OWNER(G$PSYS) UACC(NONE)
But it doesn't show the real situation when an error occurs (violation...).
The person, who changed the rule will know it, but later on it will be difficult to find the link between @DYNAMIC rules and the documentation of CA Technologies.
As it's necessary to protect the rule-sets in our environment, with different types of access as a refinement of the external security, I liked to know how others solved the problem.
We've taken the approach to just remove the asterisk before doing the opsecure() call.
Never had any confusion.
Marcel van Ek
this is quit the same as replacing the * by an @.
But what to do when SEC.AUAODSNA is an asterix (*)? See Option 4.5.1 with * as rule set name?
Here again we have to replace the * by something as a resource OPSMVS.OPSAOF..L or OPSMVS.OPSAOF.*.L is not valid for RACF,
while OPSMVS.OPSAOF.@.L is valid. You also can use $ or £ or €.
Frank TernestEuroclear NV/SA
Frank, the * in 4.5.1 (or 4.5.3 for that matter) only executes an AOF LIST (or LISTINST) instruction , then internally in ISPF code it loops through all the found rulesets.
We use SEC.AUAORSNA (rulesetname) to determine access, not the fully qualified dsname.(these are dataset protected anyway)
Only in the LISTINST (4.5.3) it will include the *DYNAMIC entry as a whole. And as said we internally replace the SEC.AUAORSNA with the * removed. So no problem.
We've been running this for over 20 years like this. Not only for RACF but also supporting ACF2 and TSS.
I opened a case at CA Technologies, but without a great response (with the exception of a document "how to define General resources" from Stu Henderson, dated 2007.I started working with RACF in 1989 with MVS V3 and prepared also the course RACF Advanced Administration. I think that I know a little bit about RACF.
But the problem is not only a problem for RACF, but also for TSS users.Best Regards,