CICS

For the Sudbury, Ontario radio station, see CICS-FM.

CICS (Customer Information Control System) is a transaction server that runs primarily on IBM mainframe systems under z/OS or z/VSE. CICS on distributed platforms is called TXSeries and it is available on AIX, Windows, Solaris and HP-UX. CICS is also available on other operating systems, notably i5/OS, OS/2. The z/OS implementation, ie, CICS Transaction Server for z/OS is by far the most popular and significant. It is known foremost as a pseudo-conversational computer application.

CICS is a transaction processing system designed for both Online and Batch processing activity. A transaction is basically a set of operations performing a task. Usually, the majority of transactions are relatively simple tasks such as updating the balance of an account. On IBM System z servers, CICS easily supports thousands of transactions per second, making it a mainstay of enterprise computing. CICS applications 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 id. CICS screens are sent as a construct called a map, using a programming language such as COBOL. The end user inputs data which is made accessible to the program by receiving a map. CICS screens may contain text that is highlighted, having different colors or blinking. An example of how a map can be sent through COBOL is given below.

EXEC CICS SEND MAPSET(MPS1) MAP(MP1) END-EXEC.

CICS is used in bank teller applications, ATM systems etc. CICS first went on sale on July 8, 1969, not long after IMS. It was originally developed in the United States at IBM's Palo Alto lab. In 1974, CICS development shifted to IBM's programming labs in Hursley, United Kingdom, where work continues today.

While CICS has its highest profile among financial institutions such as banks and insurance companies, over 90 percent of Fortune 500 companies are reported to rely on CICS (running on z/OS) for their core business functions, beside many governments.

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

Recent CICS Transaction Server enhancements include support for Web services and Enterprise Java Beans (EJBs). IBM began shipping the latest release, CICS Transaction Server - Version 3.2, in June 2007.

1 CICS structure
2 History
3 Pronunciation
4 See also
5 References
6 External links

CICS structure

In the z/OS environment a CICS installation comprises one or more address spaces, spread across one or more z/OS system images. Each address space (which is synonymous in CICS terms with a region) comprises *one* major task - the "Quasi-Reentrant Task" (or QR TCB for short) on which every transaction runs. When certain services are required (such as access to DB2 data) other tasks (or TCBs) are used.

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 / address space

History

CICS was started as a batch program with standard JCL statements.

When CICS was first released, it supported programs written in IBM Assembler, PL/I and COBOL. Programs needed to be quasi-reentrant in order to support multiple concurrent transaction threads. Its modular design meant that with judicious "pruning" it could be executed on a computer with just 32K of physical memory (including the operating system).

Each unique CICS "Task" or transaction was 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.

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 were frequently unaccustomed to the internals of their programs or else did not use the necessary restrictive compile time options. This resulted in "non re-entrant" code that was often unreliable, leading to many spurious storage violations and entire CICS system crashes.

The entire partition or region operated with the same memory protection key including the CICS kernel code and so program corruption and CICS control block corruption was a frequent cause of system downtime.

These shortcomings nevertheless persisted for multiple new releases of CICS over a period of more than 20 years and, as stated above, were often critical applications used by large Banks and other financial institutions.

It was possible to provide a good measure of advance protection by performing all testing under control of a monitoring program that also served to provide Test/Debug features. One such software offering was known as OLIVER which prevented application programs corrupting memory using instruction simulation.

System calls to CICS (for example to read a record from a file) were elicited by a macro call and this gave rise to the later terminology "macro level CICS". An example of a call to the "File Control Program" of CICS might look like this:-

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

This was converted by a pre-compile Assembly which expanded the conditional assembly language macros to their COBOL or PL/1 CALL statement equivalents. Thus preparing a HLL application was effectively a "two stage" compile; output from the Assembler fed straight into the HLL compiler as input.

Command Level CICS

During the 1980s, IBM at Hursley produced a "half-way house" version of CICS which supported what became known as "Command Level CICS". This release still supported the older programs but introduced a new layer of execution to the new Command level application programs.

A typical Command level call was given in the first MAPSET example above. This was pre-processed by a pre-compile batch translation stage which converted the embedded Command calls (EXEC's) into Call statements to a stub sub-routine. 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.

At execution time, the carefully built Command level calls were converted back using a run-time translator ("The EXEC Interface Program"; part of the CICS supplied nucleus) to the old Macro level call which was then executed by the mostly unchanged CICS nucleus programs.

CEDF: This IBM-produced "Command Execution Diagnostic Facility" helped debug 'EXEC CICS' calls by showing before and after results. The "OLIVER" software pre-dated this free add on by more than 10 years and yet CEDF came without any form of memory protection. It was however complementary to OLIVER, and both could be used simultaneously.

Command level only CICS was introduced in the early 1990s which offered some advantages over earlier versions of CICS. However IBM also dropped support for Macro level application programs written for earlier versions. This "forced" many application programs to be converted or completely re-written to use Command level EXEC calls only, usually by programmers who had no exposure to earlier versions or to the original code.

By this time there were perhaps millions of programs worldwide that had been executing fairly reliably; for decades in many cases. Re-writing them inevitably introduced new bugs without necessarily adding new features.

Run time conversion

It was however possible to execute old macro level programs using conversion software such as "Command CICS" produced by APT International a former CICS Software Specialist company who had earlier produced OLIVER, described above. It was possible to take advantage of the new features of later versions of CICS whilst at the same time retaining the original unaltered codebase. It is believed that there are still programs running today using this same technology. The overhead was minimal since additional overhead was limited to the CICS calls only.

Z notation

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 Sir Tony Hoare. This work won a Queen's Award for Technological Achievement.

Pronunciation

Different countries have differing pronunciations [1]

Within IBM (specifically Tivoli) it is referred to as kicks.
In the UK, Australia, Belgium, Hong Kong and some other countries it is pronounced kicks.
In the US, it is more usually pronounced by reciting each letter (C-I-C-S or see-eye-see-ess [si.aɪ.si.es]).
In France is is pronounced say-eee-say-ess [se.i.se.es]
In Italy, it is pronounced chicks [ʧiks].
In Spain it is pronounced thicks [θiks] or sicks [siks].
In Spanish America it is pronounced sicks [siks].
In Germany, it is pronounced zicks and, less often, kicks
In Poland, it is pronounced kiks
In Portugal and Brazil it is pronounced seeks [siks].