Editing CICS (section)

==Programming==

===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.

===Macro-level programming===
When CICS was first released, it only supported application transaction programs written in [[IBM Basic Assembly Language|IBM 360 Assembler]]. [[COBOL]] and [[PL/I]] support were added years later. Because of the initial assembler orientation, requests for CICS services were made using assembler-language [[macro instruction|macros]]. For example, the request to read a record from a file were made by a macro call to the "File Control Program" of CICS might look like this:

 DFHFC TYPE=READ,DATASET=myfile,TYPOPER=UPDATE,....etc.

This gave rise to the later terminology "'''Macro-level''' CICS."

When high-level language support was added, the macros were retained and the code was converted by a pre-compiler that expanded the macros to their COBOL or PL/I CALL statement equivalents. Thus preparing a [[high-level programming language|HLL]] application was effectively a "two-stage" [[compiler|compile]]{{snd}} output from the preprocessor fed into the HLL compiler as input.

'''COBOL considerations''': unlike PL/I, IBM COBOL does not normally provide for the manipulation of pointers (addresses).  In order to allow COBOL programmers to access CICS control blocks and dynamic storage the designers resorted to what was essentially a hack.  The COBOL ''Linkage Section'' was normally used for inter-program communication, such as parameter passing. The compiler generates a list of addresses, each called a ''Base Locator for Linkage'' (BLL) which were set on entry to the called program. The first BLL corresponds to the first item in the Linkage Section and so on. CICS allows the programmer to access and manipulate these by passing the address of the list as the first argument to the program.  The BLLs can then be dynamically set, either by CICS or by the application to allow access to the corresponding structure in the Linkage Section.<ref>{{cite book|last1=IBM Corporation|title=Customer Information Control System (CICS) Application Programmer's Reference Manual|date=1972|url=http://www.bitsavers.org/pdf/ibm/370/CICS/SH20-1047-4_CICS_Application_Programmers_Reference_Manual_Dec72.pdf|access-date=Jan 4, 2016|archive-date=May 29, 2019|archive-url=https://web.archive.org/web/20190529212914/http://bitsavers.org/pdf/ibm/370/CICS/SH20-1047-4_CICS_Application_Programmers_Reference_Manual_Dec72.pdf|url-status=live}}</ref>

===Command-level programming===
During the 1980s, IBM at Hursley Park produced a version of CICS that supported what became known as "Command-level CICS" which still supported the older programs but introduced a new API style to application programs.

A typical Command-level call might look like the following:

<syntaxhighlight lang="cobolfree">
 EXEC CICS
     SEND MAPSET('LOSMATT') MAP('LOSATT')
 END-EXEC
</syntaxhighlight>

The values given in the SEND MAPSET command correspond to the names used on the first DFHMSD macro in the map definition given below for the MAPSET argument, and the DFHMSI macro for the MAP argument. This is pre-processed by a pre-compile batch translation stage, which converts the embedded 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.

Initially, at execution time, the command-level commands were converted using a run-time translator, "The EXEC Interface Program", to the old Macro-level call, which was then executed by the mostly unchanged CICS nucleus programs.  But when the CICS Kernel was re-written for TS V3, EXEC CICS became the only way to program CICS applications, as many of the underlying interfaces had changed.

===Run-time conversion===
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.

By this time, there were perhaps millions of programs worldwide that had been in production for decades in many cases. Rewriting them often introduced new bugs without necessarily adding new features. There were a significant number of users who ran CICS V2 application-owning regions (AORs) to continue to run macro code for many years after the change to V3.

It was also possible to execute old Macro-level programs using conversion software such as APT International's ''[[Command CICS]]''.<ref>{{cite web|url=http://www.ibm.com/partnerworld/gsd/solutiondetails.do?solution=16478&expand=true&lc=en|work=[[IBM]]|title=Command/CICS|access-date=22 April 2018|archive-date=15 June 2021|archive-url=https://web.archive.org/web/20210615130438/https://www-356.ibm.com/partnerworld/gsd/solutiondetails.do?solution=16478&expand=true&lc=en|url-status=live}}</ref>

===New programming styles===
Recent CICS Transaction Server enhancements include support for a number of modern programming styles.

CICS Transaction Server Version 5.6<ref>{{Cite web |url=https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&supplier=897&letternum=ENUS220-077 |title=IBM CICS Transaction Server for z/OS, V5.6 delivers significant improvements to the developer experience, security, resilience, and management |date=7 April 2020 |access-date=2020-07-09 |archive-date=2020-07-10 |archive-url=https://web.archive.org/web/20200710230551/https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&supplier=897&letternum=ENUS220-077 |url-status=live }}</ref> introduced enhanced support for Java to deliver a cloud-native experience for Java developers. For example, the new CICS Java API ([https://www.ibm.com/support/knowledgecenter/SSGMCP_5.6.0/applications/developing/java/jcicsx-api.html JCICSX]) allows easier unit testing using mocking and stubbing approaches, and can be run remotely on the developer's local workstation. A set of [https://search.maven.org/search?q=g:com.ibm.cics CICS artifacts on Maven Central] enable developers to resolve Java dependencies using popular dependency management tools such as [[Apache Maven]] and [[Gradle]]. Plug-ins for Maven ([https://github.com/IBM/cics-bundle-maven cics-bundle-maven]) and Gradle ([https://github.com/IBM/cics-bundle-gradle cics-bundle-gradle]) are also provided to simplify automated building of CICS bundles, using familiar IDEs like [[Eclipse (software)|Eclipse]], [[IntelliJ IDEA]], and [[Visual Studio Code]]. In addition, [[Node.js]] z/OS support is enhanced for version 12, providing faster startup, better default heap limits, updates to the V8 JavaScript engine, etc. Support for [[Jakarta EE]] 8 is also included.

CICS TS 5.5 introduced support for IBM SDK for Node.js, providing a full JavaScript runtime, server-side APIs, and libraries to efficiently build high-performance, highly scalable network applications for IBM Z.

CICS Transaction Server Version 2.1 introduced support for Java. CICS Transaction Server Version 2.2 supported the Software Developers Toolkit. CICS provides the same run-time container as IBM's WebSphere product family so Java EE applications are portable between CICS and Websphere and there is common tooling for the development and deployment of Java EE applications.

In addition, CICS placed an emphasis on "wrapping" existing application programs inside modern interfaces so that long-established business functions can be incorporated into more modern services. These include WSDL, SOAP and JSON interfaces that wrap legacy code so that a web or mobile application can obtain and update the core business objects without requiring a major rewrite of the back-end functions.