CICS / WebSphere

This series is intended to help new CICS support people understand the basics of the product and how it has evolved. It covers basic concepts, underlying components that may not be intuitively obvious, and daily support issues. For more information about this article series and a list of what readers should already know, see the first article at

In the early years of CICS, most of the resources any region used were produced by coding a table. These tables contained resources the region required to run system functions and application programs. Some resources were programs, some transactions, some journals for recovery, etc. The tables were coded so the source could be assembled and made into an executable load module. The load module produced wasn’t a program such as one created from COBOL source; it was a specially constructed module with a specific name CICS could recognize when required.

Since only CICS used these, the module name had the standard prefix (DFH) followed by the resource category (such as PPT for programs) and a suffix that was unique so customers could create multiple copies. For example, there could be a DFHPPTFI for the CICS region that ran financial applications and a DFHPPTWH for the CICS region that ran warehouse applications. The main table was the System Initialization Table (SIT), which was used at CICS start-up and contained most of the system parameters for the region. Figure 1 shows the format for a typical SIT. The suffix would be used to load the parameters at start-up. A complete explanation of the SIT and its contents appears in the first article in this series. IBM provides some basic table examples in a library called DFHSAMP.


Why Tables Had to Go
While table support lasted many years, it became one of the biggest limitations to online availability and 24x7 processing requirements. The contents of tables are only loaded at CICS start-up, so any changes require a recycle of the region. Many installations now only recycle their regions after weeks or months. Something had to change. The Terminal Control Table (TCT) became unmanageable since networks were growing and reassembling this table, and recycling the regions wasn’t feasible.

IBM responded by introducing Resource Definition Online (RDO). Each new release of CICS delivered additional resources that could be defined and maintained via this facility. The first delivery was for programs since they were the most prolific resource to most customers. Defining programs every time a new application was introduced was time-consuming and cumbersome. Moreover, most test or development regions had frequent changes so reassembling these resources and recycling the regions was a maintenance burden. IBM has done an amazing job of delivering RDO and removing tables from CICS support.

Resources defined via RDO are stored in a CICS file called the CICS System Definition (DFHCSD). Each region can have its own DFHCSD, but regions usually share the file since resources can be defined in the file but not used by all regions. It makes the maintenance process more efficient and flexible. When CICS initializes, it reads whatever tables are still specified to the region and then reads from the DFHCSD for groups that were identified in the DFHSIT as necessary for this region. One region can specify whatever groups it needs; other regions can use others. The groups that are loaded are specified via the DFHSIT parameter, GRPLIST. In most cases, customers use more than one list to customize the resources any region uses. For example, the following GRPLIST parameter could be specified:

This would cause CICS to first load the groups in list DFHLIST, which are the defaults for all CICS regions. It would then load all the groups in REGXLIST and the resources contained within. There can be a concatenation of four lists in this parameter so customers can use lists common to all regions and unique to a specific environment. Once the region is up and running, CICS doesn’t re-read the DFHCSD unless told to do so by specific commands. These commands can “install” new or changed resources, which are loaded out of the DFHCSD for this region. For a complete explanation of the CEDA, CEDB, and CEDC transactions, refer to the Resource Definition Guide in the CICS library.

DFHRPL and Maintenance Issues
One of the other limitations to continuous processing was the content of load libraries in the DFHRPL (the libraries from where the application programs are loaded). The concatenation of this resource is critical. When CICS receives a request to load a program, it starts at the top of the concatenation and continues down the chain until it finds a module that matches the name. If there are multiple modules in the concatenation with the same name, CICS never uses the second, it always uses “first hit.” So, if an application programmer re-creates a new load module in a lower library, it will never get used.

In addition, the concatenation of DFHRPL is loaded at CICS start-up and can’t be changed. No new libraries can be added; no libraries can be removed. Changes to the list can only be done when the region is recycled. In recent releases, however, IBM has delivered the definition and maintenance of DFHRPL via RDO. While the coding of the DFHRPL libraries can be put into CICS at start-up, it can also be supplemented via an RDO group for that region. This group can contain multiple libraries and be modified while CICS is up. This is accomplished via the RDO LIBRARY definition, which can deliver more flexibility to the DFHRPL concatenation. If you haven’t looked into using this resource, especially in a development environment that requires many changes to the application libraries, refer to the Resource Definition Guide of the release you’re running for a complete explanation of this facility.

Automatic Installation of Resources or Auto-Install
As previously covered, most resources in CICS were originally defined via tables that were moved to RDO for more flexibility. The first implementation in that progression were terminal resources. Even if terminals could be defined via RDO, there were still thousands of devices that would have to be defined that way. This was a huge limitation to availability. Even back in the ’90s, the resource that required the most maintenance were terminals. There may be hundreds of programs and transactions, but they didn’t come close to the thousands of terminals and the way networks grew regularly.

CICS Virtual Storage (VS) V1.R7 provided the ability to auto-install any device that requested access to CICS. Since the device (at that time) had to be defined in Virtual Telecommunications Access Method (VTAM) and therefore passed the request to CICS, it passed the terminal id, terminal type, and other characteristics to CICS at the time of connection. CICS was then able to read the control block and extract the necessary information to build the terminal definition within CICS. This was done (and still is) via multiple “models” stored in CICS that attempted to match the characteristics VTAM delivered with the characteristics stored in the model definitions to produce a proper terminal control block (TCTTE). No unique definition for each terminal was required in CICS, and the terminal definition was built and connectivity was produced for each device.

The result was phenomenal. Terminal definitions were built as the device requested connectivity, and the control blocks and associated storage were deleted and freed when the terminal signed off. This was an availability advantage and saved tons of storage because the definition didn’t remain in the region since it may not be needed again. This greatly improved network support. Customers flocked to CICS VS V1.R7 just to take advantage of this major breakthrough.

The next enhancement to auto-install came shortly after terminals with the delivery of programs. This was probably the other most widely accepted resource to be auto-installed. So many programs in CICS have the same characteristics. They’re probably COBOL and follow the Application Programming Interface (API) standards for command-level CICS. These programs must be compiled using the CICS translator and then have the “stub” for all CICS programs inserted into the load module. When CICS is called to execute any program, the Loader Domain finds the module in DFHRPL and detects the characteristics before passing control. The characteristics would be the language, link-edit attributes (24-bit or 31-bit), size, etc. Since the Loader Domain can detect these characteristics, there really doesn’t need to be a program definition since CICS can determine most of them itself. The removal of program definitions was a huge leap and made CICS maintenance much easier.

CICS continues to evolve and become more efficient. The basic core principles remain that made CICS the most popular transaction processing software in the industry, and new features in every release help customers with daily support.