CICS (SOS -short on storage above 16MB)

cvishu · Active User Joined: 31 Jul 2007 Posts: 136 Location: india

Hi ,

I have a CICS transaction yyyy in region A ( this a Webservice related transaction) . The related application program has a remote entry in region A and local entry in region B.

The prgram in region B acts as a router and LINKS to many child programs depending on the type of webservice request.

Now i am facing SOS abend for this transaction quite often. I know one alternative would be to increase the EDSA , but is there any reason why this transaction is causing the issue.

The abend is not persistent, it happens in Dev region but not in Producton or QA so am not sure if application is causing the issue .

Will having a single transaction and linking to many child be a root cause ? If any one is aware of similar issue , please let me know your views.

Robert Sample · Posted: Mon May 21, 2012 2:44 pm

The S-O-S may be happening in test but not QA or production because the test region has a smaller EDSA size. You need to raise this as an issue to your site CICS support person/group since if the EDSA size is the same across all regions, your transaction could have a problem once moved into production. Furthermore, they (hopefully) have tools to look at the region to see how much memory each transaction is using and so forth.

And you can be sure some application -- yours or another -- is causing the S-O-S situation; CICS does not randomly generate those messages; they only appear when application transactions are eating up all the memory.

suyogbhatkhalkar · New User Joined: 27 Sep 2005 Posts: 3

The SOS may arise due to task in waiting condition. Check how many concurrent task are waiting (queued up) when you hit the webservice related transaction. You may have to change T class to run more concurrent task for the transaction.

Bill O'Boyle · Posted: Thu Jun 28, 2012 7:05 pm

When a program is accessed via a LINK-API (an Enclave Level), GETMAIN storage is acquired internally for WS upon program entry and FREEMAINed after program exit by LE. But, if within these program's, explicitly large GETMAIN's are issued and are not explicitly FREEMAINed, there is a possibility that you could go SOS, especially if there are several of these behemoths running concurrently. The general rule I've seen over the years is this; If you've explicitly acquired storage via a GETMAIN in a given program and upon program exit, you're not retuning to CICS Logical Level 0, then issue a FREEMAIN. You can't go wrong with this approach.

But as Robert has said, allocated EDSA in the SIT could play a big part.

Do you have a 3rd-Party Monitor, such as TMON for CICS?

Reviewing a TRACE may shed some light on this as well. You'll then be able to see the gyrations that CICS goes through and will be worth your while.