Configuration Best Practices › Tuning for Improved Performance and Lower TCO › Maintain Scratch Information in Memory

Maintain Scratch Information in Memory

Use the scratch in memory and extensible scratch options in both central version and local mode environments.

Business Value:

Enabling the use of scratch in memory significantly improves CA IDMS runtime performance by eliminating file I/O to a scratch area. Defining scratch in memory also improves DBA productivity by eliminating the need to define and maintain a scratch area for every CA IDMS system.

Enabling extensible scratch reduces the possibility of task failures due to insufficient scratch space at runtime.

Additional Considerations:

CA IDMS utilizes a temporary working storage area referred to as the scratch area. This temporary storage can either be allocated in memory or allocated on DASD and accessed through standard file I/O.

The SCRATCH IN STORAGE YES system generation parameter and the SCRATCH_IN_STORAGE SYSIDMS parameter specify that the scratch area is memory-resident for central version and local mode processing, respectively. To enable the use of extensible scratch, specify both primary and secondary extent sizes.

If scratch information is not maintained in memory, then a scratch area must be allocated on DASD and physical I/O will be done to the associated file at runtime.

Customers with the following types of workloads will benefit from use of this best practice:

• IDMS SQL, JDBC, or ODBC applications. CA IDMS SQL internal processing utilizes scratch storage extensively.
• CA IDMS DC/UCF COBOL, PL/I, Assembler, or CA ADS applications that issue Scratch commands.

More Information:

For more information about scratch information in memory and extensible scratch, see the CA IDMS System Generation Guide and the CA IDMS Database Administration Guide.