CICS stands for Customer information control system. It is an online transaction processing module usually used in IBM Mainframes.
According to wiki CICS (Customer Information Control System) is a transaction server that runs primarily on IBM mainframe systems under z/OS and z/VSE.
CICS is a transaction manager designed for rapid, high-volume online processing. This processing is mostly interactive (screen-oriented), but background transactions are possible.
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. CICS is used in bank-teller applications, ATM systems, industrial production control systems, insurance applications and many other types of interactive application.
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.
Transactions
A CICS transaction is a set of operations which together perform a task. Usually, the majority of transactions are relatively simple tasks such as requesting an inventory list or entering a debit or credit to an account. On IBM System 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 sent as a construct called a map, a little program created with BMS (Basic Mapping Support) assembler macros. The end user inputs data, which is made accessible to the program by receiving a map from CICS. CICS screens may contain text that is highlighted, has different colors, and/or blinks. An example of how a map can be sent through COBOL is given below.
EXEC CICS
SEND MAPSET(MPS1) MAP(MP1)
END-EXEC.
[edit] CICS Family
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 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 (i.e., CICS Transaction Server for z/OS) is by far the most popular and significant.
[edit] Structure
In the z/OS environment, a CICS installation comprises one or more regions, spread across one or more z/OS system images. Although it processes interactive transactions, each CICS region may be started as a batch address space with standard JCL statements: it's a job that runs indefinitely. 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).
Each region comprises one major task — the "Quasi-Reentrant Task Control Block" (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. Transactions marked Threadsafe don't return to the QR TCB when their use of a service is complete.
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.
A typical installation consists of a number of distinct applications. Each application usually has its own "Terminal-Owning Region" (TOR) and one or more "Application-Owning Regions" (AORs), though other topologies are possible. For example, the AORs might not perform File I/O. Instead there would be "File-Owning Regions" (FORs) that performed the File I/O on behalf of transactions in the AOR.
[edit] History
The first release of CICS was made available 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. An earlier, single thread, transaction processing system IBM MTCS existed prior to CICS and an 'MTCS-CICS bridge' , a type of middleware, was developed to allow these transactions to execute under CICS with no change to the original application programs.
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", theoretically it could be executed on a computer with just 32K of physical memory (including the operating system). In actual practice, however, CICS was a resource hog[citation needed]needing vastly superior processing capacity (mainly CPU power and main storage size) in order to deliver any measure of useful work[citation needed].
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/I 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.
[edit] 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-level 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.
At execution time, the carefully built Command-level commands 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' commands by showing before and after results. The "OLIVER" software predated 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.
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, usually by programmers without 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. Rewriting them inevitably introduced new bugs without necessarily adding new features.
[edit] 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 which had earlier produced OLIVER, described above. It was possible to take advantage of the new features of later versions of CICS while, 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.
[edit] 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.
[edit] New programming styles
Recent CICS Transaction Server enhancements include support for a number of modern programming styles.
CICS Transaction Server Version 2.1 introduced support for Enterprise Java Beans (EJB). CICS Transaction Server Version 2.2 supported the Software Developers Toolkit. CICS provides the same runtime container as IBM's WebSphere product family so EJB applications are portable between CICS and Websphere and there is common tooling for the development and deployment of EJB applications.
Also introduced with CICS TS 2.1 was the capability for CICS transactions to be invoked via an HTTP request. This allowed CICS transactions to participate as servers in a POX or REST conversation.
CICS Transaction Server 2.3 added new EJB tracing capabilities, and new JCICS classes, allowing the invocation of CICS services using Java. End-to-end debugging was also introduced, making it easier to debug applications, from the Java client to the CICS application.
The Web services support in CICS Transaction Server Version 3.1 enables CICS programs to be Web service providers or requesters. CICS supports a number of specifications including SOAP Version 1.1 and Version 1.2, and Web services distributed transactions (WS-Atomic Transaction).
The CICS Web Services Assistant includes two batch processing utilities, DFHWS2LS and DFHLS2WS, which are used to map WSDL to programming language structures and vice versa, respectively.
The input to DFHWS2LS is a set of control statements governing its processing and file containing WSDL for a web service to be accessed. The output is a set of language structures, each corresponding to a method in the WSDL, and a WSBIND file. This utility is intended for use by an application developer who wishes to access a web service as a client and has been provided its WSDL.
In this case, the application developer populates the language structure corresponding to the method they wish to invoke, writes the structure to the DFHWS-BODY CICS container, and executes the INVOKE WEBSERVICE API. Execution of the API is synchronous, on return the DFHWS-BODY contains the response from the invoked web service mapped to a language structure.
The input to DFHLS2WS is a set of control statements governing its processing and file containing the language structure corresponding to the invocation parameters of a CICS application program. The output is the WSDL corresponding to the language structure, and a WSBIND file. This utility is intended for use by an application developer who wishes to expose a program's functionality as a web service.
In this case, the application program is invoked when an HTTP request for its services is received by the CICS region. The application program sees the request as language structure in either a CICS container or a commarea, which one is governed by the control statements fed into DFHLS2WS. The application program performs its processing and writes the response back to the language structure with which it was invoked.
In either case, whether the CICS application is acting as a web services client or server, the mapping of data to and from XML is governed by the generated WSBIND file. The message body is wrapped in, and unwrapped from, a SOAP envelope by CICS Web Services "plumbing" code external to the application program.
The connections between a web service, the WSBIND file, the WSDL, and the CICS transaction requesting or providing the service is done with CICS system level definitions and a configuration file.
Also introduced with CICS TS 3.1 was the capability for CICS applications to act as HTTP clients. This allowed CICS transactions to participate as clients in a POX or REST conversation.
CICS TS can be extended with additional programming features using SupportPacs. For example SupportPac CA8K introduces support for RSS and Atom, and SupportPac CA1S adds support for the PHP scripting language, using the same Java-based PHP engine as Project Zero.
