In this publication, you learn why IBM CICS has been the trusted core of enterprise applications and transaction processing for over 50 years and why through years of innovation this trust is maintained. This paper provides an overview for writing, updating, and running CICS applications and the new application programming interfaces (APIs), capabilities, and functions that you can use to modernize these applications to run as part of a hybrid cloud application.

IBM CICS is a mixed language application server that runs on IBM Z. Over the 50 years since CICS was introduced in 1969, enterprises have used the qualities of service (QoSs) that CICS provides to allow them to create high throughput and secure transactional applications that have powered their business. As the IT landscape has evolved, so has CICS to allow these applications to integrate with new platforms and still provide value to the rest of the business. Because of this capability, many businesses still rely on CICS to power their core applications.

When CICS debuted, the IT landscape was primarily dominated by batch processing. Anytime a record was updated, for example, a bank account or customer details, these changes would be batched together with all the other changes and applied sequentially to the main records. CICS introduced the ability to update that record immediately without the need for a batch window to run. CICS would handle all of the transactionality of the processing without the application programmer having to worry about what would happen if the record that you wanted to update was locked. As the landscape moved to embrace online transactions, CICS introduced capabilities to support different programming styles, such as conversational and pseudo-conversational. These capabilities allowed throughput to increase, and more people could update records at the same time.

Today, the cloud has changed the IT landscape again. Being able to use services, functions, and platforms as a service allows organizations to create digital experiences for their clients. However, at the heart of these experiences is still the core applications that are hosted by CICS. Since 89% of enterprises predict needing to harness multiple public and private or on-premises clouds, we call this landscape the hybrid multi-cloud.

Migrating to the hybrid cloud requires clients to look at their existing IT assets and decide how they can migrate them to the cloud. There are three possible approaches:

The simplest approach is to maintain the status quo and keep the existing applications working. Although this approach does not incur extra cost or introduce new risk, the application might fall behind technologically. This approach might eventually incur problems as the business tries to embed these applications into new digital experiences.

The second approach is to migrate all applications to the cloud as cloud-native applications. This approach is a high-risk one because there is no guarantee that the migrated application has the same performance, security, or transactional capabilities as the application that it replaces. It is also expensive. The cost of the migration will be high, and you must maintain the existing applications until the migration completes, which incurs further cost.

The final approach is to modernize the applications that you have and allow them to integrate with cloud-native applications. This modernization can be achieved either by constructing APIs that allow new cloud-native applications to connect to your existing assets, rewriting parts of your application in newer languages and hosting them back on CICS, or by using CICS capabilities to extend your applications to provide new capabilities and functions. 

This type is the type of modernization that we focus on in this publication. This paper takes a traditional example application and shows you how it works. Then, the paper extends the example, rewrites portions of its functions, and enables its APIs. It also explains how CICS applications can use continuous integration (CI) and continuous delivery (CD) to deliver, test, and deploy code into CICS easily and with quality. 

Example 1-1 shows a small COBOL batch program that does nothing except write the phrase Hello World to the terminal.

CICS provides APIs to programs to allow them to interact with resources. Example 1-2 is the same code but uses CICS APIs to write the same string to the terminal.

In Example 1-2, we look at the identification division of our COBOL program, and here we can see that our program is called “Hello”. The procedure division is where that the interesting stuff happens.

We have two API calls here: One to write the string Hello World to the terminal that started the program, and one to let CICS know that this program completed.