IMS Concepts.docx

7/30/2019 IMS Concepts.docx

1/73

IMS Concepts

This article provides a high-level overview of IMS database concepts, terminology, and

database design considerations. It covers the following topics:

Overview

Hierarchical versus Relational Databases

Design Considerations

Overview

The term database means a collection of related data organized in a way that can be

processed by application programs. A database management system (DBMS) consists of a

set of licensed programs that define and maintain the structure of the database and provide

support for certain types of application programs. The types of database structures are

network, relational, and hierarchical. This manual presents information on IMS, a

hierarchical database management system from IBM*.

The IMS software environment can be divided into five main parts:

database

Data Language I (DL/I) DL/I control blocks data communications component (IMS TM) application programs

Figure 1-1 shows the relationships of the IMS components. We discuss each of these

components in greater detail in this and subsequent chapters.

Figure 1-1: IMS environment components.

IMS Database

Before the development of DBMSs, data was stored in individual files, or as flat files. With

this system, each file was stored in a separate data set in sequential or indexed format. To

retrieve data from the file, an application had to open the file and read through it to the

location of the desired data. If the data was scattered through a large number of files,

data access required a lot of opening and closing of files, creating additional I/O andprocessing overhead. To reduce the number of files accessed by an application,
https://communities.bmc.com/communities/docs/DOC-9908#overviewhttps://communities.bmc.com/communities/docs/DOC-9908#overviewhttps://communities.bmc.com/communities/docs/DOC-9908#databaseshttps://communities.bmc.com/communities/docs/DOC-9908#databaseshttps://communities.bmc.com/communities/docs/DOC-9908#designhttps://communities.bmc.com/communities/docs/DOC-9908#designhttps://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9908-9-10731/ims_fig1.gifhttps://communities.bmc.com/communities/docs/DOC-9908#designhttps://communities.bmc.com/communities/docs/DOC-9908#databaseshttps://communities.bmc.com/communities/docs/DOC-9908#overview


2/73

programmers often stored the same data in many files. This practice created redundant

data and the related problems of ensuring update consistency across multiple files. To

ensure data consistency, special cross-file update programs had to be scheduled following

the original file update.

The concept of a database system resolved many data integrity and data duplication issues

encountered in a file system. A database stores the data only once in one place and makes

it available to all application programs and users. At the same time, databases provide

security by limiting access to data. The user's ability to read, write, update, insert, or delete

data can be restricted. Data can also be backed up and recovered more easily in a single

database than in a collection of flat files.

Database structures offer multiple strategies for data retrieval. Application programs can

retrieve data sequentially or (with certain access methods) go directly to the desired data,

reducing I/O and speeding data retrieval. Finally, an update performed on part of the

database is immediately available to other applications. Because the data exists in only oneplace, data integrity is more easily ensured.

The IMS database management system as it exists today represents the evolution of the

hierarchical database over many years of development and improvement. IMS is in use at a

large number of business and government installations throughout the world. IMS is

recognized for providing excellent performance for a wide variety of applications and for

performing well with databases of moderate to very large volumes of data and

transactions.

DL/I

Because they are implemented and accessed through use of the Data Language I (DL/I), IMSdatabases are sometimes referred to as DL/I databases. DL/I is a command-level language,

not a database management system. DL/I is used in batch and online programs to access

data stored in databases. Application programs use DL/I calls to request data. DL/I then

uses system access methods, such as Virtual Storage Access Method (VSAM), to handle the

physical transfer of data to and from the database.

IMS databases are often referred to by the access method they are designed for, such as

HDAM, PHDAM, HISAM, HIDAM, and PHIDAM. IMS makes provisions for nine types of

access methods, and you can design a database for any one of them. We discuss each of

them in greater detail in Chapter 2, "IMS Structures and Functions." The point to rememberis that they are all IMS databases, even though they are referred to by access type.

Control Blocks

When you create an IMS database, you must define the database structure and how the

data can be accessed and used by application programs. These specifications are defined

within the parameters provided in two control blocks, also called DL/I control blocks:

database description (DBD) program specification block (PSB)

In general, the DBD describes the physical structure of the database, and the PSB describes

the database as it will be seen by a particular application program. The PSB tells the

application which parts of the database it can access and the functions it can perform onthe data.


3/73

Information from the DBD and PSB is merged into a third control block, the application

control block (ACB). The ACB is required for online processing but is optional for batch

processing.

Data Communications

The IMS Transaction Manager (IMS TM) is a separate set of licensed programs that provide

access to the database in an online, real-time environment. Without the TM component,

you would be able to process data in the IMS database in a batch mode only. With the IMS

TM component, you can access the data and can perform update, delete, and insert

functions online. As Figure 1-1 shows, the IMS TM component provides the online

communication between the user and DL/I, which, in turn, communicates with the

application programs and the operating system to access and process data stored in the

database.

Application Programs

The data in a database is of no practical use to you if it sits in the database untouched. Its

value comes in its use by application programs in the performance of business or

organizational functions. With IMS databases, application programs use DL/I callsembedded in the host language to access the database. IMS supports batch and online

application programs. IMS supports programs written in ADA, assembler, C, COBOL, PL/I, VS

PASCAL, and REXX.

top

Hierarchical versus Relational Databases

There are several types of database management systems, categorized generally by how

they logically store and retrieve data. The two most common types in use today are

relational and hierarchical. Each type has its advantages and disadvantages, and in many

organizations both types are used. Whether you choose a relational or hierarchical

database management system depends largely on how you intend to use the data beingstored.

Relational Database

In a relational database, data is stored in a table made up of rows and columns. A separate

table is created for logically related data, and a relational database may consist of hundreds

or thousands of tables.

Within a table, each row is a unique entity (or record) and each column is an attribute

common to the entities being stored. In the example database described in Table 1-1 on

page 1-9, Course No. has been selected as the key for each row. It was chosen because each

course number is unique and will be listed only once in the table. Because it is unique for

each row, it is chosen as the key field for that row. For each row, a series of columnsdescribe the attributes of each course. The columns include data on title, description,

instructor, and department, some of which may not be unique to the course. An instructor,

for instance, might teach more than one course, and a department may have any

number of courses. It is important early in design of a database to determine what will be

the unique, or key, data element.

Hierarchical Databases

Now let's look at the same data stored in a hierarchical format. This time the data is

arranged logically in a top-down format. In a hierarchical database, data is grouped in

records, which are subdivided into a series of segments. In the example Department

database on Figure 1-2 on page 1-8, a record consists of the segments Dept, Course, andEnroll.
https://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#top


4/73

In a hierarchical database, the structure of the database is designed to reflect logical

dependencies-certain data is dependent on the existence of certain other data. Enrollment

is dependent on the existence of a course, and, in this case, a course is dependent on the

existence of a department. In a hierarchical database, the data relationships are defined.

The rules for queries are highly structured. It is these fixed relationships that give IMS

extremely fast access to data when compared to a relational database. Speed of access

and query flexibility are factors to consider when selecting a DBMS.

Strengths and Weaknesses

Hierarchical and relational systems have their strengths and weaknesses. The relational

structure makes it relatively easy to code requests for data. For that reason, relational

databases are frequently used for data searches that may be run only once or a few times

and then changed. But the query-like nature of the data request often makes the relational

database search through an entire table or series of tables and perform logical comparisons

before retrieving the data. This makes searches slower and more processing-intensive. In

addition, because the row and column structure must be maintained throughout thedatabase, an entry must be made under each column for every row in every table, even

if the entry is only a place holder-a null entry. This requirement places additional storage

and processing burdens on the relational system.

With the hierarchical structure, data requests or segment search arguments (SSAs) may be

more complex to construct. Once written, however, they can be very efficient, allowing

direct retrieval of the data requested. The result is an extremely fast database system that

can handle huge volumes of data transactions and large numbers of simultaneous users.

Likewise, there is no need to enter place holders where data is not being stored. If a

segment occurrence isn't needed, it isn't inserted.

