Browse Prior Art Database

Transparent Data Set Management Within EDAM

IP.com Disclosure Number: IPCOM000048342D
Original Publication Date: 1982-Jan-01
Included in the Prior Art Database: 2005-Feb-08
Document File: 2 page(s) / 15K

Publishing Venue

IBM

Related People

Cesa, LJ: AUTHOR [+4]

Abstract

A set of programs, the Extended Direct-Access Method (EDAM), has been developed to manage large amounts of data spread over several direct access data sets. Developed to aid those applications which require more main memory for their tables than the 16 megebyte MVS (Multiple Virtual Storage) region will allow, EDAM has the capability to address more than one terabyte (1,000,000,000,000 bytes) of real data. EDAM stores this data on as many direct access (EDAM) data sets as are required. The methods and algorithms necessary to manage these date sets are described below.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 2

Transparent Data Set Management Within EDAM

A set of programs, the Extended Direct-Access Method (EDAM), has been developed to manage large amounts of data spread over several direct access data sets. Developed to aid those applications which require more main memory for their tables than the 16 megebyte MVS (Multiple Virtual Storage) region will allow, EDAM has the capability to address more than one terabyte (1,000,000,000,000 bytes) of real data. EDAM stores this data on as many direct access (EDAM) data sets as are required. The methods and algorithms necessary to manage these date sets are described below.

In today's environment if a user has a large amount of data spread across many data sets, he typically must wrestle with all of those data sets to make sure that they get associated with the correct DDNAME that an application program requires. The user must also be conscious of having the correct blocksize, LRECL, etc. For a small number of data sets this might be reasonable, but for tremendous amounts of data using many data sets this becomes unmanageable and error prone. It is desirable to access large amounts of logically connected data merely by specifying the collection of data, leaving any required data set management to be transparent.

To access an EDAM file, the name of the file (up to 255 characters, for example) is passed to a file open routine. This routine looks up the passed name in a collection directory, indicated by the one DDNAME required by EDAM, and, assuming the file exists, determines the data set naming convention to be used within this EDAM file. The data set names of all data sets associated with this EDAM file could be of the form: HI-ORDER-QUALIFIER.EDxxxxx.DSyyyy where HI-ORDER-QUALIFIER is the user specified qualifier for the entire collection of EDAM files associated with the directory data set. EDAM is a unique decimal number assigned to the file within the collection, and yyyy would be the data set number of a data set within the EDAM file. Any data set associated with an EDAM file is dynamically attached to an internally generated DDNAME and opened upon demand for data residing within it.

It is EDAM's convention to store the File Control Block (FCB) in relative record 0 and 1 of data set 0000 within the file (records 0 and 1 both contain the FCB for integrity purposes). EDAM could attach a DDNAME to data set 'HI- ORDER-QUALIFIER.EDxxxxx.DS0000', for example, and read in relative records 0 and 1. After checking which copy of the FCB is currently valid, the open routine returns the address of the FCB as the file ID, and the calling program now has access to any of the 380,000 four-gigabyte storage areas.

EDAM's directory entries point to pages (each 4096 bytes, for example) either in an EDAM main storage buffer or on disk. A disk address is composed of two parts: a data set number (DSNUM) (12-bit, for example), and a...