CICS

CICS was preceded by an earlier, single-threaded transaction processing system, IBM MTCS. An 'MTCS-CICS bridge' was later developed to allow these transactions to execute under CICS with no change to the original application programs. IBM's Customer Information Control System (CICS) was first developed in conjunction with Michigan Bell in 1966.^[3] Ben Riggins was an IBM systems engineer at Virginia Electric Power Co. when he came up with the idea for the online system.^[4]

CICS was originally developed in the United States out of the IBM Development Center in Des Plaines, Illinois, beginning in 1966 to address requirements from the public utility industry. The first CICS product was announced in 1968, named Public Utility Customer Information Control System, or PU-CICS. It became clear immediately that it had applicability to many other industries, so the Public Utility prefix was dropped with the introduction of the first release of the CICS Program Product on July 8, 1969, not long after IMS database management system.

For the next few years, CICS was developed in Palo Alto and was considered a less important "smaller" product than IMS which IBM then considered more strategic. Customer pressure kept it alive, however. When IBM decided to end development of CICS in 1974 to concentrate on IMS, the CICS development responsibility was picked up by the IBM Hursley site in the United Kingdom, which had just ceased work on the PL/I compiler and so knew many of the same customers as CICS. The core of the development work continues in Hursley today alongside contributions from labs in India, China, Russia, Australia, and the United States.

CICS originally only supported a few IBM-brand devices like the 1965 IBM 2741 Selectric (golf ball) typewriter-based terminal. The 1964 IBM 2260 and 1972 IBM 3270 video display terminals were widely used later.

In the early days of IBM mainframes, computer software was free – bundled at no extra charge with computer hardware. The OS/360 operating system and application support software like CICS were "open" to IBM customers long before the open-source software initiative. Corporations like Standard Oil of Indiana (Amoco) made major contributions to CICS.

The IBM Des Plaines team tried to add support for popular non-IBM terminals like the ASCII Teletype Model 33 ASR, but the small low-budget software development team could not afford the $100-per-month hardware to test it. IBM executives incorrectly felt that the future would be like the past, with batch processing using traditional punch cards.

IBM reluctantly provided only minimal funding when public utility companies, banks and credit-card companies demanded a cost-effective interactive system (similar to the 1965 IBM Airline Control Program used by the American Airlines Sabre computer reservation system) for high-speed data access-and-update to customer information for their telephone operators (without waiting for overnight batch processing punch card systems).

When CICS was delivered to Amoco with Teletype Model 33 ASR support, it caused the entire OS/360 operating system to crash (including non-CICS application programs). The majority of the CICS Terminal Control Program (TCP – the heart of CICS) and part of OS/360 had to be laboriously redesigned and rewritten by Amoco Production Company in Tulsa Oklahoma. It was then given back to IBM for free distribution to others.

In a few years,^[when?] CICS generated over $60 billion in new hardware revenue for IBM, and became their most-successful mainframe software product.

In 1972, CICS was available in three versions – DOS-ENTRY (program number 5736-XX6) for DOS/360 machines with very limited memory, DOS-STANDARD (program number 5736-XX7), for DOS/360 machines with more memory, and OS-STANDARD V2 (program number 5734-XX7) for the larger machines which ran OS/360.^[5]

In early 1970, a number of the original developers, including Ben Riggins (the principal architect of the early releases) relocated to California and continued CICS development at IBM's Palo Alto Development Center. IBM executives did not recognize value in software as a revenue-generating product until after federal law required software unbundling. In 1980, IBM executives failed to heed Ben Riggins' strong suggestions that IBM should provide their own EBCDIC-based operating system and integrated-circuit microprocessor chip for use in the IBM Personal Computer as a CICS intelligent terminal (instead of the incompatible Intel chip and relatively immature MS-DOS).

Because of the limited capacity of even large processors of that era every CICS installation was required to assemble the source code for all of the CICS system modules after completing a process similar to system generation (sysgen), called CICSGEN, to establish values for conditional assembly-language statements. This process allowed each customer to exclude support from CICS itself for any feature they did not intend to use, such as device support for terminal types not in use.

CICS owes its early popularity to its relatively efficient implementation when hardware was very expensive, its multi-threaded processing architecture, its relative simplicity for developing terminal-based real-time transaction applications, and many open-source customer contributions, including both debugging and feature enhancement.

