The Herb Garden

Really fast engines can easily dispatch hundreds of CICS address spaces. With today’s engine speeds, every CICS region could dispatch hundreds of L8/9 TCBs also with consummate ease. However, CICS has now evolved to the point it really doesn’t need to keep chasing faster engines. Maybe all we need now is a z/OS operating system that can dispatch a TCB on any one of 500 smaller engines. Read more...

Up to and including CICS/MVS V2.1.2 CICS provided an API that ran almost everything on a single TCB, the main job step TCB.

beginning of a little bit of parallelism

Versions 3 and 4 did much the same, except the TCB that did virtually all the work for CICS transactions became known as the Quasi-Reentrant TCB or QR TCB. In these releases, certain discreet pieces of work could be offloaded to another TCB, such as the Resource Owning or RO TCB to do, for example, program loads, or to the Concurrent TCB or CO TCB (if it existed) to offload VSAM I/O operations (later releases still do this). If a CICS application made a non-CICS call for service the chance of “blocking” the QR TCB would have a disastrous effect on the entire CICS region.

beginning of true parallelism

The beginning of true parallelism arrived with CICS TS 1.3 in the shape of the J8 TCB for running Java transactions, each in their own Java Virtual Machine (JVM). There were also H8 TCBs for “hotpooled” Java.

Because the Java implementation in CICS was fully “threadsafe,” it became possible for the first time to even consider a parallel world.

Also in CICS TS 1.3 some parts of CICS internal components (that support the API) were made threadsafe (releases since have continued that effort, so many more CICS API functions have subsequently become threadsafe).

CICS TS 1.3 also introduced a new parameter on a program definition CONCURRENCY(QUASIREENTRANT | THREADSAFE) and a SIT parm FORCEQR(NO|YES). These parameters had no effect, however, until CICS TS 2.2 onward. They were made available in V1.3, so customers could start on the long haul to a threadsafe, parallel world.

What threadsafe mean? Reentrancy does notmean threadsafe.

As stated above CICS transactions have historically done all their own work on the QR TCB (or its historical equivalent) so at any one time only one transaction could be executing. Programmers, therefore, didn’t have to consider that anything else might be running at the same time as their program, be that another identical transaction trying to run the same program or another transaction trying to run its own program. Everything was therefore serialized or made “serially reusable.”

Defining a program as CONCURRENCY(THREADSAFE) means that more than one instance of our program could be executing in parallel on behalf of multiple users. In the past, due to the speed of the mainframe processor, it was an illusion that end users all seemed to be running their work simultaneously.

A given CICS region could only run the QR TCB on one of the engines at once in a multi-processor machine.

Threadsafe, therefore, means that appropriately well-behaved programs can be running in parallel, each on its own TCB (L8 or L9 TCBs).

Given a highly (or better still “massively”) paralleled multi-engined machine, this should mean a quantum leap in throughput when all of CICS API functionality is made threadsafe; even V3.1 is short of that distinction (with notable exceptions being File Control and BMS/Terminal Control).

TCB Switching in V2.2 and V2.3

Given that Java transactions run in parallel already, the first real exploitation of threadsafe arrived with CICS TS 2.2. It applied exclusively to installations running CICS work into DB2.

Prior to V2.2, applications calling DB2 had to leave the QR TCB and get onto an MVS-managed DB2 thread or TCB. Once the call completed, the task was switched back onto the QR TCB to continue its processing in CICS.

TCB Switching in V3.1 Onward

CICS TS 3.1 enabled L8/9 TCB exploitation for all threadsafe programs, no longer restricting this functionality to DB2. In addition, a new parameter option on the CEDA program definition API(CICSAPI | OPENAPI) was introduced.

IIn this scenario (Figure 3, right side), if we had specified EXECKEY(USER) on the program definition, we would have seen an L9 TCB (see later). Just for completeness, this scenario also would prevail if we have STGPROT=NO even with EXECKEY(USER).

(Incidentally, programs defined with API(OPENAPI) could make non-CICS API calls without blocking the QR TCB. If you choose to exploit this, you’re on your own!)

If you have a program that uses DB2 extensively and has little need to switch back to the QR TCB by calling nonthreadsafe CICS or non-threadsafe user programs, you should see substantial benefits manifested in reduced CPU utilization due to shorter pathlength (fewer TCB switches) and better throughput through parallelism. However, some programs could really suffer by being run as threadsafe because they could experience excessive TCB switches.

TCB Switching in V3.1 Onward USER Key Programs

CICS/TS 3.1 also introduced the possibility of using USER key programs in that the EXECKEY(USER) option on the program definition causes the program to be run in key-9 on an L9 TCB.

Providing STGPROT=YES also is set. When an OPENAPI Task-Related User Exit (TRUE) is invoked, as in an SQL call to DB2, the task leaves the L9 TCB and executes in DB2 using an L8 TCB and immediately switches back to L9. In this scenario (see Figure 4), we’ve greatly increased the overhead due to much more frequent TCB switches.

Note: The EXECKEY(USER) option was previously ignored for threadsafe non-Java programs. In V2.3, Java programs defined as user key-9 ran on a J9 TCB.

What Programs Qualify?

Initially, few programs will probably qualify for threadsafe exploitation.

Access to shared entities such as the Common Work Area (CWA), GETMAIN SHARED areas, etc. must be serialized using such techniques as compare and swap instruction or EXEC CICS ENQ/DEQ before and after access to the shared entity.

The ENQs may need a Sysplexwide ENQSCOPE() applied via use of an ENQMODEL Resource Definition Online (RDO) object definition.

What can you do to better position your site to take maximum advantage of the advent of a threadsafe CICS environment?

Here are some steps to consider:

• Use the load module scanner program, DFHEISUP, to identify candidate programs for investigation
• Implement serialization techniques where necessary
• Compile and linkedit with the RENT option
• Check that any Global User Exits (GLUEs), TRUEs and User Replaceable Modules (URMs) are threadsafe. (Note: OPENAPI doesn’t apply to GLUEs.)
• Remember that just defining a program as threadsafe doesn’t make it so.
• Avoid OPENAPI for programs with multiple non-threadsafe API calls and programs specified with

1. EXECKEY(USER) that have SQL calls in them.
2. OPENAPI candidate programs are those using threadsafe API calls only, perhaps using SQL but defined in CICS key-8. Ideally, CPU-intensive programs could give great relief to the QR TCB by getting them onto an L8 TCB right at the beginning.

• Review the IBM Redbook titled Threadsafe Considerations for CICS (SG24-6351).

• CICS