CICS was conceived in 1968, and early copies of the product were distributed to IBM customers as a free, Type II Application Program (basically a sample program). In 1969, CICS was among the first IBM software products to become fee-based. What was most important about CICS in its very first offerings, and continues to be important today, is the product's basic architecture which has enabled it to evolve, incorporating new technologies and supporting what the user had implemented on a release to release basis.
Embodied in CICS' basic architecture is the notion of CICS being a group of "management modules" which provide services to its applications and managing the overall execution environment. Although CICS did not use the term, it was an "application server". A goal of CICS was to minimize the programming necessary on the user's part to just providing the essential parameters for a functional request and CICS would then perform whatever was necessary to carry out that request.
The management modules included Terminal Control, Program Control, Storage Control, File Control, Transient Data, Temporary Storage and Interval Control. In 1969, CICS executed on the operating systems of the time, namely PCP (Primary Control Program), MFT (Multiprogramming with a Fixed Number of Tasks) and MVT (Multiprogramming with a Variable Number of Tasks). PCP permitted only one operating system (OS) job to run at one time. MFT enabled multiple jobs to run concurrently, each in a partition of a fixed real memory size. MVT enabled the user to run multiple jobs concurrently, in dynamically attached regions of variable sizes.
Looking back, one might wonder about environments such as PCP and ask why would anyone want to run in such a restricted environment. Part of the answer is that PCP was intended for the smallest hardware systems of the day, and CICS wanted to make itself available to that class of users. MFT was practical at the time because the use of real memory (real storage) systems was rigidly defined and managed. The use of MVT implied the user had a large system with more real storage and wanted the ability to schedule varying mixes of work during the operational business day, but it implied having the largest systems of the time.
Another CICS goal was to provide the user with an environment which could support a large number of communications terminals (IBM 1050s, 2740s, TWX, etc), entering transactional requests with data, and executing a mixture of applications concurrently. The idea of "online" transaction processing was new for a majority of computer users at the time.
CICS Terminal Control provided support for terminals connected to the mainframe computer using the Basic Telecommunications Access Method (BTAM), and to a lesser degree, devices such as card readers/punches, tape drives and disk drive data sets viewed as "sequential terminals". In the late 1960s, other communication access methods had come into being but they were not considered appropriate for "transaction processing". And, CICS use of BTAM was considered more efficient use of the limited environments, similar to CICS support in other functional areas, using CICS-provided function rather than the native support of the particular environment.
From its very beginning, CICS has avoided the need for the user to reinstall the product simply because new resources were being added to the runtime environment. During CICS' early years, the notion of "tables" was an important concept. CICS Terminal Control (the management module) did not have to be statically assembled with a given terminal configuration. Definitions of terminals could be done separately, and a "Terminal Control Table" could then be used at execution time, defining the lines and terminals to be used with CICS. Resource definition tables are used for all CICS management modules. A trivial concept today, but important at the time.
Once the user defined the communication lines, terminals and sequential devices to be used for input/output, CICS provided the polling, reading and writing of those devices, under direction of user specifications and/or programming. A terminal on a given line could be polled (invited) to send input, and assuming the data was entered correctly, a new transaction (unit of work) could then be initiated.
CICS had the notion of a Program Control Table (PCT) and it defined the initial program to be executed when a request was received to execute a particular transaction (specified by a transaction ID). The new unit of work initiated a CICS "task", which may have been designed to be conversational, non-conversational or so-called "pseudo-conversational". A conversational task would remain in execution for some time, issuing reads and writes to its terminal. Because resources were limited (memory, computer cycles, etc), conversational applications were discouraged because while the application waited for terminal operator input, valuable real memory was being held, unused, until the operator responded.
A non-conversational application simply accepted input, did its work (maybe retrieving a file record and sending it to the terminal) and terminating. A pseudo-conversation was a CICS concept in which the application was actually a series of transactions/tasks within CICS to carry out an external business unit of work. Taking a simple illustration, imagine the terminal user entering a request to have a menu displayed at the terminal, and then after choosing some application function to be executed, the terminal user would enter that selection and continue with the application. The point to be made about pseudo-conversation is that the display of the menu was one internal CICS unit of work (transaction) and the function selected by the terminal user would be executed as a separate unit of work. No internal CICS or operating resources were used "between" the first and second interactions with the terminal operator. An important concept and facility which dates back to 1968-1969.
Multiple terminals could be supported by CICS, each entering transactions for concurrent use of the same or different applications. Because of the severe limitations of PCP, and the costly use of operating systems services to attach multiple subtasks within the same partition or region, CICS has always provided its own form of multi-tasking. In the 1968-69 version of CICS, only applications written in Assembler were supported. It was felt at the time, that the size and overhead of high level languages such as COBOL and PL/I were too excessive for systems of the day.
CICS did not require that applications be reentrant. The user assigned priorities to terminals, operators and transactions and the cummulative total determined the dispatching priority of the newly created internal task. CICS did require that applications be "quasi-reentrant", meaning they would be in a consistent state before and after issuing CICS commands. Until later years, the CICS form of multi-tasking made very efficient use of otherwise costly and resource limited environments, and was able to support large numbers of terminals and concurrent transaction workloads.
The program(s) to be executed to carry out the work of the requested transaction could be loaded into memory dynamically. This was the function of CICS Program Control. Initially, CICS used program loading and storage allocation facilities of the host operating system, but this was later determined to be too costly from a CPU cycle and storage management point of view, and CICS would later change to doing its own program loading and allocation/deallocation of storage (memory).
In addition to dynamic program loading, CICS has always enabled the user to "load" a program module and keep it resident for some period of time. This may have been done for frequently used programs or it may have been done to bring a module into memory which was not actually an executable program, but rather a module containing data for use by multiple applications. A dynamic "use count" was kept by CICS so as to know, in real time, the number of active users of a load module, and if needed, CICS could free unused programs.
File organizations available in 1969 included such things as ISAM, BDAM, QSAM and BSAM. ISAM was the indexed sequential access method and enabled users to organize data for either sequential retrieval or random retrieval by key. BDAM was the Basic Direct Access Method and use primarily for "random access" which usually meant retrieval by key. QSAM was the Queued Sequential Access Method and BSAM was the Basic Sequential Access Method. ISAM and BDAM were considered data file access methods whereas CICS used QSAM and BSAM for the reading and/or writing of data considered to be "extra-partition" data entering or leaving the CICS environment.
In addition to file data, using ISAM or BDAM, CICS provided support for data queues. Temporary Storage (TS) queues were dynamically named and allocated, and the data stored in either main storage or auxiliary direct access storage using BDAM. Queued data could be created by any application and read by any other application. A typical use of temporary storage was to hold terminal, operator or application data for a user-defined period of time. Data remained on its queue until deleted, therefore it could be read multiple times before deletion.
CICS also introduced and supported another form of data queues known Transient Data (TD). TD queues were statically defined before CICS execution as being either intrapartition or extrapartition. Any application could read or write any queue. A TD intrapartition queue would be stored in a BDAM file and could be written to or read by any application. Once a data record was read, CICS advanced to the next record in the queue, providing a form of batch processing. An extrapartition queue was commonly a sequential data set written to be used outside of CICS, or conversely a sequential data set created outside CICS but read for use within CICS.
The CICS Interval Control management module provided time services to CICS applications. An application could acquire the time of day in various formats, or schedule other tasks to be initiated at a specific time of day or interval later than the current time. CICS managed its own time services because use of the operating system's time services was too costly in terms of CPU cycles.
The point of this article is that CICS provided valuable application services and function to the user, while making most efficient use of the resources and environments of the time. With the ensuing years, CICS would grow in every dimension - the size of systems, the amount of work performed, new and improved technologies made available to the user, etc. Other articles in this series will discuss CICS growth in other years.
Copyright © 2003 - Yelavich Consulting, Sparks, NV
Click here
for other articles regarding the evolution of CICS.