Optimizing Storage Management › Session Storage Cleanup › RELEASE PROGRAM

RELEASE PROGRAM

The RELEASE PROGRAM statement can be useful and can help improve performance. If used inappropriately, however, its use can significantly increase I/O, resulting in performance degradation that can be dramatic. A standard that includes coding a RELEASE PROGRAM each time after a program is called is not a good standard. Although it controls the amount of temporary and above-the-line storage that is present at any one time, it significantly increases CPU and I/O costs.

RELEASE allows you to free a resource that is no longer needed in a CA Ideal program. Regardless of whether a program is in VLS format or load module format, the RELEASE PROGRAM statement frees the storage that is attributed to the updateable portion of a CA Ideal program.

It also marks the area in the Run Control Block (RCB) used for this program so that it is reused during the run. However, it does not reduce the size of the RCB. CA Ideal enlarges the RCB in increments of 4 KB as needed.

The following are good candidates for the RELEASE PROGRAM statement:

• Initialization programs.

  You should release any program that is called at the beginning of a run and never called again.

• The leg of an application called from a CA Ideal menu program.

  If you have a menu program that calls programs that are considered applications and if users spend a long period of time in one application before moving to another piece of the menu, you might consider using the RELEASE PROGRAM statement on the “application” program.

  This type of application can also lend itself to setting up each leg as its own transaction and using CA Ideal FINAL-ID to invoke the transaction. The invoked transaction can then invoke the menu transaction when it is complete. This frees up all resources because you ended the CA Ideal run.

Misusing RELEASE PROGRAM can increase I/Os, resulting in significant performance degradation.

For example, if you release a program in VLS format and then reuse the program, the updateable portion must be retrieved from the VLS library so that a copy can be made. The readonly portion of the program will also be read from VLS. Likewise, when a program in load module format is released and then reused, the updateable portion of the program must be retrieved from the load module library, unless it is in core because CICS has not yet released it or because it was made resident. In all situations, the existing copy of the data is deleted and then reallocated. The RELEASE statement has no effect on the CICS load module that contains the shareable portion of the code. CICS handles that storage as usual at the end of the transaction boundary.

Because the RELEASE PROGRAM statement also reinitializes the working data and parameter sections, some programmers use it for this purpose. This might not be a good practice. It can be more efficient to execute a few SET statements to reinitialize only those fields that need to be initialized.

Doing block SETS can be even more efficient: Set up a 01-level group in working data that contains all the working data fields that need to be initialized. Set the group equal to $SPACES or, for non-alpha groups or alpha groups that need to be initialized to something other than blanks, equate the group to another group containing the same setup using MOVE BY POSITION.