MAINFRAME > Tips & Techniques > Systems Management

CICS Security With RACF

There’s much flexibility, and hence potential complexity, in the security definitions available to control CICS multiregion security.

There’s much flexibility, and hence potential complexity, in the security definitions available to control CICS multiregion security.

Note: This is the third article in a three-part series. The first article appeared in the November/December issue of IBM Systems magazine, IBM Z (

This is the final installment of the series on CICS* and RACF* security. Here I’ll briefly outline many CICS security features and options that you may encounter in more complex CICS environments. For brevity I won’t delve into any great detail for all these options; this is meant rather as an introduction to what’s available. I recommend the excellent CICS documentation should you require further detail on any of the following features.

CICS-Provided RACF Security Classes

So far I’ve covered securing CICS transactions (the GCICSTRN/TCICSTRN class pair) and CICS commands (the VCICSCMD/CCICSCMD class pair). For many installations just protecting transactions and commands will be sufficient security; however, for organizations requiring the highest level of granularity and segregation in their security environment some or all of the following RACF classes may be useful:

  • DCICSDCT or ECICSDCT—Transient data destinations (queues)
  • FCICSFCT or HCICSFCT—Files managed by CICS file control
  • ACICSPCT and BCICSPCT—Started transactions and those checked using the XPCT class
  • MCICSPPT or NCICSPPT—Invoke or change the load status of other programs
  • SCICSTST or UCICSTST—Temporary storage queues
  • RCICSRES or WCICSRES—CICS document templates
  • PCICSPSB or QCICSPSB—DL/I program specification blocks used in IMS*

Custom CICS Classes

All CICS-related RACF classes may be replaced or extended by defining to RACF alternative grouping class pairs. Often this is done to segregate security definitions for production versus non-production systems. For example, where CICS provides the GCICSTRN/TCICSTRN pair of classes, these are often added to with naming conventions such as GCICSPRD/TCICSPRD and GCICSTST/TCICSTST for prod and test CICS regions, respectively.

These classes are added to RACF by modifying the RACF class descriptor table (ICHRRCDE) either using the older style ICHERCDE macro or the newer dynamic CDT class. Although the most commonly added classes are for transactions, it isn’t uncommon to see custom classes added for all CICS security resources to allow for future expansion and reserve the name space (e.g., G@PRDTRN/T@PRDTRN, F@PRDFCT/H@PRDFCT and J@PRDJCT/K@PRDJCT).

Remember that the first character of any CICS-related resource grouping class pair is fixed or predetermined. When adding custom classes the end user can only choose the last seven characters of the class name for any particular type of resource security. This suffix is then specified in the CICS System Initialization Table (SIT) with CICS itself supplying the first character determined by the resource type being secured.

For example, to use File Control security the XFCT parameter is required in the CICS SIT. XFCT set to ‘YES” (i.e., XFCT=YES) uses the default class pair FCICSFCT/HCICSFCT, whereas XFCT=@TSTFCT uses a class pair with the names F@TSTFCT/H@TSTFCT. Most CICS SIT parameters for resource security behave similarly.

Michael Cairns works for IBM as a technical specialist in the Tivoli zSecure range of software. Michael can be reached at

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Optimal Service Delivery

Overcome eight key challenges and reduce costs


An Accurate Benchmark Is Important

Advice for the Lazy Administrator

Steps you can take to avoid late nights and system frights.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters