This series of articles is intended to help new CICS support people understand the basics of the product, and how it has evolved into the strong, robust software it is. It’s intended to help with basic concepts, underlying components that may not be intuitively obvious, and daily issues that may help everyone support the product. It targets an audience of people who come from distributed systems (UNIX, etc.), recent college graduates with no (or limited) z/OS experience, and applications developers moving into the systems arena.
For a complete explanation of what these articles will contain, and a list of basic prerequisites that are assumed the reader already possesses, go to the first article in the series: www.mainframezone.com/it-management/cics-101-the-starting-pointcics-initialization.
Debugging is a way of life in CICS. As long as developers upgrade and install new applications, there will be issues that arise, and it’s almost always the responsibility of the CICS systems programmer to address them. Let’s take a look at the evolution of CICS and the useful documentation and resources available to simplify debugging.
The Early Years
During the early years of CICS, the product was shipped and maintained as source code. Customers would literally reassemble the components when they installed or applied maintenance. This presented numerous problems since customers could (and did) modify the product to suit their needs. It also presented many challenges for IBM, since when problems were reported, there was no guarantee the base product code was at fault if modified.
CICS became Object Code Only (OCO). Customers could no longer modify the base code; any customization had to be done within exit points that restricted what could be modified. That helped minimize outages to CICS and simplify debugging. IBM later changed the architecture of the CICS components to run in their own areas, called Dynamic Storage Areas (DSAs). CICS modules ran in CICS key in their own areas, and user code (application programs) ran in USER key. CICS key storage couldn’t be modified by any program running in USER key. It created a much more stable environment since application programs couldn’t corrupt CICS modules, which usually bring down the whole region. USER programs can inadvertently modify other USER storage, but that usually corrupts the transaction, not CICS.
Transaction Problems vs. System Problems
As explained earlier, application programs no longer have access to CICS storage. When they experience problems, they usually produce a dump and abnormally end the executing task. The region goes on, however, and since any region can be running many tasks in a short time, the other tasks usually aren’t affected by these failures. If the problem shows up in a test or development region, this is often considered normal and a part of the development process. While testing, a programmer may experience failures, which are therefore diagnosed and the application program is modified to avoid future failures.
Many customers have purchased vendor products that capture these dumps, import them, and produce reports that help analyze the problem. If your installation doesn’t have one of these tools, IBM provides a basic utility that will process the transaction dump. Go to the CICS Website for publications at http://www-01.ibm.com/software/htp/cics/library/ and choose the release you’re running. Find the CICS Operations and Utilities Guide; it contains documentation for DFHDUnnn, the CICS Dump Utility Program where nnn is the version/release you’re running. The Job Control Language (JCL) for the utility is well-documented. You will need to run it against whatever DFHDMPA or DFHDMPB data sets are active in that region and you can view the contents. There’s also a facility to “suppress” any irrelevant transaction dumps. There’s an option in all CICS regions to create a Transaction Dump (TRD) code table. This table can suppress many transaction dumps from DFHDMPA or DFHDMPB when they won’t be analyzed anyway. A sample table entry for transaction dumps is:
Trd(ASRA) Tra Loc Max( 020 ) Cur(0002)
The abend ASRA is set with the option to allow the transaction dump, but since the next option SYD is set to NOSYS and therefore appears blank, no system dumps will be allowed. If you don’t want a transaction dump to be taken, use the option NOTRAN and the transaction dump will be suppressed. You can choose to take a system dump for a transaction abend, but most installations don’t. The CICS Operations and Utilities Guide further explains these.
System problems are more difficult to diagnose since they involve the whole CICS system. These can still be caused by an application program, but only in small cases. They don’t write the dump to DFHDMPA or DFHDMPB, but to a z/OS system dump that the z/OS systems programmer has set up. The common target for these dumps is to SYS1.DUMP.xxx or whatever the z/OS systems programmer has set up. In most cases, since they usually can take up large quantities of storage, a routine is created to archive them as quickly as possible. Talk to your z/OS systems programmer to find out where these are stored and named. These dumps can also be suppressed, since in many test or development regions, the dump isn’t analyzed. Here’s an example message indicating a suppressed system dump:
