CICS

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

Customer Information Control System (CICS) 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. Applications are written in a variety of languages and use CICS-supplied language extensions to interact with CICS resources such as files, database connections or to invoke functions such as web services. CICS manages the entire transaction such that if for any reason a part of the transaction fails all recoverable changes can be backed out.

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,^[1] along with many government entities. CICS is used in bank-teller applications, ATM systems, industrial production control systems, insurance applications, and many other types of interactive applications.

Web services and Enterprise Java Beans (EJBs), Event processing, Atom feeds, and RESTful interfaces. CICS Transaction Server version 4.2,^[2] which became generally available on 24 June 2011, includes support for system events, 64-bit Java, transaction tracking, and password phrases.

History

The first release of the CICS Program Product developed by IBM became available on July 8, 1969, not long after IMS database management system. CICS was originally developed in the United States at an IBM Development Center in Des Plaines, Illinois, beginning in 1966. The first CICS product was released in 1968, named Public Utility Customer Information Control System, or PU-CICS. CICS was originally developed to address requirements from the public utility industry, but 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.

Early evolution

CICS originally only supported a few IBM-brand devices like the 1965 IBM 2741 Selectric (golf ball) typewriter. The 1964 IBM 2260 and 1972 IBM 3270 video display terminals eventually played major roles in the evolution of CICS paperless office capabilities.

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 real-time computing system (similar to the 1965 IBM Airline Control Program used by the American Airlines Sabre computer reservations system) for high-speed data access-and-update to customer information for their telephone operators (without waiting for over-night 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 short years, CICS generated over $60 Billion dollars in new hardware revenue for IBM, and became their most-successful mainframe software product.

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-generation 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 ASCII-based Intel chip, and immature Microsoft 1980 DOS).

In 1974, CICS development responsibility was shifted to IBM's Hursley, United Kingdom Laboratory, where development work continues today.

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.

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).

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 system generation (sysgen) process 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 services emulated the functions of the operating system, but provided services tailored to support only quasi-reentrant transaction processing that were more efficient than the generalized services in the operating system and much simpler for programmers to use, particularly with respect to communication with diverse terminal devices.

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 (computer science) 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).

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.

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.

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 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 serious shortcomings persisted for multiple new releases of CICS over a period of more than 20 years. CICS application transactions were often mission-critical for public utility companies, large banks and other multi-billion-dollar financial institutions. Top-quality CICS skills were in high demand and short supply. The complex learning curve was shallow and long. Unqualified novice developers could have a major negative impact on company operations.

Eventually, it became possible to provide a measure of advance application protection by performing all testing under control of a monitoring program that also served to provide Test and Debug features. One such software offering was known as OLIVER, which prevented application programs corrupting memory by using instruction set simulation of the application code, providing partial virtualization.

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 that 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.

Command-level CICS

During the 1980s, IBM at Hursley produced a "half-way house" version of CICS that 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.

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 that 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.

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.^[3]

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 run-time 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 a CICS program to be a Web service provider or requester. CICS supports a number of industry standard and specifications including SOAP Version 1.1 and Version 1.2, Web services distributed transactions (WS-Atomic Transaction) and XML Encryption and Signing.^[4]

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 (communication area), 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 it was invoked with.

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 Atom feeds, and SupportPac CA1S adds support for the PHP scripting language, using the same Java-based PHP engine as Project Zero. Often SupportPac introduce new technologies into CICS before they are added into the main product, for example CA8K introduced Atom feeds before it was officially integrated into the product in CICS TS 4.1

New Management Interface – CICS Explorer

On 5 November 2008, IBM introduced a SupportPac containing the new CICS Explorer Eclipse-based graphical tooling interface for CICS.

Transactions

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 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, SDEF or Delta Map. 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.

Example of BMS Map Code

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

Example of SDEF Map Code

         TITLE 'LOS FAC SCAN'      
SCANLOSI AUSN1ST SCREEN=S001,LEVEL=10,PREFIX=XX01   
**     COMMENTS.                                     
**         LAST CHANGED: JANUARY 21 1987                               
**            
         AUSNSDF  NEW,1,1,UALM,'LOSI',ITMNM=CL
         PUNCH 'COBDAT       12  FILLER  REDEFINES XX01-CL.'
         AUSNSDF  NEXT,23,01,PAL,'PF1-HELP     ',ITMNM=PF1 
         AUSNSDF  NEXT,23,15,PAL,'2-          ',ITMNM=PF2  
         AUSNSDF  NEXT,23,28,PAL,'3-          ',ITMNM=PF3  
         AUSNSDF  NEXT,23,41,PAL,'4-          ',ITMNM=PF4  
         AUSNSDF  NEXT,23,54,PAL,'5-          ',ITMNM=PF5  
         AUSNSDF  NEXT,23,67,PAL,'6-           ',ITMNM=PF6 
         AUSNSDF  NEXT,24,01,PAL,'7-           ',ITMNM=PF7 
         AUSNSDF  NEXT,24,15,PAL,'8-          ',ITMNM=PF8  
         AUSNSDF  NEXT,24,28,PAL,'9-         ',ITMNM=PF9   
         AUSNSDF  NEXT,24,40,PAL,'10-         ',ITMNM=PF10 
         AUSNSDF  NEXT,24,53,PAL,'11-         ',ITMNM=PF11 
         AUSNSDF  NEXT,24,66,PAL,'12-CANCEL    ',ITMNM=PF12
         AUSNLST                                           
         END    SCANLOSI

