In ACF2/CICS transaction resource access rules, when DATA is added to rule line, user's access to the protected resource is disabled. When DATA is removed, access is available.
What is causing this?
A site written CICS program was using ACFAEUCP for resource validations to ACF2. When this is the case, CICSKEY USERDATA=NO does not take effect and the USERDATA information is passed back to the calling program. Sites should use ACFAEUCR in order to be able to suppress any USERDATA information being returned to the caller.
If ACFAEUCP is being used, the common area has to account for an adequate amount of space for the data being returned, otherwise an overflow may occur and cause unintended violations as described above. The data area contains both the $USERDATA control card information as well as the DATA field information in the rule entry. Accounting for x'130' amount of space should be adequate to allow the max amount of data to be returned.
Example:
The $USERDATA field on the ruleset is rather large:
$USERDATA(THIS IS A RATHER LARGE AMOUNT OF USERDATA FOR A RULE)
If the common area for the program only allowed for x'40' (64 bytes) length for the data area, there are only x'C' (12 bytes) remaining for the DATA on the rule entry.
Having a length greater than the allotted x'40' (64 bytes) will overwrite any other field that comes below the field containing the USERDATA information which had the effect of DENYing the user access.
Options for resolving the above example are: