CICS subpool LDEPGMRO in the ERDSA getting full

maschina · Posted: Wed Mar 06, 2013 8:56 pm

Dear specialists,

every time specific program in region was executed, storage used for LDEPGMRO subpool has increased. This leads to SOS when amount of transactions processed by CICS has doubled. Might this be caused by program definition within the CICS or the way this program was written? I can see there are only getmain requests and no freemain.

Thanks for your help.

Bill O'Boyle · Posted: Wed Mar 06, 2013 9:20 pm

Maschina,

Do any of the programs issue a GETMAIN SHARED? If they do, an explicit FREEMAIN is mandatory. This could be a potential issue if the task abends. Non-Shared GETMAIN's will be implicitly FREEMAIN'ed at task termination, regardless. Otherwise, non-FREEMAIN'ed SHARED storage becomes orphaned (and not deallocated).

I'm not big fan of GETMAIN SHARED, specifically for the potential for the storage to be orphaned.

A region-recycle is the only way I'm aware of to recoup this orphaned storage.

Welcome to the Forum....

Robert Sample · Posted: Wed Mar 06, 2013 9:25 pm

Is this a new program or recently changed program?
Did the SOS just start or has it been going on a while and somebody decided finally to do something about it?
Is the program unusually large -- perhaps it has internal tables that increased the size of the load module?
LDEPGMRO contains 31-bit application programs, so the CICS support person at your site would want to start by looking at the program definition (compared to similar programs, especially) as well as what the program is doing as either one could be causing the issue.

Jose Mateo · Posted: Fri Mar 08, 2013 8:06 pm

Good day to all!
Maschina, you are getting the SOS condition because there's a contention for dynamic storage due to as you mentioned that the transaction load has double in your CICS region. Two things could be done and that is decrease the MXT (maximum concurrent tasks) parameter plus if its possible increase the EDSALIM parameter.

maschina · Posted: Fri Mar 15, 2013 6:34 pm

Thanks to all for your help.

Bill O'Boyle :
While checking the trace in Omegamon I did not noticed any GETMAIN SHARED, but I will search, thanks for input.

Robert Sample:
This is old program used for a long time and nobody decided to do anything, just me because I take care about CICS region and it annoys me to solve SOS cause by these programs ;-) program is small.. but every run takes a little bit of memory.

Jose Mateo:
Transactions are not running concurently. Transaction load has doubled, but still - if you check currently executing, there is usually nothing. For this reason I do not see the point to increase EDSALIM because storage is taken by tasks that have finished already, just left orphaned storage probably.

I am just collecting as much info I can to send it to developers of the application to tune the programs. It does not cause any issues during normal processing (EDSALIM is high enough) just when transaction load increase (beginning of month, quater or whenever it is used). When I monitor EDSA during the day, in the evening I can see most of it is taken already.. but CICS service hours are only 7-18h30 so before it can cause any issues, it's stopped.