Impact of ACF2 $USERDATA and DATA fields on CICS access
search cancel

Impact of ACF2 $USERDATA and DATA fields on CICS access

book

Article ID: 251029

calendar_today

Updated On:

Products

ACF2 - z/OS ACF2 ACF2 - MISC

Issue/Introduction

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?

Resolution

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:

  1. Keep the combined length of the USERDATA field and the DATA field less than 64 bytes.
  2. Change the amount of space allocated for the USERDATA information to x'130'.
  3. Change the assembler program to use ACFAEUCR and not return the USERDATA and DATA fields.