IBM Support

DFHSM0102 - Tips for diagnosing storage violations in CICS

Technical Blog Post


Abstract

DFHSM0102 - Tips for diagnosing storage violations in CICS

Body

Whether your a novice or have been working with CICS for 40+ years, you will eventually encounter a storage violation in your CICS environment. A storage violation can be caused by a one byte overlay or a massive multiple page overlay that can lead to your region crashing. The massive overlays can lead to a number of different abends in CICS but the most common storage violation is identified by a DFHSM0102:

DFHSM0102 applid A storage violation (code X'code') has been detected by module modname.


In the DFHSM0102 message, a X'code' (X'0D11', X'0F0C', X'030B') is provided that corresponds to a trace entry in the CICS trace table. This trace entry will provide some valuable information as to where this storage overlay is occurring (I will discuss this a bit later). CICS continues unless you specify in the dump table that CICS should terminate.


Receiving the DFHSM0102 dump indicates the Storage Accounting Area (SAA), also referred to as Storage Check Zones (SCZ), in CICS has been altered. The SAA is an X'8' byte delimiter that is added on each piece of transaction storage at the beginning and the end during the getmain request and it includes notations that indicate the type of storage (CICS/USER, ABOVE/BELOW the line storage) along with what task number owns this storage.

Example of SAA (SCZ):
A00NNNNN (A = Type of Storage, N = Transaction Number)


Usually the overlay is not detected until task termination during the freemaining of transaction storage.


Once you receive the storage violation dump you can attempt to identify who is possibly overlaying the storage. Initially you will need to obtain the X'code' given in the DFHSM0102 dump and locate this trace entry in the CICS trace with IPCS command VERBX DFHPDnnn 'TR=2', where nnn is the version of CICS you are running. All 3 possible X'code' values will provide you with basically the same information, but there is some specific information provided with each, so you should locate the X'code' entry in the Storage manager domain trace points section of the CICS Trace Entries documentation.  The trace entry will provide you with an address as well as a certain number of bytes that include the leading and trailing Storage Check Zone areas (remember if you are receiving the DFHSM0102, some portion of the SCZ has been altered). 


With the address from the trace entry, you can verify the length of the piece of storage in question and determine the task that owns the storage. First use IPCS command VERBX DFHPDnnn 'SM=3' to display the storage manager (SM) domain then search for the address within the SM domain. The address should be located in a Storage Element Descriptor (SCE).  Below is an example of an SCE:

SCE.M0099999 XXXXXXXX Storage Element Descriptor
0000  00000050 4084D440 00000050 4081B620  00047000 00000470


The 5th word will be your address and the 6th word will be the length of the storage. Double check to ensure the task number in the SCE matches the task number running in trace at the time of dump.


Now with the address and length of the piece of storage in question, go take a look at the storage in BROWSE mode by entering an =1 on the command line (or go to option 1 from the IPCS PRIMARY OPTION MENU). This will display the following panel:

--------------------------------------------------- IPCS - ENTRY PANEL ---------------------------
Command ==>

CURRENT DEFAULTS:
Source ==> DSNAME('EXAMPLE.XXX.XXXXX.XXX.SVC.DUMP')
Address space ==> ASID(X'02FC')

OVERRIDE DEFAULTS:
Source ==> DSNAME('EXAMPLE.XXX.XXXXX.XXX.SVC.DUMP')
Address space ==>
Password ==>

POINTER:
Address ==> <------ Enter address Here
Remark ==>


Verify that the ASID displayed matches the ASID of the CICS region for the dump. At the POINTER address, paste the address from the trace entry and press enter. Once here, verify the Storage Check Zones are intact, keeping in mind they are X'8' bytes in length at the beginning and end of the piece of storage in question. In our example SCE above, the SCZ should be M0099999. Once you identify which SCZ has been overlaid, if the overlay appears to be application data, please contact your application team to find out if they are able to identify what transaction or application owns the data. If you are unable to identify the storage at this point, you will need to activate the the Storage Violation Trap. This trap can be activated in two ways:

  • Code CHKSTSK=CURRENT in your System Initialization Table (SIT)
  • Enter CSFE DEBUG,CHKSTSK=CURRENT from a CICS terminal

Ensure all trace components are set to standard level 1 except for EI and AP which should be set to 1-2. Your trace table should be at least 6M. Once the trap springs you will receive a DFHSM0103 dump:

DFHSM0103 applid A storage violation (code X'code') has been detected by the storage violation trap. Trap is now inactive.

The trap will be deactivated after the dump is taken.


To assist in debugging the DFHSM0103 dump, you can take a look at the Debugging Storage Violations in CICS Support Technical Exchange Webcast.

Whether you are a novice or been working with the product for 40+ years, at some point you will likely have to rely on IBM CICS support to assist in resolving certain problems. Section Collecting CICS troubleshooting data (CICS MustGather) for IBM Support in the CICS documentation provides guidance on what diagnostic data support will need, including the diagnostic data for storage violation problems.

[{"Business Unit":{"code":"BU011","label":"Systems - zSystems"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","Platform":[{"code":"PF035","label":"z/OS"}],"Version":"5.2;5.3;5.4;5.5","Edition":""}]

UID

ibm11080759