Cause of DC045018 and DC027007 after PUT SCRATCH command, and how to prevent this?

Document ID : KB000054177
Last Modified Date : 14/02/2018
Show Technical Document Details

Description

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 the error-status after the PUT SCRATCH command. This document explains how this occurs, and how to prevent this.

Solution

   If a program or dialog issues a PUT SCRATCH, it is possible to get error 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. In most situations, checking the Error-status would avoid an abend, but in this case, if the scratch area is full, it will not. Instead you will see the above errors followed by a dump.

    In ADS, PL/I or COBOL, if you issue a PUT SCRATCH and the command results in the scratch area being full, we abend the transaction immediately with the DC045018. Control never returns to the dialog for the IDMS-Status call to be issued. A NOSPXIT user exit exists that can be invoked if a no space condition is found, but this can only be invoked on a #PUTSCR command in assembler. In that situation, RHDCSCRM does check for a 32 return code (area full) and if found and the program has requested the NOSP exit be called, control will be passed back to the program. However, if you want this level of control you need to use assembler. This exit is not available in any other language.

   In terms of preventing the scratch area from filling, there are a few things you can check:

  1. Two parms on the ADS Sysgen 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.


  • Also make certain the Sysgen specifies SCRATCH IN XA IS YES.


  • If this abend occurs with any frequency, it may be worth monitoring the scratch usage. This can be done using the DCPROFIL command; page one gives the HWM for scratch.


  • Scratch index control blocks are longterm storage. They are not automatically released when a transaction or task ends, but only when the user signs off and longterm resources are free 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.


  • On CA IDMS release 17.0 the SCRATCH clause of the Sysgen SYSTEM statement allows for dynamic growth of the Scratch area if it is allocated in memory rather than using a physical DDLDCSCR file.
    Implementing this can prevent the scratch area from filling, but as always usage should be monitored to ensure that resources are not being over-used. The syntax to allow this is as follows:
  • SCRATCH IN STORAGE IS YES        LOCATION XA/ANY/64-bit                  PRIMARY EXTENT <size>/DEFAULT       SECONDARY EXTENT <size>/DEFAULT     LIMIT <limit-with-unit>/DEFAULT.