Storage management tuning

Storage management tuning can reduce the overhead involved in getting and freeing storage for the application program. With proper tuning, several GETMAIN and FREEMAIN calls can be eliminated.

First of all, storage management was designed to keep a block of storage only as long as necessary. This means that during the execution of a COBOL program, if any block of storage becomes unused, it will be freed. This can be beneficial in a transaction environment (or any environment) where you want storage to be freed as soon as possible so that other transactions (or applications) can make efficient use of the storage.

However, it can also be detrimental if the last block of storage does not contain enough free space to satisfy a storage request by a library routine. For example, suppose that a library routine needs 2K of storage but there is only 1K of storage available in the last block of storage. The library routine will call storage management to request 2K of storage. Storage management will determine that there is not enough storage in the last block and issue a GETMAIN to acquire this storage (this GETMAINed size can also be tuned). The library routine will use it and then, when it is done, call storage management to indicate that it no longer needs this 2K of storage. Storage management, seeing that this block of storage is now unused, will issue a FREEMAIN to release the storage back to the operating system.

Now, if this library routine or any other library routine that needs more than 1K of storage is called often, a significant amount of CPU time degradation can result because of the amount of GETMAIN and FREEMAIN activity.

Fortunately, there is a way to compensate for this with LE; it is called storage management tuning. The RPTSTG(ON) runtime option can help you in determining the values to use for any specific application program. You use the value returned by the RPTSTG(ON) option as the size of the initial block of storage for the HEAP, ANYHEAP, BELOWHEAP, STACK, and LIBSTACK runtime options. This will prevent the above from happening in an all VS COBOL II, COBOL/370, COBOL for MVS & VM, COBOL for OS/390® & VM, or Enterprise COBOL application. However, if the application also contains OS/VS COBOL programs that are being called frequently, the RPTSTG(ON) option may not indicate a need for additional storage. Increasing these initial values can also eliminate some storage management activity in this mixed environment.

The IBM® supplied default storage options for batch applications are listed below:

ANYHEAP(16K,8K,ANYWHERE,FREE) 
BELOWHEAP(8K,4K,FREE) 
HEAP(32K,32K,ANYWHERE,KEEP,8K,4K) 
LIBSTACK(4K,4K,FREE) 
STACK(128K,128K,ANYWHERE,KEEP,512K,128K) 
THREADHEAP(4K,4K,ANYWHERE,KEEP) 
THREADSTACK(OFF,4K,4K,ANYWHERE,KEEP,128K,128K)

If you are running only COBOL applications, you can do some further storage tuning as indicated below:

STACK(64K,64K,ANYWHERE,KEEP)

The IBM supplied default storage options for CICS® applications are listed below:

ANYHEAP(4K,4080,ANYWHERE,FREE) 
BELOWHEAP(4K,4080,FREE) 
HEAP(4K,4080,ANYWHERE,KEEP,4K,4080) 
LIBSTACK(32,4000,FREE) 
STACK(4K,4080,ANYWHERE,KEEP,4K,4080)

If all of your applications are AMODE(31), you can use ALL31(ON) and STACK(,,ANYWHERE). Otherwise, you must use ALL31(OFF) and STACK(,,BELOW).

Overall below the line storage requirements have been reduced by reducing the default storage options and by moving some of the library routines above the line.

Note: Beginning with LE for z/OS® Release 1.2, the runtime defaults have changed to ALL31(ON),STACK(,,ANY). LE for OS/390 Release 2.10 and earlier runtime defaults were ALL31(OFF),STACK(,,BELOW).