Part of CICS was formalized using the Z notation in the 1980s and 1990s in collaboration with the Oxford University Computing Laboratory, under the leadership of Tony Hoare. This work won a Queen's Award for Technological Achievement.^[6]

In 1986, IBM announced CICS support for the record-oriented file services defined by Distributed Data Management Architecture (DDM). This enabled programs on remote, network-connected computers to create, manage, and access files that had previously been available only within the CICS/MVS and CICS/VSE transaction processing environments.^[7]

In newer versions of CICS, support for DDM has been removed. Support for the DDM component of CICS z/OS was discontinued at the end of 2003, and was removed from CICS for z/OS in version 5.2 onward.^[8] In CICS TS for z/VSE, support for DDM was stabilised at V1.1.1 level, with an announced intention to discontinue it in a future release.^[9] In CICS for z/VSE 2.1 onward, CICS/DDM is not supported.^[10]

CICS Transaction Server first introduced a native HTTP interface in version 1.2, together with a Web Bridge technology for wrapping green-screen terminal-based programs with an HTML facade. CICS Web and Document APIs were enhanced in CICS TS V1.3 to enable web-aware applications to be written to interact more effectively with web browsers.

CICS TS versions 2.1 through 2.3 focused on introducing CORBA and EJB technologies to CICS, offering new ways to integrate CICS assets into distributed application component models. These technologies relied on hosting Java applications in CICS. The Java hosting environment saw numerous improvements over many releases. A multi-threaded JVM resource called the JVMSERVER was introduced during the CICS TS version 4.1 release, this was further enhanced to use 64-bit JVM technology in version 5.1. Version 5.1 also saw the introduction of the WebSphere Liberty profile web-container. Ultimately WebSphere Liberty was fully embedded into CICS Transaction Server in version 5.3. Numerous web facing technologies could be hosted in CICS using Java, this ultimately resulted in the removal of the native CORBA and EJB technologies.

CICS TS V3.1 added a native implementation of the SOAP and WSDL technologies for CICS, together with client side HTTP APIs for outbound communication. These twin technologies enabled easier integration of CICS components with other Enterprise applications, and saw widespread adoption. Tools were included for taking traditional CICS programs written in languages such as COBOL, and converting them into WSDL defined Web Services, with little or no program changes. This technology saw regular enhancements over successive releases of CICS.

CICS TS V4.1 and V4.2 saw further enhancements to web connectivity, including a native implementation of the Atom publishing protocol.

Many of the newer web facing technologies were made available for earlier releases of CICS using delivery models other than a traditional product release. This allowed early adopters to provide constructive feedback that could influence the final design of the integrated technology. Examples include the Soap for CICS technology preview SupportPac for TS V2.2, or the ATOM SupportPac for TS V3.1. This approach was used to introduce JSON support for CICS TS V4.2, a technology that went on to be integrated into CICS TS V5.2.

The JSON technology in CICS is similar to earlier SOAP technology, both of which allowed programs hosted in CICS to be wrapped with a modern facade. The JSON technology was in turn enhanced in z/OS Connect Enterprise Edition, an IBM product for composing JSON APIs that can leverage assets from several mainframe subsystems.

Many partner products have also been used to interact with CICS. Popular examples include using the CICS Transaction Gateway for connecting to CICS from JCA compliant Java application servers, and IBM DataPower appliances for filtering web traffic before it reaches CICS.

Modern versions of CICS provide many ways for both existing and new software assets to be integrated into distributed application flows. CICS assets can be accessed from remote systems, and can access remote systems; user identity and transactional context can be propagated; RESTful APIs can be composed and managed; devices, users and servers can interact with CICS using standards-based technologies; and the IBM WebSphere Liberty environment in CICS promotes the rapid adoption of new technologies.

By January, 1985 a 1969-founded consulting company, having done "massive on-line systems" for Hilton Hotels, FTD Florists, Amtrak, and Budget Rent-a-Car, announced what became MicroCICS.^[11] The initial focus was the IBM XT/370 and IBM AT/370.^[12]

Although when CICS is mentioned, people usually mean CICS Transaction Server, the CICS Family refers to a portfolio of transaction servers, connectors (called CICS Transaction Gateway) and CICS Tools.

