In-memory files: Difference between revisions

From m204wiki
Jump to navigation Jump to search
No edit summary
m (minor cleanup)
Line 3: Line 3:
<p class="note"><b>Note:</b> In-memory files are not supported on z/VSE systems.</p>
<p class="note"><b>Note:</b> In-memory files are not supported on z/VSE systems.</p>


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 either the [[DEFINE DATASET command]] or [[ALLOCATE command]].
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 <var>MEMORY PAGES</var> keywords in either the <var>[[DEFINE DATASET command|DEFINE DATASET]]</var> command or the <var>[[ALLOCATE command|ALLOCATE]]</var> 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.
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:
The following scenarios show how you might use in-memory files:
Line 11: Line 11:
<ul>
<ul>
<li>
<li>
You have a WORK file that applications use.  
You have a <code>WORK</code> file that applications use.  
<br>
<p>
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.
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. </p></li>
</li>


<li>
<li>You have a file that gets an extremely high number of updates.  
You have a file that gets an extremely high number of updates.  
<p>
<br>
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. </p></li>
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.
</li>
</ul>
</ul>


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.
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.
Using an in-memory file reduces CPU time processing, such as <var>COMMIT</var> 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===
===Opening and closing in-memory files===
You must define the data set with the MEMORY and PAGES keywords, then
You must define the data set with the <var>MEMORY</var> and <var>PAGES</var> keywords, then
create it, open it, and initialize it. Afterward, you can use the file as you would
create it, open it, and initialize it. Afterward, you can use the file as you would
any other Model 204 file.
any other Model 204 file.
<ul>
<ul>
<li>The FPL page enqueue list is maintained for in-memory files.</li>
<li>The FPL page enqueue list is maintained for in-memory files.</li>
<li>The system enqueues used to protect FPL page updates are not used for
<li>The system enqueues used to protect FPL page updates are <i>not</i> used for
in-memory files.</li>
in-memory files.</li>
</ul>
</ul>
===Freeing an in-memory file===
===Freeing an in-memory file===
When an in-memory file is no longer required, you can free it with the [[FREE command]].
When an in-memory file is no longer required, you can free it with the <var>[[FREE command|FREE]]</var> command.


[[Category: File management]]
[[Category: File management]]

Revision as of 01:58, 22 February 2014

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 either the DEFINE DATASET command or 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.