Initially, CICS supported only Assembler Language application programs, and then, only on the so-called "full operating system", meaning PCP, MFT and/or MVT, and not the Disk Operating System (DOS)(which later evolved into the DOS/VSE product).
The decision to support only Assembler was based on several things. First, memory cycles and real storage were limited in the hardware systems of the late 1960s, and it was felt only through the use of Assembler could an online system provide good performance in a multi-tasking environment.
COBOL and PL/I did not provide for reentrancy at the time and could only support one use of an application at one time, serializing the use of a given program. The usability of COBOL and/or PL/I was also considered unacceptable for online systems, due to their relatively greater use of CPU cycles and real storage. COBOL and PL/I use with CICS was first offered beginning in December 1970. Until later versions of the compilers, CICS found it necessary to internally allocate unique copies of compiler working storage for each concurrent CICS use of the application.
The developers of CICS made an early decision not to require Assember application programmers to code pure reentrant programs. The perception was that coding pure reentrant programs would be new for most programmers at the time, difficult and perhaps unnecessary. CICS would dispatch only one CICS transaction (application program) at one time under its single OS TCB. CICS chose not to support multiple TCBs (one per transaction, for instance) within the job step task due to the implied high overhead of TCB management and the requirement for applications to be pure reentrant (when and if the same application were to run concurrently). The requirement for pure reentrancy was avoided by CICS' adoption of the so-called "quasi-reentrant" style of programming.
For an application to meet the less restrictive programming requirement of quasi-reentrancy, it could have self-modifying code, but only between its use of CICS statements (macro level at the time). In 1977, CICS macro level programming was superceded by the so-called "command level programming" and the "EXEC CICS" application programming interface (API). Even with the introduction of command level programming, CICS still did not require pure reentrant programming becase a given application was not being dispatched under multiple, different OS TCBs.
If an application program were to be placed in the operating system's Link Pack Area (LPA) or similar area, then the operating system required the program module to be specified as pure reentrant and not self-modifying. CICS has supported to use of such storage areas.
Beginning with the CICS Transaction Server (CICS TS) product in 2002, CICS DB2 application programs within a single region could be dispatched under different TCBs. This introduced the idea of "thread safe" programs. An application which meets this new criteria is now able to be dispatched on more than one TCB (for instance, the so-called QR TCB and an Open Transaction Environment (OTE) TCB). The new capability reduced TCB switching, saving cycles and improving performance.
Copyright © 2003 - Yelavich Consulting, Sparks, NV
Click here
for other articles regarding the evolution of CICS.