Joined: 06 Jun 2008 Posts: 8231 Location: Dubuque, Iowa, USA
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.
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.
Joined: 14 Jan 2008 Posts: 2504 Location: Atlanta, Georgia, USA
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.