RESSEC transaction resource security parameter

Specifying RESSEC(YES) in the definition of a transaction, together with the appropriate resource classes defined in the system initialization parameters, introduces another layer of security checking in addition to the transaction-attach security described in Transaction-attach processing when SEC=YES and XTRAN=YES.

For most simple (or single-function) transactions, this extra layer of security is not necessary. For example, if the transaction is designed to enable the terminal user to update a personnel file and nothing else, it should be sufficient to authorize access to the transaction without controlling access to the file also. However, if you have a complex transaction that offers users a choice of functions, or you are unsure about all the options available within a transaction, you may want to add the extra layer of security to restrict access to the data as well as to the transaction. Before implementing resource security checking, take into account the extra overhead that resource security checking involves, and only implement it if you believe the extra cost is worthwhile.

If you specify RESSEC(YES) on a transaction definition, CICS calls RACF for each CICS command that applies to one of the following resources, for which you have requested security, using an Xname resource class parameter: Consider this example:
The system initialization parameters include:
SEC=YES
XDCT=NO
XFCT=YES
XTRAN=YES
XTST=YES
Transaction TRN1 contains the following EXEC CICS commands:
  • 4 file control READ commands
  • 1 file control WRITE command
  • 2 transient data WRITEQ commands
  • 1 temporary storage WRITEQ command
When TRN1 executes, the seven calls are made to RACF:
  • 1 at transaction attach, because XTRAN=YES is specified
  • 5 for file control access, because XFCT=YES is specified
  • 1 for temporary storage access, because XTST=YES is specified
RACF is not called for transient data access, because XDCT=NO is specified