CICS
| Company type | Software suite |
|---|---|
| Industry | Information technology, Middleware |
| Founded | 1966 |
| Founder | Ben Riggins |
| Headquarters | Hursley , United Kingdom |
Area served | Worldwide |
| Products | CICS Transaction Server, CICS Transaction Gateway, TXSeries |
| Owner | IBM |
| Website | www |
IBM CICS (Customer Information Control System) represents a suite of mixed-language application servers designed to deliver online transaction management and connectivity for applications operating on IBM mainframe platforms running z/OS and z/VSE.
Operating as middleware, CICS products facilitate swift, large-scale online transaction processing. A single CICS transaction constitutes a processing unit initiated by one request, which can impact multiple components. While processing is predominantly interactive, it may also execute asynchronously in the background.
At the forefront of this suite is CICS Transaction Server (CICS TS), which provides services that either augment or substitute certain operating system capabilities. These offerings enhance operational efficiency and streamline application development, particularly in managing communication with a variety of terminal devices.
Developers can create CICS applications using multiple programming languages, leveraging CICS-specific extensions to interact with resources such as files, database connections, terminals, or web services. Transaction management within CICS ensures data integrity by enabling rollback of all changes if any part of the transaction encounters failure.
CICS TS enjoys widespread adoption among leading financial organizations—including banks and insurance companies—as well as numerous Fortune 500 firms and government entities. It also serves smaller businesses and is frequently implemented in bank teller systems, ATM networks, industrial control environments, insurance platforms, and other interactive solutions.
Recent enhancements to CICS TS have concentrated on improving the developer environment by expanding available APIs, frameworks, editors, and build tools, alongside bolstering security, fault tolerance, and system administration. Earlier versions introduced capabilities such as support for Web services, Java, event processing, Atom feeds, and RESTful APIs.
History
CICS originated as an evolution of IBM's prior single-threaded transaction processing system, IBM MTCS, with an 'MTCS-CICS bridge' allowing legacy transactions to operate under CICS without modification. Created collaboratively with Michigan Bell in 1966, IBM’s Customer Information Control System was initially developed to address the requirements of the public utility sector. The concept for this online system was conceived by IBM systems engineer Ben Riggins.
The initial development took place at IBM’s Des Plaines facility in Illinois. The first iteration was introduced in 1968 under the name Public Utility Customer Information Control System (PU-CICS). Recognizing its potential beyond utilities, IBM removed the "Public Utility" designation when launching the first official CICS Program Product on July 8, 1969—shortly after unveiling the IMS database management system.
Although originally created in Palo Alto and regarded as secondary to IMS, persistent customer demand ensured CICS’s continuation. When IBM considered discontinuing it in 1974 to concentrate on IMS development, responsibility shifted to the IBM Hursley site in the United Kingdom due to its expertise with overlapping clientele. Hursley remains a principal development center today, supported by teams located in India, China, Russia, Australia, and the United States.
Early development
Initially, CICS supported a limited range of IBM hardware, including the 1965 IBM 2741 terminal and subsequently the IBM 2260 and IBM 3270 video display terminals.
During the early era of mainframe computing, software like CICS was provided at no additional cost with hardware purchases. Large enterprises such as Standard Oil of Indiana (Amoco) played a role in enhancing the system. Efforts to accommodate non-IBM terminals, such as the ASCII-based Teletype Model 33 ASR, encountered financial limitations and early technical challenges; notably, Amoco reengineered critical components and contributed these improvements back to IBM for broader implementation.
By the early 1970s, CICS had become a major contributor to IBM’s revenue, driving over $60 billion in new hardware sales and establishing itself as IBM’s top-performing mainframe software product.
In 1972, IBM released three distinct versions of CICS designed for varying memory sizes and operating systems: DOS-ENTRY for low-memory DOS/360 machines; DOS-STANDARD for higher-memory DOS/360 systems; and OS-STANDARD V2 targeting larger OS/360 environments.
In 1970, principal developers including Riggins relocated to Palo Alto to continue advancing the product. Although early IBM executives were skeptical about generating revenue from software—a stance reversed only after federal unbundling regulations—CICS’s design proved highly effective for real-time transaction processing on expensive hardware. However, IBM missed strategic opportunities such as integrating CICS with its personal computer initiatives during the 1980s.
Given the limited processing power of that period, each CICS installation required assembling system modules via CICSGEN, a customizable process that allowed exclusion of unnecessary features or device support. This modular design contributed significantly to CICS’s performance and flexibility.
CICS’s initial success derived from its efficient multi-threaded design, straightforward development of terminal-based real-time applications, and substantial enhancements driven by customer input.
Z notation
During the 1980s and 1990s, portions of CICS were formally specified using Z notation through collaboration with the Oxford University Computing Laboratory, led by Tony Hoare. This work was recognized with a Queen's Award for Technological Achievement.
CICS as a distributed file server
In 1986, IBM extended CICS capabilities by introducing support for record-oriented file services through the Distributed Data Management Architecture (DDM). This allowed remote network programs to access files that had previously been restricted to CICS/MVS and CICS/VSE systems.
Subsequent versions of CICS have phased out DDM support. For CICS z/OS, DDM was discontinued by the end of 2003 and completely removed starting with version 5.2. In CICS TS for z/VSE, DDM support stabilized at version 1.1.1 before plans for eventual withdrawal. From version 2.1 onward, CICS/DDM is no longer supported on z/VSE platforms.
CICS and the World Wide Web
The introduction of a native HTTP interface in CICS Transaction Server version 1.2 was complemented by Web Bridge technology, which enabled terminal-based applications to be presented within an HTML framework. Enhancements to CICS Web and Document APIs in version 1.3 improved browser interactions.
Between versions 2.1 and 2.3, CORBA and EJB technologies were integrated, allowing CICS resources to participate in distributed application component models through hosted Java applications. The Java environment saw significant advancements: a multi-threaded JVM resource (JVMSERVER) debuted in version 4.1 and was upgraded to a 64-bit JVM in version 5.1. Additionally, version 5.1 introduced the WebSphere Liberty profile web container, which became fully embedded by version 5.3. This Java-based hosting environment replaced earlier native CORBA and EJB implementations.
Version 3.1 brought native SOAP and WSDL support along with client-side HTTP APIs facilitating outbound communication, enabling integration with enterprise systems. Tools were developed to transform traditional CICS programs (such as COBOL) into WSDL-defined web services with minimal modifications—a feature further refined in later releases.
Versions 4.1 and 4.2 enhanced web connectivity capabilities further by adding native support for the Atom publishing protocol.
Many newer web technologies were introduced outside standard product releases to collect early user feedback—for instance, Soap for CICS preview in TS 2.2 and ATOM SupportPac in TS 3.1. This approach also delivered JSON support initially in TS 4.2 before its incorporation into TS 5.2.
JSON functionality within CICS parallels earlier SOAP capabilities by providing modern interfaces over hosted programs. It was further developed within IBM’s z/OS Connect Enterprise Edition, which constructs JSON APIs utilizing multiple mainframe subsystems.
Complementary partner solutions enhance CICS integration options—for example, the CICS Transaction Gateway supports JCA-compliant Java servers, while IBM DataPower appliances provide web traffic filtering.
Contemporary versions of CICS offer broad integration features: bidirectional access to remote systems; propagation of user identities and transactional contexts; creation of RESTful APIs; adherence to standards-based interactions among devices, users, and servers; and exploitation of the embedded IBM WebSphere Liberty environment to accelerate adoption of emerging technologies.
MicroCICS
In January 1985, a consulting company established in 1969, recognized for its extensive online systems developed for clients such as Hilton Hotels, FTD Florists, Amtrak, and Budget Rent-a-Car, launched MicroCICS. This product was initially targeted at the IBM XT/370 and IBM AT/370 hardware platforms.
CICS Family
The term CICS Family refers to a suite of transaction servers, connectors (known as CICS Transaction Gateway), and various tools. The flagship offering is the CICS Transaction Server; however, the family also includes solutions designed for distributed environments under IBM TXSeries. TXSeries is a distributed transaction processing middleware that supports applications written in C, C++, COBOL, Java™, and PL/I, operating across both cloud infrastructures and traditional data centers. It runs on multiple operating systems including AIX, Linux x86, Windows, Solaris, and HP-UX. Additionally, CICS is available on platforms such as IBM i and OS/2, with the z/OS variant (CICS Transaction Server for z/OS) being the most widely utilized.
IBM previously offered two now-obsolete CICS versions for VM/CMS. In 1986, IBM introduced CICS/CMS, a single-user development edition whose applications were subsequently ported to production environments on MVS or DOS/VS. Later, in 1988, IBM rolled out CICS/VM, tailored for the IBM 9370 departmental mainframe. This version was intended to run on branch or departmental mainframes alongside central mainframes operating CICS for MVS.
CICS Tools
The suite known as CICS Tools facilitates provisioning, administration, and analysis of both CICS systems and their applications. These tools encompass capabilities such as performance monitoring and resource allocation. In 2015, alongside the release of CICS Transaction Server for z/OS version 5.3, IBM updated four essential foundational tools along with the CICS Optimization Solution Pack for z/OS. The primary tools include: CICS Interdependency Analyzer for z/OS, CICS Deployment Assistant for z/OS, CICS Performance Analyzer for z/OS, and CICS Configuration Manager for z/OS.
Releases and versions
The following table outlines the release history of CICS Transaction Server for z/OS:
CICS Transaction Server for z/OS versions continue as follows: CICS Transaction Server for z/OS 5.2 Announced: 2014-04-07 Released: 2014-06-13 End of Service: 2020-12-31 CICS Transaction Server for z/OS 5.3 Announced: 2015-10-05 Released: 2015-12-11 End of Service: 2021-12-31 CICS Transaction Server for z/OS 5.4 Announced: 2017-05-16 Released: 2017-06-16 End of Service: 2023-12-31 CICS Transaction Server for z/OS 5.5 Announced: 2018-10-02 Released: 2018-12-14 End of Service: 2025-09-30 CICS Transaction Server for z/OS 5.6 Announced: 2020-04-07 Released: 2020–06–12 Introduced support for Spring Boot, Jakarta EE 8, Node.js 12, a new JCICSX API enabling remote development, along with enhancements in security and management. CICS Transaction Server for z/OS 6.1 Announced: 2022–04–05 Released: 2022–06–17 Added compatibility with Java 11, Jakarta EE 9.1, Eclipse MicroProfile 5, Node.js 12; incorporated TLS 1.3 support plus security improvements and region tagging features. CICS Transaction Server for z/OS 6.2 Announced: 2024–04–09 Released: 2024–06–14| Version | Announcement Date | Release Date | End of Service Date | Features |
|---|---|---|---|---|
| CICS Transaction Server for OS/390 1.1 | 1996-09-10 | 1996-11-08 | 2001-12-31 | |
| CICS Transaction Server for OS/390 1.2 | 1997-09-09 | 1997-10-24 | 2002-12-31 | |
| CICS Transaction Server for OS/390 1.3 | 1998-09-08 | 1999-03-26 | 2006-04-30 | |
| CICS Transaction Server for z/OS 2.1 | 2001-03-13 | 2001-03-30 | 2002-06-30 | |
| CICS Transaction Server for z/OS 2.2 | 2001-12-04 | 2002-01-25 | 2008-04-30 | |
| CICS Transaction Server for z/OS 2.3 | 2003-10-28 | 2003-12-19 | 2009-09-30 | |
| CICS Transaction Server for z/OS 3.1 | 2004-11-30 | 2005-03-25 | 2015-12-31 | |
| CICS Transaction Server for z/OS 3.2 | 2007-03-27 | 2007-06-29 | 2015-12-31 | |
| CICS Transaction Server for z/OS 4.1 | 2009-04-28 | 2009-06-26 | 2017-09-30 | |
| CICS Transaction Server for z/OS 4.2 | 2011-04-05 | 2011-06-24 | 2018-09-30 | |
| CICS Transaction Server for z/OS 5.1 | 2012-10-03 | 2012-12-14 | 2019-07-01 |
Programming considerations
To accommodate multiple simultaneous transaction threads, CICS application programs needed to be quasi-reentrant. A single programming mistake in one application had the potential to disrupt service for all users. The modular architecture of CICS control programs allowed numerous users and applications to operate efficiently on systems equipped with only 32K of expensive magnetic core memory, including the operating system itself.
Developers working with CICS placed a strong emphasis on transaction performance, often restricting program size to 4,096 bytes (4K) to enable memory reuse for inactive programs or other storage demands. When OS/360 introduced virtual memory in 1972, this 4K limit became essential to minimize paging and reduce resource contention overhead.
Although CICS supported languages like COBOL and PL/I, many applications were still written in assembler due to performance priorities. Given the high cost and limited availability of hardware during the 1960s and 1970s, system optimization specialists competed to shrink code size and reduce CPU usage by collaboratively refining critical code sections. Smaller development groups lacked this collaborative advantage, which slowed their optimization efforts.
Since programs were shared across concurrent threads, the use of static variables or operating system memory was generally discouraged. Nonetheless, these guidelines were frequently disregarded—particularly by COBOL programmers unfamiliar with internal system restrictions—resulting in non-reentrant code that caused storage violations and system failures.
In the early stages, all CICS components operated under a single memory protection key within an MVS region, making corruption of programs and control blocks a common cause of downtime. Mistakes within one application could overwrite memory areas used by others, complicating troubleshooting for operating system analysts.
These challenges continued through numerous CICS versions despite strong demand for experienced professionals. They were gradually mitigated in TS V3.3, V4.1, and V5.2 with the introduction of Storage Protection, Transaction Isolation, and Subspace features that utilize OS hardware capabilities to isolate application code and data within the same address space—even for legacy applications not originally designed with separation in mind. Presently, CICS transactions remain critical components for utilities, leading banks, and other multibillion-dollar financial enterprises.
Furthermore, application security can be strengthened through testing under monitoring tools that offer debugging and test functionalities.
Macro-level programming
At its inception, CICS supported application transaction programs exclusively written in IBM 360 Assembler. Support for COBOL and PL/I was incorporated later. Early service requests in CICS were executed through assembler-language macros, such as:
DFHFC TYPE=READ,DATASET=myfile,TYPOPER=UPDATE,....
This method is referred to as "Macro-level CICS."
With the introduction of high-level language support, macros persisted but were expanded by a pre-compiler into COBOL or PL/I CALL statements. Consequently, developing a HLL application involved a two-step process: macro expansion followed by compilation.
COBOL considerations: Since IBM COBOL does not natively support pointer manipulation, CICS utilized the COBOL Linkage Section to access control blocks and dynamically allocated storage. The compiler produces Base Locators for Linkage (BLLs), which are dynamically set by CICS or applications to reference corresponding structures within the Linkage Section.
Command-level programming
During the 1980s, IBM Hursley launched "Command-level CICS," which preserved compatibility with existing Macro-level programs while introducing a fresh API style. A standard Command-level invocation appears as follows:
<syntaxhighlight lang="cobolfree">
EXEC CICS
SEND MAPSET('LOSMATT') MAP('LOSATT')
END-EXEC
</syntaxhighlight>
The values specified in SEND MAPSET correspond to identifiers established in the DFHMSD and DFHMSI macros. This code undergoes preprocessing to transform embedded EXEC commands into calls directed at stub subroutines, thereby maintaining a two-phase preparation mechanism. Applications employing a "mixed mode" approach, combining both Macro-level and Command-level statements, were also supported.
At first, during execution, Command-level commands were converted by the EXEC Interface Program into Macro-level calls handled by the existing CICS nucleus. However, following the rewrite of the CICS Kernel for TS Version 3, EXEC CICS became the sole programming interface due to modifications in the underlying system interfaces.
Run-time conversion
The Command-level-only iteration of CICS introduced in the early 1990s brought improvements over prior versions but eliminated support for Macro-level application programs. Consequently, numerous legacy applications required conversion or redevelopment to utilize Command-level EXEC commands. Considering the vast number of programs in operation, rewriting posed risks of introducing defects without delivering new capabilities. As a result, many users continued operating CICS V2 application-owning regions (AORs) to maintain macro code functionality well after the release of Version 3.
Tools such as APT International's Command CICS facilitated running legacy Macro-level programs without necessitating complete rewrites.
New programming styles
Recent advancements in CICS Transaction Server prioritize modern development paradigms and enhancing developer productivity.
Version 5.6 of CICS Transaction Server introduced expanded Java support tailored for cloud-native environments. The updated CICS Java API (JCICSX) enables unit testing with mocking and stubbing capabilities and allows remote execution from local workstations. CICS components are distributed via Maven Central, supporting dependency management through Apache Maven and Gradle, with plug-ins that streamline automated builds within IDEs such as Eclipse, IntelliJ IDEA, and Visual Studio Code. Enhancements to Node.js on z/OS for version 12 include faster startup times, increased heap limits, and an updated V8 engine. Additionally, support for Jakarta EE 8 is incorporated.
With CICS TS 5.5, IBM introduced SDK support for Node.js, offering a comprehensive JavaScript runtime alongside server-side APIs designed to develop scalable network applications on IBM Z platforms.
Earlier releases introduced Java capabilities: Version 2.1 incorporated Java support, while Version 2.2 added compatibility with the Software Developers Toolkit. Since CICS shares its runtime container with IBM WebSphere, Java EE applications benefit from portability and consistent development tools.
CICS emphasizes encapsulating legacy applications with contemporary interfaces like WSDL, SOAP, and JSON to facilitate their integration into web or mobile platforms without extensive backend modifications.
Transactions
A CICS transaction comprises a series of operations executed collectively to accomplish a specific task, often involving straightforward activities such as querying inventory or recording account debits and credits. A fundamental characteristic is that transactions exhibit atomic behavior. On IBM Z platforms, CICS can handle thousands of transactions each second, serving as a cornerstone for enterprise-level computing.
CICS transactions are implemented using multiple programming languages, including COBOL, PL/I, C, C++, IBM Basic Assembly Language, Rexx, and Java.
Every program is triggered by a unique transaction identifier. The user interfaces in CICS are presented as maps, which are developed using Basic Mapping Support (BMS) assembler macros or third-party utilities. These maps may feature highlighted or colored text depending on the terminal’s capabilities. For instance, a COBOL application obtains input data through a map provided by CICS:
<syntaxhighlight lang="cobolfree">
EXEC CICS
RECEIVE MAPSET('LOSMATT') MAP('LOSATT') INTO(OUR-MAP)
END-EXEC.
</syntaxhighlight>
Certain command parameters require arguments enclosed in quotes while others do not, prompting many developers to consult documentation or use coding templates for accuracy.
Example of BMS Map Code
Basic Mapping Support employs assembler macros to define screen layouts. These macros produce both the physical map set—a load module stored within a CICS library—and the symbolic map set—a structure definition or DSECT utilized in source code written in languages like PL/I or COBOL.
<syntaxhighlight lang="cobolfree">
LOSMATT DFHMSD TYPE=MAP, X
MODE=INOUT, X
TIOAPFX=YES, X
TERM=3270-2, X
LANG=COBOL, X
MAPATTS=(COLOR,HILIGHT), X
DSATTS=(COLOR,HILIGHT), X
STORAGE=AUTO, X
CTRL=(FREEKB,FRSET)
*
LOSATT DFHMDI SIZE=(24,80), X
LINE=1, X
COLUMN=1
*
LSSTDII DFHMDF POS=(1,01), X
LENGTH=04, X
COLOR=BLUE, X
INITIAL='MQCM', X
ATTRB=PROT
*
DFHMDF POS=(24,01), X
LENGTH=79, X
COLOR=BLUE X
ATTRB=ASKIP, X
INITIAL='PF7- 8- 9- 10- X
11- 12-CANCEL'
*
DFHMSD TYPE=FINAL
END
</syntaxhighlight>
Structure
Within the z/OS framework, a CICS setup comprises one or more "regions" (commonly referred to as "CICS Regions") distributed across multiple z/OS system images. Each region generally operates as a batch job or started task, running continuously until it is deliberately stopped. When restarting, the process may be a "Cold" start (without recovery) or a "Warm"/"Emergency" start (utilizing logs after an unexpected termination). Cold restarts for large regions can be lengthy due to the need to reprocess all definitions.
To separate applications and functions, and to surpass workload limits of a single region or mainframe instance within a z/OS SysPlex, installations employ multiple address spaces.
A standard configuration involves several applications forming a service, with numerous "Terminal-Owning Regions" (TORs) directing transactions to various "Application-Owning Regions" (AORs). Alternative arrangements also exist, such as designating a specific "File-Owning Region" (FOR) to manage file input/output operations for AORs, addressing constraints like VSAM’s restriction of write access to one address space at a time.
While certain CICS applications depend on VSAM or other single-address-space data stores, many utilize IMS/DB or Db2 databases along with MQ queue managers. TORs distribute transaction loads evenly among AORs that directly interact with these shared resources. CICS supports XA two-phase commit protocols across different data stores, facilitating ACID-compliant transactions that span MQ, VSAM/RLS, and Db2 environments.
Furthermore, CICS accommodates distributed transactions through the SNA LU6.2 protocol between address spaces either within the same cluster or across different clusters. This capability enables ACID-consistent updates across multiple data repositories by collaborating applications. However, potential communication failures can result in uncertain transaction states, which has limited widespread adoption of this functionality.
Sysplex exploitation
During the early 1990s and with the release of CICS ESA V3.2, IBM confronted the challenge of adapting CICS to take full advantage of the newly introduced z/OS Sysplex mainframe architecture.
The transition from ECL hardware to CMOS technology marked a significant shift; CMOS was more economical thanks to mass production driven by consumer electronics like the Sony PlayStation. ECL required intricate cooling due to its high power consumption, whereas CMOS systems were air-cooled but initially slower—a concern since major mainframe clients heavily depended on CICS workloads.
To achieve comparable transaction throughput on Sysplex systems, workloads needed to run concurrently across multiple machines. However, CICS’s quasi-reentrant design restricted parallel processing to roughly 1.5 processors per address space despite employing MVS sub-tasks. Without improved parallelism, customers might migrate to competitors. IBM debated whether to abandon upward compatibility in favor of a fully reentrant model akin to IMS/DC or extend existing designs through multi-region operation (MRO).
After engaging with the CICS user community—which opposed breaking compatibility due to Y2K risks and the expense of rewriting vast amounts of code—IBM opted for the latter approach.
IBM’s advised Sysplex architecture involved deploying at least one Terminal Owning Region per node that routed transactions to multiple Application Owning Regions (AORs) throughout the Sysplex. Access to shared resources was managed via Sysplex-aware data stores like IBM Db2 or IMS/DB, or centralized Resource Owning Regions (RORs) such as File Owning Regions (FORs) for VSAM and CICS Data Tables; Queue Owning Regions (QORs) for MQ, CICS Transient Data (TD), and Temporary Storage (TS). While preserving legacy compatibility, this approach introduced greater operational complexity.
Subsequent versions allowed CICS to exploit Sysplex-aware features in VSAM/RLS and MQ for z/OS and integrated its own Data Tables, TD, and TS into the Coupling Facility (CF), thereby eliminating most RORs. The CF offers shared resource coordination with hardware-assisted messaging for efficient and dependable cross-node sharing.
By this point, CMOS-based processors had surpassed ECL in power density by incorporating more CPUs per chip. Coupled nodes enabled workload scaling by orders of magnitude; for instance, by 2002 Charles Schwab operated a "MetroPlex" consisting of dual redundant Sysplexes each containing 32 nodes supporting a shared CICS/DB2 workload that managed extensive web traffic before the dot-com bubble burst.
This cost-efficient and scalable CMOS platform, combined with IBM’s enhancements in 64-bit addressing and CF capabilities, contributed to mainframe clone manufacturers like Amdahl and Hitachi exiting the market.
CICS Recovery and Restart
The objective of CICS recovery and restart processes is to reduce or completely prevent damage to the Online System during failures, thereby safeguarding system and data integrity. When a CICS region is properly shut down, it initiates a "Warm" start by utilizing the checkpoint saved at shutdown. Conversely, a "Cold" start involves reloading all definitions and clearing the log, leaving resources in their existing condition.
Resources that CICS can recover include:
- VSAM files
- CMT data tables maintained by CICS
- Intrapartition Temporary Data Queues (TDQ)
- Temporary Storage Queues stored in auxiliary memory
- I/O messages within VTAM networks
- Database and queuing resources supporting XA two-phase commit protocols (such as IMS/DB, Db2, VSAM/RLS)
CICS offers a comprehensive suite of recovery and restart features tailored for customized system restoration, including:
- Dynamic Transaction Backout (DTB)
- Automatic Restart of Transactions
- Resource Recovery through System Log or Journal
- Complete System Restart
- Extended Recovery Facility
System Components
Within each CICS region, transactions execute on a primary task, while certain services (for example, IBM Db2 access) utilize additional tasks known as Task Control Blocks (TCBs). Transactions operate under cooperative multitasking principles, expected to relinquish CPU control promptly; this process is managed automatically by CICS services.
Each distinct CICS task or transaction is allocated dynamic memory upon initiation, with subsequent memory requests handled by the Storage Control program embedded within the CICS nucleus (kernel), functioning similarly to an operating system.
A complete CICS system encompasses the online nucleus, batch support utilities, and application service components.
Nucleus
The initial CICS nucleus consisted of multiple functional modules implemented in 370 assembler language up to Version 3:
- Task Control Program (KCP)
- Storage Control Program (SCP)
- Program Control Program (PCP)
- Program Interrupt Control Program (PIP)
- Interval Control Program (ICP)
- Dump Control Program (DCP)
- Terminal Control Program (TCP)
- File Control Program (FCP)
- Transient Data Control Program (TDP)
- Temporary Storage Control Program (TSP)
Starting from Version 3, the nucleus was reorganized into a kernel-and-domain framework using IBM's PL/AS language, which compiles into assembler code.
The earlier architecture lacked clear modular separation, resulting in tight interdependencies among programs and potential defects without extensive code examination. The redesigned modular structure enhanced stability and simplified maintenance. Initial domains preserved the original program names but omitted the trailing "P" suffix (for instance, Program Control Domain DFHPC and Transient Data Domain DFHTD). The kernel served as a dispatcher for requests between domains; although initially this introduced overhead for frequent operations like Trace, PL/AS macros allowed in-lining these calls while maintaining modularity.
Subsequent releases incorporated newly designed domains such as the Logging Domain DFHLG and Transaction Domain DFHTM, which replaced the former Journal Control Program (JCP).
Support Utilities
In addition to online capabilities, CICS provides several batch-oriented support programs:
- High-level language macro preprocessor
- Command language translator
- Dump utility for formatting outputs from CICS Dump Management
- Trace utility for formatting and printing trace data from CICS
- Journal formatting utility to produce formatted reports of errors within CICS regions
Application Services
CICS facilitates application development through the following components:
- Basic Mapping Support (BMS) – provides terminal input/output that is independent of the device
- APPC Support – offers LU6.1 and LU6.2 API capabilities for distributed applications with two-phase commit functionality
- Data Interchange Program (DIP) – enables compatibility with IBM 3770 and 3790 programmable devices
- 2260 Compatibility – allows software designed for IBM 2260 displays to operate on 3270 terminals
- EXEC Interface Program – a stub that translates
EXEC CICScommands into CICS function calls - Built-in Functions – includes features such as table lookup, phonetic conversion, field validation/editing, bit testing, input formatting, and weighted retrieval
Pronunciation
The way CICS is pronounced differs across regions:
- Inside IBM, especially within Tivoli, it is articulated as .
- In the United States, the letters are enunciated individually as .
- Countries including Australia, Belgium, Canada, Hong Kong, and the United Kingdom pronounce it as .
- In Denmark, Greece, India, Iran, Russia, Slovenia, Sweden, and Uganda, it is said as kicks.
- Finland uses ; France pronounces it ; Germany, Austria, and Hungary say or occasionally .
- Italy uses ; Poland pronounces it ; Portugal and Brazil say ; Spain uses .
- In Turkey, it is spoken as kiks.
See also
- IBM TXSeries (CICS on distributed systems)
- IBM WebSphere
- IBM 2741
- IBM 2260
- IBM 3270
- OS/360 and successors
- Source Program Maintenance Online II (an early online editor running under CICS)
- Transaction Processing Facility
- Virtual Storage Access Method (VSAM)