Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Write Anytime After Change Data in Memory Mapping

IP.com Disclosure Number: IPCOM000109350D
Original Publication Date: 1992-Aug-01
Included in the Prior Art Database: 2005-Mar-23
Document File: 3 page(s) / 178K

Publishing Venue

IBM

Related People

Fecteau, G: AUTHOR [+4]

Abstract

A data in memory (data in virtual) mapping mechanism is disclosed that allows changed mapped data to be written back in-place (i.e., to the mapped-to DASD blocks) at any time after the data has been changed (referred to herein as write anytime after change mapping). Previously, data in memory mapping mechanisms (for example, the MVS/ESA* DataIn-Virtual DIV macro) guaranteed that changed data would not be written back in-place until the application specifically requested a data in memory commit operation (referred to hereafter as write only at commit mapping). Write anytimeafter change mapping reduces the commit-time I/O operations required as compared with write only at commit mapping.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 38% of the total text.

Write Anytime After Change Data in Memory Mapping

       A data in memory (data in virtual) mapping mechanism is
disclosed that allows changed mapped data to be written back in-place
(i.e., to the mapped-to DASD blocks) at any time after the data has
been changed (referred to herein as write anytime after change
mapping).  Previously, data in memory mapping mechanisms (for
example, the MVS/ESA* DataIn-Virtual DIV macro) guaranteed that
changed data would not be written back in-place until the application
specifically requested a data in memory commit operation (referred to
hereafter as write only at commit mapping). Write anytimeafter change
mapping reduces the commit-time I/O operations required as compared
with write only at commit mapping.

      Many operating systems provide an application I/O mechanism
typically termed data in virtual or data in memory mapping.  In a
data in memory mapping system, an application program associates data
on direct access storage devices (DASDs) with locations in memory.
After establishing a mapping association, the data contained on the
DASD blocks appears to the application to be available in the
associated memory locations.  Data transfer between DASD and memory
occurs implicitly (usually as a function of system paging) as the
application references the mapped memory locations, rather than via
explicit application I/O requests.  Data in memory mapping systems
typically include a commit operation that is used to guarantee that
the application's DASD has been updated with the most recent copy of
changed mapped data.

      This invention concerns itself with how the operating system
handles changed mapped data in between the time that the data is
changed and the time that the application requests a commit
operation.  In particular, the invention deals with the case in which
the paging subsystem needs to reclaim (e.g., for use by other
applications) some amount of processor storage that currently
contains mapped application data and the data contained in the
storage has been changed while it was resident.

      The prior art, as exemplified by the MVS/ESA Data In Virtual
(DIV) macro interface, implements semantics that can be described
from the application's point of view as write only at commit.  In
such a system, the mapping functions guarantee that the application's
DASD locations will be updated only when explicitly requested by the
application.

      In a write only at commit system, if the operating system needs
to reclaim some processor storage (a page frame) containing changed,
mapped data before the application has requested a commit operation,
it allocates DASD locations from system paging space and writes the
changed data onto those system paging blocks before using the
processor storage for other purposes.  If the application again needs
the data, the operating system fetches the data from the system
paging space back into processor storage where it is available t...