MAINFRAME > Tips & Techniques > Systems Management

Going Commando in CICS

Among all the IBM products available for z/OS, CICS implements one of the most comprehensive and detailed security exploitations of RACF.

Note: This is the second article in a three-part series on CICS* and RACF* security. The first installment appeared in the November/December 2007 issue.


In the previous article on CICS/RACF security I covered the details of securing CICS transactions using RACF profiles. The concepts of RACF grouping and member classes were introduced, and CICS profile prefixing was briefly mentioned. This article covers securing CICS commands.

CICS command security controls the sub-commands of the transactions CEMT and CECI, respectively the CICS Master Terminal the CICS Command Interpreter. The commands implemented by these transactions may also be issued by application program transactions using the EXEC CICS interface and are subject to RACF checking when called this way. Usually these commands are used by systems programming or development personnel to control the configuration of the CICS system or applications. As such, these commands can be powerful and are considered sensitive enough to warrant an additional level of security above basic transaction security. It's essential to use transaction security to protect the CEMT transaction.

Just like transaction security, command security is implemented in RACF by grouping and member classes. By default these are the VCICSCMD (grouping) and CCICSCMD (member) classes.

Chapter 2.6.2 of the CICS Transaction Server for z/OS* V3.2 RACF Security Guide contains a comprehensive list of the resource names that CICS uses when calling RACF. You can define profiles in the appropriate RACF classes to control access to the equivalent related CICS commands. In a typical production CICS environment, systems programmers are given access to all CICS commands and a limited subset of staff - perhaps trusted developers - is granted the necessary RACF authorities to display, but not change, data manipulated by the CEMT transaction. In development environments these controls may be more relaxed, allowing developers to implement changes such as defining or changing files, DB2* connections or programs using CEMT.

Setting Up the CICS Region to Use Command Security

Before command security can be used the CICS region must be configured to use it. This is done via the CICS System Initialization Table (SIT). The SIT may be pre-compiled into CICS or specified as in-stream configuration statements in the CICS region job-control language (JCL) or a combination of both. This is controlled by the systems programmers who set up the CICS region, so it's usually necessary to have some working knowledge of how your CICS regions are built and configured to ensure that command security is functioning.

The main SIT parameter used to establish command security is XCMD. This takes a value of either YES, NO or a RACF class name. In the case of XMCD=YES, RACF checking is activated and the default classes of VCICSCMD and CCICSCMD is used. When an alternate class to the default is desired the XCMD parameter is set to the name of the RACF-defined member class you want to use where the first character of the class name isn't specified, only a suffix is used. The first character of a CICS command security member class is always "C." Likewise the first character of the grouping class is always "V." Thus, if you want to use a custom class pair of CCICSPRD/VCICSPRD, then the XCMD SIT parameter would be specified as XCMD=CICSPRD. This feature's most common use is to segregate the production regions RACF classes from those used to control non-production regions. This is similar to specifying custom classes for transaction security using the SEC and SECPRFX SIT parameters.

It's also possible to define command security on a transaction-by-transaction basis using the transaction definition parameter CMDSEC. This parameter takes values of YES or NO and is specified on the transaction definition rather than in the SIT. An override SIT parameter called CMDSEC also exists - it takes the value ALWAYS and forces the behavior of CMDSEC=YES for all transaction definitions regardless of the specific transaction CMDSEC settings.

As described in the previous article, profile prefixing can also be applied to command security. If this is used, then the resource names passed to RACF are prefixed with the CICS region user ID and RACF profiles must likewise be prefixed in order to match the resources.


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