The choice of which type of DBMS to use often revolves around how the data will be used

and how quickly it should be processed. In large databases containing millions of rows or

segments and high rates of access by users, the difference becomes important. A very

active database, for example, may experience 50 million updates in a single day. For this

reason, many organizations use relational and hierarchical DBMSs to support their

data management goals.

Sample Hierarchical Database

To illustrate how the hierarchical structure looks, we'll design two very simple databases to

store information for the courses and students in a college. One database will storeinformation on each department in the college, and the second will contain information on

each college student.

In a hierarchical database, an attempt is made to group data in a one-to-many relationship.

An attempt is also made to design the database so that data that is logically dependent on

other data is stored in segments that are hierarchically dependent on the data. For that

reason, we have designated Dept as the key, or root, segment for our record, because the

other data would not exist without the existence of a department. We list each

department only once. We provide data on each course in each department. We have a

segment type Course, with an occurrence of that type of segment for each course in

the department. Data on the course title, description, and instructor is stored as fields


5/73

within the Course segment. Finally, we have added another segment type, Enroll, which will

include the student IDs of the students enrolled in each course.

In Figure 1-2, we also created a second database called Student. This database contains

information on all the students enrolled in the college. This database duplicates some of

the data stored in the Enroll segment of the Department database. Later, we will construct

a larger database that eliminates the duplicated data. The design we choose for our

database depends on a number of factors; in this case, we will focus on which data we will

need to access most frequently,

The two sample databases, Department and Student, are shown in Figure 1-2. The two

databases are shown as they might be structured in relational form in Table 1-1, Table 1-2,

and Table 1-3 on page 1-9.

Figure 1-2: Sample hierarchical databases for department and student.

Department Database

The segments in the Department database are as follows:

Dept

Information on each department. This segment includes fields for the department ID

(the key field), department name, chairman's name, number of faculty, and number

of students registered in departmental courses.

CourseThis segment includes fields for the course number (a unique identifier), course title,

course description, and instructor's name.

EnrollThe students enrolled in the course. This segment includes fields for student ID (the

key field), student name, and grade.

Student Database

The segments in the Student database are as follows:

StudentStudent information. It includes fields for student ID (key field), student name,

address, major, and courses completed.

BillingBilling information for courses taken. It includes fields for semester, tuition due,

tuition paid, and scholarship funds applied.

The dotted line between the root (Student) segment of the Student database and the Enroll

segment of the Department database represents a logical relationship based on data

residing in one segment and needed in the other. Logical relationships are explained indetail in "The Role of Logical Relationships" on page 2-55.
https://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9908-9-10732/ims_fig2.gif


6/73

Example Relational Structure

Tables 1-1, 1-2 and 1-3 show how the two hierarchical Department and Student databases

might be structured in a relational database management system. We have broken them

down into three tables-Course, Student, and Department. Notice that we have had to

change the way some data is stored to accommodate the relational format.

Course No. Course Title Description Instructor Dept ID

HI-445566 History 321 Survey course J. R. Jenkins HIST

MH-778899 Algebra 301 Freshman-level A.L. Watson MATH

BI-112233 Biology 340 Advanced course B.R. Sinclair BIOL

Table 1-1: Course database in relational table format.

Student ID Student Name Address Major

123456777 Jones, Bill 1212 N. Main History

123456888 Smith, Jill 225B Baker St Physics

123456999 Brown, Joe 77 Sunset St Zoology

Table 1-2: Student database in relational table format.

Dept ID Dept. Name Chairman Budget Code

HIST History J. B. Hunt L72

MATH Mathematics R. K. Turner A54

BIOL Biology E. M. Kale A25

Table 1-3: Department database in relational table format.

top

Design Considerations

Before implementing a hierarchical structure for your database, you should analyze the end

user's processing requirements, because they will determine how you structure the

database. To help you understand the business processing needs of the user, you can

construct a local view consisting of the following:

list of required data elements

controlling keys of the data elements data groupings for each process, reflecting how the data is used in business practice mapping of the data groups that shows their relationships

In particular, you must consider how the data elements are related and how they will be

accessed. The topics that follow should help you in that process.

Normalization of Data

Even though you have a collection of data that you want to store in a database, you may

have a hard time deciding how the data should be organized. Normalization of data refers

to the process of breaking data into affinity groups and defining the most logical, or

normal, relationships between them. There are accepted rules for the process of

data normalization. Normalization usually is discussed in terms of form. Although there are


7/73

five levels of normalization form, it is usually considered sufficient to take data to the third

normalization form. For most uses, you can think of levels of normalization as the following:

First normal form. The data in this form is grouped under a primary key-a unique identifier.In other words, the data occurs only once for each key value.

Second normal form. In this form, you remove any data that was only dependent on part ofthe key. For example, in Table 1-1 on page 1-9, Dept ID could be part of the key, but the

data is really only dependent on the Course No.

Third normal form. In this form, you remove anything from the table that is not dependenton the primary key. In Table 1-3, the Department table, if we included the name of the

University President, it would occur only once for each Dept ID, but it is in no way

dependent on Dept ID. So that information is not stored here. The other columns, Dept.

Name, Chairman, and Budget Code, are totally dependent on the Dept ID.

Example Database Expanded

At this point we have learned enough about database design to expand our original

example database. We decide that we can make better use of our college data by

combining the Department and Student databases. Our new College database is shown in

Figure 1-3.

Figure 1-3: College database (combining department and student databases).

The following segments are in the expanded College database:

CollegeThe root segment. One record will exist for each college in the university. The

key field is the College ID, such as ARTS, ENGR, BUSADM, and FINEARTS.

Dept

Information on each department within the college. It includes fields for the

department ID (the key field), department name, chairman's name, number

of faculty, and number of students registered in departmental courses.

CourseIncludes fields for the course number (the key field), course title,

course description, and instructor's name.

EnrollA list of students enrolled in the course. There are fields for student ID (key

field), student name, current grade, and number of absences.

Staff

A list of staff members, including professors, instructors, teaching assistants,

and clerical personnel. The key field is employee number. There are fields for

name, address, phone number, office number, and work schedule.

Student Student information. It includes fields for student ID (key field), student name,


8/73

address, major, and courses being taken currently.

Billing

Billing and payment information. It includes fields for billing date (key field),

semester, amount billed, amount paid, scholarship funds applied,

and scholarship funds available.

Academic

The key field is a combination of the year and the semester. Fields include grade

point average per semester, cumulative GPA, and enough fields to list courses

completed and grades per semester.

Data Relationships

The process of data normalization helps you break data into naturally associated groupings

that can be stored collectively in segments in a hierarchical database. In designing your

database, break the individual data elements into groups based on the processing functions

they will serve. At the same time, group data based on inherent relationships between data

elements.

For example, the College database (Figure 1-3) contains a segment called Student. Certaindata is naturally associated with a student, such as student ID number, student name,

address, and courses taken, Other data that we will want in our College database-such as a

list of courses taught or administrative information on faculty members-would not work

well in the Student segment.

Two important data relationship concepts are one-to-many and many-to-many. In the

College database, there are many departments for each college (Figure 1-3 shows only one

example), but only one college for each department. Likewise, many courses are taught by

each department, but a specific course (in this case) can be offered by only one

department. The relationship between courses and students is one of many-to-many, asthere are many students in any course and each student will take a number of courses. A

one-to-many relationship is structured as a dependent relationship in a hierarchical

database: the many are dependent upon the one. Without a department, there would be

no courses taught: without a college, there would be no departments.

Parent and child relationships are based solely on the relative positions of the segments in

the hierarchy, and a segment can be a parent of other segments while serving as the child

of a segment above it. In Figure 1-3, Enroll is a child of Course, and Course, although the

parent of Enroll, is also the child of Dept. Billing and Academic are both children of Student,

which is a child of College. (Technically, all of the segments except Collegeare dependents.)

When you have analyzed the data elements, grouped them into segments, selected a key

field for each segment, and designed a database structure, you have completed most of

