CICS / WebSphere

This article examines the evolution of threadsafe execution in CICS from its inception to today, and why you should exploit threadsafe in as many of your applications as possible. Other topics discussed include: 

  • How threadsafe applications run more efficiently
  • What the Task Control Block (TCB) structure means to threadsafe applications and pitfalls to avoid
  • Implementation techniques to ensure you have the correct settings for optimum performance. 

Threadsafe implementations aren’t new to CICS; they’ve been around for several releases. Not all customers have taken advantage of this feature, however, for various reasons. Perhaps this article will provide incentive to move in that direction and highlight a few features of CICS that will ease the transition and make the effort much less time-consuming and complicated. 

Program Autoinstall 

The Program Autoinstall feature of CICS eliminates the requirement to define every program resource an application will need during execution. While the programs must be in a library in the DFHRPL concatenation, CICS can dynamically build the physical definition of that program when, and only when, it’s required. This eliminates the need to load hundreds or thousands of program definitions when CICS initializes and the need to define them in the CICS System Definition file (DFHCSD) when they may never be called. This dynamic definition of application programs can be a real asset when implementing the threadsafe feature and any region. For that reason, we’ve included here a short review of program autoinstall for customers who haven’t yet used it. 

PGAIPGM={INACTIVE|ACTIVE} is the System Initialization (SIT) parameter that activates the feature. The default is INACTIVE; customers must reassemble the SIT or override this parameter at start-up to ACTIVE so CICS can use the dynamic feature. When active, CICS first looks for a PROGRAM definition when a program is called. If the definition is found, it’s used. If no definition is found, one is dynamically created using the program attributes in the load module (i.e., program language, LINK attributes, etc.). For customers who want to ease into this feature, existing program definitions can be retained and used, and slowly removed to implement the dynamic creation. When programs are dynamically created, the message in Figure 1 is produced and written to the CICS log. This way, you know that program definition was dynamically created. 

The other option in this feature is the model used by CICS during the build process. In this example, the default DFHPGAPG would be used. CICS delivers the model in a group in the DFHLIST concatenation in every release of CICS. Why is this important when moving to threadsafe? The default value is QR (Quasirent), so all program definitions autoinstalled are built with a mode of QR. This can be changed and used to make the default mode TH (Threadsafe). Of course, before making the default TH, you must ensure that any application that uses this model is truly threadsafe. There are some pitfalls if proper research isn’t first done.  

So, where do you start? The IBM Redbook written in 2007 remains relevant and is probably the Rosetta Stone of CICS threadsafe topics and materials. You can download it at or find it as IBM publication CICS Threadsafe Considerations (SG24-6351). Also see the reference section at the end of this article for information about CICS Open Transaction Environment (OTE) and threadsafe topics. 

CICS Threadsafe and MQ 

Further incentives for customers who haven’t implemented threadsafe techniques came in CICS TS V3.2 with availability of this feature for applications using MQ. In the V3.2 documentation, IBM stated that exploiting OTE will benefit threadsafe applications using WebSphere MQ. IBM also noted that: “For multiple WebSphere MQ requests, TCB switching can be avoided, resulting in a saving of CPU and an increase in overall throughput because applications can now run on multiple, open TCBs and avoid bottlenecking.” 

3 Pages