DFHSM0133 short on storage after setting AUTODST ON

Cause

The automatic storage tuning system initialization table (SIT) parameter AUTODST can be a CPU cycle saver, by saving numerous getmains normally done by active, storage intensive programs. It can also cause storage fragmentation that causes CICS to go SOS, if used in the wrong type of environment. Here is why:

The CICS storage manager allocates 1M extents to each of the Extended Dynamic Storage Areas (DSAs) as needed.
EUDSA - user task storage subpool , for example, U00nnnnn where nnnnn is the task number.
ECDSA - CICS task storage (C00nnnnn), and CICS storage subpools , for example, TSMAIN, TCTTE, TCA, and so on.
ESDSA - shared storage subpools SMSHRU31, LDPGM, and so on.
ERDSA - readonly storage subpools for RENT programs LDPGMRO, and so on.

The CICS storage manager (SM) will allocate a 1M extent to a DSA if there is not enough storage available to satisfy a request. This 1M comes from the EDSALIM total. If there are no more unallocated extents, stealing occurs, where one DSA will steal an extent from another DSA, only if it is completely free.

These two main facts about how the CICS SM works is what can make AUTODST cause SOS and severe fragmentation problems.

1. If a getmain request is greater than a 1M extent, CICS storage manager will find multiple 1M contiguous extents to satisfy the request. When freed, the multiple meg extent is not broken back down into single 1M extents. It is freed but remains the new large extent size.
2. Getmain requests are satisfied by first fit, not best fit.

Here is an example of how these two facts would affect a system in a negative manner.

You have a CICS region with AUTODST=YES . The auto storage tuning function is active. The system has a diverse set of transactions, but here are three that are used most of the time, using above the line storage.

TRN1 uses a total of 6M determined by auto-tuning
TRN2 uses a total of 25K determined by auto-tuning
TRN3 uses a total of 500K determined by auto-tuning

The system has been started with EDSALIM=100M and TRN1 runs and LE and CICS getmain 6M. The CICS storage manager finds six contiguous extents and allocates them to EUDSA. TRN1 ends, and CICS SM freemains the storage but a 6M extent (empty) remain allocated to EUDSA.

TRN2 runs and requests 25K. CICS storage manager finds it will fit in the 6M empty extent, so gives 25K of it to TRN2 with remaining storage of 5.975M within that extent.

Another TRN1 runs, needing 6M, but the remaining 5.975M from the above extent is too small, so storage manager finds "another" six contiguous extents for this task. TRN1 ends again. CICS frees the storage but we now have a second 6M empty extent.

TRN3 runs and needs 500K . The CICS storage manager gives that transaction 500K from the newly empty 6M extent, leaving 5.5M free.

As each transaction with smaller storage requirements come in and take 6M extents, the storage manager will have to try to allocate more for the 6M transactions. The system will soon have numerous 6M extents until CICS can no longer find six contiguous 1M extents, leading to a short on storage condition.