IBM Support

DFHSM0133 Short On Storage in SMSHRC31 under CICSPlex SM

Technote (troubleshooting)


A CICSPlex SM (CPSM) address space (CMAS) goes short on storage (SOS) because it uses too much SMSHRC31 storage. This results in various types of messages including DFHSM0133, EYUPN0005W, EYUPN0005W, and EYUCL0117E.


DFHSM0133 CICS is under stress (short on storage above 16MB).
EYUPN0005W Notify created for SAM, Sev=VHS, Event=!!SAMSTL, Text=IRLINK STALLED
EYUPN0005W Notify created for SAM, Sev=HW, Event=!!SAMTDM, Text=ID=AICA
EYUCL0117E Insufficient ECDSA storage to expand link buffer pool


Loss of communications to another CMAS

Diagnosing the problem

CPSM stores the Method Argument List (MAL) control block and its associated data in the SMSHRC31 subpool. When you lose communication to another CMAS, the local CMAS still makes requests to send MALs to it. Large numbers of MALs cause the problem. They must wait for CICS to recover communication.

You need to determine who the partner is and recover communication to it. When you start communications to the other CMAS, the local CMAS removes them from the queue and storage.

MRO does not post a SEND until the data is completely transferred to the partner. Until then, control shows on the other side. To see if this is the case, check the MRO session's TCTTE for the TCTEIRCO bit. If this bit is on, it means that the local CMAS requested the send of the data. But the send is not yet complete. You need a dump of the other CMAS to determine why the data is not completely sent.

Resolving the problem

Re-establish communication to the other CMAS.

Product Alias/Synonym


Document information

More support for: CICSPlex SM

Software version: 3.1, 3.2, 4.1, 4.2, 5.1

Operating system(s): z/OS

Reference #: 1178847

Modified date: 25 September 2013

Translate this page: