Technical Blog Post
Did you ever wonder who owns shared storage in CICS?
Working in CICS level 2 support, we look at many different types of storage issues, SOS or short on storage issues being one of them. Looking at SOS conditions in CICS Transaction Server for z/OS (CICS TS) V5 has now gotten a bit easier. Many times short on storage conditions are caused by a build up of 'shared' storage. This is storage getmained by the application, where they specify the 'shared' option on the request.
This shared storage is not automatically freed when the task terminates, allowing it to be shared between different tasks. It must be explicitly freemained by some task, otherwise it will stay allocated until the CICS region is recycled. If applications are behaving badly, not freemaining this storage, it can lead to a SOS (DFHSM0131 or DFHSM0133) condition in CICS. In the past, all we could do is look at the allocated shared storage and hope the application could recognize the data, in hopes they could identify the transaction or task it was associated with. Now in CICS TS V5, serviceability has been added that allows us to identify the following information about shared storage:
1- the time of the GETMAIN
2- the transaction number of the task doing the getmain
3- the transaction ID of the task requesting this storage.
This information can be located in the Storage Element descriptor or SCE starting at offset x'20.
Here is an example of an SCE from shared subpool SMSSHARED from a dump:
The storage was getmained at STCK CEFBCC4E91329CB5 which converted is 05/22/2015 14:29:17.027113 STCK by task number 58, and transaction CSSY.
This new information will definitely help when debugging short on storage conditions.
To learn more about CICS storage and changes to V5, see the replay of the presentation that Erich Hoppe and I presented on CICS Storage 101 - a look into CICS Dynamic Storage Areas - updated for CICS TS V5.