Text preview for : An_OS360_BDAM_Users_Guide_Jun69.pdf part of IBM An OS360 BDAM Users Guide Jun69 IBM 360 os bdam An_OS360_BDAM_Users_Guide_Jun69.pdf
Back to : An_OS360_BDAM_Users_Guide | Home
AN OS/360 BDAM USERS GUIDE
Wayne E Fisher
IBM Corporation
Education Center
3424 Wilshire Blvd
Los Angeles, Calif 90005
This paper is not intended to replace the IBM publications
pertaining to BDAM. Rather it is intended to supplement,
clarify, and bring together the BDAMmaterial in the
.various IBM publications.
It is assumed that the reader is familiar with the
Assembly Language and the Supervisor and Data Management
macro instructions.
June 30, 1969
TABLE OF CONTENTS
Introduction 1
Track Format Review 1
Blocks Versus Records 2
Programming Considerations 3
Formatting the Data Set Space 3
Addressing Schemes 3
Keys 3
Direct Addressing 4
Indirect Addressing 6
Overflow Record Handling 7
Record Reference Methods 9
Referencing a Specific Record 9
Referencing a Record with a Specific Key 11
Extended Search Option 12
Dynamic Buffering 13
Programming Considerations 13
Advantages Versus Disadvantages 13
Obtaining Buffers 14
Releasing Buffers 14
Feedback 14
Requesting Feedback 15
Storing Feedback 15
Form of Feedback 15
Exclusive Control 17
CHECK Macro Versus WAIT Macro 18
Errors 18
Space Allocation 19
Fixed Format Records 20
Creating a Direct Data Set 20
Formatting the DASD Space 20
The WRITE Macro 20
Return Codes 21
Test Completion of WRITE Operation 21
DCB Considerations 22
DD statement Considerations 22
Processing Format F Without Keys 23
To Retrieve 24
To Update 24
To Make Additions 25
DCB Considerations 25
Examples 27
Processing Format F With Keys 28
To Retrieve a Specified Block 29
To Retrieve a Block With a Specified Key 30
To Update a Specified Block. 31
To Update a Block With a Specified Key 32
To Make Additions 33
DCB Considerations 34
Examples 35
INTRODUCTION
TRACK FORMAT REVIEW
Information is recorded on all direct access volumes in
a standard format. In addition to device-dependent data
(home address), each track contains a track descriptor record
(also called a "capacity record" or RO), and one or more data
records. User data is placed in the data records. The
system maintains the track descriptor record on each track.
There are only two possible data record formats
Count-Data and Count-Key-Data -- only one of which can be
used for a particular data set. The following illustrates
the two possible data record formats.
Count-Data Format
Icountl IDatal ICount I IDatal [][J Icountl IData]
Track Descriptor Data Record Data Record
Record (RO) (Rl) (Rn)
Count-Key-Data Format
[c_oun~ IData] Icountl ~ IData I Icount I EJ IDatal
Track Descriptor Data Record (Rl) Data Record (R2)
Record (RO)
Figure 1. Data Record Formats on DASD Tracks
The Count area of each record contains eight bytes that
identify the location of the record in terms of the cylinder,
head, and record numbers; its key length (0 if no keys are
used); and its data length.
If records are written with keys, the Key area (1-255
bytes) contains a record key that identifies the following
Data area. This identifying information might be a part
number, account number, sequence number, etc. The hardware
is capable of searching the Key area of each record on each
track for a particular key. Once more, the keys do not have
to be in any particular sequence.
The Data area contains the user's data records. Its
length can be up to 32,760 bytes, but realistically is
determined by the particular device's track capacity. Each
Data area contains a block. Each block can consist of one
or more logical records.
1
BLOCKS VERSUS RECORDS
As previously stated, each Data area contains a block
which may consist of one or more logical records. However,
since a direct data set can only be processed by the basic
access technique, the user must perform any blocking or
deblocking if in fact there are more than one, logical record
per block. The reader should be aware that the term "block"
and "record" are used interchangeably in this publication
as well as the IBM SRL publications. They both refer to the
contents of the Data area on a direct access track.
2
PROGRAMMING CONSIDERATIONS
FORMATTING THE DATA SET SPACE
Before data records can be placed in a direct data set,
the DASD space allocated must be "formatted". Formatting
the data set is the process of initializing each track, one
after another in a sequential fashion. In fact, a sequential
access method (BSAM) is used to perform the formatting.
For fixed length records (RECFM=F), formatting is
essentially the process of creating "buckets" which act as
place holders for actual records to be added at a later time.
For variable length (RECFM=V) and undefined length
(RECFM=V) records, formatting is the process of initializing
the Track Descriptor Record (there is one on the front of
every track). Each will reflect the fact that there are
no records written on the track and that the entire track
space is available.
ADDRESSING SCHEMES
Each record in a data set is comprised of one or more
related data fields. One or more of these data fields may
serve as an identifier or key field which uniquely distin-
guishes that record from others in the same data set.
Typical keys are: names, part numbers, or chronologically
assigned 'serial numbers such as employee number, invoice
number, etc. The key is the means of selecting and retriev-
ing a desired record from the data set.
Every record in a directly organized data set also has
a unique address. This address identifies to the access
method the location within the data set where the record
should be found. The format of the record address will be
discussed later.
In a direct data set, there is a definite relationship
between the record key and the record address or location.
It is this relationship which allows you to directly retrieve
any record in the data set without a sequential or index
search. This relationship is completely determined by each
user -- it might be a direct or an indirect relationship.
3
Direct Addressing
It is entirely possible to have keys which identify the
location of the record in the data set. This is a direct
addressing scheme, thus obviating the need for a transfor-
mation or mathematical manipulation of the key. One of the
characteristics of a direct addressing scheme is that there
is a unique DASD address for each record key.
strict Relationship
The ideal situation would be to use the record's key
as its DASD address, that is, there is a strict relationship
between the record's key and its address in the data set.
An example of this type of direct addressing would be a data
set of personnel records where the four-digit employee num-
ber is the key and also serves as the location of the record,
i.e., the record for employee number 6545 would be the 6,545th
record within the data set.
Figure 2 illustrates a card record with a key of 6545
which serves as the address of the corresponding record in
the direct data set.
Key = 6545
Figure 2. Direct Addressing
This technique assumes that there is an addressable
location or "bucket" available for each employee number
regardless of whether or not there is an employee with that
number. For example, if we have employee numbers which
range from 0001 to 9999, then we must have 9,999 buckets
even though we may have only a couple hundred employees.
4
The use of direct address using a strict relationship
is usually limited to data sets with small numerical keys.
Additionally, in all direct addressing schemes the data
records must be fixed length without track overflow.
Cross-Reference Table
There is no unique and simple way of transforming a
long key to a shorter unique address. One technique of
handling records with a cumbersome key is to build a cross-
reference table (index). When a record is written in the
data set, you note the physical location and store this,
along with its key, in the table. Finding the address of
a particular key is achieved by programming a table lookup
of the cross-reference table.
Figure 3 illustrates a card record with a key of SMITH
which serves as the argument in a programmed table lookup
of a cross-reference table. When the argument is found in
the table, the corresponding value (623'in this example)
will be the address of SMITH's record in the direct data set.
Key = SMITH ___,
Record #623
\
/ { SMITH J
-e=---
'\
\
'
Cross-Reference )
Table
I
SMITH 623
Figure 3. Direct Addressing Using a Cross-Reference Table
5
This technique of direct addressing allows space to be
allocated on the basis of the number of records in the data
set rather than on the range of keys. New records can be
added sequentially to the end of the data set space and their
location noted and placed in the cross-reference table.
The obvious disadvantages are that cross-referencing
requires the user to maintain the table, and core storage
and processing time is required to search and update the
table.
Indirect Addressing
A more common technique for organizing the data set
involves the use of indirect addressing. In indirect
addressing, the address of each record in the data set is
determined by a mathematical manipulation of the key. This
manipulation of the key is referred to as randomizing.
There are many different techniques of transforming a record
key (external identification) into the corresponding record
address (internal location). No attempt is made here to
describe or explain the various algorithms that might be
appropriate for your data set.
Figure 4 illustrates a record with a key of A360 which,
when run through a randomizing algorithm, yields the address
(127 in this example) of the record in the direct data set.
Key = A360
Record #127
\ /~ A360 ]
\i
\
A360
Randomizing
Scheme
I
)
127
Figure 4. Indirect Addressing
6
Overflow Record Handling
Characteristic of most randomizing schemes is the
synonym problem -- the transformation of two or more unique
keys into the same DASD address. The record that is written
where it belongs is called the home record. The second and
subsequent records with keys which convert to the same
address are called overflow records. A procedure must be
provided for storing elsewhere those overflow records whose
keys convert to an address that is already occupied. There
are many different techniques used to handle overflow records.
No attempt will be made here to examine them. Rather, we
shall discuss the method provided by BDAM called progressive
overflow.
Progressive overflow assumes that the entire data set
space is not 100% used, that is, there are buckets that are
not yet filled and that the overflow record may be stored
in one of them. The search for an empty bucket starts at
the address produced by the randomizing scheme and continues
through consecutive addresses.
Before
Adding F U 1
~
2
U 3
~
4
LI I---=-J
5 6
I~
7
~'.
Add F U 1
~
2
U 3
l 4
U 5
L:J
6
I~
7
After
Adding F '--_I
1
~ U~
2 3 4
L:J 5
I~U
6 7
Add K u~u
1 2 3 4 5 6 7
After
Adding K
1 2 3 4 5 6 7
Figure 5. Overflow Record Handling
7
Figure 5 illustrates a data set containing seven buckets
presently having three records. Let's suppose we add a
record with a key of F and that our randomizing scheme assigns
F to bucket 4. Since bucket 4 is already occupied, a search
is made for an empty bucket. Bucket 5 is empty and F is
placed in it. Next we add a record with a key of K and once
again let's suppose our randomizing scheme assigns K to
bucket 4. When we attempt to put K in bucket 4, we find it
is occupied so we attempt to put it in bucket 5. But bucket
5 is also occupied so we attempt to put it in bucket 6. This
process continues until an empty bucket is found, which in
this example is bucket 7.
In searching for an empty bucket in which to store an
overflow record, how does the system know when it encounters
an empty bucket? How far will the system search for an empty
bucket? Once an overflow record is stored in the data set,
how does the system ever retrieve it? ,The answers to these
questions will hopefully become answered at a later time.
For now, the handling of overflow records by the system
requires that the data set be recorded in the Count-Key-Data
format and that empty buckets be system dummy records. How
far the system will search is a function of the optional
"extended search" feature. Both system dummy records and
the extended search feature will be explained later.
8
RECORD REFERENCE METHODS
The READ and WRITE macros are used to retrieve and
store individual records (i.e., blocks). Which particular
record retrieved or stored is a function of the OPTCD and
KEYLEN parameters in the DCB and the "type", "block address",
and "key address" parameters in the READ or WRITE macro
instructions. Basically, the access method searches either
for a record which occupies a specific "bucket" or a record
with- a specific key.
Referencing a Specific Record
Retrieving or storing a specific record is requested
by specifying a DI "type" parameter in the READ/WRITE macro.
Which 'particular record retrieved/stored is determined by
the "block address" parameter in the READ/WRITE macro. The
"block address" parameter contains the core storage address
of the record address (left-most byte) of the particular
record. This is illustrated in the following figure.
READ DECB,DI,MYDCB,WORK,80,O,ADDE
MYDCB DCB DS~~~~
ADOR OS I!ddres~~
WORK OS SOC ~
;
.. / ...
.'
/
" 1-.-_.-_