Session Storage Cleanup

This section presents the different ways that are available to improve performance, enforce security, and purge a session or storage.
cadts
This section presents the different ways that are available to improve performance, enforce security, and purge a session or storage.
This page contains the following topics:
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™ for CA Datacom®
 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™ for CA Datacom®
 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™ for CA Datacom®
 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™ for CA Datacom®
     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™ for CA Datacom®
     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™ for CA Datacom®
     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.
Timeouts and Disconnections
Coding a timeout parameter for VTAM, CICS, or a security package, can help you to enforce security. For example, it can reduce the chances of an unauthorized user taking over a session at an unattended terminal that is still signed on.
A disconnection can result because of a network problem or if the user simply closes the 3270 emulator window.
Session storage is only deleted after a timeout or disconnection if the VPE Purge Invocation code has been invoked.
If the VPE Purge Invocation Code (VPUR) is not executed after a timeout or disconnection, you can expect the following to remain:
  • User session Temporary Storage records allocated by CA IPC, Datadictionary, and 
    CA Ideal™ for CA Datacom®
    .
  • EDSA acquired for the updateable copy of the application program
  • Use counts and enqueues performed on VLS entities.
  • Storage allocated by Datadictionary for each terminal accessing DD.
If any of the preceding situations happen, it is because VPE has not been returned control, which allows it to clean up the session. Without invoking the VPE Purge Invocation code, this data can only be released if another 
VPE-based transaction uses the same terminal or CICS is recycled.
VPUR
If a 
CA Ideal™ for CA Datacom®
 session is aborted and VPE does not regain control and perform a session clean up, you can start a VPUR transaction that initiates a clean up process. Typically, this happens when a 327x terminal disappears and the CICS Node Error Program (DFHZNEP) is automatically enabled to handle the situation. To start VPUR, the VTAM codes are checked to ensure that the conditions are appropriate. VPUR invokes the VPE module VPEPURGE, and uses the input data from the CICS terminal ID that has been abnormally terminated. Using the TERMID, VPEPURGE finds the VPE Session Anchor Block (VSAB) and deletes all of the storage acquired by GETMAIN in various DSAs and Temporary Storage records that make up a 
CA Ideal™ for CA Datacom®
 user session. VPEPURGE will also dequeue any enqueues that have been issued for the session.
When VPUR is started, it is only known that the terminal where a 
CA Ideal™ for CA Datacom®
 task is executing has ceased to exist in the CICS environment. VPUR is invoked with the input data of the four-character CICS TERMID. Sometimes the task continues to execute the application, even though the TERMID has ceased to exist in CICS. If VPUR has been started, VPUR releases the storage that belonged to the task, the task is still executing and tries use its old session storage, which could by this time be reallocated by CICS to another task, resulting in abends or storage violations. Because of this potential problem, it is important to determine how VPUR should be implemented to be most effective based on a site's particular environment. For example, if long running tasks are the norm, it may be critical to first determine that the task has ended for a TERMID by querying CICS before invoking VPUR. VPUR could be invoked from the CICS NEP or the CICS terminal autoinstall exit.
Node Error Recovery
You can purge a session by invoking the VPE purge storage function from a Node Error Program (NEP). If available, CICS invokes a NEP when VTAM notifies it that a terminal was lost (LOSTERM notification). The NEP schedules a transaction that issues the purge storage function on behalf of the lost terminal.
To invoke the purge storage function from a NEP, first customize and then add the following statements to your site's CICS Node Error Program:
NEP0AF   DS    OH                                              @BD5021A *-----------------BEGINNING OF SUGGESTED VPE PURGE INVOCATION CODE----*         CLI   TWAEC,TCZxxxx       ERROR?         BE    PURGEIT                  CLI   TWAEC,TCZxxxx       ERROR?         BE    PURGEIT         CLI   TWAEC,TCZxxxx       ERROR?         B     GO_ON               NO; ELSE... PURGEIT DS    OH         EXEC  CICS START TRANSID('VPUR') LENGTH(4) FROM(TWANID) GO-ON   DS    0H *-----------------END OF SUGGESTED VPE PURGE INVOCATION CODE----------*
In the preceding illustration, '
xxxx
' represents the error code you intend to trap. Commonly trapped error codes include TCZTXCU (node unrecoverable), TCZNSP01 (network error 1) and TCZNSP02 (network error 2). The values that need to be trapped will depend on your network configuration. See the DFHZEQU macro for specific error code definitions. Also see the CICS Customization documentation for more information about Node Error Program processing.
PURGE term-id
You might need to purge storage for a 
CA Ideal™ for CA Datacom®
 session that is abruptly ended in CICS. For example, if a transaction is canceled, Virtual Processing Environment (VPE) can have storage areas and control blocks still allocated on behalf of the terminal. If the session is not purged, these storage areas could be allocated indefinitely since the random terminal-ID assignment of AUTOINSTALL cannot reuse the original terminal ID. The PURGE command cleans up these storage areas.
PURGE 
termid
  • termid
    The four-character terminal ID. You must type this value exactly as generated by the AUTOINSTALL routine since term-ID is case sensitive.
When the session is purged, the following message displays:
Terminal '
termid
'
 purge complete
If the value supplied for
 termid
 is not a defined terminal ID, the following message displays:
Terminal '
termid
'
 not found
Check to be sure you entered the terminal ID in the correct case, exactly as the AUTOINSTALL routine generated it.