DFHSM0143 MVS above the bar storage for CICS critically low

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.