your database design. You may find, however, that the design you have chosen does not

work well for every application program. Some programs may need to access a segment by

a field other than the one you have chosen as the key. Or another application may need to

associate segments that are located in two different databases or hierarchies. IMS has

provided two very useful tools that you can use to resolve these data requirements:

secondary indexes and logical relationships.


9/73

Secondary indexes let you create an index based on a field other than the root segment key

field. That field can be used as if it were the key to access segments based on a data

element other than the root key. Logical relationships let you relate segments in separate

hierarchies and, in effect, create a hierarchic structure that does not actually exist in

storage. The logical structure can be processed as if it physically exists, allowing you to

create logical hierarchies without creating physical ones. We discuss both of

these concepts in greater detail in Chapter 2, "IMS Structures and Functions."

Hierarchical Sequence

Because segments are accessed according to their sequence in the hierarchy, it is important

to understand how the hierarchy is arranged. In IMS, segments are stored in a top-down,

left-to-right sequence (see Figure 1-4). The sequence flows from the top to the bottom of

the leftmost path or leg. When the bottom of that path is reached, the sequence continues

at the top of the next leg to the right.

Understanding the sequence of segments within a record is important to understanding

movement and position within the hierarchy. Movement can be forward or backward and

always follows the hierarchical sequence. Forward means from top to bottom, andbackward means bottom to top. Position within the database means the current location at

a specific segment.

Hierarchical Data Paths

In Figure 1-4, the numbers inside the segments show the hierarchy as a search path would

follow it. The numbers to the left of each segment show the segment types as they would

be numbered by type, not occurrence. That is, there may be any number of occurrences of

segment type 04, but there will be only one type of segment 04. The segment type is

referred to as the segment code.

To retrieve a segment, count every occurrence of every segment type in the path and

proceed through the hierarchy according to the rules of navigation: top to bottom front to back (counting twins) left to right

For example, if an application program issues a GET-UNIQUE (GU) call for segment 6 in

Figure 1-4, the current position in the hierarchy is immediately following segment 6 (not

06). If the program then issued a GET-NEXT (GN) call, IMS would return segment 7.

As shown in Figure 1-4, the College database can be separated into four search paths:

The first path includes segment types 01, 02, 03, and 04. The second path includes segment types 01, 02, and 05. The third path includes segment types 01, 06, and 07. The fourth path includes segment types 01, 06, and 08.

The search path always starts at 01, the root segment.


10/73

Figure 1-4: Sequence and data paths in a hierarchy.

Database Records

Whereas a database consists of one or more database records, a database record consists

of one or more segments. In the College database, a record consists of the root segment

College and its dependent segments. It is possible to define a database record as only a rootsegment. A database can contain only the record structure defined for it, and a database

record can contain only the types of segments defined for it.

The term record can also be used to refer to a data set record (or block), which is not the

same thing as a database record. IMS uses standard data system management methods to

store its databases in data sets. The smallest entity of a data set is also referred to as a

record (or block). Two distinctions are important:

A database record may be stored in several data set blocks. A block may contain several whole records or pieces of several records.

In this article, we try to distinguish between database record and data set record where themeaning may be ambiguous.

Segment Format

A segment is the smallest structure of the database in the sense that IMS cannot retrieve

data in an amount less than a segment. Segments can be broken down into smaller

increments called fields, which can be addressed individually by application programs.

A database record can contain a maximum of 255 types of segments. The number of

segment occurrences of any type is limited only by the amount of space you allocate for the

database. Segment types can be of fixed length or variable length. You must define the size

of each segment type.

It is important to distinguish the difference between segment types and segment

occurrences. Course is a type of segment defined in the DBD for the College database.

There can be any number of occurrences for the Course segment type. Each occurrence of

the Course segment type will be exactly as defined in the DBD. The only differences in

occurrences of segment types is the data contained in them (and the length, if the segment

is defined as variable length).

Segments consist of two major parts, a prefix and the data being stored. (SHSAM and

SHISAM database segments consist only of the data, and GSAM databases have no


11/73

segments.) The prefix portion of a segment is used to store information that IMS uses in

managing the database.

Prefix Data

segment

code

1 byte

delete byte

1 byte

counters and

pointers

4 bytes per

element

size

field

2 bytes

seq.

(key)

field

data

length varies, based

on a minimum and

maximum size

Figure 1-5: Format of a variable-length segment.

Figure 1-6 shows the format of a fixed length segment. In the fixed-length segment, there is

no size field.

Prefix Data

segment

code

1 byte

delete byte

1 byte

counters and

pointers

4 bytes per

element

size

field

2 bytes

seq.

(key)

field

data

length is whatever

is specified for

the segment

Figure 1-6: Format of a fixed-length segment.

The fields contained in an IMS database segment are described below. In the data portion,

you can define the following types of fields: a sequence field, data fields.

Segment

Code

IMS uses the segment code field to identify each segment type stored in

a database. A unique identifier consisting of a number from 1 to 255 is

assigned to each segment type when IMS loads the database. Segment types are

numbered in ascending sequence, beginning with the root segment as 1 and

continuing through all dependent segment types in hierarchic order.

Delete

Byte

IMS uses this byte to track the status of a deleted segment. The space it occupied

may (or may not) be available for use.

Counters and Pointers

This area exists in hierarchic direct access method (HDAM) and hierarchic indexed direct

access method (HIDAM) databases and, in some cases, hierarchic indexed sequential access

method (HISAM) databases. It can contain information on the following elements:

Counters - Counter information is used when logical relationships are defined. Logicalrelationships are discussed in detail in "The Role of Logical Relationships" on page 2-55.

Pointers - Pointers consist of one or more addresses of segments pointed to by thissegment. Pointers are discussed in detail in "Pointer Types" on page 2-37.

Size Field

For variable-length segments, this field states the size of the segment, including the sizefield (2 bytes).


12/73

Sequence (Key) Field

The sequence field is often referred to as the key field. It can be used to keep occurrences

of a segment type in sequence under a common parent, based on the data or value entered

in this field. A key field can be defined in the root segment of a HISAM, HDAM, or HIDAM

database to give an application program direct access to a specific root segment. A key field

can be used in HISAM and HIDAM databases to allow database records to be retrieved

sequentially. Key fields are used for logical relationships and secondary indexes.

The key field not only can contain data but also can be used in special ways that help you

organize your database. With the key field, you can keep occurrences of a segment type in

some kind of key sequence, which you design. For instance, in our example database you

might want to store the student records in ascending sequence, based on student ID

number. To do this, you define the student ID field as a unique key field. IMS will store the

records in ascending numerical order. You could also store them in alphabetical order

by defining the name field as a unique key field.

Three factors of key fields are important to remember:

The data or value in the key field is called the key of the segment. The key field can be defined as unique or non-unique. You do not have to define a key field in every segment type

Data

You define data fields to contain the actual data being stored in the database. (Remember

that the sequence field is a data field.) Data fields, including sequence fields, can be defined

to IMS for use by applications programs. Field names are used in SSAs to qualify calls. See

"Segment Search Argument" on page 3-22 for more information.

Segment DefinitionsIn IMS, segments are defined by the order in which they occur and by their relationship

with other segments:

Root segmentThe first, or highest segment in the record. There can be only one

root segment for each record. There can be many records in a database.

Dependent

segmentAll segments in a database record except the root segment.

Parent

segment

A segment that has one or more dependent segments beneath it in

the hierarchy.

Child segment A segment that is a dependent of another segment above it inthe hierarchy.

Twin segmentA segment occurrence that exists with one or more segments of the same

type under a single parent.

Segment Edit/Compression

IMS provides a Segment Edit/Compression Facility that lets you encode, edit, or compress

the data portion of a segment in full-function or Fast Path DEDB databases. You can use the

Edit/Compression Facility to perform the following tasks:

encode data-make data unreadable to programs that do not have the edit routine to see itin decoded form


13/73

edit data-allow an application program to receive data in a format or sequence other thanthat in which it is stored

