What Makes CICS, a Mixed Language Application Server, So Special?
CICS® has been around since 1969 and still continues to flourish as a mixed language application server today. Primarily running on mainframes, also known as an IBM Z®, CICS does run in limited forms on other platforms, as well. As an application server, it is used to host applications that can be written in several languages, with COBOL being the most common programming language used. Modern programming languages, such as Java®, PHP and C, can also be hosted in a CICS environment. In terms of its customers, most of the Fortune 500 companies run CICS as part of their IT infrastructure. CICS customers include banks, brokerage houses, insurance companies, retail establishments and travel, just to name a few.
Why Is CICS So Popular?
CICS can process an enormous amount of work in a very short period of time. It is used for mission critical applications such as bank account transactions and credit card processing. It can process large amounts of data with security, reliability, and has many built in features to support high availability. According to IBM, there are approximately 6,900 tweets, 30,000 Facebook likes and 60,000 Google searches every second. CICS processes over 1.1 million transactions per second, which is 100 billion transactions a day (bit.ly/2DC5H4Q).
What Is CICS?
In a sentence, CICS is middleware between the operating system, in this case IBM z/OS®, and business applications. It can host and manage the user interface, although most customers today use different platforms to provide this interface and simply rely on CICS to provide the business logic. This means it can certainly handle the communication to, and from, any other platform using practically all existing transports. It also handles the retrieval and modification of data using VSAM, Db2® and various other data access methods.
In order to understand CICS, it’s important to know the difference between batch and online processing. Going back many years, the only way to process data was in a batch format, which means that requests would usually come in from a file and would be processed sequentially. Only when all processing was complete would the results be transmitted. Batch is still widely used in z/OS back office processing, such as order entry and warehouse processing, but for user interactions, online interaction is preferred. Online processing involves a user interface that interacts directly with a customer. Requests are processed immediately, and they arrive randomly. The results are transmitted once they are available, which in CICS tend to be sub-second. A good example of online processing is credit card authorizations.
As the world changed and hardware became less expensive, there was a drive to online transaction processing. CICS was developed by IBM to play an integral role in this new processing format.
Tasks: The Basic Unit of Work
To truly understand CICS, we must start with a basic unit of work, which is known as a transaction in CICS. Although we may think of a business transaction as a basic unit of work, CICS further subdivides transactions into individual tasks. For example, processing a bank withdrawal may require several tasks: logging in, viewing your balance, then withdrawing the money. When combined, these individual tasks make up the business transaction of withdrawing money. The tasks, which are the basic unit of work, can run one or many programs, depending on what is required.
The problem with physically running multiple tasks simultaneously, which would be required in a system that can support tens of thousands of users simultaneously, is the lack of central processing units (CPUs). In the early days of computing, a mainframe would be lucky if it had more than one CPU. If we need multiple people accessing the same system in real time with a limited number of processors, what can we do?
The answer IBM provided was a programming style called pseudo-conversational programming. Conversational programming is easy to understand; effectively, the machine is yours and you process all the tasks without giving up control. The problem is that decision points, in many instances, require you to go back to the customer to ask a question. If the customer goes to make a cup of coffee, the program effectively waits until they return to provide the input. This works, but it means that the processor is dedicated to the task until the task is complete. With pseudo-conversational programming, every request sent to the user will cancel that task and free up any resources the task was holding. This way, others can make use of that CPU until the user responds to the input. This is known as task switching and, if done fast enough, it gives all users rapid response times while needing fewer processors.
This all sounds great, but what does a person have to do to ensure they can restart a task where they left off? After all, if the start of a new task would run the same code repeatedly, we wouldn’t get anywhere. The answer provided is a communication area—or a section of storage—where the programmer can place state information, allowing them to restart the application where it left off. That is the pseudo-conversational programming model. With new advances to the CICS product, there are now other ways to store state data, such as the channel/container interface, but the principle remains the same.
With the pseudo-conversational programming style in place, CICS can switch between tasks belonging to different users while still giving each user the impression that they are the only one using the system. However, that still means we are single threading tasks.
Programing in CICS
Aside from developing a tool that allows for online processing, part of the problem IBM was trying to solve was to make coding on mainframes easier. With the advent of pseudo-conversational style programming, it looked like they were going in the opposite direction. However, they also provided a programming interface, which is known today as the CICS API. This makes communicating with z/OS and other subsystems easier. An example of this is reading VSAM files. In a batch COBOL program with the JCL running it, there is additional work a programmer must complete to allow reading and writing of records from files. In the world of CICS, they simply code an EXEC CICS READ command and, without any set-up, have access to the data on the file within their program. If these commands take time to process, CICS can use this as an additional task switching opportunity, allowing even more throughput and solving the single threading of tasks issue.
Now, a systems programmer will still need to configure the system to support the file using the built-in CICS transactions, however the programmer does not need to concern themselves with this detail. That’s why there are the three roles within a CICS environment: a systems programmer to maintain the system, the resources required by applications and the application programmer to code the applications that run in the system.
In addition, CICS provides built-in transactions that not only allow for the care and maintenance of the system, but also allow application programmers the ability to debug the CICS API coded within their programs. Built-in transactions are provided to test and, in some cases, execute commands without writing application programs. These built-in transactions are commonly used by system and application programmers maintaining CICS regions or writing programs for CICS.
Expanding the Footprint of CICS
With the popularity of CICS increasing in the mid-70s and early 80s, IBM ran into another issue. Back then, the size of the address space was limited to 16 megabytes, which would even not be enough to even boot up your mobile phone today. As customers placed more and more inside a single CICS region, they began running out of room for all the programs and resource definitions required by the supported applications.
IBM addressed the problem by creating communication vehicles such as multi-region operation (MRO) and inter-system communication (ISC). These allowed customers to split their regions by function and workload, allowing for larger environments through the use of multiple CICS address spaces or regions.
It was then that the concept of naming region types was born. Today, we have terminal owning regions (TORs), application owning regions (AORs) and file owning regions (FORs), just to name a few. This not only solved the sizing problem, but added the ability to provide regions for redundancy and reliability. The same application can be installed in several AORs and CICS can choose which one to route the work to, based on availability and expected performance.
Unbeknownst to the user who logs on to a single CICS region to run their workload, behind the scenes, CICS is routing work to several regions to get the job done efficiently. This removes any restrictions due to region size limits, while at the same time allows for work to be routed away from regions that are experiencing problems.
CICS Today
Today, region sizes are up to two gigabytes and, with the new 64-bit addressing mode, have even begun to use storage in the 64-bit range. This allows for a single region to support a vast number of programs and resources. Customers can start to reduce the physical number of CICS regions in their complex, making managing the environment easier.
Advances in computer technology are growing at an exponential rate. In order to keep up, IBM delivers a new release of CICS on an 18-month cycle. Each release provides new functionalities and enhancements to match the modern development experience, all while supporting applications written decades ago but still running every day.
The latest release of CICS (V5.6) was delivered June 12, 2020 and provides new support for Pivotal Spring Boot and Jakarta EE 8. They added new Maven Central libraries for CICS Java application development, as well as new plug-ins for Maven and Gradle to automate building resources in CICS, which is required by Java applications. Security and resiliency options were also enhanced as part of the new release, which not only shows that IBM continues to support CICS, but is enhancing it so that it can continue to be the mixed language application server of choice for many years to come.