IBM released CICS Transaction Server for z/OS Version 4.2 on June 24, 2011. One of the themes of the new release is scalability; enhancements allow more work to occur faster in a single CICS system. This allows increased vertical scaling and may reduce the need to scale horizontally, decreasing the number of regions required to run the production business applications.
Scalability enhancements in CICS Transaction Server V4.2 fall into two broad areas: increased exploitation of Open Transaction Environment (OTE) and increased exploitation of 64-bit storage.
OTE is an architecture introduced for three purposes:
- To allow CICS to make better use of the mainframe. OTE enables CICS to do more things in parallel, increasing system throughput. This results in more work being done in the same amount of time.
- To improve the performance of existing applications, particularly those that access external resources managers such as DB2, by consuming fewer mainframe resources
- To augment the already rich set of capabilities provided by the CICS Application Programming Interface (API) by supporting application interfaces supplied by other software components.
To benefit from OTE capabilities, customers must ensure their applications are threadsafe. If the mainframe has many CPUs and many processes are running in parallel, an application that’s threadsafe runs correctly and generates the right result. CICS makes sure its code runs correctly, but customers must ensure their COBOL code, for example, runs correctly. If an application is threadsafe, it can be defined to CICS via a CONCURRENCY keyword so it uses OTE. If an application isn’t threadsafe, CICS runs it without using OTE.
Applications that can’t use OTE must run on the main CICS Task Control Block (TCB), the Quasi-Reentrant (QR) TCB, while applications that use OTE can run on a CICS open TCB. A CICS system has only one QR TCB, and the CICS dispatcher shares use of the QR TCB between all the tasks. However, a single CICS system can have hundreds of open TCBs. Exploiting OTE effectively keeps an application running on an open TCB as long as possible and minimizes the number of times it must switch back to the QR TCB. This provides CPU savings and improves throughput; the open TCBs can run in parallel and take advantage of the multi-processor mainframe.
OTE enhancements in CICS TS 4.2 fall into three areas:
- The introduction of a new concurrency option on the program definition that allows for greater exploitation of OTE for threadsafe applications
- Exploitation of OTE for function shipping, by allowing the mirror program, when it’s invoked in a remote CICS region via an IP Interconnectivity (IPIC) connection, to run on an open TCB
- Making more of the API and System Programming Interface (SPI) threadsafe, including access to IMS databases via the CICS-DBCTL interface.
Prior to CICS TS 4.2, an application program can be defined as CONCURRENCY(QUASIRENT) or CONCURRENCY(THREADSAFE):
- A CONCURRENCY(QUASIRENT) program always runs on the QR TCB.
- A CONCURRENCY(THREADSAFE) program is a program that’s been coded to threadsafe standards and contains threadsafe logic. It can run on either the QR TCB or an open TCB. It starts off running on the QR TCB. If processing, such as a DB2 request, causes a switch to an open TCB, once it returns to the program, the program continues on the open TCB.
CICS TS 4.2 provides a new CONCURRENCY(REQUIRED) setting (see Figure 1). As with CONCURRENCY(THREADSAFE), the new setting specifies that the program was coded to threadsafe standards and contains threadsafe logic, but the program also must run on an open TCB. So the program runs on an open TCB from the start, and if CICS has to switch to the QR TCB to process a non-threadsafe CICS command, CICS returns to the open TCB when it returns control to the application program.