AUTODST: Language Environment automatic storage tuning

How it works: Language Environment automatic storage tuning at system level

Language Environment uses storage obtained from CICS for each run-unit. When each program is first used, Language Environment tells CICS how much storage the run unit work area (RUWA) requires. When automatic storage tuning is active, Language Environment monitors each main program execution. If at the end of each program execution any additional storage had to be allocated, Language Environment retains this information. Next time the program is executed, Language Environment increases the initial storage allocation to include this extra storage. This process helps to minimize the number of GETMAIN and FREEMAIN requests that CICS has to perform.

Automatic storage tuning is particularly helpful for programs that issue many dynamic calls, as such programs can easily exceed their initial storage allocations. It also removes the need to tune storage manually for individual COBOL programs.

However, you should be aware that once Language Environment has increased the initial storage allocation for a program, it is never decreased. If a program execution requires an unusually large amount of storage, perhaps because the user has activated a seldom-used function of the program, this amount of storage is allocated for all subsequent executions of the program. So in rare cases, you can find that automatic storage tuning leads to an excessive allocation of storage for some programs.

Why AUTODST might cause storage fragmentation and SOS conditions

Language Environment automatic storage tuning works by increasing initial storage allocations for a run-unit if needed.

The CICS storage manager allocates storage by multiples of 1M extents to each of the extended dynamic storage areas as needed. If there is not enough storage available in a DSA to satisfy a request, the CICS storage manager allocates storage to the DSA from the EDSALIM total, or if no more unallocated extents are left, it steals storage from another, completely free DSA to satisfy the request.

The following example helps you understand why the two facts can contribute to storage fragmentation.

Example:

The system has been started with EDSALIM=100M, and TRN1 runs. Language Environment obtains 6M from CICS for TRN1. The CICS storage manager finds 6M of contiguous free storage and allocates it to EUDSA. When TRN1 ends, the CICS storage manager releases the storage, but an empty 6M extent remains allocated to EUDSA.

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

Now another TRN1 runs, and it needs 6M, but the remaining 5.975M from the above extent is too small, so the CICS storage manager finds another 6M of contiguous free storage for this task. When TRN1 ends, CICS frees the storage but EUDSA now has a second 6M empty extent.

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

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

Customizing Language Environment storage tuning through Language Environment user exit CEECSTX

You can alter the behavior of the automatic storage tuning mechanism using the Language Environment storage tuning user exit CEECSTX. The user exit can enable or disable storage tuning for a particular program, and you might find this useful if you have an application whose storage needs vary greatly between different executions. It can also provide the starting values for initial storage allocation, and you can use it to limit the maximum amount of storage that Language Environment will allocate during the automatic storage tuning process.

If the CEECSTX user exit was previously used as your Language Environment storage tuning method, you might find that the automatic storage tuning mechanism provides the same function, without the user exit. You need to decide which mechanism to use as your main storage tuning method, because when you are running CICS with automatic storage tuning, the CEECSTX user exit has limited function. Automatic storage tuning operates by monitoring storage allocations, whereas the storage tuning user exit CEECSTX monitors the actual storage used by the user application program. Despite this, automatic storage tuning incurs less overhead than the tuning method based on the CEECSTX exit. Also, automatic storage tuning provides tuning for each initial program invoked by a transaction, while the CEECSTX exit provides tuning for only those programs contained in the table that the exit uses as its input. This means that automatic storage tuning can provide a greater benefit by tuning the storage used by more programs.

For more information about CEECSTX, see Language Environment storage tuning user exit in z/OS Language Environment Customization.