Browse Prior Art Database

Scatter Write/Gather Read in Extended Count, Key, Data Architecture

IP.com Disclosure Number: IPCOM000105375D
Original Publication Date: 1993-Jul-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 2 page(s) / 61K

Publishing Venue

IBM

Related People

Beardsley, BC: AUTHOR [+2]

Abstract

Extended Count, Key, Data (ECKD) Architecture can be improved to accommodate the reading and writing of non-contiguous, fixed blocks on disk through the implementation of a Scatter Write/Gather Read mechanism. This enhancement helps those operating systems which have a high degree of random disk access and which refer to blocks by block number. These operating systems could then generate simpler channel programs when performing disk I/O.

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

Scatter Write/Gather Read in Extended Count, Key, Data Architecture

      Extended Count, Key, Data (ECKD) Architecture can be improved
to accommodate the reading and writing of non-contiguous, fixed
blocks on disk through the implementation of a Scatter Write/Gather
Read mechanism.  This enhancement helps those operating systems which
have a high degree of random disk access and which refer to blocks by
block number.  These operating systems could then generate simpler
channel programs when performing disk I/O.

      The implementation proposes to specify the cylinder number
within the Define Extent and to send a bitmap of the block numbers
along with the Locate Record Extended (LRE) parameters.  There is
already a precedent for the use of bitmaps by LRE as well as the
ability to send a variable length parameter list (20 bytes in a fixed
portion, up to 65525 in the variable portion).

      It is understood that the disk format is guaranteed to be
consistent in that there are no keys, the disk blocks are fixed in
size, and the count fields are re-numbered beginning with each track.
Furthermore, recognizing the inherent problems in sending a large
bitmap, the size of the bitmap that a subsystem or controller will
accept are defined in a two byte value returned by (RDC) Read Device
Characteristics.  If the value is zero, it is implicitly understood
that the function is not supported.  If the value is non-zero the
host software can construct channel programs which send bitmaps up to
the size specified in RDC data.

Implementation

1.  Read Device Characteristics

    a.  Return a two byte value defining the maximum bitmap size in
        bytes
    b.  Zero value implies function is not supported

2.  Define Extent

    a.  Blocksize must represent a fixed size
    b.  Blocksize must match the on-disk blocksize
    c.  Seek Control and Access Authorization must b...