Analyzing short-on-storage conditions

Analysis of short-on-storage (SOS) problems begins by obtaining a dump when the system is in an SOS condition.

About this task

Short-on-storage conditions might occur for the following reasons. Perform this task to analyze short-on-storage conditions.
  1. Other resource constraints that cause CICS tasks to occupy storage for longer than is normally necessary
  2. A flood of tasks that overwhelms available free storage
  3. Badly designed applications that require unreasonably large amounts of storage

Procedure

  1. Set an entry in the dump table to produce a dump when message DFHSM0131, DFHSM0133, or DFHSM0606 is issued.
    For example, to produce a dump the first time message DFHSM0131 is issued, use the following command:
    CEMT SET SYDUMPCODE(SM0131) SYSDUMP MAXIMUM(1) ADD
  2. When you obtain the dump, enter the following IPCS commands:
    1. Use the IPCS command VERBX CICS710 'SM=3' to format the SM control blocks.
    2. Use the IPCS command VERBX CICS710 'LD=3' to format the LD control blocks.
  3. Run DFH0STAT just before the statistics interval completes.
    For example, if the statistics interval is 1 hour, run DFH0STAT at 59 minutes. DFH0STAT provides useful information in the storage summary without a breakdown by subpool. See The sample statistics program, DFH0STAT for more information.
  4. In the information that you have collected, examine the DSA summaries, noting which DSAs are short on storage and the amount of free space in the other DSAs.
    The amount of free space is given for each extent for each DSA. Frequently, either the UDSA or the CDSA is short on storage but there is a large amount of free storage in the SDSA.
    Also, look for evidence of large amounts of redundant program storage (RPS), which can cause a short-on-storage condition. Redundant program storage can be identified in the domain subpool summary and the loader domain summary.

Example

The dump extracts in this example are from a situation where the UDSA is short on storage.

Storage extents in 24-bit storage (below the line) are always allocated in multiples of 256 KB, except for the UDSA. If transaction isolation is active, the extent size for the UDSA is 1 MB, and each UDSA extent must be aligned on a megabyte boundary. If translation isolation is not active, the allocation is in 256 KB extents. You must allow for some fragmentation between the 256 KB extents of the CDSA, RDSA, and SDSA, compared with the 1 MB extents of the UDSA.

Storage extents in 31-bit storage (above the line) are allocated in multiples of 1 MB.

Storage extents in 64-bit storage (above the bar) are allocated in multiples of 2 GB.

Each extent has an associated page pool extent (PPX) and page allocation map (PAM).

Examination of the SDSA extents shows several extents with large amounts of free space. For example, the extent beginning at 00700000 running through 0073FFFF has only 4 KB allocated and 252 KB free. 
Extent list:      Start      End          Size     Free
                  00700000   0073FFFF     256K     252K
The DSA extent summary shows that the PPX for the extent at 00700000 is found at 09F0A100, and the associated PAM is found at 09F0A150. Examination of the PAM shows that only one page is allocated, and it belongs to the subpool with an ID of X'7A'. 
  Start      End          Size   PPX_addr   Acc     DSA
  00700000   0073FFFF     256K   09F0A100    C     SDSA
 
  PPX.SDSA 09F0A100 Pagepool Extent Control Area
 
     0000  00506EC4 C6C8E2D4 D7D7E740 40404040  *.&>DFHSMPPX     *
     0010  E2C4E2C1 40404040 09A1BA68 071B3EA0  *SDSA    ........*
     0020  00040000 00700000 0073FFFF 071B5EE0  *................*
     0030  00000000 09F0A150 00000040 0710A268  *.....0.&;.. ..s.*
     0040  0003F000 00000000 00000000 00000000  *..0.............*
 
  PAM.SDSA 09F0A150 Page Allocation Map
 
     0000  00000000 00000000 00000000 00000000  *................*
     0010 -    002F LINES SAME AS PREVIOUS
     0030  00000000 0000007A 00000000 00000000  *................*
The domain subpool summary determines, for the SDSA, which subpool is associated with the ID of X'7A'. In this dump, 7A is the ID for subpool ZCTCTUA. Do not rely on the IDs being the same for multiple runs of CICS®, because the IDs are assigned in the order in which the ADD_SUBPOOL is issued. 
  ==SM: UDSA Summary (first part only)
 
     Size:                             512K
     Cushion size:                      64K
     Current free space:                56K  (10%)
   * Lwm free space:                    12K  ( 2%)
   * Hwm free space:                   276K  (53%)
     Largest free area:                 56K
   * Times nostg returned:                0
   * Times request suspended:             0
     Current suspended:                   0
   * Hwm suspended:                       0
   * Times cushion released:              1
     Currently SOS:                     YES
 
  ==SM: SDSA Summary (first part only)
 
     Size:                            4352K
     Cushion size:                      64K
     Current free space:              2396K  (55%)
   * Lwm free space:                   760K  (17%)
   * Hwm free space:                  2396K  (55%)
     Largest free area:                252K
   * Times nostg returned:                0
   * Times request suspended:             0
     Current suspended:                   0
   * Hwm suspended:                       0
   * Times cushion released:              0
     Currently SOS:                      NO

What to do next

  1. Review the storage limits for your CICS system. See Setting the limits for CICS storage.
  2. For an SOS condition in 24-bit storage, determine whether the DSALIM parameter is set as large as possible. See Estimating, checking, and setting DSALIM.
  3. For an SOS condition in 31-bit storage, determine whether the EDSALIM parameter is set as large as possible. See Estimating, checking, and setting EDSALIM.
  4. For an SOS condition in 64-bit storage, determine whether the z/OS MEMLIMIT parameter is set to an appropriate value. See Estimating, checking, and setting MEMLIMIT.
  5. Review the use of options such as the maximum task specification (MXT parameter) and defining programs as resident, to keep down the overall storage requirement. Changing these settings might limit task throughput. You can also reduce a storage constraint below 16 MB by using programs that run above 16 MB. In addition, using the LPA reduces the amount of storage used in LDNUCRO by approximately 100 KB.
  6. Consider the tuning possibilities of z/OS and other tuning possibilities outside CICS. Also consider ways of dividing your CICS region.
  7. Consider enabling the CICS self-tuning mechanism, or fixing the size of one or more individual DSAs by using the appropriate SIT overrides. For instructions, see Fixing short-on-storage conditions caused by subpool storage fragmentation.