ACF2

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.

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-…

The full URL is

https://docops.ca.com/ca-acf2-for-z-os/15-0-&-16-0/en/cics-and-ims-environments/cics-support/administration-of-the-cics-interface/implementing-record-level-protection-rlp