z/OS and Friends: Rich Functionality Is What CICS Is All About—Then and Now
Joe Gulla traces the evolution of the Customer Information Control System (CICS), harkening back to its first release and providing a comprehensive accounting of its modern-day application development capabilities
This is the second article in this two-part series on the Customer Information Control System (CICS). The first part introduced the functional aspect of CICS, while this article will continue the discussion with a focus of new capability delivered in recent releases.
At the end of this article, I have a table of information about developing applications with CICS. The elements in the table cover the functional capabilities that are both old and new. Some elements in the table are smaller scale, like transforming data in and out using XML format. Others are colossal in scope, for example, designing and developing for recovery or using Business Transaction Services (BTS) to be better able to model complex business transactions. This table could be used as a catalogue of solutions to challenges both big and small.
Early CICS Experience
My early application development with CICS involved the first 1969 release. That release included functionality from pre-release versions but still left plenty of room for contributions from customers to extend the product and fill gaps in function.
The mindset of customers at the time was to contribute as needed to the product. It was not uncommon for customers to make software additions and the software engineers who stepped up were very resourceful. They were not graduates of computer science programs (only a few in the 1960s) and learned on the job. They were curious and skilled.
First Software Engineers
These developers made software from IBM “better” because it was “part of the job.” Things are different today as system programmers “administer” commercial products (versus enhance or extend or customize.) I knew and worked with a number of these early software engineers, and I was in awe of their skills and years of experience with software projects.
In those early CICS days, the users of real-time applications under CICS employed IBM 2741 Selectric (golf ball) typewriter-based terminals for input and output. We developers used CRTs, but the early users of the applications didn’t yet have them as they were costly.
A Wave of Changes
When I left the 1969 world of my first employer and entered the 1980 world of my new employer, I immediately noticed big differences. First, the CICS system I was now using had much more functionality and stability. CICS region abends were infrequent. Command-level programming with COBOL programs replaced macros-level coding. Programmers no longer had to imbed Assembler-language macros into their COBOL code. Command-level was refreshingly simple to use. Also, debugging was made simpler through a new transaction that came with CICS called the Execution Diagnostic Facility (the CEDF transaction). CEDF worked together with Command-level statements in a before-and-after sequence. My heart is speeding up just writing about it—it was that fantastic an innovation.
The Hursley ‘Lift’
The dramatic improvement in CICS resulted from the changes injected into the product by the IBM Hursley lab in the UK, starting in 1974 with a roughly 160-person team. Full CICS responsibility came to Hursley on the 1st of January 1975, when Hursley traded PL/I with the Palo Alto lab for CICS, making CICS a significant part of IBM Hursley history. When I came to understand that the UK team was providing all the magic, I wanted to meet the people and go to the place. Eventually, I presented a paper at a high-availability conference at the Hursley lab, and my dream was realized. Nearby Winchester Cathedral was in the back yard of the hotel where I stayed and the entire experience was uplifting in every way.
The Hursley team’s software inventiveness helped CICS achieve $1 billion in yearly revenue at a peak time in its history. I once worked on a different $1 billion-a-year product, and the year we hit that big number, we had our annual kickoff in Florida, where we rented out part of Disney World for employee afternoon recreation. It was 25 years ago and I remember it like it happened just the other day. Success can result in fun and powerful memories.
Centralized to Distributed Via a Network
Over time, IT providers developed distributed computing models, facilitated by Internet Protocol (IP) networks. CICS development extended the product to embrace the benefits of distributed systems and the network that connects them. What technology? The themes of CICS extensions are to improve and embrace the developer experience and to make the most of new technologies and approaches. If you made a concept chart of this change, what might it look like?
The figure above lists many technologies, but what is their context? Why would you use these new technologies? Let me try to explain a few of them.
Then: CICS in the 1970s
The CICS of the 1970s had innovative functionality that made online, real-time processing possible. The networks were BTAM and later VTAM, which provided more flexibility and recovery capability. The programming languages were COBOL (very popular) with BAL for high performance or special needs and PL/I for both scientific and business applications.
VSAM is a high performing access method, which was a great choice for many applications as you could read, write, update (syncpoint) and browse depending on the type of dataset created. VSAM is the access method above all others supplying entry-sequenced (ESDS), key-sequenced (KSDS), linear (LDS), fixed-length and variable-length relative record (RRDS) types of datasets. CICS had basic security and operating-system-like capabilities for programs to interact with one another, like link and transfer, only simpler than using OS functions to do the same.
Now: CICS Family in 2025
When distributed computing and the web started to dominate the attention of users and developers, CICS development added flexible new functionality to the product while still supporting the long-standing capabilities of traditional CICS. Why did they add new functionality? In short, developers wanted access to legacy applications and their data using new ways to access and integrate.
Some developers just wanted to use the tools and methods they used day-to-day with other systems, so the CICS team opened the door to using different editors and testing environments and techniques. What did they add? Consider both CICS and SOAP and CICS and JSON under the umbrella of Web Services.
CICS Web Services With SOAP and JSON
Programmers can expose existing CICS applications as Simple Object Access Protocol (SOAP) web services and create CICS applications to act as both SOAP web service providers and requesters. With CICS, there are two different development approaches with SOAP:
- Quick Approach – Enables rapid deployment with the least amount of programming effort
- Flexible Approach – Gain complete flexibility and control over your web service applications by using code that you write
Both approaches are supported by infrastructure of one or more pipelines and message handler programs that operate on web service requests and responses. More details can be read here.
JavaScript Object Notation (JSON) web services enable CICS programs as JSON services. These may be RESTful services or request-response remote-procedure-call style services. Both types are possible. The technology uses JCL procedures called DFHLS2JS and DFHJS2LS that are the basis to generate WSBind files. The bind files are deployed into CICS as WEBSERVICE resources, which speeds up automatic conversions between JSON and application binary data formats. More details can be read here.
APIs Became a Rich Source
CICS programs that use the CICS API can perform a variety of operations, like communicating with terminals and devices (including printers) within their communication network. You can also connect to programs on other platforms that use TCP/IP protocols. Additionally, using z/OS Connect Enterprise Edition, the developer is provided with RESTful API access to z/OS applications and data, including those hosted in CICS, IMS, IBM MQ and Db2.
New Frameworks, Editors and Build Tools
CICS Transaction Server Version 5.6 introduced enhanced support for Java to deliver what Java developers would expect from a cloud environment experience. For example, the new CICS Java API (JCICSX) allowed easier unit testing using mocking and stubbing approaches. In addition, it can be run remotely on the developer’s local workstation.
A set of CICS artifacts on Maven Central enable developers to resolve Java dependencies using popular dependency management tools such as Apache Maven and Gradle. Plug-ins for Maven (cics-bundle-maven) and Gradle (cics-bundle-gradle) are also provided to simplify automated building of CICS bundles, using familiar IDEs like Eclipse, IntelliJ IDEA, and Visual Studio Code.
In addition, Node.js z/OS support has been enhanced to providing faster startup, better default heap limits, updates to the V8 JavaScript engine, etc. Support for Jakarta EE 8 is also included.
HTTP and HTTP Client Side APIs
For CICS as an HTTP client, CICS is the web client and it communicates with an HTTP server. A user-written application program sends requests through CICS to the HTTP server and receives the responses from it. CICS maintains a persistent connection with the server using a session token on the commands issued by the application program to identify the connection. This is the first way it can be used.
CICS can also act as an HTTP client and communicate with an HTTP server on the internet. A user-written application program sends requests through CICS to the HTTP server and receives the responses from it. A user-written application program can work in two ways:
1. Interact with hardware or software using the HTTP protocol. For example, printers can often be controlled in this way.
2. Interface with HTTP applications that provide useful information, for example, the share price of stocks. The user-written program would retrieve this information for use in the application.
More details on this capability can be found here.
Developing Applications
The table below contains important and comprehensive information on developing applications in CICS. It is a wonderfully detailed compendium of what is possible with CICS application development in COBOL, Java, Node.js, C, C++, PL/I, Assembler and REXX languages.
CICS provides application programming interfaces so that applications written in the supported languages can access CICS services and data in other components and products, such as VSAM and Db2. That is just the start.
Below is a compendium of what is possible. I created a “tag line” so you could get the main idea before exploring the details of each supported activity. If that capability doesn’t interest you, skip it and move on to the next one. The table has 28 use cases.
Table 1. Developing Applications With CICS
| Tag Line | What are you doing? | Why are you doing it? |
| Employ Business Services using an SOA approach | Creating business services from CICS applications | For organizations that want business services that utilize an SOA approach. That means to align with business processes and not necessarily be just technology-driven. You have the flexibility to create channel-based or XML-based services. Additional details from IBM are here. |
| Simplify to benefit from Language Environment | Using Language Environment for CICS programs | Language Environment allows you to use only one runtime environment regardless of the programming language or system resource needs. Additional details from IBM are here. |
| Handle older compilers with newer CICS approaches | Utilizing translation and compilation | Since some older compilers (and assemblers) cannot process CICS commands directly, an additional step is needed to convert program into executable code, opening up the use of more productive CICS facilities. If you use the integrated CICS translator approach, many of the translation tasks are done at compile time and you do not need to complete the additional translation step. Additional details from IBM are here. |
| Effectively customize the translation of lower-case and mixed-case character input from a terminal | Employing upper-case translation | Customize the translation of lower-case and mixed-case characters and national characters that are input at a terminal. In addition, you can translate operator messages produced by temporary storage data sharing. Additional details from IBM are here. |
| Considerations when planning for recovery | Developing for recovery | When you are planning aspects of recovery, you must consider your applications, system definitions, internal documentation and test plans. Developing for recoverability is made easier by addressing 10 topics in the topic information from IBM. |
| Use asynchronous API commands as building blocks for special application functionality | Developing for asynchronous requests | Develop CICS applications using the asynchronous API commands to start one or more child tasks and fetch responses from them. Consider a credit card application where you start a credit check as a way to employ the functionality to good use. More details on this programming tactic from IBM are here. |
| Infuse AI by using existing products from within CICS | Infusing AI into applications | Applications that run in CICS Transaction Server can make timelier and better decisions by making use of AI within transactions by leveraging IBM Watson Machine Learning on z/OS (WMLz) and IBM Operational Decision Manager (ODM) with WMLz. Another approach is using a community-available AI framework such as IBM Snap Machine Learning (Snap ML), TensorFlow, or PyTorch. The general approach from IBM is here. |
| Use Business Transaction Services (BTS) to be better able to model complex business transactions | Developing with the BTS API | BTS has everything necessary to support the needs of business transactions including API commands to work on processes and activities, data-containers, events and objects. More details from IBM are here. |
| Use the Front End Programming Interface (FEPI) applications to simulate terminals | Developing with the FEPI API | Application developers can use CICS API commands to develop FEPI applications. This information describes how to develop FEPI applications, including the interfaces that are available and how to handle conversations and errors. |
| Effectively code, translate, and compile COBOL programs | Developing COBOL applications | Use this information to help you code, translate and compile COBOL programs that you want to use as CICS application programs. |
| Exploit the power of the C and C++ programming languages | Developing C and C++ applications | Use this information to help you code, translate and compile C and C++ programs that you want to use as CICS application programs. |
| PL/I is part of the language family that also includes Assembler, COBOL, C/C++, Java, Node.js and REXX | Developing PL/I applications | Use this information to help you code, translate, and compile PL/I programs that you want to use as CICS application programs. |
| Make use of assembler language when program performance is paramount | Developing Assembler language applications | Assembler language programs offer high performance characteristics. A set of sample application programs is provided to show how EXEC CICS commands can be used in a program written in Assembler language. |
| Write applications in Java to tap into language-specific capabilities and toolsets | Developing Java applications | Using the IBM CICS SDK for Java or other Java IDEs, you can develop applications that use the CICS Java APIs (JCICS and JCICSX) to access CICS resources and interact with programs that are written in other languages. Additionally, you can declare Java dependencies in a Gradle project or a Maven module and develop the Java applications in the same way as you do for other platforms. More details are provided here. |
| Use Java Script to its best advantage to build CICS applications | Developing Node.js applications | Node.js applications are written using JavaScript and involve asynchronous programming concepts that might be unfamiliar to COBOL and Java programmers. Experienced Node.js developers find that developing applications for CICS is a similar process to developing Node.js applications for other platforms. More details are provided here. |
| Use CICS Explorer to create CICS bundles to contain the application resources | Setting up an application | The potentially large set of resources that makes up a business application within CICS can be logically defined as a single entity and deployed on a platform as a single resource. More details are available here. |
| Leverage existing REXX skills to create CICS application programs | Developing REXX applications | REXX is a powerful and flexible language. A REXX program consists of REXX language instructions that the REXX interpreter interprets directly. A program can also contain commands that the host environment executes, such as CICS commands. More details are available here. |
| Make use of CICS support for distributed workloads | Developing distributed applications | You can develop an application that runs across multiple CICS regions and accesses resources in multiple regions. CICS provides a number of useful facilities including function shipping, distributed transaction processing and transaction routing. More details are included here. |
| Expanded application functionality through external interfaces | Developing for external interfaces | CICS supports applications that communicate with and utilize external data and resources, such as Db2, IBM MQ, IMS DBCTL, data tables and ONC RPC applications. More details are included here. |
| Exploit data tables for online application use | Developing for access to shared data tables | The CICS shared data table facility is an extension of CICS file management services. Using shared data tables, all files that are defined as data tables can potentially be shared using cross-memory services, which will result in high performance from in-memory data access. More details on this topic can be found here. |
| Utilize database resources effectively | Developing for access to data sources | CICS supports access to external data in Db2 and DL/I databases. There are many design and development considerations due to the significance of database processing in applications. It is hard to imagine a more important topic to application success. More details are available here. |
| Use flexible two-way communication between a non-CICS and a CICS program to build innovative applications | Developing applications to use the CICS-MQ bridge | Send and receive IBM MQ messages over the CICS-MQ bridge. The data required by the CICS application is included in request messages. The CICS-MQ bridge uses reply messages to return the data provided, making non-CICS-to-CICS program interaction useful. More on this can be found here. |
| Leverage MQ through its flexible adapter | Developing applications to use the CICS-MQ adapter | The CICS-MQ adapter implements the IBM MQ Message Queue Interface (MQI) for use by CICS application programs. The adapter also supports a CICS-MQ API-crossing exit, which can be used to intercept MQI calls as they are being run for a variety of purposes. This is explained further here. |
| Client/server apps using CICS API | Developing web applications | Programmers can develop an application that uses the CICS API to interact with clients or a server over HTTP. The external CICS interface (EXCI) is used to link to an application using the CICS business logic interface. More on this can be found here. |
| Use SOAP and JSON with CICS | Developing Web Services | CICS supports two distinct web service protocols, the SOAP and the JavaScript Object Notation (JSON) protocols. The focus is expose existing CICS applications through providing innovative access. More details can be found here. |
| Transform data, as needed, with JSON support | Developing with JSON | Programmers can write application programs to transform application binary data into JavaScript Object Notation (JSON) and vice versa. CICS provides a JSON assistant to map how the data is transformed during runtime processing. More details from IBM can be found here. |
| Effective use of XML | Developing with XML | Programmers can write application programs to transform application binary data into or out of XML format. CICS-supported high-level languages provide an XML assistant to map how the data is transformed during runtime processing. More details on this from IBM are here. |
| Improve application security | Developing Security Assertion Markup Language (SAML) applications | CICS supports SAML, which is an XML-based framework for describing and exchanging security information between multiple service partners. You can develop CICS applications to process SAML tokens. More information on SAML can be found here. |
If you want flexibility and choice, CICS has it, and the support is robust. I hope that you, like me, found this table with more than a few welcome surprises.
What Is Next?
The next product focus in “z/OS and Friends” is on Information Management System (IMS). Like this CICS series, IMS will be discussed in two related articles.