Shielding the programmer from complex application processing

When developers write applications, particularly enterprise-grade applications, they have complex concerns to resolve, such as security, integrity of data, or the exchange of incompatible formats of data between applications. CICS® provides services for the processing of applications that save individual developers having to understand and code these services.

Setting up security
CICS provides a set of security capabilities to identify, authenticate, authorize all users of an application, and encrypt the data that flows between CICS and a user. Applications don’t need to implement the checks themselves because CICS supplies the functions to them. For identification, CICS uses a z/OS® facility that is called SAF to create, update, and authenticate tokens on behalf of an application. For authorization, CICS ensures that, if an application accesses resources, such as a database, the identity that is associated with the request has the authority to do so. For encryption, CICS provides mechanisms to encrypt the route in and out of an application. Data that flows between a user and CICS is encrypted with industry-standard algorithms. As security requirements change, the security implementation of the infrastructure can change, often without the need to change the program source code. Since CICS shares the SAF with other applications on IBM Z®, it also provides a single point of control for security across the platform.
Transferring execution and data between programs
CICS not only supports hosting programs in multiple languages but also provides functions to allow those programs to call each other and pass data between them. All languages have ways to invoke another program that is written in the same language. If all programs are written in the same language, transferring between them is relatively easy. If each program is written in a different language – for example, linking from Java to COBOL - it is difficult. There are options (for example, JNI or exposing each program as an application in its own right) but these add complexity in coding, monitoring or administration.

CICS solves this problem by providing an API that can be used by any program in any language to call any other program. The CICS API is tailored for each language that CICS supports so that it is familiar to an application developer, but an API call in one language has that same functional effect as the same API call in another programming language. For example, the CICS LINK API allows a programmer to tell CICS to start running another program. CICS then handles the complexity of this mixed language call on behalf of the application program.

Just calling another program isn’t enough. Different language represent data in different ways and these ways can be incompatible with each other. CICS provides a mechanism called “channels and containers” to allow programs to share data with other programs. A container is simply a piece of storage that a program can use to store data that it wants to pass to another program. A channel is a collection of these containers.

Ensuring the integrity of data (transactionality)
In CICS, the processing of each request is handled as a separate transaction. All of the updates that are made as part of that 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 application programs. However if the program wants more control over the transaction model then they can use two CICS API calls: one is called syncpoint, used to finalize the in-doubt unit of work and 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.

Transactions are not unique to CICS. Other application servers also provide transaction capability to hosted applications. For example, Java Transaction Architecture (JTA) is part of the Java EE full platform specification. Unlike other transaction architectures, CICS can maintain a transaction over the execution of programs that are written in different languages. Even as applications are extended by new programs, the transactionality of the application is still maintained.

Accessing data in databases and z/OS data sets
CICS allows applications to access databases and data sets in the same way as they would if they weren’t running in CICS. This makes it easier for the developer. CICS adds value by including databases and data sets in its handling of abnormal situations. For example, if a system failed, CICS can reverse, or back-out, changes to the database that were made by the program and no specific code changes were needed in the program to make use of that capability.
Accessing other resource managers
CICS applications can include command that are processed by resource managers outside CICS, such as Db2®, IMS, and IBM® MQ. CICS uses adapters to provide the connection between the application and the resource manager.
Handling business events
Business events that occur in CICS applications can be captured and passed to an event processing adapter for formatting and routing. Event processing can be used in many ways, for example, for detecting customer trends, or for detecting abnormalities in patterns of customer behavior that might indicate irregular or fraudulent situations.

Find out more

About CICS applications gives more detailed information about how CICS supports application programming.