compress data-use various compression routines, such as removing blanks or repeatingcharacters, to reduce the amount of DASD required to store the data

The Segment Edit/Compression Facility allows two types of data compression:

data compression-compression that does not change the content or relative position of thekey field. For variable-length segments, the size field must be updated to show the length

of the compressed segment. For segments defined to the application as fixed-length, a 2-

byte field must be added at the beginning of the data portion by the compression routine

to allow IMS to determine storage requirements.

key compression-compression of data within a segment that can change the relativeposition, value, or length of the key field and any other fields except the size field. In the

case of a variable-length segment, the segment size field must be updated by the

compression routine to indicate the length of the compressed segment.

Pointers

IMS uses pointers to locate related segments in a database. Pointers are physically stored in

the prefix portion of a segment. Each pointer contains the relative byte address (RBA) of

another segment. When the database is loaded, IMS creates pointers according to the DBD

you specified. During subsequent processing, IMS uses pointers to traverse the database

(navigate from segment to segment). IMS automatically maintains the contents of pointers

when segments are added, deleted, and updated.

IMS Structures and Functions

VERSION 6

Created on: Mar 24, 2010 7:36 AM byAnirban Dutta- Last Modified: Mar 29, 2010 9:05 AM

byAnirban Dutta

Part 2 in a series (Part 1|Part 3)

This article discusses IMS database organization, access methods, secondary indexes, and

logical relationships. It covers the following topics:

Control Blocks

Access Methods

Hierarchic Sequential DatabasesHierarchic Direct Databases
https://communities.bmc.com/communities/people/anirbanduttahttps://communities.bmc.com/communities/people/anirbanduttahttps://communities.bmc.com/communities/people/anirbanduttahttps://communities.bmc.com/communities/people/anirbanduttahttps://communities.bmc.com/communities/people/anirbanduttahttps://communities.bmc.com/communities/people/anirbanduttahttps://communities.bmc.com/communities/docs/DOC-9908https://communities.bmc.com/communities/docs/DOC-9908https://communities.bmc.com/communities/docs/DOC-9908https://communities.bmc.com/communities/docs/DOC-9973https://communities.bmc.com/communities/docs/DOC-9973https://communities.bmc.com/communities/docs/DOC-9973https://communities.bmc.com/communities/docs/DOC-9943#blockshttps://communities.bmc.com/communities/docs/DOC-9943#blockshttps://communities.bmc.com/communities/docs/DOC-9943#methodshttps://communities.bmc.com/communities/docs/DOC-9943#methodshttps://communities.bmc.com/communities/docs/DOC-9943#sequentialhttps://communities.bmc.com/communities/docs/DOC-9943#sequentialhttps://communities.bmc.com/communities/docs/DOC-9943#directhttps://communities.bmc.com/communities/docs/DOC-9943#directhttps://communities.bmc.com/communities/docs/DOC-9943/diff?secondVersionNumber=6https://communities.bmc.com/communities/docs/DOC-9943#directhttps://communities.bmc.com/communities/docs/DOC-9943#sequentialhttps://communities.bmc.com/communities/docs/DOC-9943#methodshttps://communities.bmc.com/communities/docs/DOC-9943#blockshttps://communities.bmc.com/communities/docs/DOC-9973https://communities.bmc.com/communities/docs/DOC-9908https://communities.bmc.com/communities/people/anirbanduttahttps://communities.bmc.com/communities/people/anirbandutta


14/73

Fast Path Databases

The Role of Secondary Indexes

The Role of Logical Relationships

Control Blocks

When you create an IMS database, you tell IMS what the physical structure of the database

will be-the segment names, segment lengths, the fields that each segment will contain, the

segment's position in the hierarchy, and so on. You also tell IMS what segments can be

accessed, whether they can be updated, deleted, or new ones inserted, and other access

control specifications. You do this through a series of specifications that will be contained in

control blocks, also called DL/I control blocks, because the DL/I command language is used

perform the data manipulation functions. Control blocks do just what the name implies-

they control the way in which IMS will structure and access the data stored in the database.

The data structure and control specifications you write will be contained in three major

control blocks:

DBD, which describes the database organization and access methods PSB, which describes an application program's view and use of the database ACB, which combines information from the DBD and PSB

Database Description

A database description (DBD) is a series of macro statements that define the type of

database, all segments and fields, and any logical relationships or indexing. DBD macro

statements are submitted to the DBDGEN utility, which generates a DBD control block and

stores it in the IMS.DBDLIB library for use when an application program accesses the

database.

Figure 2-1 shows a sample DBD for an HDAM database. When the DBD is assembled and

link-edited, a load module is created and stored in an IMS DBDLIB library. In the DBDGEN

process, each segment is assigned a segment code, a one-byte value in ascending sequence,that is used to identify the segment in physical storage.

In the DBD statement, an IMS access method and a system access method are specified

(HDAM, OSAM in this example). The roles of the two access methods are discussed in

greater detail in "Access Methods."

Fields within each segment can be defined as key fields or non-key search fields for use by

application programs in retrieving segments. A key field is used for searching and

sequencing. Each segment occurrence will be placed in a database record according to the

sequence of the key fields. In Figure 2-1, the statement for field COLLID (college ID) is

defined as a sequence field (SEQ) and as unique (U). Only fields that will be used in SSAs or

that are key fields must be defined in the DBD.

Figure 2-1: DBD for an HDAM database with secondary index.

The DBD contains the following statements:
https://communities.bmc.com/communities/docs/DOC-9943#pathhttps://communities.bmc.com/communities/docs/DOC-9943#pathhttps://communities.bmc.com/communities/docs/DOC-9943#indexeshttps://communities.bmc.com/communities/docs/DOC-9943#indexeshttps://communities.bmc.com/communities/docs/DOC-9943#rolehttps://communities.bmc.com/communities/docs/DOC-9943#rolehttps://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10748/ims2-1.gifhttps://communities.bmc.com/communities/docs/DOC-9943#rolehttps://communities.bmc.com/communities/docs/DOC-9943#indexeshttps://communities.bmc.com/communities/docs/DOC-9943#path


15/73

DATASETDefines the DDname and block size of a data set. One DATASET statement

is required for each data set group.

SEGM

Defines a segment type, its position in the hierarchy, its physical characteristics,

and its relationship to other segments. Up to 15 hierarchic levels can be defined.

The maximum number of segment types for a single database is 255.

FIELDDefines a field within a segment. The maximum number of fields per segment is

255. The maximum number of fields per database is 1,000.

LCHILD

Defines a secondary index or logical relationship between two segments. It also is

used to define the relationship between a HIDAM index and the root segment of

the database.

XDFLD

Used only when a secondary index exists. It is associated with the target segment

and specifies the name of the indexed field, the name of the source segment, and

the field to be used to create the secondary index. See "The Role of Secondary

Indexes" for more information.

DBDGEN Indicates the end of statements defining the DBD.

END Indicates to the assembler that there are no more statements.

DBD Names the database being described and specifies its organization.

Program Specification BlockThe program specification block (PSB) is a series of macro statements that describe the data

access characteristics of an application program. Among other things, the PSB specifies:

all databases that the application program will access which segments in the database that the application program is sensitive to how the application program can use the segments (inquiry or update)

A PSB consists of one or more program communication blocks (PCBs). The PCB specifies the

segments to which the application program can have access and the processing

authorization for each segment. You define a PCB for each database (or each view of the

database) accessed by the application program. In the application program host code, you

specify the PSB for that application.

For each PCB, you must code a corresponding block in the application program's linkage

section. These data communication I/O areas are used for communication between IMS

and the application. (There are actually two types of PCBs, a database PCB and a data

communications PCB.)

PCBs contain SENSEG (sensitive segment) and SENFLD (sensitive field) statements. These

statements allow you to specify which segments and fields the application program will

"see." If you define a segment as sensitive, it will be accessible to the application. If you do

not, it will be ignored by the application program. This gives you great flexibility in creatingthe views that application programs will have of your database.


16/73

