ACF2

  • 1.  ACF2 CICS Transaction Record / Field level security

    Posted 07-20-2016 11:02 PM

    I have a requirement to enable ACF2 security for CICS transactions to control field / record level security. I do not have access to the transaction codes / script, and do not know what the field name at the back end.

    Example:

    EMPL [transaction screen]

    Option ===> I - Insert, D - Deleted, M - Modify

    ACF2 ID    ===>

    Name       ===>

    Mail Drop  ===>

    Division#  ===>

    Work Phone ===>

    This is all I have, now I have to control this EMPL transaction fields access. I understand, I can add SERVICE parameter in the access rule to control Read / Add / Delete / Update, but, I want control on the Option keyword, ACF2 ID keyword, Name, etc.

     

    My access rules should be

    $KEY(EMPL) TYPE(CKC) -> Transaction security

    $KEY(OPTIONI) TYPE(***) -> Option I keyword security access rule

    $KEY(OPTIOND) TYPE(***) -> Option D keyword security access rule

    ...

    $KEY(WORK PHONE) TYPE(***)

     

    This type of security may become uncontrolled / not monitored without relating it to the actual field at the backend / script. I do not know the DFHCSD dataset names or their layout / format if it applies. Given the current situation with limited information, I am required to make security rules based on this front end / field names, only known information. Is Maintaining Field records / Record level protection [& Protecting screen input] section of ACF2 Admin guide / CICS guide the best approach to accomplish my requirement.

     

    I appreciate if anyone can post sample rules or provide detailed information in this regard.

     

    Note, there will be two different security, 1) Who can access which OPTION; 2) Who is allowed to modify / access which field [ACF2 ID, NAME, Mail Drop, etc.]

     

    Running on zOS 2.1 ACF2 r15 CICS 5.1 [moving to 5.3]

     

    Thank you.



  • 2.  Re: ACF2 CICS Transaction Record / Field level security

    Broadcom Employee
    Posted 07-28-2016 12:07 PM

    Hi,

    The process that would be easiest to implement would be described

    in the ACF2/CICS manual as  

     

    Protecting Screen Input

     

     

    There are two possible components here - depending on how your transaction

    processes the screen

     

    If the transaction calls another transaction, then the screen protection will occur

     

     

    when the next transaction is validated.
    if the transaction calls another program to process the data on the screen, then

    program validation will be used to validate the screen content.

     

    The two ACF2 components that protect screens are..
    EXPRESSION and RECORD records.

    Lets use a transaction rule as an example of the setup..

     

    $KEY(EMPA) TYPE(CKC)

    $RECNAME(EMPLSCRN) USERDATA(NOCACHE)

    UID(user1) ALLOW RECCHECK(EMPLFLDS)

    UID(user2) ALLOW

     

    EMPLSCRN provides details of the input field locations

     

    recname(EMPLSCRN)

    fldname(rectype) row(1) col(12) length(1) type(char)

    fldname(name) row(2) col(13) length(20) type(char)

    fldname(addr1) row(4) col(12) length(20) type(char)

     

    EMPFLDS will contain Boolean checks for access checks.

     

    expressn(EMPFLDS)

    if RECTYPE ne 'D' and NAME EQ 'JOHN'

    If this does not provide all the answers you require, I suggest that you read the

    record level protection (RLP) section of the CICS manual and then lastly open a support case.

    https://docops.ca.com/ca-acf2-for-z-os/15-0-&-16-0/en/cics-and-ims-environments/cics-support/administration-of-the-cics-…



  • 3.  Re: ACF2 CICS Transaction Record / Field level security