CICS on distributed platforms—not mainframes—is called IBM TXSeries. TXSeries is distributed transaction processing middleware. It supports C, C++, COBOL, Java™ and PL/I applications in cloud environments and traditional data centers. TXSeries is available on AIX, Linux x86, Windows, Solaris, and HP-UX platforms.^[13] CICS is also available on other operating systems, notably IBM i and OS/2. The z/OS implementation (i.e., CICS Transaction Server for z/OS) is by far the most popular and significant.

Two versions of CICS were previously available for VM/CMS, but both have since been discontinued. In 1986, IBM released CICS/CMS,^[14][11] which was a single-user version of CICS designed for development use, the applications later being transferred to an MVS or DOS/VS system for production execution.^[15][16] Later, in 1988, IBM released CICS/VM.^[17][18] CICS/VM was intended for use on the IBM 9370, a low-end mainframe targeted at departmental use; IBM positioned CICS/VM running on departmental or branch office mainframes for use in conjunction with a central mainframe running CICS for MVS.^[19]

Provisioning, management and analysis of CICS systems and applications is provided by CICS Tools. This includes performance management as well as deployment and management of CICS resources. In 2015, the four core foundational CICS tools (and the CICS Optimization Solution Pack for z/OS) were updated with the release of CICS Transaction Server for z/OS 5.3. The four core CICS Tools: 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.

CICS Transaction Server for z/OS has used the following release numbers:

Multiple-user interactive-transaction application programs were required to be quasi-reentrant in order to support multiple concurrent transaction threads. A software coding error in one application could block all users from the system. The modular design of CICS reentrant / reusable control programs meant that, with judicious "pruning," multiple users with multiple applications could be executed on a computer with just 32K of expensive magnetic core physical memory (including the operating system).

Considerable effort was required by CICS application programmers to make their transactions as efficient as possible. A common technique was to limit the size of individual programs to no more than 4,096 bytes, or 4K, so that CICS could easily reuse the memory occupied by any program not currently in use for another program or other application storage needs. When virtual memory was added to versions OS/360 in 1972, the 4K strategy became even more important to reduce paging and thrashing unproductive resource-contention overhead.

The efficiency of compiled high-level COBOL and PL/I language programs left much to be desired. Many CICS application programs continued to be written in assembler language, even after COBOL and PL/I support became available.

With 1960s-and-1970s hardware resources expensive and scarce, a competitive "game" developed among system optimization analysts. When critical path code was identified, a code snippet was passed around from one analyst to another. Each person had to either (a) reduce the number of bytes of code required, or (b) reduce the number of CPU cycles required. Younger analysts learned from what more-experienced mentors did. Eventually, when no one could do (a) or (b), the code was considered optimized, and they moved on to other snippets. Small shops with only one analyst learned CICS optimization very slowly (or not at all).

Because application programs could be shared by many concurrent threads, the use of static variables embedded within a program (or use of operating system memory) was restricted (by convention only).

Unfortunately, many of the "rules" were frequently broken, especially by COBOL programmers who might not understand the internals of their programs or fail to use the necessary restrictive compile time options. This resulted in "non-re-entrant" code that was often unreliable, leading to spurious storage violations and entire CICS system crashes.

Originally, the entire partition, or Multiple Virtual Storage (MVS) region, operated with the same memory protection key including the CICS kernel code. Program corruption and CICS control block corruption was a frequent cause of system downtime. A software error in one application program could overwrite the memory (code or data) of one or all currently running application transactions. Locating the offending application code for complex transient timing errors could be a very-difficult operating-system analyst problem.

These shortcomings persisted for multiple new releases of CICS over a period of more than 20 years, in spite of their severity and the fact that top-quality CICS skills were in high demand and short supply. They were addressed in TS V3.3, V4.1 and V5.2 with the Storage Protection, Transaction Isolation and Subspace features respectively, which utilize operating system hardware features to protect the application code and the data within the same address space even though the applications were not written to be separated. CICS application transactions remain mission-critical for many public utility companies, large banks and other multibillion-dollar financial institutions.