The PSB macros are used as input to the PSBGEN utility, a macro assembler that generates

a PSB control block. The PSB control block is stored in the IMS.PSBLIB library for use during

database processing. There can be many PSBs for one DBD.

Figure 2-2 shows the structure of PSB generation input.

Figure 2-2: Sample PSBGEN generation input.

The PSB statements include the following:

PCB

Defines the database to be accessed by the application program. The statement

also defines the type of operations allowed by the application program. Each

database requires a separate PCB statement. PSB generation allows for up to 255

database PCBs (less the number of alternate PCBs defined).

SENSEG

Defines the segment types to which the application program will be sensitive. A

separate SENSEG statement is required for each segment type. If a segment is

defined as sensitive, all the segments in the path from the root to that segment

must also be defined as sensitive. Specific segments in the path can be exemptedfrom sensitivity by coding PROCOPT=K in the SENSEG statement.

SENFLD

Defines the fields in a segment type to which the application program is sensitive.

Can be used only in association with field-level sensitivity. The SENFLD statement

must follow the SENSEG statement to which it is related.

PROCOPTDefines the type of access to a database or segment. PROCOPTs can be used

on the PCB or SENSEG statements. Primary PROCOPT codes are as follows:

G read only

R replace, includes G

I insert

D delete, includes G

A get and update, includes G, R, I, D

K used on SENSEG statement; program will have key-only sensitivity to

this segment
https://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10751/ims2-2.gif


17/73

L load database

Secondary PROCOPT codes are as follows:

E exclusive use of hierarchy or segments

O get only, does not lock data when in use

P must be used if program will issue path call using the D command code

S sequential (LS is required to load HISAM and HIDAM databases; GS gets

in ascending sequence)

Application Control Block

Application control blocks (ACBs) are created by merging information from PSBs and DBDs.

For online applications, ACBs must be prebuilt using the ACB maintenance utility. For batch

applications, ACBs can be built dynamically using DBDLIB and PSBLIB as input (PARM=DL/I)

or the prebuilt ACB from ACBLIB can be used (PARM=DBB). The ACBGEN process is shown

in Figure 2-3.

Figure 2-3: ACB generation.

Prebuilt ACBs require less time to schedule an application program and use less storage.

The ACB maintenance utility also provides some error-checking capability.

ACBs can be built for all PSBs, for particular PSBs, or for all PSBs that reference a particular

DBD. Prebuilt ACBs are stored in the IMS.ACBLIB library. During ACB generation, the ACB

maintenance utility must have exclusive control of the IMS.ACBLIB. Because of this, the

utility must be executed using an IMS.ACBLIB that is not currently allocated to an active IMS

system. You can execute the ACB maintenance utility against an inactive copy of ACBLIB,

then use the IMS Online Change function to make the new members available to an

active IMS online system.

top

Access Methods

IMS accesses data after it has been retrieved from DASD and places it in a buffer pool in

memory. The task of retrieving the data from DASD is performed by one of several system

access methods. These should not be confused with IMS access methods such as HSAM,

HISAM, HDAM, HIDAM, and so on. IMS access methods are actually types of database

organizations. In IMS terminology, however, databases often are referred to by their IMSaccess method. An IMS database definition must always specify an IMS access method and
https://communities.bmc.com/communities/docs/DOC-9943#tophttps://communities.bmc.com/communities/docs/DOC-9943#tophttps://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10752/ims2-3.gifhttps://communities.bmc.com/communities/docs/DOC-9943#top


18/73

a system access method. In some cases, you can choose the type of system access method

you want to use. In other cases, the system access method is dictated by the IMS access

method. HISAM, for instance, uses only VSAM.

Both the system and IMS access methods are used for IMS database retrieval and update.

Application programs specify the data to retrieve and make a DL/I call to the system access

method. The system access method returns a block of data to IMS. The IMS access method

then locates the data within the block and passes it to the application program. The IMS

database types and their access methods are shown in Table 2-1.

Table 2-1: IMS database and system access types.

VSAM

In the discussion on HISAM and HIDAM databases later in this chapter, you will find

reference to VSAM, particularly in association with VSAM key-sequenced data sets (KSDSs)

and entry-sequenced data sets (ESDSs), because of the way in which certain databases use

these data sets. Before discussing the various IMS access methods, it is helpful to have an

understanding of VSAM's role in the storage and retrieval of data. VSAM performs the

physical I/O of data for IMS. It retrieves the data from DASD and places it in the mainstorage buffer pool for use by IMS. When processing has been completed, VSAM returns

the data to DASD, where it is stored until needed again. To perform these functions,

VSAM uses its own set of data storage and retrieval structures.

A VSAM data set consists of a set of records. The records are grouped into control intervals

(CIs), which in turn are grouped into larger groupings called control areas (CAs). The layout

of a control interval is shown in Figure 2-4.

Figure 2-4: VSAM control interval layout.

A VSAM CI consists of records, free space, and control information. You can determine the

size of a CI or let VSAM do it for you. When you define the size of a CI for a data set, all CIs

in the data set will be the same size. When you define the CI, you also determine the

percentage of free space to be designated. You will attempt to create enough free space to

avoid CI splits while not using so much free space that you waste DASD. CI splits occur when

there is no room to insert another record; consequently, VSAM moves half of the records

from the CI where the record was to be inserted to a new CI. CI splits are a costly overhead,

especially in high-activity systems. (You can correct CI splits by reorganizing the database.)

CIs are grouped inside a control area (CA). The goal is to have enough unused CIs to allow

new data to be added without causing a CA split. CA splits are more processing-intensive

than CI splits. On the other hand, you don't want to waste DASD by defining too many

unused CIs. For information on calculating space requirements, refer to the IBM manuals

IMS/ESA Administration Guide: Database Manager and IMS/ESA Administration Guide:

System.

The control information portion of the CI contains two types of fields:


19/73

The record definition field (RDF) contains information on the records stored in the CI, theirlength, and whether they are fixed or variable length.

The control interval definition field (CIDF) contains information on the CI itself. It keepstrack of the amount of free space available and where the free space is located relative to

the beginning of the CI. CIs have only one CIDF but may have a variable number of RDFs,

depending on whether the CI contains fixed-length or variable-length records or a

combination of the two.

Sequence Sets and Indexes

For KSDSs, VSAM keeps track of all CAs and CIs through the use of two levels of indexing-

the sequence set and the index set.

VSAM maintains a sequence set record for each CA in the data set. The sequence set record

contains an entry for each CI in the CA. Each entry contains the key of the highest record in

the CI and a pointer to the CI. The index contains an entry for each sequence set record.

This gives the index an entry for each CA, since there is a sequence set for every CA. Each

index entry contains the key of the highest record in its CA and a pointer to the

sequence set record for that CA.

By following the values of record keys from index to sequence set to CA to CI, VSAM can

locate any record in the data set. When VSAM reaches the CI, it can obtain record

information from the CIDF and RDFs of the CI. The example in Figure 2-5 illustrates this

concept.

Figure 2-5: Structure of VSAM index set and sequence set records.

Key-Sequenced Data Sets


20/73

The data sets we have described so far have been key-sequenced data sets (KSDSs). You can

see that the name derives from the way VSAM stores and retrieves records based on the

record key.

VSAM can retrieve the records in a KSDS in a number of ways. The simplest and most

obvious way is to read each record in the logical order (lowest key to highest key) in which

they are stored. This is called sequential retrieval. Obviously, this method has limitations if

you want only some of the records or if you want them in other than key sequence order.

VSAM can use the key sequence retrieval method to return only a portion of the records.

This method is called keyed sequential retrieval or skip sequential retrieval. With this

method, you specify the keys of the records you want retrieved, but they must be in

ascending order. Another method, addressed sequential retrieval, locates the records to be

retrieved by their RBA (relative byte address-the number of bytes from the beginning of the

data set to the beginning of the record). You must supply the RBAs to VSAM. Addressed

sequential retrieval can be used with KSDSs but is primarily designed for ESDSs.

