Introduction
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[citation needed], 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.
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 4.1, which contains support for Event processing, Atom feeds, and RESTful interfaces, in June 2009.
History
The first release of the CICS Program Product developed by IBM became available on July 8, 1969, not long after IMS. 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.
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. 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 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). 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 process to establish values for conditional assembly 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 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 terminal devices. Considerable effort was still required from CICS application programmers to make their programs 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 use the memory occupied by any program not currently in use for another program or other application storage needs. As the efficiency of compiled high level language programs left much to be desired, many early CICS application programs were written in assembler language. CICS owes its early popularity to its relatively efficient implementation, its multi-threaded processing architecture, and its relative simplicity for developing terminal based applications.
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.
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.
CICS – “DEMAND IN FUTURE”
CICSPlex System Manager (CPSM)
CICSPlex System Manager (CPSM) is a mixed blessing. On one hand, it is an excellent tool for monitoring and changing resources across huge CICS region farms. Despite a few quirks, CPSM's dynamic transaction routing (DTR) runs with little fuss and works very well. Lastly, CPSM is the backbone of the Web User Interface (WUI) and CICS Explorer, two very nice management tools.
Unfortunately, CPSM is also a complicated black box with a confusing application programming interface (API) that often fails to work the same way twice. And, for one further gripe, CPSM real-time analysis (RTA) will never be very useful until all the alert information comes out as one console message instead of two.
Command-level interface
Sure, it's a little awkward and kind of jarring to see in the middle of some programming languages, but it freed IBM to work behind the scenes without worrying about someone diddling with system internals. I don't think there's any way to tell which features we take for granted that wouldn't be available today if IBM had to work around user code. For customers, this means that programs older than some recently hired college graduates can continue to run without recompiling.
More Task Control Blocks
CICS's single-task structure had two weaknesses. First, CICS can never run more work than one CPU can process. Second, any kind of operating system wait would freeze the whole region.
IBM created multiple tasks in the CICS address space and took the idea a step further, grouping Task Control Blocks (TCBs) into "modes" dedicated to handling a particular workload. Then they perfected the code necessary to painlessly (except for longer instruction path length) move a running transaction between task modes. This is where transactions using the open API will run. New modes may be on their way as IBM finds more things for CICS to do.
Resource management interface and task-related user exits
The resource management interface (RMI) grew out of the concept of CICS as a unit of work coordinator. Through RMI, other systems that require data integrity, such as databases (DB2 and IMS) or messaging (MQ) can participate in syncpoint/rollback processing. When the next big database management system (DBMS) comes out (DB3 or DL/2), CICS will be in position to support it once the RMI interface is available.
CICS run-rime libraries for higher-level languages
Support for higher-level languages like COBOL or PL/1 wouldn't have meant much if it had created too many programming restrictions or destroyed CICS's cooperative multitasking environment. Instead, someone at IBM got the bright idea of providing a CICS run-time library for the higher-level languages that would enable them to slide easily into the CICS environment. These CICS run-time routines took care of operating system-type requests (e.g., program management) as well as created separate copies of working storage so even COBOL programs could run in parallel.)
Of course, a few restrictions on what a CICS program can do remain, but those will drop off as CICS extends its multiple task control block structure and the open API. The pain of maintaining separate run-time libraries is largely ameliorated with the advent of Language Environment).
Multi-region operation
Multi-region operation (MRO) was a huge step forward. Instead of dealing with multiple single-use regions, systems programmers could connect them together into flexible and resilient CICSPlexes with an efficient, private protocol built on top of cross-memory services and cross-coupling facility.
Many concepts bloomed from this simple idea of allowing regions to talk to each other:
- Remote resource definitions, which allow a transaction in Baltimore to use a file in Vancouver without a single change to an application program. This reached its ultimate in usefulness with the distributed program link, which enabled CICS to implement a transport-agnostic client server structure and served as the entry point for CICS Transaction Gateway.
- Users could now design topologies to run transactions in parallel to avoid reaching the processing limit of CICS's quasi-reentrant TCB and get around virtual storage constraints.
- My personal favorite concept is dynamic workload routing. Specific transactions are no longer tied to specific regions. Instead, routing software can make a choice -- again, transparent to the application based on its own criteria, thus avoiding bottlenecks and slow or crippled systems. I couldn't imagine running the applications we have today without it.
SUMMARY
CICS (Customer Information Control System) is an online transaction processing (OLTP) program from IBM that, together with the COBOL programming language, has formed over the past several decades the most common set of tools for building customer transaction applications in the world of large enterprise mainframe computing. A great number of the legacy applications still in use are COBOL/CICS applications.
Using the application programming interface (API) provided by CICS, a programmer can write programs that communicate with online users and read from or write to customer and other records (orders, inventory figures, customer data, and so forth) in a database (usually referred to as "data sets") using CICS facilities rather than IBM's access methods directly. Like other transaction managers, CICS can ensure that transactions are completed and, if not, undo partly completed transactions so that the integrity of data records is maintained.
IBM markets or supports a CICS product for OS/390, Unix, and Intel PC operating systems. Some of IBM's customers use IBM's Transaction Server to handle e-business transactions from Internet users and forward these to a mainframe server that accesses an existing CICS order and inventory database.
0 comments:
Post a Comment