When CICS was first released, it only supported application transaction programs written in IBM 360 Assembler. COBOL and PL/I support were added years later. Because of the initial assembler orientation, requests for CICS services were made using assembler-language macros. For example, the request to read a record from a file were made by a macro call to the "File Control Program" of CICS might look like this:

DFHFC TYPE=READ,DATASET=myfile,TYPOPER=UPDATE,....etc.

This gave rise to the later terminology "Macro-level CICS."

When high-level language support was added, the macros were retained and the code was converted by a pre-compiler that expanded the macros to their COBOL or PL/I CALL statement equivalents. Thus preparing a HLL application was effectively a "two-stage" compile – output from the preprocessor fed into the HLL compiler as input.

COBOL considerations: unlike PL/I, IBM COBOL does not normally provide for the manipulation of pointers (addresses). In order to allow COBOL programmers to access CICS control blocks and dynamic storage the designers resorted to what was essentially a hack. The COBOL Linkage Section was normally used for inter-program communication, such as parameter passing. The compiler generates a list of addresses, each called a Base Locator for Linkage (BLL) which were set on entry to the called program. The first BLL corresponds to the first item in the Linkage Section and so on. CICS allows the programmer to access and manipulate these by passing the address of the list as the first argument to the program. The BLLs can then be dynamically set, either by CICS or by the application to allow access to the corresponding structure in the Linkage Section.^[36]

During the 1980s, IBM at Hursley Park produced a version of CICS that supported what became known as "Command-level CICS" which still supported the older programs but introduced a new API style to application programs.

A typical Command-level call might look like the following:

 EXEC CICS
     SEND MAPSET('LOSMATT') MAP('LOSATT')
 END-EXEC

The values given in the SEND MAPSET command correspond to the names used on the first DFHMSD macro in the map definition given below for the MAPSET argument, and the DFHMSI macro for the MAP argument. This is pre-processed by a pre-compile batch translation stage, which converts the embedded commands (EXECs) into call statements to a stub subroutine. So, preparing application programs for later execution still required two stages. It was possible to write "Mixed mode" applications using both Macro-level and Command-level statements.

Initially, at execution time, the command-level commands were converted using a run-time translator, "The EXEC Interface Program", to the old Macro-level call, which was then executed by the mostly unchanged CICS nucleus programs. But when the CICS Kernel was re-written for TS V3, EXEC CICS became the only way to program CICS applications, as many of the underlying interfaces had changed.

The Command-level-only CICS introduced in the early 1990s offered some advantages over earlier versions of CICS. However, IBM also dropped support for Macro-level application programs written for earlier versions. This meant that many application programs had to be converted or completely rewritten to use Command-level EXEC commands only.

By this time, there were perhaps millions of programs worldwide that had been in production for decades in many cases. Rewriting them often introduced new bugs without necessarily adding new features. There were a significant number of users who ran CICS V2 application-owning regions (AORs) to continue to run macro code for many years after the change to V3.

It was also possible to execute old Macro-level programs using conversion software such as APT International's Command CICS.^[37]

Recent CICS Transaction Server enhancements include support for a number of modern programming styles.

CICS Transaction Server Version 5.6^[38] introduced enhanced support for Java to deliver a cloud-native experience for Java developers. For example, the new CICS Java API (JCICSX) allows easier unit testing using mocking and stubbing approaches, and 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 is enhanced for version 12, providing faster startup, better default heap limits, updates to the V8 JavaScript engine, etc. Support for Jakarta EE 8 is also included.

CICS TS 5.5 introduced support for IBM SDK for Node.js, providing a full JavaScript runtime, server-side APIs, and libraries to efficiently build high-performance, highly scalable network applications for IBM Z.

CICS Transaction Server Version 2.1 introduced support for Java. CICS Transaction Server Version 2.2 supported the Software Developers Toolkit. CICS provides the same run-time container as IBM's WebSphere product family so Java EE applications are portable between CICS and Websphere and there is common tooling for the development and deployment of Java EE applications.

In addition, CICS placed an emphasis on "wrapping" existing application programs inside modern interfaces so that long-established business functions can be incorporated into more modern services. These include WSDL, SOAP and JSON interfaces that wrap legacy code so that a web or mobile application can obtain and update the core business objects without requiring a major rewrite of the back-end functions.