VSAM can also retrieve KSDS records directly. You provide the record key, and VSAM uses

the index set and sequence set to navigate its way to the correct CI and to the record you

requested. With this method, you can retrieve records in any order.

VSAM can retrieve a record directly by its RBA. This method, addressed direct retrieval, like

addressed sequential retrieval, is designed primarily for ESDSs.

Entry-Sequenced Data Sets

Entry-sequenced data sets (ESDSs) are stored in the order in which they are loaded, rather

than by key sequence. With ESDSs, VSAM does not create an index and does not reserve

free space. No index is needed because there are no record keys to track. Likewise, freespace is not needed because the next record added to the data set is stored at the end of

the existing set of records. If a record is too large to fit in the CI being loaded, VSAM creates

a new CI and puts the record there. VSAM does not attempt to use space that may be left

at the end of each CI.

ESDSs are retrieved only by RBA using either addressed sequential retrieval or addressed

direct sequential retrieval. With addressed sequential retrieval, you give VSAM the RBA of

the first record. It retrieves the succeeding records by computing their RBA based on the

record length field of each record's RDF. With the addressed direct method, you must

supply VSAM with the RBA of each record you want.

Because of their storage and retrieval mechanisms, ESDSs have certain limitations that

make them less attractive for many applications. Although updating is relatively simple,

adding and deleting records proves more difficult. With updating, you read the record,

enter changes, and rewrite it, without changing the record length. To delete, you read the

record and mark it for deletion, but VSAM does not physically delete the record or reclaim

the unused space. To add a record, you must add it at the end of the data set.

QSAM

The queued sequential access method (QSAM) processes records sequentially from the

beginning of the data set. QSAM groups logical records into physical blocks before writingthem to storage and handles the blocking and deblocking of records for you. QSAM is


21/73

typically used by application programs that retrieve or create a single member at a time

within a partitioned data set (PDS). The characteristics of a member of a PDS-which is a

collection of sequentially organized members-are the same as those of a sequential data

set.

BSAM

The basic sequential access method (BSAM) allows you to read and write physical records

only. It does not perform blocking or deblocking of records. With BSAM, you can begin

processing a data set at any point

BDAM

The basic direct access method (BDAM) allows you to write or retrieve records directly by

address, using the physical track, relative track, or relative record number.

OSAM

The overflow sequential access method (OSAM) was developed for use with DL/I databases.

It combines many features of sequential access methods and of BDAM. To the operating

system, an OSAM data set appears the same as a sequential data set. An OSAM data set can

be read with BSAM or QSAM. OSAM allows direct access to records.Database Organizations

The nine types of databases supported by IMS can be grouped by their IMS access method.

Hierarchic sequentially accessed databases include

HSAM SHSAM HISAM SHISAM GSAM

Hierarchic direct databases include

HDAM HIDAM

Fast Path databases provide fast access with limited functionality

DEDB MSDB

top

Hierarchic Sequential Databases

The earliest IMS database organization types were based on sequential storage and access

of database segments. Hierarchic sequential databases share certain characteristics.

Compared to hierarchic direct databases, which we will discuss later, hierarchic sequential

databases are of simpler organization. The root and dependent segments of a record arerelated by physical adjacency. Access to dependent segments is always sequential. Deleted

dependent segments are not physically removed but are marked as deleted. Hierarchic

sequential databases can be stored on tape or DASD.

HSAM

In a hierarchic sequential access method (HSAM) database, the segments in each record are

stored physically adjacent. Records are loaded sequentially with root segments in ascending

key sequence. Dependent segments are stored in hierarchic sequence. The record format is

fixed-length and unblocked. An HSAM database is updated by rewriting the entire

database. Although HSAM databases can be stored on DASD or tape, HSAM is basically a

tape-based format. Figure 2-6 shows an HSAM database record and segment format.


22/73

Figure 2-6: HSAM database segment structure.

IMS identifies HSAM segments by creating a two-byte prefix consisting of a segment code

and a delete byte at the beginning of each segment. HSAM segments are accessed through

two operating system access methods:

basic sequential access method (BSAM) queued sequential access method (QSAM)

QSAM is always used as the access method when the system is processing online, but you

can specify either method for batch processing through the PROCOPT parameter in the

PCB.

Entry to an HSAM database is through GET UNIQUE (GU) or GET NEXT (GN) calls. The first

call starts at the beginning of the database and searches sequentially through the records

until it locates the requested segment. Subsequent calls use that position as the starting

point for calls that process forward in the database.

HSAM databases are limited by the strictly sequential nature of the access method. DELETE

(DLET) and REPLACE (REPL) calls are not allowed, and INSERT (ISRT) calls are allowed only

during the database load. Field-level sensitivity is provided, but HSAM databases are limited

in the number of IMS options they can use.

Because of the numerous limitations, HSAM databases see limited use and are reserved

primarily for applications that require sequential processing only.

SHSAM

A simple HSAM (SHSAM) database contains only one type of segment-a fixed-length root

segment. Because there is no need for a segment code and deletes are not allowed, there is

no need for a prefix portion of a SHSAM database segment. Because they contain only user

data, SHSAM databases can be accessed by BSAM and QSAM. The only DL/I calls used with

SHSAM databases are the GET calls. Like HSAM, SHSAM database segments can be deleted

or inserted only during a reload.HISAM

The hierarchic indexed sequential access method (HISAM) database organization adds some

badly needed capabilities not provided by HSAM. Like HSAM, HISAM databases store

segments within each record in physically adjacent sequential order. Unlike HSAM, each

HISAM record is indexed, allowing direct access to each record. This eliminates the need to

read sequentially through each record until the desired record is found. As a result, random

data access is considerably faster than with HSAM. HISAM databases also provide a method

for sequential access when that is needed.

A HISAM database is stored in a combination of two data sets. The database index and all

segments in a database record that fit into one logical record are stored in a primary data


23/73

set that is a VSAM KSDS. Remaining segments are stored in the overflow data set, which is a

VSAM ESDS. The index points to the CI containing the root segment, and the logical record

in the KSDS points to the logical record in the ESDS, if necessary.

If segments remain to be loaded after the KSDS record and the ESDS record have been

filled, IMS uses another ESDS record, stores the additional segments there, and links the

second ESDS record with a pointer in the first record. You determine the record length for

the KSDS and the ESDS when you create the DBD for the database.

If segments are deleted from the database, they are still physically present in the correct

position within the hierarchy, but a delete byte is set to show that the record has been

deleted. Although the segment is no longer visible to the application program, it remains

physically present and the space it occupies is unavailable until the database is reorganized.

The only exception to this is the deletion of a root segment where the logical record in the

VSAM KSDS is physically deleted and the index entry is removed; any VSAM ESDS logical

records in the overflow data set are not be deleted or updated in any way.

Inserting segments into a HISAM database often entails a significant amount of I/O activity.

Because IMS must enforce the requirement for segments to be physically adjacent and in

hierarchic order, it will move existing segments within the record or across records to make

room for the insertion; however, any dependent segments are not flagged as deleted. To

facilitate indexing, HISAM databases must be defined with a unique sequence field in each

root segment. The sequence fields are used to construct the index.

HISAM databases are stored on DASD, and data access can be much faster than with HSAM

databases. All DL/I calls can be used against a HISAM database. Additionally, HISAMdatabases are supported by a greater number of IMS and MVS options.

HISAM databases work well for data that requires direct access to records and sequential

processing of segments within each record.

Figure 2-7 shows the database structure for HISAM. Notice that four ESDS records have

been used in loading one logical record. The arrows represent pointers.


24/73

Figure 2-7: HISAM database structure.

HISAM Segment Structure

Figure 2-8 shows the HISAM segment structure.

Figure 2-8: HISAM segment structure.

A HISAM segment contains the following fields:

Segment

Code

1 byte. The segment code byte contains a one-byte unsigned binary number that

is unique to the segment type within the database. The segments are numbered

