Browse Prior Art Database

Providing Fast Access to Blocked Static Data

IP.com Disclosure Number: IPCOM000118223D
Original Publication Date: 1996-Nov-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 4 page(s) / 106K

Publishing Venue

IBM

Related People

Wilson, K: AUTHOR [+2]

Abstract

A number of data storage applications exhibit the following characteristics: 1. There is a large quantity of data that is defined in blocks. 2. The data is static: any changes to a block or the addition of a new block happens occasionally and not during a run of the system accessing the data. Thus, any updates to the data occur offline and not very often. 3. Normally access is only required to a couple of blocks in any particular run of a system. 4. There is a key which can be used to indicate which block of data is required.

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

Providing Fast Access to Blocked Static Data

      A number of data storage applications exhibit the following
characteristics:
  1.  There is a large quantity of data that is defined in
       blocks.
  2.  The data is static:  any changes to a block or the addition
       of a new block happens occasionally and not during a run of
       the system accessing the data.  Thus, any updates to the
       data occur offline and not very often.
  3.  Normally access is only required to a couple of blocks in
       any particular run of a system.
  4.  There is a key which can be used to indicate which block
       of data is required.

      An example of such an application is the storage of translation
tables, such as EBCDIC to ASCII code page translation tables, which
cannot be calculated in some manner.  Each table is fairly large and
corresponds to a block of data as described above.

      The access technique described exploits the constraints on
change and access described above to provide fast access to such
data, while being simple to implement and making only limited demands
on resources, such as memory.  It also provides means for the data to
be encrypted.

      The Figure shows the improved technique in block design form.

      A query from an application (1) is sent to a Query Module
(2).  The Query Module then determines where the data is and sends a
request to an appropriate Data Module.  The response is then passed
back up to the application.

Data Modules

      There are one or more Data Modules containing the blocks of
data.  The actual number of such modules depends upon the size of
each block, the number of blocks and the relationship between the
blocks of  data.

      Since an individual Data Module will be loaded into memory, it
should not be too large with respect to the memory that will be
available.

      Each data module has an access function.  The access function
takes as input a key which indicates which block of data is required.
The block of data is obtained and returned to the caller.

      Each block of data is held in a format that is quick and easy
to access.  A typical implementation would use an array, with each
entry in the array being a block of data.  Thus, typically the array
would be  an initialized structure array.  The key passed to the
access function  would typically be the element number of the array
which contains the required block of data.  The access function
returns the address of the  required array element.

      A typical implementation of a Data Module would be a Dynamic
Link Library (DLL), with the access function being an exported entry
point.

      Using the EBCDIC to ASCII codepage translation example, there
would be a Data Module for each EBCDIC code page...