Transactions in CICS

A CICS transaction consists of an item of processing that can be run by one or more application programs. Transactions can be defined by users of CICS®, and are referred to as user transactions in CICS documentation. CICS also supplies transactions to control CICS operations, and these are CICS transactions.

The term transaction is used extensively in the IT industry to describe a unit of recovery, typically a complete operation that is recoverable. It can be committed or backed out as an entirety, as a result of programmed command or system failure. In CICS, this is called a unit of work. In many cases, the scope of a CICS transaction is also a single unit of work but it doesn't have to be.

In CICS, unless a programmer chooses more granular control over units of work, all of the updates that are made as part of a transaction are kept in-doubt until CICS finishes processing the request. When the processing is complete, all the updates are finalized at the same time. This implicit way of handling transactions and units of work requires no code changes and is transparent to the applications. If the program wants more control over the transaction model, they can use two CICS API calls: one is called syncpoint, used to finalize the in-doubt unit of work and to start a new one. The second is rollback, used to signify that this unit of work can no longer complete and should be backed out.

Unlike other transaction architectures, CICS can maintain a transaction over the execution of programs that are written in different programming languages.

An analogy of a transaction

To understand a CICS transaction where the transaction is also a single unit of work, think of a vending machine that contains your favorite treat. To obtain the treat you must enter a certain amount of money, enter a code to tell the machine what treat you would like and in return, the machine takes your money and dispenses the treat. The vending machine is acting as a transaction server that processes your request to purchase a treat.

At the beginning, you and the vending machine are each in a starting state. You know the processing that you want to run (you want to buy a treat), you know the transaction (the code that is used by the machine), and you have the correct change (data) to obtain your treat. The vending machine is error free, knows its stock levels, and is ready to process a request. At the end of the transaction, both you and the machine reach your end state. You no longer have your money, but you have a treat. The machine takes your money and updates its stock levels. The transaction is the complete operation of your purchase.

Transactional integrity is an important part of CICS. In our vending machine example, what if something goes wrong? The treat fails to dispense, the product code is unknown by the machine, or some other issue arises. As a result, the transaction cannot complete as requested. In this example, ideally, the vending machine returns your money. This situation is known as backing out the transaction. Because the machine cannot progress you to the end-state, it must return both actors in the transaction to the beginning state (as if the transaction never started). Consider an application that needs to make the same update to two different files. If for some reason the second file cannot be updated, CICS can roll back the transaction and back out the update from both files.

Transactions and transaction definitions

You describe each transaction type to CICS with a TRANSACTION resource definition. This definition gives the transaction type a name (the transaction identifier, or TRANSID) and provides information to CICS about the work to be done; for example, which program to start first, and what kind of authentication is required throughout the execution of the transaction.

You run a transaction by submitting its TRANSID to CICS. CICS uses the information that is recorded in the TRANSACTION definition to establish the correct execution environment, and starts the first program.

A transaction is an item of processing that is initiated by a single request. This request can be from various sources, including a terminal, a web page, an application in another CICS system, or triggered automatically at a predefined time. For descriptions of different ways to run CICS transactions, see Internet, TCP/IP, and HTTP concepts and Overview of CICS external interfaces.

User transactions

These transactions are defined by you, rather than supplied with CICS.

You tell CICS how you want your transaction to run with a TRANSACTION resource definition. This definition gives the transaction type a name (TRANSID) and provides information to CICS about the work to be done; for example, which program to start first, and what kind of authentication is required throughout the execution of the transaction. On the TRANSACTION definition, you also link the transaction with other resources, such as programs or profiles.

You can use a CICS bundle to create, edit, and install a TRANSACTION resource definition. If you create a TRANSACTION resource in this way, you must use the CICS bundle to manage the lifecycle of that resource, and you cannot manage the resource independently. For more information, see Defining CICS bundles.

For applications that run on CICS platforms (see Cloud-enabling CICS), a TRANSACTION resource can be declared as an application entry point.

For security, define users of these transactions to specific RACF groups and give the groups access only to the transactions that apply to them. For more information, see Transaction security.

For information about defining the transaction, see TRANSACTION resources.

CICS transactions

CICS transactions have transaction identifiers that start with C and are 4 characters long; for example, CEMT. For a complete list of CICS transactions, including the transactions that do not have an operator interface, see the List of CICS transactions.

The CICS transactions are described in three categories. Each category specifies the recommended security.
Category 1
Category 1 transactions are for CICS internal use only and must not be started from a user terminal. Because these transactions are part of CICS itself, they run under the CICS region user ID. CICS does not validate that the CICS region user ID has authority to run Category 1 transactions because these transactions are supplied with CICS. This reduces security risks that can be caused due to misconfiguration because the CICS region user ID has implicit authority to run these transactions.

Some Category 1 transactions are defined by CICS during initialization rather than in the CICS system definition data set (CSD).

