Post on 07-Apr-2018
transcript
8/4/2019 IMS Concepts - Copied From Website
1/64
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
OverviewThe 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 and processing overhead. To reduce the number of files accessed by an
application, 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.
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#overview8/4/2019 IMS Concepts - Copied From Website
2/64
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 datasequentially 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 one place, 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/IBecause they are implemented and accessed through use of the Data Language I (DL/I), IMS databases 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 remember is 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 on the data.
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
8/4/2019 IMS Concepts - Copied From Website
3/64
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 calls embedded 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 logicallystore 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 being stored.
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 beenselected 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 columns describe 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, and Enroll.
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 fordata 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
the database, 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.
https://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#top8/4/2019 IMS Concepts - Copied From Website
4/64
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 accessby 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 store information 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 thekey, 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 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:
DeptInformation 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
https://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9908-9-10732/ims_fig2.gif8/4/2019 IMS Concepts - Copied From Website
5/64
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 in detail in "The Role of Logical Relationships" onpage 2-55.
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
https://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#top8/4/2019 IMS Concepts - Copied From Website
6/64
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 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 of the key. Forexample, 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 dependent on the primarykey. 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:
https://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9908-9-10735/ims_fig3.gif8/4/2019 IMS Concepts - Copied From Website
7/64
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.
Course
Includes 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.
StudentStudent information. It includes fields for student ID (key field), student name, address, major,
and courses being taken currently.
BillingBilling and payment information. It includes fields for billing date (key field), semester, amount
billed, amount paid, scholarship funds applied, and scholarship funds available.
AcademicThe key field is a combination of the year and the semester. Fields include grade point averageper 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. Certain data 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, as there 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 College are dependents.)
https://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#top8/4/2019 IMS Concepts - Copied From Website
8/64
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.
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 bottomof 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, and backward 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.
https://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#top8/4/2019 IMS Concepts - Copied From Website
9/64
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 root segment. 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 the meaning 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, whichcan 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 segments.) The prefix portion of a
segment is used to store information that IMS uses in managing the database.
Prefix Data
segment delete byte counters and size seq. data
https://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9908-9-10734/ims_fig4.gif8/4/2019 IMS Concepts - Copied From Website
10/64
code
1 byte
1 byte
pointers
4 bytes per
element
field
2 bytes
(key)
field 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. Logical relationships arediscussed 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 this segment. Pointers arediscussed 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 size field (2 bytes).
Sequence (Key) FieldThe 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,
https://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#top8/4/2019 IMS Concepts - Copied From Website
11/64
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 Definitions
In 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 in the 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 it in decodedform
edit data-allow an application program to receive data in a format or sequence other than that in which itis stored
compress data-use various compression routines, such as removing blanks or repeating characters, toreduce 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 the key field. Forvariable-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 relative position, value, orlength 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
https://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#top8/4/2019 IMS Concepts - Copied From Website
12/64
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.
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 Databases
Hierarchic Direct Databases
Fast Path DatabasesThe 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, aload 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,
https://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://communities.bmc.com/communities/docs/DOC-9908#tophttps://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#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/docs/DOC-9943#rolehttps://communities.bmc.com/communities/docs/DOC-9943#indexeshttps://communities.bmc.com/communities/docs/DOC-9943#pathhttps://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-99088/4/2019 IMS Concepts - Copied From Website
13/64
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:
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.
LCHILDDefines 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 creating the views that application programs will have of your
database.
https://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10748/ims2-1.gif8/4/2019 IMS Concepts - Copied From Website
14/64
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 PCBstatement. 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 exempted from 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
L load database
Secondary PROCOPT codes are as follows:
E exclusive use of hierarchy or segmentsO 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.
https://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10751/ims2-2.gif8/4/2019 IMS Concepts - Copied From Website
15/64
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.ACBLIBthat 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 IMS access method. An IMS database definition must always specify an IMS accessmethod and 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
main storage 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.
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#top8/4/2019 IMS Concepts - Copied From Website
16/64
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:
The record definition field (RDF) contains information on the records stored in the CI, their length, andwhether they are fixed or variable length.
The control interval definition field (CIDF) contains information on the CI itself. It keeps track of theamount of free space available and where the free space is located relative to the beginning of the CI. CIshave 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.
https://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10753/ims2-4.gif8/4/2019 IMS Concepts - Copied From Website
17/64
Figure 2-5: Structure of VSAM index set and sequence set records.
Key-Sequenced Data Sets
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 toread 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
https://communities.bmc.com/communities/servlet/JiveServlet/showImage/102-9943-6-10754/ims2-5.gif8/4/2019 IMS Concepts - Copied From Website
18/64
needed because there are no record keys to track. Likewise, free space 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. Withthe 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 thedata set. QSAM groups logical records into physical blocks before writing them to storage and handles the
blocking and deblocking of records for you. QSAM is 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
8/4/2019 IMS Concepts - Copied From Website
19/64
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 are related 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.
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 specifyeither 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 canuse.
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
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-10755/ims2-6.gifhttps://communities.bmc.com/communities/docs/DOC-9943#top8/4/2019 IMS Concepts - Copied From Website
20/64
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 alsoprovide 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 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 apointer 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, HISAM databases 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.
8/4/2019 IMS Concepts - Copied From Website
21/64
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.
Counters and Pointers
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 or bidirectional withphysical pairing, a four-byte counter will exist.
If the segment is a logical parent and has one or more logical relationships that are bidirectional with
virtual pairing, then for each relationship there is a four-byte RBA pointer 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.
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.gif8/4/2019 IMS Concepts - Copied From Website
22/64
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 a variable 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 beaccessed 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.
TopHierarchic Direct Databases
Hierarchic direct access method (H