A PUT SCRATCH command in an ADS dialog or COBOL or PL/I program can result in a task abend along with a DC045018 SCRATCH AREA FULL message, even if the dialog or program checks ERROR-STATUS after the PUT SCRATCH command. This document explains how this occurs, and how to prevent this.
Release: IDMS, all supported releases.
If a program or dialog issues a PUT SCRATCH, it is possible to get this abend:
DC045018 V1 SCRATCH AREA FULL and DC027007 Vnnnn Tnnnnn TASK <task-code> PROG <program-name> ABENDED WITH CODE D002.
This can occur even if the program or dialog includes a PERFORM IDMS-STATUS or checks the ERROR-STATUS after the PUT SCRATCH. For normal database commands, checking the ERROR-STATUS can avoid an abend. But in this case, if the scratch area is full, the abend occurs unconditionally.
In ADS, PL/I or COBOL, if you issue a PUT SCRATCH and the command results in the scratch area being full, the task is abended immediately with the DC045018 message. Control never returns to the invoking program.
However, in the assembler #PUTSCR macro, there is an undocumented NOSPXIT parameter which can be used in the same way that the documented REPXIT, NEWXIT and EREPXIT parameters can be used. If a scratch full condition is encountered, control will be passed to the label in the NOSPXIT parameter.
There is no way to do this in ADS, PL/I or COBOL. If this level of control is desired, then an assembler program must be used.
In terms of preventing the scratch area from filling, check the following:
Two parms on the SysGen ADSO statement can effect scratch usage. If ADS dialogs are utilized by your site, the ADS Sysgen statement should always specify FAST MODE THRESHOLD IS OFF, and RESOURCES ARE FIXED.
Make sure the SysGen SYSTEM statement specifies SCRATCH IN STORAGE IS YES.
If this abend occurs with any frequency, it may be worth monitoring the scratch usage. This can be done using the DCMT DISPLAY SCRATCH command.
Scratch index control blocks are longterm storage. They are not automatically released when a task ends, but only when the user signs off and longterm resources are freed from the LTERM. Because of this, it is not uncommon to delete scratch records prior to subsequent execution of a dialog, to ensure that any residual scratch records in the scratch area, from previous executions are cleared. This can be done using the DELETE SCRATCH AREA ID <scratch-id> ALL command, or using the DELETE option on a GET SCRATCH command if/when these records are read by another transaction. These programmatic interventions can be a big help in preventing the area from filling up with records that are no longer required, but are still stored.
Expanding the scratch area may be helpful, but if other measures are not also taken, this may be inadequate to resolve the abends.
Since r17.0, if SCRATCH IN STORAGE is in use, the scratch area can be set up to dynamically expand. See Expansion of scratch-storage-parms in the SysGen SYSTEM statement. These settings can be changed dynamically with the DCMT VARY SCRATCH command.