A CICS transaction is a set of operations that perform a task together. Usually, the majority of transactions are relatively simple tasks such as requesting an inventory list or entering a debit or credit to an account. A primary characteristic of a transaction is that it should be atomic. On IBM Z servers, CICS easily supports thousands of transactions per second, making it a mainstay of enterprise computing.

CICS applications comprise transactions, which can be written in numerous programming languages, including COBOL, PL/I, C, C++, IBM Basic Assembly Language, Rexx, and Java.

Each CICS program is initiated using a transaction identifier. CICS screens are usually sent as a construct called a map, a module created with Basic Mapping Support (BMS) assembler macros or third-party tools. CICS screens may contain text that is highlighted, has different colors, and/or blinks depending on the terminal type used. An example of how a map can be sent through COBOL is given below. The end user inputs data, which is made accessible to the program by receiving a map from CICS.

 EXEC CICS
     RECEIVE MAPSET('LOSMATT') MAP('LOSATT') INTO(OUR-MAP)
 END-EXEC.

For technical reasons, the arguments to some command parameters must be quoted and some must not be quoted, depending on what is being referenced. Most programmers will code out of a reference book until they get the "hang" or concept of which arguments are quoted, or they'll typically use a "canned template" where they have example code that they just copy and paste, then edit to change the values.

Basic Mapping Support defines the screen format through assembler macros such as the following. This was assembled to generate both the physical map set – a load module in a CICS load library – and a symbolic map set – a structure definition or DSECT in PL/I, COBOL, assembler, etc. which was copied into the source program.^[39]

 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

In the z/OS environment, a CICS installation comprises one or more "regions" (generally referred to as a "CICS Region"),^[40] spread across one or more z/OS system images. Although it processes interactive transactions, each CICS region is usually started as a batch processing|batch address space with standard JCL statements: it's a job that runs indefinitely until shutdown. Alternatively, each CICS region may be started as a started task. Whether a batch job or a started task, CICS regions may run for days, weeks, or even months before shutting down for maintenance (MVS or CICS). Upon restart a parameter determines if the start should be "Cold" (no recovery) or "Warm"/"Emergency" (using a warm shutdown or restarting from the log after a crash). Cold starts of large CICS regions with many resources can take a long time as all the definitions are re-processed.

Installations are divided into multiple address spaces for a wide variety of reasons, such as:

• application separation,
• function separation,
• avoiding the workload capacity limitations of a single region, or address space, or mainframe instance in the case of a z/OS SysPlex.

A typical installation consists of a number of distinct applications that make up a service. Each service usually has a number of "Terminal-Owning Region" (TORs) that route transactions to multiple "Application-Owning Regions" (AORs), though other topologies are possible. For example, the AORs might not perform File I/O. Instead there would be a "File-Owning Region" (FOR) that performed the File I/O on behalf of transactions in the AOR – given that, at the time, a VSAM file could only support recoverable write access from one address space at a time.

But not all CICS applications use VSAM as the primary data source (or historically other single-address-space-at-a-time datastores such as CA Datacom) − many use either IMS/DB or Db2 as the database, and/or MQ as a queue manager. For all these cases, TORs can load-balance transactions to sets of AORs which then directly use the shared databases/queues. CICS supports XA two-phase commit between data stores and so transactions that spanned MQ, VSAM/RLS and Db2, for example, are possible with ACID properties.

CICS supports distributed transactions using SNA LU6.2 protocol between the address spaces which can be running on the same or different clusters. This allows ACID updates of multiple datastores by cooperating distributed applications. In practice there are issues with this if a system or communications failure occurs because the transaction disposition (backout or commit) may be in-doubt if one of the communicating nodes has not recovered. Thus the use of these facilities has never been very widespread.

At the time of CICS ESA V3.2, in the early 1990s, IBM faced the challenge of how to get CICS to exploit the new z/OS Sysplex mainframe line.

