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 http://esmpubs.com/q1hhi. To read the most recent article in this series, go to http://esmpubs.com/5syv6.

Early CICS users were required to edit a macro definition for CICS resources (such as files, transactions, programs, etc.) and then reassemble the macro into a load module. A load library in the CICS region Job Control Language (JCL) made this module available to each region. The contents of the macro definition were loaded in their entirety at start-up, whether or not the resource was used. This made terminal control tedious and resource-intensive in each region. When CICS went Object Code Only (OCO), macros were no longer supported and a more user-friendly, less resource-consuming facility gradually replaced these tables. The introduction of Resource Definition Online (RDO) gave customers a facility to define, alter and delete resources to any CICS region via transactions that controlled this process. These transactions—CEDA, CEDB and CEDC—let customers have online access to any resource; they could be dynamically manipulated while the region was still running. Since CICS was being increasingly pressured to be available continuously, customers needed a facility that wouldn’t require regions to be recycled to load new definitions. These transactions fulfilled that requirement.

CEDA, CEDB and CEDC
These transactions provide similar access to the resource definitions, but only CEDA and CEDB can alter the definitions. They provide the ability to define, alter or delete any definition. For that reason, most installations secure these transactions so only CICS systems programmers have access to them. Some installations give developers access to them but only in development or test environments; most don’t allow production access. 

CEDC allows access to any definition, but only to view the contents. This can be extremely helpful, as it would give you the list of definitions in a group or a list of groups in a list. Since the DFHSIT GRPLIST concatenation can contain as many as four lists, you may be curious as to the contents of each list. CEDC lets you expand any group and access the contents of the definitions. CEDC generally isn’t given any security designation since it’s strictly view access and can’t make changes. 

These transactions all define resources, but the resources must be added to a group; in fact, when the resources are defined, they must have a group name in the define process. After the definition is added to a group, that group must be in the list of groups for the list that’s in the GRPLIST concatenation or the definition won’t be available to the region. This lets you have a different GRPLIST concatenation for any region so the definitions are (or aren’t) available. 

The GRPLIST concatenation is usually in the form:

GRPLIST=(DFHLIST, COMMLIST, REGLIST)
There can be a fourth parameter in the concatenation, if necessary. The first item must be DFHLIST since it contains the required IBM definitions that must be available to all regions. Most installations then have a common list that would be used for all regions. This list could include, for example, groups that contain installation utilities and vendor products that all regions use. This is handy; you can make a change to any group in this list or add a group to this list and it’s available to all regions. These changes don’t get loaded until the region is recycled, but if needed immediately, the resource or the entire group can be installed into any region that loads it for immediate access. 

The third list, REGLIST, would be the list of groups unique to this region. In this way, each region can have its own resources and definitions that aren’t shared with other regions. Many definitions may be shared; there may be only a few unique definitions. These definitions could be stored in a single group, so the only difference would be this single group in REGLIST that isn’t in any other lists.

DFHCSD
While in the past all the macro tables were assembled and stored in a library, all RDO definitions are stored in the DFHCSD (CICS system definition) file. This file is shipped with each release; it will contain DFHLIST. There may be new transactions and other definitions with each release, so be sure to use the most current one. 

This file lets you create groups and lists for each region, sharing the same DFHCSD but having potentially different contents. It’s usually best to share a single DFHCSD, if possible, since multiple ones require more effort to keep them synchronized. For example, if you have a COMMLIST for all definitions common to all regions, you would need to update this list in every DFHCSD when changes are made. If you share a DFHCSD, a single update to that list would be reflected in each region. In the previous example, REGLIST would be in a common DFHCSD but there may be a different REGLIST; perhaps a PAYLIST or a CICALIST for different regions. If the region’s list contains the region name in some form, it makes it easier to identify which list is used by which region. 

2 Pages