in hierarchic order, starting at 1 and ending with 255 (X'01' through X'FF').

Delete

Byte1 byte. The delete byte contains a set of flags.


The appearance of this area depends on the logical relationship status of the segment:

o If the segment is not a logical child or logical parent, this area is omitted.o If the segment is a logical child, and if a direct pointer (see "Pointer Types") is specified (the

logical parent must be in an HD database), the four-byte RBA of the logical parent will be

present.

o If the segment is a logical parent and has a logical relationship that is unidirectional orbidirectional with physical pairing, a four-byte counter will exist.

If the segment is a logical parent and has one or more logical relationships that arebidirectional with virtual pairing, then for each relationship there is a four-byte RBA pointer
https://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10757/ims2-8.gifhttps://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10756/ims2-7.gifhttps://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10757/ims2-8.gifhttps://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10756/ims2-7.gif


25/73

to the first logical child segment (a logical child first pointer) and, optionally, a four-byte

RBA pointer to the last logical child segment (a logical child last pointer), depending on

whether you specified LCHILD=SNGL or LCHILD=DBLE in the DBD.

There is only one counter in a segment, but there can be multiple logical child first (LCF) and

logical child last (LCL) pointers. The counter precedes the pointers. The pointers are in the

order that the logical relationships are defined in the DBD, with a logical child first pointer

before a logical child last pointer.

Figure 2-9 shows a segment with multiple logical child pointers.

Figure 2-9: Multiple logical child pointers in a segment.

Data

The length of the data area (which is specified in the DBD) can be a fixed length or avariable length. For a logical child segment with symbolic keys (PARENT=PHYSICAL on the

SEGM statement), the concatenated key of the logical parent will be at the start of the

segment.

If the segment is variable length, the first two bytes of the data area are a hexadecimal

number that represents the length of the data area, including the two-byte length field.

SHISAM

As is the case with SHSAM, a simple HISAM (SHISAM) database contains only a root

segment, and its segment has no prefix portion. SHISAM databases can use only VSAM as

their access method. The data must be stored in a KSDS. All DL/I calls can be used with

SHISAM databases, and their segments can be accessed by DL/I calls and VSAM macros.

GSAM

Generalized sequential access method (GSAM) databases are designed to be compatible

with MVS data sets. They are used primarily when converting from an existing MVS-based

application to IMS because they allow access to both during the conversion process. To be

compatible with MVS data sets, GSAM databases have no hierarchy, database records,

segments, or keys. GSAM databases can be based on the VSAM or QSAM/BSAM MVS access

methods. They can have fixed-length or variable-length records when used with VSAM or

fixed-length, variable-length, or undefined-length records when used with QSAM/BSAM.

Top

Hierarchic Direct Databases

Hierarchic direct access method (HDAM) and hierarchic indexed direct access method

(HIDAM) databases are referred to collectively as HD databases. The hierarchic direct

databases were developed to overcome some of the deficiencies of sequential access

databases. HD databases share these characteristics:

Pointers are used to relate segments. Deleted segments are physically removed. VSAM ESDS or OSAM data sets are used for storage. HD databases are stored on DASD. HD databases are of a more complex organization than sequentially organized databases.

The following sections discuss HDAM, PHDAM, HIDAM and PHIDAM

database organizations. Because pointers play such an integral role in direct

access databases, they are referenced frequently in the text. Pointers are four-
https://communities.bmc.com/communities/docs/DOC-9943#tophttps://communities.bmc.com/communities/docs/DOC-9943#tophttps://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10758/ims2-9.gifhttps://communities.bmc.com/communities/docs/DOC-9943#top


26/73

byte address values that give the offset from the beginning of the data set of the segment

being addressed. They tie the segments together without the need for segments to be

physically adjacent. Segments can be inserted or deleted without the need to move other

segments. There are different types of pointers. Pointers are discussed in greater detail in

"Pointer Types" below.

HDAM

HDAM databases are typically used when you need fast access to the root segment of the

database record, usually by direct access. In a hierarchic direct access method (HDAM)

database, the root segments of records are randomized to a storage location by an

algorithm that converts a root's key into a storage location. No index or sequential ordering

of records or segments is involved. The randomizing module reads the root's key and,

through an arithmetic technique, determines the storage address of the root segment. The

storage location to which the roots are randomized are called anchor points or root anchor

points (RAPs). The randomizing algorithm usually attempts to achieve a random distribution

of records across the data set.

Theoretically, randomizing the location of records minimizes the number of accesses

required to retrieve a root segment.

The randomizing technique results in extremely fast retrieval of data, but it usually does not

provide for sequential retrieval of records. This can be achieved in HDAM databases

through the use of secondary indexes or by using a physical-key-sequencing randomizer

module.

The advantage of HDAM is that it does not require reading an index to access the database.

The randomizing module provides fast access to root segments and to the paths ofdependent segments. It uses only the paths of the hierarchy needed to reach the segment

being accessed, further increasing access speed. The disadvantage is that you cannot

process HDAM databases in key sequence unless the randomizing module stores root

segments in physical key sequence.

An HDAM database consists of one data set split into two parts: the root addressable area

(RAA) and the overflow area. The data set can be a VSAM ESDS or an OSAM data set. You

specify which access method to use in the DBD ACCESS parameter.

In designing an HDAM database, you decide the size of the RAA and the number of CIs (orblocks, if you are using OSAM) that it will be broken down into. Within a CI or block, you

define the number of Raps The randomizer uses these parameters in establishing a storage

location for the root segment of the record. The CI does not contain just RAAs and Raps It

also is used for storage of the record's dependent segments. Each CI begins with a free

space element anchor point (FSEAP) area. The FSEAP is used to locate free or unused space

in the block. When IMS inserts new segments in the block, it updates the FSEAP.

Figure 2-10 shows how a record appears in an HDAM database.


27/73

Figure 2-10: HDAM database structure.

Three CIs are in the RAA, and four CIs are in the overflow area. Together, they make up the

data set. Each CI in the RAA contains two Raps In the example, the College recordrandomized to the second RAP in the second CI in the data set. The RAP does not contain

the root segment. It contains a four-byte pointer that contains the address of the root

segment.

After an initial load, segments within a database record are very likely to be grouped

together in blocks/CIs in hierarchic order. After update activity, this may not be the case.

To insert a root segment, IMS invokes the HDAM randomizer that has been specified in the

DBD. This determines the RAP from which the root must be chained.

When a segment has been inserted in an HDAM database, the segment is never moved so

that all the direct address pointers are preserved. The example assumes physical child first

pointers and twin forward pointers are specified for all segment types. If, as in the case

under consideration, there are more segments in the database record at initial load than

the BYTES parameter in the DBD will allow to be inserted in the RAA, all other segments will

be inserted into overflow. This is also true for multiple inserts of segments within the

same database record during the same synchronization point. If the database were to use

multiple data set groups, each secondary data set group would have the format of the

overflow part of an HDAM database.

If segments are deleted from the database segment, they are physically deleted from thedata set and the space is designated as free space.


28/73

Bit Maps

In HD databases, bit maps are used to keep track of free space. A bit map is a string of bits

that indicate whether enough space is available in a CI or OSAM block to contain an

occurrence of the longest segment defined for the data set. In a VSAM ESDS, the bit map is

located in the second CI of the data set. (The first CI is reserved.) In OSAM, bit maps are put

in the first block of the first extent of the data set.

As you read the bits in a bit map from left to right, they reflect the status of the

corresponding CI or block following the bit map. The bits are set as follows:

0 if not enough space exists in the CI or block 1 if there is adequate space for the longest segment specified for the data set.

For example, if the first bit is set to 1, the first CI or block following the block containing the

bit map will have space available. If the third bit in the bit map is set to 0, the third CI or

block following that containing the bit map will not have sufficient space available, and so

on. As data is added and new CIs are created, the number of CIs may reach the size limit of

the bit map. If so, another bit map is created and the process repeated for CIs thatare added subsequently.

Free Space Element Anchor Point