The Sysplex was to be based on CMOS (Complementary Metal Oxide Silicon) rather than the existing ECL (Emitter Coupled Logic) hardware. The cost of scaling the mainframe-unique ECL was much higher than CMOS which was being developed by a keiretsu with high-volume use cases such as Sony PlayStation to reduce the unit cost of each generation's CPUs. The ECL was also expensive for users to run because the gate drain current produced so much heat that the CPU had to packaged into a special module called a Thermal Conduction Module (TCM^[41]) that had inert gas pistons and needed plumbed with high-volume chilled water to be cooled. However, the air-cooled CMOS technology's CPU speed initially was much slower than the ECL (notably the boxes available from the mainframe-clone makers Amdahl and Hitachi). This was especially concerning to IBM in the CICS context as almost all the largest mainframe customers were running CICS and for many of them it was the primary mainframe workload.

To achieve the same total transaction throughput on a Sysplex, multiple boxes would need to be used in parallel for each workload. However, a CICS address space, due to its quasi-reentrant application programming model, could not exploit more than about 1.5 processors on one box at the time – even with use of MVS sub-tasks. Without enhanced parallelism, customers would tend to move to IBM's competitors rather than use Sysplex as they scaled up the CICS workloads. There was considerable debate inside IBM as to whether the right approach would be to break upward compatibility for applications and move to a model like IMS/DC which was fully reentrant, or to extend the approach customers had adopted to more fully exploit a single mainframe's power – using multi-region operation (MRO).

Eventually the second path was adopted after the CICS user community was consulted. The community vehemently opposed breaking upward compatibility given that they had the prospect of Y2K to contend with at that time and did not see the value in re-writing and testing millions of lines of mainly COBOL, PL/I, or assembler code.

The IBM-recommended structure for CICS on Sysplex was that at least one CICS Terminal Owning Region was placed on each Sysplex node which dispatched transactions to many Application Owning Regions (AORs) spread across the entire Sysplex. If these applications needed to access shared resources they either used a Sysplex-exploiting datastore (such as IBM Db2 or IMS/DB) or concentrated, by function-shipping, the resource requests into singular-per-resource Resource Owing Regions (RORs) including File Owning Regions (FORs) for VSAM and CICS Data Tables, Queue Owning Regions (QORs) for MQ, CICS Transient Data (TD) and CICS Temporary Storage (TS). This preserved compatibility for legacy applications at the expense of operational complexity to configure and manage many CICS regions.

In subsequent releases and versions, CICS was able to exploit new Sysplex-exploiting facilities in VSAM/RLS,^[42] MQ for zOS^[43] and placed its own Data Tables, TD, and TS resources into the architected shared resource manager for the Sysplex: the Coupling Facility or CF, dispensing with the need for most RORs. The CF provides a mapped view of resources including a shared timebase, buffer pools, locks and counters with hardware messaging assists that made sharing resources across the Sysplex both more efficient than polling and reliable (utilizing a semi-synchronized backup CF for use in case of failure).

By this time, the CMOS line had individual boxes that exceeded the power available by the fastest ECL box with more processors per CPU. When these were coupled together, 32 or more nodes would be able to scale two orders of magnitude greater in total power for a single workload. For example, by 2002, Charles Schwab was running a "MetroPlex" consisting of a redundant pair of mainframe Sysplexes in two locations in Phoenix, AZ, each with 32 nodes driven by one shared CICS/DB/2 workload to support the vast volume of pre-dotcom-bubble web client inquiry requests.

This cheaper, much more scalable CMOS technology base, and the huge investment costs of having to both get to 64-bit addressing and independently produce cloned CF functionality drove the IBM-mainframe clone makers out of the business one by one.^[44][45]

The objective of recovery/restart in CICS is to minimize and if possible eliminate damage done to Online System when a failure occurs, so that system and data integrity is maintained.^[46] If the CICS region was shut down instead of failing it will perform a "Warm" start exploiting the checkpoint written at shutdown. The CICS region can also be forced to "Cold" start which reloads all definitions and wipes out the log, leaving the resources in whatever state they are in.

Under CICS, following are some of the resources which are considered recoverable. If one wishes these resources to be recoverable then special options must be specified in relevant CICS definitions:

• VSAM files
• CMT CICS-maintained data tables
• Intrapartition TDQ
• Temporary Storage Queue in auxiliary storage
• I/O messages from/to transactions in a VTAM network
• Other database/queuing resources connected to CICS that support XA two-phase commit protocol (like IMS/DB, Db2, VSAM/RLS)

