When there are no SURROGAT resources defined to CA Top Secret, even in FAIL mode, it is possible for CICS transactions to run with any acid.
The security trace shows RC=04, but SAF requires a return code of x'00' and not a x'04' to CICS, because CICS only understands x'00' or x'08' as SAF code.
x'00' for allowed access
x'08' for failed access
This is why access is allowed. To prevent this from happening, there are two options are available, see the Instructions: section below.
in order to prevent any SURROGAT access from undefined SURROGAT resources, choose one of the following options:
1) Define the following SURROGAT resource to CA Top Secret and permit it to the *ALL* record as shown below:
TSS ADD(dept) SURROGAT(*.DFHSTART)
TSS PER(ALL) SURROGAT(*.DFHSTART) ACTION(FAIL)
2) Add the DEFPROT attribute to the SURROGAT class in the RDT via:
TSS REP(RDT) RESCLASS(SURROGAT) ATTR(DEFPROT)
Refer to the CA Top Secret User Guide for details on how to administer the RDT record.
Use the following to verify what your SURROGAT class in the RDT looks like using the command below:
TSS LIS(RDT) RESCLASS(SURROGAT)
The output should read:
RESOURCE CLASS = SURROGAT
RESOURCE CODE = X'08B' POSIT = 104
ATTRIBUTE = MASKABLE,MAXOWN(26),MAXPERMIT(044),ACCESS,DEFPROT
ACCESS = NONE(0000),CONTROL(0400),UPDATE(6000),READ(4000)
ACCESS = WRITE(2000),ALL(FFFF)
DEFACC = NONE
Adding the DEFPROT attribute to any resource class makes it to work like the DATASET resource class. In other words, all resources within that class are protected by default in FAIL mode, even if they are not defined to CA Top Secret. ACIDs must be explicitly permitted to have access to them. Sites need to be very careful about setting DEFPROT on a resource class because there may be undefined resources in that class that users are currently allowed access to because the resources are not defined. These accesses will fail after adding DEFPROT unless they are permitted.