Will setting RUWAPOOL=YES cause SOS in CICS TS?
Does setting RUWAPOOL=YES cause short on storage (SOS) condiitions in CICS Transaction Server for z/OS (CICS TS) similar to AUTODST=Yes as explained in DFHSM0133 short on storage after setting AUTODST ON?
Thanks, Ravikumar
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 Bertram
IBM CICS Level2 Support
Sarah,
Thank you so much for your reply!.
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 ?
Thanks,Ravikumar
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.
Here is an item that talks about this:
DFHSM0133 short on storage after setting AUTODST ON
Here is another item with information about RUWAPOOL and AUTODST that may help:
LE storage tuning in CICS using AUTODST and RUWAPOOL
Hope this information helps.
Sarah
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 ?