CICS also offers extensive recovery/restart facilities for users to establish their own recovery/restart capability in their CICS system. Commonly used recovery/restart facilities include:

• Dynamic Transaction Backout (DTB)
• Automatic Transaction Restart
• Resource Recovery using System Log
• Resource Recovery using Journal
• System Restart
• Extended Recovery Facility

Each CICS region comprises one major task on which every transaction runs, although certain services such as access to IBM Db2 data use other tasks (TCBs). Within a region, transactions are cooperatively multitasked – they are expected to be well-behaved and yield the CPU rather than wait. CICS services handle this automatically.

Each unique CICS "Task" or transaction is allocated its own dynamic memory at start-up and subsequent requests for additional memory were handled by a call to the "Storage Control program" (part of the CICS nucleus or "kernel"), which is analogous to an operating system.

A CICS system consists of the online nucleus, batch support programs, and applications services.^[47]

The original CICS nucleus consisted of a number of functional modules written in 370 assembler until V3:

• 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 in V3, the CICS nucleus was rewritten into a kernel-and-domain structure using IBM's PL/AS language – which is compiled into assembler.

The prior structure did not enforce separation of concerns and so had many inter-program dependencies which led to bugs unless exhaustive code analysis was done. The new structure was more modular and so resilient because it was easier to change without impact. The first domains were often built with the name of the prior program but without the trailing "P". For example, Program Control Domain (DFHPC) or Transient Data Domain (DFHTD). The kernel operated as a switcher for inter-domain requests – initially this proved expensive for frequently called domains (such as Trace) but by utilizing PL/AS macros these calls were in-lined without compromising on the separate domain design.

In later versions, completely redesigned domains were added like the Logging Domain DFHLG and Transaction Domain DFHTM that replaced the Journal Control Program (JCP).

In addition to the online functions CICS has several support programs that run as batch jobs.^{[48] : pp.34–35}

• High-level language (macro) preprocessor
• Command language translator
• Dump utility – prints formatted dumps generated by CICS Dump Management
• Trace utility – formats and prints CICS trace output
• Journal formatting utility – prints a formatted dump of the CICS region in case of error

The following components of CICS support application development.^{[48]: pp.35–37}

• Basic Mapping Support (BMS) provides device-independent terminal input and output
• APPC Support that provides LU6.1 and LU6.2 API support for collaborating distributed applications that support two-phase commit
• Data Interchange Program (DIP) provides support for IBM 3770 and IBM 3790 programmable devices
• 2260 Compatibility allows programs written for IBM 2260 display devices to run on 3270 displays
• EXEC Interface Program – the stub program that converts calls generated by EXEC CICS commands to calls to CICS functions
• Built-in Functions – table search, phonetic conversion, field verify, field edit, bit checking, input formatting, weighted retrieval

Different countries have differing pronunciations^[49]

• Within IBM (specifically Tivoli) it is referred to as /ˈkɪks/.
• In the US, it is more usually pronounced by reciting each letter /ˌsiːˌaɪˌsiːˈɛs/.
• In Australia, Belgium, Canada, Hong Kong, the UK and some other countries, it is pronounced /ˈkɪks/.
• In Denmark, it is pronounced kicks.
• In Finland, it is pronounced [kiks]
• In France, it is pronounced [se.i.se.ɛs].
• In Germany, Austria and Hungary, it is pronounced [ˈtsɪks] and, less often, [ˈkɪks].
• In Greece, it is pronounced kiks.
• In India, it is pronounced kicks.
• In Iran, it is pronounced kicks.
• In Italy, is pronounced [ˈtʃiks].
• In Poland, it is pronounced [ˈkʲiks].
• In Portugal and Brazil, it is pronounced [ˈsiks].
• In Russia, it is pronounced kiks.
• In Slovenia, it is pronounced kiks.
• In Spain, it is pronounced [ˈθiks].
• In Sweden, it is pronounced kicks.
• In Uganda, it is pronounced kicks.
• In Turkey, it is pronounced kiks.

• IBM TXSeries (CICS on distributed platforms)
• IBM WebSphere
• IBM 2741
• IBM 2260
• IBM 3270
• OS/360 and successors
• Source Program Maintenance Online II (early online editor running under CICS)
• Transaction Processing Facility
• Virtual Storage Access Method (VSAM)