Browse Prior Art Database

Record Caching with Count Key Data Emulation on Fixed Block Architecture Devices

IP.com Disclosure Number: IPCOM000115803D
Original Publication Date: 1995-Jun-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 2 page(s) / 104K

Publishing Venue

IBM

Related People

Beardsley, BC: AUTHOR [+4]

Abstract

A method of cache management is disclosed for Fixed Block Architecture (FBA) devices emulating Count Key Data (CKD) DASD. This method, which is called record caching, will manage the cache in units much less than the CKD track size(s) emulated and is a multiple of the FBA device block size.

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

Record Caching with Count Key Data Emulation on Fixed Block Architecture
Devices

      A method of cache management is disclosed for Fixed Block
Architecture (FBA) devices emulating Count Key Data (CKD) DASD.  This
method, which is called record caching, will manage the cache in
units much less than the CKD track size(s) emulated and is a multiple
of the FBA device block size.

      A problem when emulating CKD tracks with FBA devices is the
record sizes used by the application programs need not match the FBA
block size.  In addition, CKD record sizes may vary from track to
track or even within a track.  For this reason, the cache is usually
managed in units of the CKD track size.  This can lead to
inefficiencies for those applications that have poor locality on a
track basis but improved locality on a CKD record basis.  Transaction
Processing Facility (TPF) by IBM* is an example of one such
application.

      Extended Count Key Data (ECKD) Architecture which makes up the
command set used to communicate with CKD devices now has a Regular
Data Format indicator which means that the track format within the
domain of the access is predictable from the information given in
commands prior to data transfer commands (i.e., the Define Extent and
Locate commands).  The ability to predict the amount of contiguous
data referenced in an ECKD access allows for an efficient
implementation of record caching for FBA devices emulating CKD
devices.  Alternatively, part of the cache could be used to keep
track of the format of all of the CKD tracks.  In this way, even when
Regular Data Format was not specified, the amount of data referenced
in an ECKD access could still be determined if the chain used a
Locate command since this command indicates the number of contiguous
records that will be referenced.

      Given that the format of the CKD track and the amount of data
referenced in an access can be determined, at least for the vast
majority of the accesses, then an record cache management algorithm
can be devised with a cache allocation unit a multiple of the FBA
device block size, called a cache segment.  Ideally, the cache
segment size would be much smaller than the number of FBA blocks
required to store an entire CKD track but large enough to hold the
data for most of the accesses for the applications using the cached
subsystem.
  Note: For those accesses where the format of the CKD track is
unknown or the amount of data referenced is unknown a fraction of the
cache can be reserved for full track operations.

      The cache segment size can either be fixed by the microcode or
could be set...