ACF2 Troubleshooting Guide: How to write or debug a resource rule with violation information
Article ID: 264349
Updated On:
Products
Issue/Introduction
This document discusses how to write an ACF2 resource rule based off of an ACFRPTRV report violation in order to allow access to a resource. It serves as an example and will not cover all available use cases.
Before completing the steps in this document, make sure to obtain the following information:
- The violation information in the RV report. The RV report should be ran against the SMF active at the time of the error.
- If possible: the error/violation message that the user sees
Sample RV report JCL:
//REPORT EXEC PGM=ACFRPTRV
//SYSPRINT DD SYSOUT=*
//HEXDUMP DD SYSOUT=*
//* RECMAN1 DD DSN=IFASMF.STREAM,DISP=SHR,
//* SUBSYS=(LOGR,IFASEXIT)
//RECMAN1 DD DISP=SHR,DSN=SYS1.MAN1
//RECMAN2 DD DISP=SHR,DSN=SYS1.MAN2
//RECMAN3 DD DISP=SHR,DSN=SYS1.MAN3
//SYSIN DD *
TITLE(ACFRPTRV)
Environment
Release : 16.0
Resolution
Listed below is a sample violation from the RV report and a description of multiple pieces of information that assists in writing a rule to address the resource violation:
RFAC-IRR.DIGTCERT.LISTRING *VIO RFAC-IRR
TESTLID STCINRDR SYS1 ACF9CAUT NO-RULE - DIRECTRY UPDT
23.108 04/18 11.10 TESTJOB TESTLID TESTING LID 0 0 20 0 16
RESOURCE NAME: IRR.DIGTCERT.LISTRING
IRR.DIGTCERT.LISTRING - is the full resource name
FAC - is the ACF2 type code for the resource class
IRR - is the $KEY of the rule that was searched
TESTLID - is the UID string for the user. Take care if there are spaces in the UID string like in the example. Those must be accounted for when writing UID based resource rules.
NO-RULE - means that a ruleset was found, but there is no rule entry that matches the environment being requested. This is a very important distinction from NO-REC, which if seen means that there is no ruleset for the resource (ie the $KEY doesn't exist).
UPDT - is the SERVICE level access being requested. UPDT means that the SERVICE level requested is for UPDATE access.
The error below is an example of what the end user would see. It is not as descriptive as the RV report, but does provide the TYPE code and resource name to help in debugging access needs:
ACF04056 ACCESS TO RESOURCE IRR.DIGTCERT.LISTRING TYPE RFAC BY TESTLID
NOT AUTHORIZED
Once the RV report has been analyzed, if NO-RULE is seen, then the ruleset will need to be listed or decompiled to see where the issue is. If NO-REC was seen, then a new rule would need to be created. In the example with NO-RULE, the rule exists and is in type code FAC and has a $KEY of IRR:
SET R(FAC)
LIST IRR
ACF75052 RESOURCE RULE IRR STORED BY ADMIN ON 12/03/24-16:13
$KEY(IRR) TYPE(FAC)
DIGTCERT.LISTRING UID(****************TESTLID) SERVICE(READ) ALLOW
ACF75051 TOTAL RECORD LENGTH= 222 BYTES, 5 PERCENT UTILIZED
From this point, take a look at the resource rule entries such as the resource name, the UID string and the SERVICE level in order to determine why access is not being granted. For this example, the rule entry specifies SERVICE(READ), but the RV report shows that the requested access is for UPDATE access. Therefore, the rule needs to be modified to look like this:
ACF75052 RESOURCE RULE IRR STORED BY ADMIN ON 12/03/24-18:13
$KEY(IRR) TYPE(FAC)
DIGTCERT.LISTRING UID(****************TESTLID) SERVICE(READ,UPDATE) ALLOW
ACF75051 TOTAL RECORD LENGTH= 222 BYTES, 5 PERCENT UTILIZED
If the rule is resident, be sure to issue an F ACF2,REBUILD(typecode) command on all systems that share the ACF2 database.
Additional Information
To get the violation information in RV report format, please see: ACF2 Troubleshooting Guide: Dataset/Resource unexpected violations or access allowed
For more information regarding the RV report, please see: ACFRPTRV - Resource Event Log
Feedback