Another specialized field, the free space element anchor point (FSEAP), is used in

determining the availability of free space within a CI or block. As shown in Figure 2-10, the

FSEAP is located at the beginning of each CI or OSAM block in a data set. An FSEAP is made

up of two 2-byte fields. The first field contains the offset, in bytes, to the first free space

element (FSE) in the block. An FSE is associated with each area of free space within the

block or CI. The FSEs in a CI are chained together using pointers. The second field in

the FSEAP tells whether this block or CI contains a bit map.

Free Space ElementIn addition to an FSEAP, each OSAM block or VSAM CI contains free space elements (FSEs)

that provide information about the free space available in the block. The FSE makes up the

first eight bytes of each area of free space. It consists of the following fields:

Free space chain pointer (CP). This 2-byte field gives the offset in bytes to the beginning ofthe next FSE in the block or CI. If it is the last FSE in the block, it is set to zero.

Available length field (AL). This 2-byte field gives the length of the free space area, includingthe length of the FSE.

Task ID field (ID). This 4-byte field contains the task ID of the program that freed the space.This field is used to allow a program to reuse the same space during a specified period

without contending with other programs for the space.PHDAM

PHDAM databases are partitioned HDAM databases. Each PHDAM database is divided into

a maximum of 1001 partitions which can be treated as separate databases. A PHDAM

database is also referred to as a High Availability Large Database (HALDB).

HIDAM

Unlike HDAM, HIDAM databases use an index to locate root segments. HIDAM databases

are typically used when you would like to access database records randomly and

sequentially and also access segments randomly within a record. The index and the

database are stored in separate data sets. The index is stored as a single VSAM KSDS. The

database is stored as a VSAM ESDS or OSAM data set. The index stores the value of the key


29/73

of each root segment, with a four-byte pointer that contains the address of the root

segment.

The root segment locations in the index are stored in sequential order, allowing HIDAM

databases to be processed directly or sequentially. A disadvantage of HIDAM databases is

that the additional step required to scan an index makes access slower than with HDAM

databases.

When you access a record by root key, IMS searches for the key in the index and uses the

pointer to go directly to the record. If the PTR =TB or PTR=HB (twin backward pointer or

hierarchic backward pointer) parameter is defined for the root, the root segments are

chained together in ascending order.

Sequential processing is done by following this pointer chain. In HIDAM, Raps are

generated only if you specify the PTR=T or PTR=H (twin pointer or hierarchic

pointer) parameter for the root. When either of these pointer parameters is defined,

IMS puts one RAP at the beginning of the CI or block. Root segments within the CI or blockare chained by pointers from the most recently inserted back to the first root on the RAP.

The result is that the pointers from one root to the next cannot be used to process roots

sequentially. Sequential processing must be performed by using key values, which requires

the use of the index and increases access time. For this reason, you should specify PTR=TB

or PTR=HB for root segments in HIDAM databases.

Figure 2-11 shows how the database record exists in a HIDAM database.

Figure 2-11: HIDAM database structure.

After an initial load, segments within a database record are stored physically in blocks/CIs in

hierarchic order. After update activity, this may not be the case.


30/73

When a segment has been inserted in a HIDAM database, the segment is never moved to

preserve all the direct address pointers. The example assumes that physical child first

pointers and twin forward pointers are specified for all segment types.

If segments are deleted from the database segment, they are physically deleted from the

data set, and the space is designated as free space. If the database has multiple data set

groups, each secondary data set group has the format of the main part of the HIDAM

database.

PHIDAM

PHIDAM databases are partitioned HIDAM databases. Each PHIDAM database is divided

into a maximum of 1001 partitions which can be treated as separate databases. A PHIDAM

database is also referred to as a High Availability Large Database (HALDB).

HDAM/HIDAM Segment Structure

Figure 2-12 shows the HDAM/HIDAM segment structure.

Figure 2-12: HDAM/HIDAM segment structure.

An HDAM/HIDAM segment contains the following fields:

Segment

Code

1 byte. The segment code byte contains a one-byte unsigned binary number that

is unique to the segment type within the database. The segments are numberedin hierarchic order, starting at 1 and ending with 255 (X'01' through X'FF').

Delete

Byte1 byte. The delete byte contains a set of flags.


The following four-byte fields can be in this area and, if present, will occur in the following

order:

Counter

If the segment has a logical relationship that is unidirectional or bidirectional with physicalpairing, a four-byte counter will exist.

Hierarchic or Physical Twin Pointers

A hierarchic forward pointer or a twin forward pointer must be present in the segment

prefix, unless PTR=NOTWIN was specified in the SEGM statement. Hierarchic backward

pointers or twin backward pointers can also be present (PTR=HB or PTR=TB on SEGM

statement).

Physical Parent Pointer

This pointer will be present if the segment is a logical child or has a logical child below it in

the hierarchy. It will also be generated if the segment is a logical parent or has a logical

parent below it in the hierarchy.


31/73

It is also present in any segments that are target segments for a secondary index or that lie

on the hierarchical paths between the root segment and any target segments.

Logical Twin Pointers

A logical twin forward pointer and a logical twin backward pointer exist only in a logical

child segment with a bidirectional logical relationship that is virtually paired. A logical twin

backward pointer will be present if LTWINBWD is specified on the SEGM statement of the

logical child segment.

Logical Parent Pointer

A logical child segment can have a direct pointer to its logical parent (PHYSICAL specified on

SEGM statement) if the logical parent is in an HD database.

Logical Child Pointers

If the segment is a logical parent and has one or more logical relationships that are

bidirectional with virtual pairing, for each relationship there is a four-byte RBA pointer to

the first logical child segment (a logical child first pointer). There can also be a four-byte

RBA pointer to the last logical child segment (a logical child last pointer), depending on

whether you specified LCHILD=SNGL or LCHILD=DBLE in the DBD. The pointers are in theorder that the logical relationships are defined in the DBD, with a logical child first

pointer before a logical child last pointer.

Physical Child Pointers

If physical pointers rather than hierarchical pointers have been chosen for the segment,

there is a four-byte RBA pointer to the first physical child segment (a physical child first

pointer). There can also be a four-byte RBA pointer to the last physical child segment (a

physical child last pointer). The pointers are in the order that the physical children are

defined in the DBD, with a physical child first pointer before a physical child last pointer.

Figure 2-13 shows a logical parent with unidirectional relationships, two bidirectional

virtually paired relationships (the second with backward pointers), and three physicalsegments (the second with backward pointers).

Figure 2-13: Sample counter and pointers in a typical HD-type segment.

Data

The data area can be a fixed length that is specified in the DBD or variable length

(described in "Variable-Length Segment Structure"). For a logical child segment with

symbolic keys (PARENT=PHYSICAL on the SEGM statement), the concatenated key ofthe logical parent will be at the start of the segment.

Data

Pad

If the segment length is an odd number of bytes, a one-byte pad will be appended

to the segment to ensure that all segments start on half-word boundaries.

Variable-Length Segment Structure

Figure 2-14 depicts a variable-length segment (VLS) that can exist in HISAM, HDAM, and

HIDAM databases.
https://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10763/ims2-14.gifhttps://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10762/ims2-13.gifhttps://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10763/ims2-14.gifhttps://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10762/ims2-13.gif


32/73

Figure 2-14: Variable length segment structure.

Variable-length segments contain the following fields:

Segment

Code See the definition for the appropriate database organization.

Delete Byte See the definition for the appropriate database organization.

Counters

and

Pointers

See the definition for the appropriate database organization.

Length Field2 bytes. Signed binary number that specifies the length of the data portion of

the segment, including the length field itself.

Data

See the definition for the appropriate database organization. If a variable-

length segment in a HISAM database is replaced and is longer than it was

before, IMS moves the following segments to make room for the new

segment. IMS does not move HDAM and HIDAM database segments once they

hav

Date post:	04-Apr-2018
Category:	Documents
Upload:	nitin-pal
View:	220 times
Download:	0 times

IMS Concepts.docx

Documents