CICS / WebSphere

It’s also possible to access shared storage in a manner that’s technically non-threadsafe but is acceptable in practice. Using this same CWA example, operations may want a program that would report how many records had been written so far. In that case, the program would simply extract the current counter value from the CWA, place it in an output message field in working storage and send it to the operator’s console. This activity is non-threadsafe in that the counter value can change between the time the program extracts it and the time the message is sent (in other words, the program could have moved a value of 0001 into its working storage, but the value in the CWA might be 0002 before it issues the send). However, in practice, although the process of building the message in working storage is automatically serialized when the program runs as QUASIRENT, the actual value of the CWA counter can change dramatically by the time the message is received and displayed on the console. In effect, running this non-threadsafe code in a program defined as threadsafe will result in a value that’s only slightly more out-of-date than if the code was converted to threadsafe.

Converting Non-Threadsafe Code to Meet Threadsafe Standards
If non-threadsafe code exists, it must be converted to meet threadsafe standards before the programs are marked as threadsafe. At this point, the benefit of the savings identified earlier must be weighed against the costs of modifying the code to be threadsafe. There are several mechanisms that can be used to serialize access to shared storage (often an EXEC CICS ENQ). However, it may be that using another facility, one that’s automatically serialized, to host the data is the best solution to the problem. For example, removing the counter field from the CWA and replacing it with a named counter would make this process threadsafe. In either case, the process of serialization will add overhead as compared to the in-core counter, reducing the CPU savings generated by the threadsafe conversion and changing the cost/benefit analysis that had previously justified the conversion.

The most efficient method of providing serialized access to an in-core counter value (like the CWA counter in our example) is the use of the Assembler Compare and Swap family of instructions. These instructions allow serialization at the hardware level and have an imperceptible level of CPU overhead. Their drawback is that they’re Assembler code; if the program that requires serialization is written in COBOL or PL/1, a new callable utility must be developed in Assembler to provide the Compare and Swap capability.

While providing serialization of shared resources usually requires some kind of code change, it’s possible under some circumstances to achieve serialization without modifying the program in question. If all the non-threadsafe activity in an application is contained within a small subset of programs, these programs can be left as QUASIRENT. If a program running on an L8 TCB issues a CICS LINK or XCTL to a program that’s defined as QUASIRENT, CICS will spin the task to the QR TCB before giving control to the LINKed-to program; running single-threaded on the QR TCB will provide the level of serialization the program was originally designed around, so no coding changes are required.

When and Why a Two-Phased Threadsafe Conversion Is Appropriate
Allowing part of an application to remain QUASIRENT during a threadsafe conversion will reduce the level of CPU savings that might otherwise have been achieved, but the option of some savings now—without the expense of source code changes—vs. no savings until some time in the future is usually a valid trade-off. In the same way, implementing a threadsafe conversion with programs that still have a large number of non-threadsafe commands will provide partial CPU savings now vs. possibly larger savings if the non-threadsafe commands are modified. In both cases, the possibility of a two-phased threadsafe conversion is raised.

In a two-phased conversion, programs that meet threadsafe standards have their program definitions changed to THREADSAFE, even though their actual CPU savings is substantially below their potential savings. At some later point, when programming resources become available, these programs can be enhanced to (in the first case) bring those remaining programs up to threadsafe requirements, or (in the second case) reduce or eliminate non-threadsafe CICS command activity to further reduce TCB switches. The advantage of a two-phased conversion is that partial CPU savings is realized immediately, helping justify the cost of the programming effort required for phase 2, so the greatest possible savings is eventually achieved. 

This series of articles was introduced after we observed that some CICS shops still aren’t fully aware of the mechanics of the CICS OTE or the many benefits of the OTE—both for DB2 and non-DB2 programs. Every CICS environment would see some improvement following a threadsafe conversion, and for many, this improvement would take the form of a reduction in peak CPU requirements that can lead directly to real savings in both hardware and software costs.

Because every threadsafe conversion project is unique, and every shop has its own programming and operational requirements, it’s probable the costs of a threadsafe conversion would sometimes exceed the benefits for certain applications. However, the potential benefits of OTE exploitation are so significant and widespread, that it’s always reasonable to research the impact of OTE exploitation in your specific set of conditions even when it appears unlikely that a threadsafe conversion would be approved. Put simply, the existence of the OTE changes many of the basic parameters around which CICS applications were designed and coded. Performance considerations that were once obvious are no longer obvious; coding conventions (pseudo-reentrancy, for example) that were rigidly enforced aren’t good enough and elaborate coding mechanisms designed to avoid QR CPU blocking can be eliminated. It’s time to accept these changes and start planning how to make them work for you.

“CICS and the Open Transaction Environment: A Retrospective,”
“CICS and the Open Transaction Environment: What to Do Without DB2,”

3 Pages