Editing CICS (section)

===Programming considerations===
Multiple-user interactive-transaction application programs were required to be [[wikt:quasi-|quasi]]-[[reentrant (subroutine)|reentrant]] in order to support multiple concurrent [[database transaction|transaction]] [[thread (computer science)|thread]]s. 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]]).

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)|thrashing]] 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 method|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).

Because application programs could be shared by many [[concurrency (computer science)|concurrent]] threads, the use of [[static variable]]s embedded within a program (or use of operating system memory) was restricted (by convention only).

[[Image:OLIVER advert.png|thumb|right|upright=0.7|Advertisement for CICS debugging product, 1978]]

Unfortunately, many of the "rules" were frequently broken, especially by COBOL programmers who might not understand the internals of their programs or fail to use the necessary restrictive [[compile time]] options. This resulted in "non-re-entrant" code that was often unreliable, leading to spurious [[storage violation]]s and entire CICS system crashes.

Originally, the entire [[memory management (operating systems)#Partitioned allocation|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 shortcomings persisted for multiple new releases of CICS over a period of more than 20 years, in spite of their severity and the fact that top-quality CICS skills were in high demand and short supply. They were addressed in TS V3.3, V4.1 and V5.2 with the Storage Protection, Transaction Isolation and Subspace features respectively, which utilize operating system hardware features to protect the application code and the data within the same address space even though the applications were not written to be separated. CICS application transactions remain mission-critical for many public utility companies, large banks and other multibillion-dollar financial institutions.

Additionally, it is possible to provide a measure of advance application protection by performing test under control of a monitoring program that also serves to provide Test and Debug features.