In-memory files

You can create temporary in-memory Model 204 files to reduce the CPU time used for physical commits and reloading pages from files that have been physically closed while you are working. In-memory Model 204 files incur less CPU overhead and none of the I/O associated with permanent Model 204 files.

Note: In-memory files are not supported on z/VSE systems.

If you need a temporary Model 204 file, you no longer have to allocate it on disk. It can be built in memory, ATB (above the bar), using the MEMORY PAGES keywords in the ALLOCATE command.

In-memory files let you use system memory and take advantage of the structure and capabilities of a Model 204 file. The most important capability is that the file pages are shared among all users, and file updates can be backed out on a transaction back out. Most system memory access requires no extra movement of data to or from the buffer pools and does not affect buffer pool performance.

The following scenarios show how you might use in-memory files:

• You have a WORK file that applications use.

  If this is an in-memory file, all file read (DKRD) and write (DKWR) operations merely move pages from the in-memory file to and from the buffer pool for processing just like any other file, but there is no physical disk I/O. Any updated pages will be moved (DKWR) back to the in-memory file, but that also avoids physical disk I/O.

• You have a file that gets an extremely high number of updates.

  This file can be allocated as an in-memory file and restored from a backup copy. Then it can be used by any update processes needed, and when complete, the file can be closed by all users and then dumped to the backup data set.

All pages for an in-memory file reside in and use system memory (above the bar) while still taking advantage of the structure and capabilities of a Model 204 file.

Using an in-memory file reduces CPU time processing, such as COMMIT statements and file page loading and swapping, as the file pages remain in storage even after the last physical file close. All in-memory file pages are shared among all users via the buffer pool, like any other Model 204 file.

Opening and closing in-memory files

You must define the data set with the MEMORY and PAGES keywords, then create it, open it, and initialize it. Afterward, you can use the file as you would any other Model 204 file.

• The FPL page enqueue list is maintained for in-memory files.
• The system enqueues used to protect FPL page updates are not used for in-memory files.

Freeing an in-memory file

When an in-memory file is no longer required, you can free it with the FREE command.

Restoring an in-memory file

When you create an in-memory file, the default FRCVOPT is X'24', which means that this file does not participate in journal and checkpoint logging.

However, remember that restoring an in-memory file with RESTORE from a backup will copy the FRCVOPT from that backup copy into the in-memory file, thus overriding the default. In-memory files are also created with FOPT=0, which is TBO enabled, and TBO is supported. REGENERATE is also supported. RESTART recovery is not supported.

The DUMP command and RESTORE command can process in-memory files.

Note: You cannot create in-memory files that are part of a multi-dataset file, such as the following:

CREATE FILE filename FROM filenam1, filenam2