2 answers

Hi @Ravi_sri,To answer your last question about CICS storage allocation. A little information first, as you may know, CICS manages the above the line dynamic storage area (DSA) in allocations of 1M extents. Within each EDSA, CICS manages the extents at a page size allocation. When talking about the RUWAPOOL, this belongs to the EUDSA, which has a page size of x'10000' bytes.

So, for example, lets say the first request for EUDSA storage is a task requesting x'28010' bytes of storage, CICS would allocate a 1M extent to the EUDSA, and then out of this extent, allocate 3 contiguous x'10000' pages (total x'30000' bytes) to satisfy this x'28010' storage request. The rest of this 1M extent would be free and available to satisfy other EUDSA storage allocations.

Setting RUWAPOOL=YES, helps reduce the amount of GETMAINs and FREEMAINs when a task issues EXEC CICS LINK commands. CICS keeps track of the storage for the transaction and will cause 1 larger GETMAIN to be issued on the next run of this transaction.

Only if the size of this storage is greater than 1M, would CICS then have to allocate an extent of size 2M to the EUDSA, in order to satisfy the request. So you are correct, with RUWAPOOL set to yes, that if the storage history grew to > 1M and < 2M, that would cause CICS to have to allocate an extent in the size of
2M.

I hope this helps, let me know if you have further questions. Sarah BertramIBM CICS Level2 Support

If we set RUWAPOOL=YES, there is noway AUTODST=YES can cause the SOS condition right??

I am working for an installation wherein CICS regions are spending 5 to 10% of CICS TCB time in the heap routines. RUWAPOOL is set to YES and AUTODST is set to NO and STORAGE(00,NONE,NONE,8K) is set. Is there anyway to reduce CPU time spent in heap routines ?

Hi Ravikumar ( @Ravi_sri ),
To answer your question 1 above, that is not true.. IBM support has seen AUTODST=yes contribute to SOS conditions in CICS if there is a different mix of transactions, using different storage amounts.

No, neither of these options "cause" a region to go SOS. What causes storage problems in a region with options like this is using them without first having a full understanding of exactly what they do and how they interact with LE along with understanding the application workload/profile that is running in the region. Rule 1 applies: If you don't know what you're doing, leave it alone.

Thanks for your reply!.. While searching net, I found that Run Unit Work Area (LE_RUWA) consists of Enclave level storage, EICB, TICB, language work area, initial STACK, initial LIBSTACK, initial HEAP and initial ANYHEAP. The size of RUWAPOOL is sum of those values and RUWAPOOL =YES will issue single GETMAIN to acquire that much of storage. This may result in CICS SM combining multiple 1MB extents into single extent to satisfy that single GETMAIN. Is my understanding correct ?