IBM Support

DFHSM0143 MVS above the bar storage for CICS critically low

Question & Answer


Question

Why can't CICS get more storage above the bar after an upgrade to CICS Transaction Server for z/OS (CICS TS) V5.2? The GDSA can't get another extent allocated above the initial 1Gig for the GUDSA even though 6Gig is specified in MEMLIMIT.

I see the following message in the CICS log:

DFHSM0143 THE AMOUNT OF MVS ABOVE THE BAR STORAGE AVAILABLE TO CICS IS STILL CRITICALLY LOW.

Reviewing a dump taken at the time of the DFHSM0143, the CICS storage manager (SM) domain (VERBX DFHPD690 'SM=1) shows that CICS has only used one gigabyte:

 -----------------------------------------------------------------------
    Current GDSA limit:                   6144M
 
    Current GDSA total:                   1023M
 
    Current GDSA allocated:               1024M
 
    Hwm GDSA allocated:                   1024M
 
    Currently SOS above 2G:                 YES
 
    MEMLIMIT:                             6144M
 
    MEMLIMIT Source:                   JCL
 
 
 ==S2: GCDSA Summary
 
    Current Size:                  1024M
 
    Active Size :                    15M
 
    Current free space:            1009M
 
    Currently SOS:                    NO
 
    Access:                         CICS
 
    Number of extents:                 1
 
 
 ==S2: GUDSA Summary
 
    Current Size:                     0M
 
  * Times request suspended:           1
 
    Current suspended:                 1
 
  * Hwm suspended:                     1
 
    Currently SOS:                   YES
 
  * Times went SOS:                    1
 
    Access:                         USER
 
    Number of extents:                 0
 
 -----------------------------------------------------------------------

An MVS inquiry into storage above the bar indicates storage is available.

Answer

Section Estimating, checking, and setting MEMLIMIT in the CICS TS V5.2 documentation states the need for an entire 6Gig to be available to CICS:

CICS requires a MEMLIMIT value of 6 GB; any additional use by applications or JVMs should be allowed for with a larger value of MEMLIMIT.

In addition to this statement, you need to understand the concept of guarded (or hidden) storage. And, you need to understand that CICS views guarded storage differently than MVS.

MVS (z/OS) allows a request for contiguous storage addresses without actually making all of those addresses active. For example, a program might need 10Meg total but only needs 1meg of storage at the moment. But, if it needs more in the future, it wants the address range to be contiguous (in the same address range) with the storage it already has. So, it makes a request to MVS for 1Meg of active storage and 9Meg of guarded storage. MVS returns the 1Meg of storage and blocks off the next 9Meg for future use. At this point, MVS only considers 1Meg of storage as having been acquired. The other 9Meg are "guarded" or "hidden" against use by any other program.

CICS is able to determine how much above the bar storage has been requested in its address space. Unlike MVS, CICS takes into consideration what would happen if the "guarded" segments were made useable. In the above example, CICS would consider all 10Meg to be used. CICS then does its own calculations of all storage, active and guarded, against MEMLIMIT. If the total of storage is less than 1Gig, CICS does not make the request for storage. Instead, it marks the task in a GUDSA wait and returns message DFHSM0143.

NOTE: At the time this answer was provided, CICS TS V5.1 does not return message DFHSM0143 but higher releases do return DFHSM0143.

Using the system dump, above the bar storage can be seen with the IPCS command:

     RSMDATA HIGHVIRT ASID(x'xxxx')

where xxxx is the address space of the CICS region.

The "Requestor" column shows an address that can be equated with the module that made the request. If the storage isn't in the dump, use IPCS command:

     IP WHERE zzzzzzzz

where zzzzzzzz is the address of the requestor. It should provide the name of the module at that location.

The RSM data shows that CICS had 2Gig of storage.

  • 1Gig for GCDSA storage as be seen in the SM domain.

  • 1Gig for its internal trace table that is not shown in the SM domain.

Then, there was a pattern of three pieces of storage repeated 68 times related to LE module CELSLMOD. This is for 68 of the 70 threads defined to LE for this environment. The three pieces of storage added up to about 37Meg.

Also, there is other storage requested by LE and JVM (JAVA). The total of active and guarded storage added up to over 3Gig. Adding those to the 2Gig already in use by CICS, that came to over 5Gig already in use. That means that there was less that 1Gig left in above the bar storage.

CICS always requests above the bar storage in 1Gig segments. CICS determines that there is not enough room within the 6Gig MEMLIMIT. It returns message DFHSM0143 instead of making the request to z/OS for the storage.

In conclusion, the current design of CICS requires at least 6Gig of storage for its own use. All other storage needs must be added onto that amount, including all storage guarded by other products.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Platform":[{"code":"PF035","label":"z\/OS"}],"Component":"Storage","Version":"5.2"}]

Product Synonym

CICS/TS CICSTS CICS TS CICS Transaction Server

Document Information

Modified date:
11 March 2016

UID

dwa1257042