Example of Delta Map Code

**PDL**0003467834/LOSACCT/01/LOS TRANSACTION SCREEN     
.*D                                                               
.*D  Screen Layout for primary LOS Transaction Screen  
.*D                                                               
.LAYOUT-LOS,-                                                      
.   CURSOR = VOUCHER-NUM,-                                         
.   LAYOUT-SIZE=(24,80)                                            
.*-----------------------------------------------------------------
 LOSS                      TRANSACTION ACCOUNTING                                                                   
 Client Details:                                                   
 Transaction Number &&&&&&&&&&&&&&&&&&&             DATE && && &&&&     
 Account            &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&  
 Client             &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&  

.*                                                           
.VARIABLES            ,UNPROTECTED,PAD,PREFIX=LPS,COLOR=GREEN
.*   CONTROL-LINE AND MESSAGE-LINE DEFINED IN STANDARD MACRO 
.*                                                           
    -TRANS-NUM              ,UPDATE                          
    -DOT-DD                 ,UPDATE,NUM                      
    -DOT-MM                 ,UPDATE,NUM                      
    -DOT-CCYY               ,UPDATE,NUM                      
    -ACCOUNTNUM             ,FROM,PROTECTED,COLOR=BLUE       
    -COMPANYNAME            ,FROM,PROTECTED,COLOR=BLUE       
.CONSTANTS, COLOR=BLUE                      
    'LOS Accounting', COLOR=TURQUOISE
    'Account:', COLOR=TURQUOISE      
    'Client:', COLOR=TURQUOISE    
.END

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 (i.e. not z/OS) is called IBM TXSeries, which is available on AIX, Windows, Solaris, and HP-UX operating systems. 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.

Structure

In the z/OS environment, a CICS installation comprises one or more regions (generally referred to as a "CICS Region")^[5] , 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.

Pronunciation

Different countries have differing pronunciations ^[6]

• Within IBM (specifically Tivoli) it is referred to as /ˈkɪks/ kicks.
• In the US, it is more usually pronounced by reciting each letter (C-I-C-S /ˌsiːˌaɪˌsiːˈɛs/).
• In Australia, Belgium, Canada, Hong Kong, the UK and some other countries, it is pronounced /ˈkɪks/.
• In Finland, it is pronounced [kiks]
• In France, it is pronounced [se.i.se.ɛs].
• In German, it is pronounced [ˈtsɪks] and, less often, [ˈkɪks].
• In India, it is pronounced kicks.
• In Italian, 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 Spanish, it is pronounced [ˈθiks].
• In Israel, it is pronounced kicks.
• In Uganda, it is pronounced kicks.
• In Turkiye, it is pronounced kiks.

See also

• IBM TXSeries (CICS on distributed platforms)
• IBM WebSphere
• IBM 2741
• IBM 2260
• IBM 3270
• OS 360
• VSAM
• z/TPF
• Command CICS a run-time macro to Command level translator

References

1. ^ IBM, 2004. CICS 35 year anniversary
2. ^ IBM, 2011. CICS Transaction Server for z/OS V4.2
3. ^ King, Steve (1993). "The Use of Z in the Restructure of IBM CICS". In Hayes, Ian. Specification Case Studies (2nd ed.). New York: Prentice Hall. pp. 202–213. ISBN 0-13-832544-8. 
4. ^ IBM, 2010, CICS TS 4.1 Information Centre, http://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.webservices.doc/concepts/dfhws_standards.html
5. ^ IBM (September 13, 2010). "CICS Transaction Server glossary". CICS Transaction Server for z/OS V3.2. IBM Information Center, Boulder, Colorado. http://publib.boulder.ibm.com/infocenter/cicsts/v3r2/index.jsp. Retrieved 12 December 2010. 
6. ^ IBM, 2004, CICS an introduction, ftp://service.boulder.ibm.com/software/htp/cics/PDF/cics_introduction.pdf

External links

• IBM CICS Family official website
• IBM CICS Whitepaper - Why to choose CICS Transaction Server for new IT projects
• CICS official 35th Anniversary website
• CICS User Community website for CICS related news, announcements and discussions
• CICS specific wiki
• The Master Terminal CICS Development blog
• Bob Yelavich's CICS focused website. (Archived copy from 5 Feb 2005) Note that this site uses frames, but on high-resolution screens the left-hand frame, which contains the site index, may be hidden. Scroll right within the frame to see its content.