For a list of transactions in this category, see List of CICS Category 1 transactions.

Category 2
Category 2 transactions are similar to user transactions. They are initiated by CICS users or are associated with CICS users in different roles, such as application developer, operator, or system programmer. It is unlikely that users require access to all the transactions in this category, so you can group them in subcategories, as shown in Table 1. The sample CLIST DFH$CAT2 (in library CICSTS56.CICS.SDFHSAMP) shows one way that you might group the Category 2 transactions. To use a different setup, adapt the CLIST, or provide your own.

Define users of these transactions to specific RACF groups and give the groups access only to the subcategory of transactions that apply to them.

Table 1. Suggested subcategories for Category 2 transactions.
Subcategory Contains Notes
For all users:
ALLUSER Transactions that are used by all users. Add to the list of transactions your good morning transaction (defined on the GMTRAN system initialization parameter) and your good night transaction in this group (defined on the GNTRAN system initialization parameter).
For operators:
SYSADM Transactions that are used by system programmers who need full access to the system.  
INQUIRE Transactions that are used by operators or other users who need only to inquire on resources.  
OPERATOR Transactions that are used by operators.  
DBCTL Transactions that are used by operators of the DBCTL interface to IMS.  
CMCIUSER Transactions that are used by operators who use the CICS Explorer® and other users of the CMCI.  
For application developers:
DEVELOPER Transactions that are used by application developers on a non-production system.  
For application users:
JVMUSER Transactions that are used by users of Liberty applications. Depending on your security configuration, transactions CJSA and CJSU might require the CICS default user to have access. For more information, see Security for Java applications.

As a security best practice, turn on Liberty security and avoid using the CICS default user to run application tasks. For the z/OS® Connect Service, you can install a URIMAP resource that CICS uses to associate the work for the Service with a specific transaction ID in CICS and with an initial user ID.

CJSA is the default transaction ID for any web request that does not have a matching URI. Consider restricting access to CJSA to prevent any arbitrary application being run.

INTERCOM Transactions that are used by application users who run transactions on multiple regions. If you are using function shipping, the mirror transactions must be available to remote users in a function shipping environment. When a database or file is on another CICS region, CICS function ships the request to access the data. The request runs under one of the CICS-supplied mirror transactions. In this situation, the following conditions apply:
  • The terminal user that runs the application must be authorized to use the mirror transaction. See Transaction security.
  • The terminal user must also be authorized to use the data that the mirror transaction accesses. The mirror transactions are supplied with RESSEC(YES) defined; so, even if the user's transaction specifies RESSEC(NO), the mirror transaction fails if the user is not authorized to access the data.

    If you do not use resource security checking, change the mirror transaction definitions to specify RESSEC(NO). Because the mirror transactions are an IBM®-protected resource, first copy these definitions into your own groups and then change them.

For a deferred START request, if the user transaction to be started is eligible for dynamic routing, system transaction CDFS will run and start the user transaction at the specified time. Ensure that security for CDFS is correctly configured.

WEBUSER Transactions that are used by application users who run transactions through the CICS web interface. The CICS default user requires access to the CWBA transaction initially, even if an analyzer program is then used to assign another user ID to the task. Make sure that the CICS default user that is specified in the DFLTUSER system initialization parameter has access to this transaction. If you use the supplied CLIST DFH$CAT2 to create a WEBUSER RACF® profile, the default user must have access to this profile.
RPCUSER Transactions that are used by application users who run transactions through ONC RPC.  
PIPEUSER Transactions that are used by application users who run web services transactions.  
EVENTUSER Transactions that are used by EP adapters. If the RESSEC and CMDSEC options for these transactions are not the ones you want, you can specify your own transaction IDs in the adapter tab Advanced Options section of the Event binding editor. For more information, see Specifying EP adapter and dispatcher information.
For users of IBM MQ:
MQADMIN
  • CKAM
  • CKCN
  • CKDL
  • CKRS
  • CKSD
  • CKSQ
 
MQBRIDGE
  • CKBC
  • CKBP
  • CKBR
 
MQMONITOR
  • CKTI
 
MQSTATUS
  • CKQC
  • CKBM
  • CKRT
  • CKDP
 

For a list of transactions in this category, see List of CICS Category 2 transactions.

Category 3
Category 3 transactions are available to all users, whether signed-on or not. These transactions are not subject to security checking.

For a list of transactions in this category, see List of CICS Category 3 transactions.

For more information, see Transaction security.

Most of the CICS transactions are generated in the designated groups when you initialize your CICS system definition data set (CSD). Do not modify the CSD definitions of the Category 1 transaction. This initialization does not include the CICS sample transactions (the transactions that are in Category 2 and in groups that start with DFH$). Some Category 1 transactions are not in the CSD. They are defined by CICS during installation.