Jump to content

CICS: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Pcs305 (talk | contribs)
Pcs305 (talk | contribs)
m Corrected a spelling mistake in the CEDF paragraph and added an external link.
Line 80: Line 80:
*[http://www.ibm.com/cics/35 CICS official 35th Anniversary website]
*[http://www.ibm.com/cics/35 CICS official 35th Anniversary website]
*[http://web.archive.org/web/20040924073107/http://www.yelavich.com/ Bob Yelavich's CICS focussed website. (archived copy from 24 September 2004)]
*[http://web.archive.org/web/20040924073107/http://www.yelavich.com/ Bob Yelavich's CICS focussed website. (archived copy from 24 September 2004)]
*[http://www.pcs305.com/ CICS User Community website for CICS related news, announcements and discussions]


[[Category:IBM software]]
[[Category:IBM software]]

Revision as of 17:09, 7 June 2007

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 activity. On large IBM zSeries and System z9 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 maps 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, airline reservation systems, 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. Most state and national governments do as well.

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 and a very popular release, CICS Transaction Server Version 3.1 for z/OS, in early 2005.

Version 3.2 was announced in 2007 which includes further enhancements in the web services area.


History

When CICS was first released, it supported programs written in IBM Assembler, PL/I and COBOL. Programs needed to be quasi-reentrant 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 real memory (including the Operating System of 8K) such as an IBM 360 model 30.

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"). This is analogous to an Operating System and effectively CICS could be considered "an Operating System within an Operating System" with its own rules and calls for services such as I/O or program calls (Link to or transfer control to). CICS was in fact started as a batch program with standard JCL statements.

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

  • In Britain, Canada, Australia, France, Belgium and some other countries, CICS is pronounced the same as the word kicks. In the US, it is more usually pronounced by reciting each letter (C-I-C-S). Both pronunciations are popular.
  • In Germany, it is pronounced zicks and, less often, kicks
  • In Italy, it is pronounced chicks.
  • In Spain it is pronounced thicks.
  • In Brazil, Peru and Mexico, it is pronounced sicks.
  • In Ohio (USA), it is sometimes pronounce zhvicks (due mainly to the hybrid eastern hill accents).

See also