Professional Documents
Culture Documents
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.
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.
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 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/I
Because 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
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
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 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.
Department Database
The segments in the Department database are as follows:
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.
This segment includes fields for the course number (a unique identifier), course title, course description, and
Course
instructor's name.
The students enrolled in the course. This segment includes fields for student ID (the key field), student
Enroll
name, and grade.
Dept
Student Database
The segments in the Student database are as follows:
Student information. It includes fields for student ID (key field), student name, address, major, and courses
completed.
Billing information for courses taken. It includes fields for semester, tuition due, tuition paid, and scholarship
Billing
funds applied.
Student
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" on page 2-55.
Description
Instructor
Dept ID
Survey course
J. R. Jenkins
HIST
A.L. Watson
MATH
BIOL
Address
Major
Jones, Bill
1212 N. Main
History
123456888
Smith, Jill
123456999
Brown, Joe
77 Sunset St Zoology
123456777
History
Chairman
Budget Code
J. B. Hunt
L72
A54
BIOL
A25
Biology
E. M. Kale
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 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. 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 dependent
on 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.
College
Dept
Course
Enroll
Staff
Student
Billing
Academic
The 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.
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.
Includes fields for the course number (the key field), course title, course description, and instructor's
name.
A list of students enrolled in the course. There are fields for student ID (key field), student name, current
grade, and number of absences.
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 information. It includes fields for student ID (key field), student name, address, major, and
courses being taken currently.
Billing and payment information. It includes fields for billing date (key field), semester, amount billed,
amount paid, scholarship funds applied, and scholarship funds available.
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. 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.)
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 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, and backward means bottom to top. Position within the database means the current
location at a specific segment.
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, 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 segments.) The prefix portion of a segment is used to store
information that IMS uses in managing the database.
Prefix
counters and
segment
code
1 byte
Data
delete byte
1 byte
pointers
4 bytes per
element
data
seq.
(key) length varies, based
field on a minimum and
2 bytes
maximum size
size
field
Prefix
counters and
segment
code
1 byte
Data
delete byte
1 byte
pointers
4 bytes per
element
size
field
data
seq.
(key) length is whatever
field is specified for
2 bytes
the 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
Delete
Byte
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.
IMS uses this byte to track the status of a deleted segment. The space it occupied may (or may not) be
available for use.
Size Field
For variable-length segments, this field states the size of the segment, including the size field (2 bytes).
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 segment
Dependent
segment
Parent segment
Child segment
Twin segment
The 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.
All segments in a database record except the root segment.
A segment that has one or more dependent segments beneath it in the hierarchy.
A segment that is a dependent of another segment above it in the hierarchy.
A 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 decoded form
edit data-allow an application program to receive data in a format or sequence other than
that in which it is stored
compress data-use various compression routines, such as removing blanks or repeating
characters, 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
the key 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 fixedlength, 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, 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.
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 onebyte 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.
DATASE Defines the DDname and block size of a data set. One DATASET statement
T
is required for each data set group.
SEGM
FIELD
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
XDFLD
source segment, and the field to be used to create the secondary index.
See "The Role of Secondary Indexes" for more information.
DBDGE
Indicates the end of statements defining the DBD.
N
END
DBD Names the database being described and specifies its organization.
Program Specification Block
The 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.
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.
PCB
read only
replace, includes G
insert
delete, includes G
load database
Secondary PROCOPT codes are as follows:
must be used if program will issue path call using the D command code
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 IMS access method. An IMS database definition must
always specify an IMS access method 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.
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.
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 highactivity 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.
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
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, 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. 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 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
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.
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 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, 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.
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.
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-keysequencing 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 of dependent 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 (or blocks, 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.
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
record randomized 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 the data set and the space is designated as free space.
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 that are 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 210, 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 Element
In 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 of the 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,
including the 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 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 block are 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.
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.
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.
Delete
Byte
the DBD. 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.
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 physical segments (the second with backward pointers).
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
Data
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 length is an odd number of bytes, a one-byte pad will be
Data
appended to the segment to ensure that all segments start on half-word
Pad
boundaries.
Variable-Length Segment Structure
Figure 2-14 depicts a variable-length segment (VLS) that can exist in HISAM, HDAM,
and HIDAM databases.
Segment
See the definition for the appropriate database organization.
Code
Delete
Byte
Counters
and
See the definition for the appropriate database organization.
Pointers
Length
Field
2 bytes. Signed binary number that specifies the length of the data
portion of the segment, including the length field itself.
Data
Use of a compression routine always makes the segment variable length in the
data, but may be presented to the user through a DL/I call as fixed length.
How the user sees the segment data is determined by the SIZE parameter in the
DBD.
Delete Byte
Counters and
Pointers
VLS Pointer
Free Space
Data Portion
The data portion contains the following fields:
Segment
Code
Delete
Byte
Length
Field
2 bytes. Signed binary number that specifies the length of the data
portion of the segment, including the length field.
Data
Pointer Types
Pointers play an important role in accessing data stored in hierarchic direct access
and indexed databases. An understanding of the various types of pointers and how
they are used is important in understanding how database segments are accessed.
In HD databases, the records are kept in hierarchical sequence through the use of
pointers-four-byte fields that contain the address of another segment. The prefix in
every HD segment contains one or more pointers, and each pointer contains the
relative byte address (relative to the beginning of the database) of the segment to
which it points.
There are a number of types of pointers, and they can be mixed within a database
record to meet specific data access requirements.
Hierarchic Forward Pointers
Hierarchic forward (HF) pointers point to the next segment in the hierarchy.
Segments are located by following the HF pointers to the desired segment. This is
essentially the same as using a sequentially accessed database. As with a
sequential database, when HF pointers are used, all the segments in the hierarchy
must be searched until the requested segment is located. HF pointers are most
suitable for databases where segments are typically processed in hierarchic
sequence.
PCL pointers are most often used with PCF pointers in two cases:
when no sequence field is defined for the segment type
when new segment occurrences of a type are inserted at the end of existing
occurrences
PCL pointers give fast access to the last occurrence of a segment type, a feature
that significantly speeds inserts applied at the end of existing
occurrences. PCL pointers also provide fast retrieval of the last occurrence of
a segment type.
Physical Twin Forward Pointers
With physical twin forward (PTF) pointers, each occurrence of a given segment type
under the same parent points forward to the next occurrence. PTF pointers can be
specified for root segments, but not in the same way as with other segments. If PTF
pointers are used alone, only part of the hierarchy is connected. Parent and child
segments are not connected. Physical child pointers can be used to complete the
hierarchy.
The use of multiple data set groups has a number of advantages. Primarily, it
allows you to create data set groups designed for the specific needs of various
application programs. By defining data set groups in different ways, you can:
separate frequently used segments from those that are seldom used
separate segment types that are frequently added or deleted from those that are
seldom added or deleted
separate segments that vary greatly is size from the other segments in the
database
As an example, you may have designed a database so that the most frequently
accessed segment types are highest in the hierarchy, so that they can be accessed
more quickly. Later, you write another application program that frequently accesses
a number of segments that are scattered randomly throughout the hierarchy. You
know that these segments will take more time and processing to access. To
overcome this difficulty, you can define a data set group to contain the segments
accessed by the second application program.
You define data set groups in the DBD for the database.
top
Fast Path Databases
The Fast Path feature of IMS is designed to give improved response times for
database inquiries and updates. It does so through the use of specialized databases
and the Expedited Message Handling (EMH) facility. EMH ensures that Fast Path
transaction messages bypass normal message queuing and the priority scheduling
process.
Two types of databases can be used with the Fast Path feature of IMS. They are
data entry databases (DEDBs) and main storage databases (MSDBs).
DEDBs
DEDBs are similar in structure to an HDAM database, but with some important
differences. DEDBs are stored in special VSAM data sets called areas. The unique
storage attributes of areas are a key element of the effectiveness of DEDBs in
improving performance. While other database types allow records to span data
sets, a DEDB always stores all of the segments that make up a record in a single
area. The result is that an area can be treated as a self-contained unit. In the same
manner, each area is independent of other areas. An area can be taken offline, for
example, while a reorganization is performed on it. If an area fails, it can be taken
offline without affecting the other areas.
Areas of the same DEDB can be allocated on different volumes or volume types.
Each area can have its own space management parameters. A randomizing routine
chooses each record location, avoiding buildup on one device. These capabilities
allow greater I/O efficiency and increase the speed of access to the data.
An important advantage of DEDB areas is the flexibility they provide in storing and
accessing self-contained portions of a databases. You might choose to store data
that is typically accessed during a specific period of the day in the same area or set
of areas. You can rotate the areas online or offline as needed to meet processing
demands. For example, you might keep all records of customers located in one
time zone in one set of areas and move the areas on and offline to coincide with
the business hours of that time zone. DEDBs also make it easier to implement very
large databases. The storage limit for a DEDB area is 4 gigabytes (GB). By using a
large number of areas to store a database, you can exceed the size limitation of
232 bytes for a VSAM data set.
A Unit of Work (UOW) is further divided into the root addressable part and the
dependent overflow parts. Record storage in the root-addressable and dependent
overflow parts of a UOW closely resembles record storage in an HDAM database.
The root and as many segments as possible are stored in the root addressable part,
and additional segment occurrences are stored in the dependent overflow part.
If the size of a record exceeds the space available in the root-addressable and
dependent overflow parts, segments will be added in the independent overflow
part.
Because a UOW is totally independent of other UOWs, you can process a UOW
independently of the rest of the DEDB. The ability to continue processing the
remainder of an area while reorganizing a single UOW significantly increases the
data availability of a DEDB database.
Figure 2-18 shows the configuration of a VSAM CI within a UOW.
FSEAP This field gives the offset in bytes to the first free space element (FSE). If the
CI is in the sequential dependent part, these two bytes are not used.
This describes the type of CI.
1
CI TYP 2
base section
overflow section
RAP
This contains the root anchor point if the CI is in the root addressable part of
the area. Only one RAP exists per CI. Other roots randomized to this CI will be
chained off of this RAP in ascending key sequence.
CUSN
RBA
RDF
Record definition field. This contains information on the records stored in the
CI, their length, and whether they are fixed length or variable length.
CIDF
CI definition field. This field contains information on the control interval itself.
It keeps track of the amount of free space available and where the free space
is located, relative to the beginning of the CI. Control intervals will 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.
Sequential Dependent (SDEP)
DEDBs employ a special segment type called sequential dependent (SDEP).
Sequential dependents are designed for very fast insertion of segments or to
accommodate a very high volume of inserts. They must be located in the hierarchy
as the first child of the root segment, and they occupy their own space in an area.
Although SDEPs perform well for insert operations, they are not as efficient at
online retrieval. For this reason, SDEP segments are often retrieved sequentially by
using the SDEP Scan utility and are processed further by offline jobs.
The sequential dependent part of the area is used solely for the storage of
sequential dependent segments. These segments are added in chronological order,
regardless of which root they belong to. They are chained back to the root in
reverse order by pointers.
The purely sequential nature of SDEPs allows rapid insertion of new SDEP segment
occurrences. SDEPs can only be written and read sequentially, and REPLACE and
DELETE calls are not allowed. When the sequential dependent part is full, new
segments must be added at its beginning. For this reason, the SDEP area must be
purged periodically. The SDEP Scan utility can be used to extract SDEP segments
from an area while online processing continues. The Sequential Dependent Delete
utility allows you to delete some or all of the SDEPs while online processing
continues.
SDEPs typically are used for temporary data. They are often used for recording
processing events that occur against a record during a particular time period. A
bank, for example, might record the activity of each customer account during the
day in SDEPs that are read and processed later offline.
Other DEDB segment types are direct dependent segments (DDEPs). They can be
stored and retrieved hierarchically and support ISRT, GET, DLET, and REPL calls.
IMS attempts to store DEDB DDEPs in the same CI as the root segment. If space is
not available in the root CI, IMS will search the dependent overflow and then the
independent overflow parts. You can define DDEP segments with or without a
unique sequence field. DDEPs are chained together by a PCF pointer in the parent
for each dependent segment type and a PTF pointer in each dependent segment.
Figure 2-19 illustrates the format of a DEDB record.
Root and direct dependent segments can be stored in the root addressable part of
a UOW or the dependent overflow part, if the root addressable part is full. The
independent overflow part consists of empty CIs that are not initially designated for
use by a specific UOW. Any UOW can use any CI in the independent overflow part.
When a UOW begins using a CI in the independent overflow part, however, the CI
can be used only by that UOW. The sequential dependent part of an area stores
SDEPs in the order in which they are loaded, without regard to the root segment or
the UOW that contains the root.
DEDBs are supported by DBRC and standard IMS logging, image copy, and recovery
procedures. DEDB areas are accessed by using VSAM improved control interval
processing (ICIP).
Randomizing Module
IMS uses a randomizing module to determine the location of root segments.
The randomizing module addresses records by:
As changes are made to data within one area of a MADS, IMS automatically updates
all copies to ensure the integrity of the data throughout the MADS. If one area of
the MADS fails, processing can continue with another copy of the area.
In addition to being executed in main storage, MSDBs gain speed from a number of
other processing conventions. Update calls are not executed immediately; rather,
updates are held for simultaneous execution when a synchronization point is
reached. Also, MSDBs support field calls, a feature that allows MSDB segments to
be updated at the field level while permitting other programs access to other fields
within the segment at the same time. Finally, MSDBs are made up of fixed-length
root segments only. Because there are no dependent segments, segment searches
are simplified. There are two general types of MSDBs: terminal-related and
nonterminal-related.
Terminal-Related MSDBs
With terminal-related MSDBs, each segment occurrence is associated with, or
owned, by a specific logical terminal. Only the logical terminal that owns a segment
is allowed to update the segment, but all logical terminals are allowed to retrieve
all segments. The name of the logical terminal that owns the segment is used as
the key of the segment. The key of a terminal-related segment does not actually
reside in the segment. Terminal-related MSDBs are used when segments contain
data that can be associated with a specific user or terminal.
Nonterminal-related MSDBs are typically used when a large number of users need
to update data frequently, such as users at point-of-purchase terminals.
Virtual Storage Option
The Fast Path Virtual Storage Option (VSO) for DEDBs allows you to achieve
performance improvements similar to those of MSDBs by loading one or more
DEDB areas into virtual storage. You do this by defining the DEDBs as VSO areas.
VSO areas must be registered with DBRC and do not allow block-level sharing while
the area is in virtual storage. Otherwise, they are the same as non-VSO DEDB
areas.
Top
The Role of Secondary Indexes
A secondary index lets you process a segment type in a sequence other than that
defined by the segments key. You can base a secondary index on any segment in
the database, including the root, and you can create more than one secondary
index on any segment. In fact, you can use up to 32 secondary indexes for a
segment type and a total of 1,000 secondary indexes for a single database. A
secondary index allows you to have an index based on any field in the database.
This section describes how secondary indexes can be used to solve access needs in
the sample College databases.
Secondary indexes can be used with HD databases and with HISAM. A secondary
index uses VSAM as its access method. A secondary index is a self-contained
database, with its own DBD, containing segments that point to a segment in the
primary database. Each secondary indexs DBD contains parameters that connect it
to the primary database.
Lets look again at the College database created in Chapter 1, IMS Concepts. It is
shown again in Figure 2-20.
As part of our database, we decided to list the students enrolled in a specific course.
We handled this requirement by creating the Enroll segment as a dependent of
Course. Suppose that the Enroll segment has the data fields shown in Figure 2-21.
If we retrieve the occurrences of the Enroll segment in key sequence order, we will
have a list based on student ID number. But suppose we want the information in
this segment in an alphabetical list based on the students names. To create this list
using the StudeID field would be difficult. If we create a secondary index based on
the Name field, we can generate our listing easily by processing sequentially on the
new Name key field.
You can also use the secondary index to access segments individually. You do this
by referring to them specifically by the secondary index name (remember, the
secondary index is a database) in the segment search argument you write.
Finally, you can treat the secondary index as a database and use the information
stored in it. Using our StudeID secondary index, we can retrieve just the contents of
the field to which it points, giving us an alphabetical list of student names.
Optional. This 4-byte field is present only when the pointer segment
contains non-unique keys. It is used to chain together the KSDS and
Non-Unique
ESDS logical records with the same key value. It is not part of the
Pointer
segment prefix. It is not reflected in the prefix length of the generated
DBD.
Segment
Code
Optional. This 1-byte field appears only if DOS COMPAT was specified in
the index DBD. The prefix length in the generated DBD always assumes
this field is present, even though it may not be present.
Delete Byte
Direct
Pointer
CONST
SUBSEQ
Optional. It consists of one to five fields copied from the index source
segment. If present, it is concatenated with the search (SRCH) data to
produce a unique VSAM key.
DDATA
Optional. It consists of one to five fields copied from the index source
segment. It is available only when processing the secondary index as a
separate database.
Symbolic
Pointer
User Data
Optional. This 1-byte field is not part of the segment data and is
present only if it is necessary to make the logical record length an even
integer to satisfy the VSAM requirement.
Note: Logical relationships cannot be used with Fast Path DEDB or MSDB databases.
To illustrate the concept of logical relationships, let's look again at the example
College database. Suppose we decide that, as part of the College database, we
want a segment under Dept that lists the classrooms being used for each course.
We could create a new segment, Rooms, as a dependent. But suppose we discover
that the physical descriptions we need are already contained in a segment of
another database. The data we need is included in the Units segment of the
Buildings database. It would be redundant to repeat the same data in our College
The logical relationship we have just established gives us the logical structure
shown in Figure 2-25.
segment of the Buildings database, we want to know which courses will be taught
in each room. We can do this by storing the Rooms logical child segment in the
Buildings database and pointing to the Course segment in the College database. As
a room is assigned to a course, the Rooms logical child will be updated in both
databases. We will have a bidirectional path that lets us determine what room a
course will be taught in and what courses will be taught in any room. The Rooms
segment is physically stored in both databases and the segments are said to be
physically paired. IMS automatically updates both logical child segments when a
logical parent segment occurrence is added.
Virtual Pairing
In the discussion of physical pairing, we discovered how to link to databases
bidirectionally by using two logical child segments, one in each database. By using
virtual pairing, we can do the same thing without creating a logical child in the
Buildings database. Instead, we can add another pointer in the Rooms logical child
in the College database to give us a two-way path between the two databases. This
gives us the effect of two logical child segments, although we only have one. The
logical child that is stored in the College database is called the real logical child.
The logical child that is created by the second pointer in the real logical child is
called the virtual logical child. The relationship we have created between the two
database segments is called bidirectional virtual pairing.
Intersection Data
When two segments are logically related, it is possible to create data that is
relevant only to the relationship. For example, in our College database, the number
of seats available in the room where a course will be taught is a unique
combination of the course and the room assigned for it. This information could be
useful in determining if the enrollment for a course has exceeded the number of
seats available. This type of data is called intersection data. It is meaningful only in
the context of the two logically related segments. Intersection data is stored in the
logical child segment. There are two types of intersection data:
fixed intersection data (FID)
variable intersection data (VID)
Fixed Intersection Data
Fixed intersection data is any data stored in the logical child. When you are using
direct pointing, FID is the only data in the logical child segment. In symbolic
pointing, the FID is stored in the data portion of the segment after the LPCK.
Variable Intersection Data
to a logical parent. The logical parent points to the logical child segment. Two types
of logical child pointers can be used:
logical child first (LCF)
a combination of LCF and logical child last (LCL) pointers
Because LCF and LCL pointers are direct pointers, the segment they are pointing to
must be in an HD database. The logical parent (the segment pointing to the logical
child) must be in a HISAM or HD database. If the parent is in a HISAM database, the
logical child must use a symbolic pointer to point to the parent.
Logical Twin Pointer
Like logical child pointers, logical twin pointers are used only for logical
relationships that use virtual pairing. Logical twins are multiple occurrences of
logical child segments that point to the same occurrence of a logical parent
segment. Two types of logical twin pointers can be used:
logical twin forward (LTF)
a combination of LTF and logical twin backward (LTB) pointers LTF pointers point
from a logical twin to the logical twin stored after it. LTB pointers, used only with
LTF pointers, point from a logical twin to the logical twin stored before it. Logical
twin pointers function similarly to the physical twin pointers described in "Physical
Twin Forward and Backward Pointers."
LTF and LTB pointers are direct pointers, containing the 4-byte address of the
segment to which they point, and can exist only in HD databases.
Physical Parent Pointer
Physical parent (PP) pointers point from a segment to its physical parent. IMS
generates PP pointers automatically for HD databases involved in logical
relationships. They are put in the prefix of all logical child and logical parent
segments and in the prefix of all segments on which a logical child or logical parent
is dependent in its physical database. Having a PP pointer in each segment in the
chain from logical segment to physical parent creates a path back to the root
segment on which the segment is dependent. This allows access to any of the
segments in the chain in forward or backward order.
As with direct pointers, PP pointers contain the 4-byte address of the segment to
which they point.
This chapter discusses the IMS online environment, online application programs, backup, and recovery. It covers the
following topics:
IMS Online Environment
Application Programs
Backup and Recovery
Database Recovery Control
IMS Online Environment
The IMS/ESA product is made up of two major components-IMS DB and IMS TM. IMS dB supports the creation and
maintenance of the database and processes database calls. IMS TM is a data communication system that supports
online transaction processing for IMS dB This section discusses the components of the IMS online environment, the
facilities available, and the types of programs that can be used.
There are major differences between batch processing and online processing. When you initiate a program in batch
mode, a region in memory, sometimes called an address space, is assigned to it. The region will be loaded with the
application program itself and the IMS modules it needs for execution. The batch application program will process
independently of other jobs being run in the system. The batch application program begins with the first JCL
statement, executes serially through the job, and (assuming it is coded properly and all systems are functioning
correctly) completes successfully. It needs no intervention from a user or another program.
In the online environment, an application program can be started and stopped intermittently. It can be launched by a
user or by another program. You don't have to submit JCL to initiate it. Instead, you can enter a transaction code
from a remote terminal. When IMS receives the message with the correct transaction code, it will initiate the
application program for you. In fact, any user with the proper authorization can initiate an online application program.
Users can use the program in interactive mode from their terminals. These capabilities, and others, make online
programs indispensable for most business computing environments.
top
Application Programming Environments
IMS supports five application processing environments that provide a wide range of processing options:
dB/DC (database/data communications)
Database Control (DBCTL)
Data Communications Control (DCCTL)
dB batch
TM batch
dB/DC
In previous chapters we have discussed IMS databases and use of the DL/I command language in writing batch
application programs. These application programs use the services of DL/I only. The IMS dB/DC environment
provides a full implementation of DL/I and the data communications interface to allow online processing.
There are a number of differences between batch and online applications.
With online applications:
Many users can access information in the databases simultaneously.
The application can communicate with users at terminals and with other applications.
Users can invoke the application from terminals.
Users get the results of the application processing immediately.
The database can be updated immediately.
Database Control
The DBCTL environment allows a transaction management subsystem other than IMS TM to have online access to
DL/I databases and data entry databases (DEDBs). This means users of the Customer Information Control System
(CICS) transaction manager, for example, can use DBCTL to access DL/I databases.
DC Control
DCCTL lets you use IMS TM to access non-IMS databases, such as DATABASE 2 (DB2*). DCCTL uses the IMS
External Subsystem (ESS) Attach Facility to access other databases. When using DCCTL, you must define the
subsystems that DCCTL can access in an IMS.PROCLIB member. DCCTL provides access to the following
subsystems: online change
MFS
MSC
DBRC
device support
IMS commands
Online Configuration
The IMS online processing environment consists of a central control region and a number of designated address
spaces within the MVS environment. Figure 3-1 shows the configuration of the online processing environment.
Each box in Figure 3-1 represents an address space in an MVS environment. The online operating environment is
controlled through the following specialized processing regions:
control region (CTL)
message processing regions (MPRs)
batch message processing regions (BMPs)
DL/I separate address space (DL/I SAS)
Database Recovery Control (DBRC)
These regions provide the following functions:
Control Region: The CTL region is the address space that holds the control program that runs continuously in the
dB/DC environment. It is responsible for a number of online functions. It holds the IMS control program, which
services all communications DL/I calls. It is responsible for Fast Path databases that are accessed by an online
program and for Fast Path I/O. It performs all IMS command processing. The control region also:
supervises processing for message queues
supervises communication traffic for all connected terminals
is responsible for restart and recovery information
is responsible for the operation of the system log
DL/I Separate Address Space: The DL/I SAS controls full-function databases accessed by an online program. It
handles full-function database physical I/O for programs. It also is responsible for full-function program isolation (PI)
locking.
Database Recovery Control: DBRC extends the capabilities of utilities for database recovery to allow easier recovery
of full-function databases, Fast Path DEDBs, and databases accessed through CICS. DBRC has three levels of
control:
log control
recovery control
share control
See "Database Recovery Control" for more information. Address spaces that contain application programs are
referred to as dependent regions. Each of the regions discussed below is a dependent region.
Message Processing Region: The MPR loads the application program and holds it to wait for messages. The control
program controls scheduling of processing in the MPR. Output can be to a terminal or to another program.
Batch Message Processing Region: The BMP region contains application programs for processing against
databases in a batch processing operation. The BMP has access to non-IMS DL/I databases such as flat files, as
well as to IMS databases and online IMS message queues. Scheduling is done by OS/VS messaging.
must provide IMS with certain information about the application programs and databases that IMS will be processing
and about the communications resources that IMS will use.
Defining Application Resources
To use the resources available to application programs, you must define those resources to IMS for use with the
application. This section discusses the resources available and how to define them to IMS.
Databases
To access databases through MPPs or BMPs, you must first define each database to IMS by entering a DATABASE
macro that lists the DBD name of the database. The following DATABASE macro accesses a database whose DBD
name is COLLEGE:
DATABASE COLLEGE
APPLCTN Macro
The dB/DC environment processes two kinds of online application programs: MPPs (see "Message Processing
Programs" on page 3-18) and BMPs (see "Batch Message Processing Programs" on page 3-18). The main
difference between the two is that IMS processes an MPP dynamically when it receives a message with an MPP as
a destination. IMS processes a BMP when it is scheduled by a system operator. BMPs are typically used to process
messages that are held in a message queue for that purpose. You must define MPPs or BMPs to IMS in the
APPLCTN system definition macros during system definition. Here is an example of an APPLCTN system definition
macro for an MPP:
APPLCTN
PSB=PROGRAM1
PSB=BMPPGM2,PGMTYPE=BATCH
Transaction Codes
Messages are associated with application programs through the use of transaction codes. You can assign more than
one transaction code to an application program, but you can assign each application code to only one application.
Transaction codes are defined through a TRANSACT macro, which follows the APPLCTN macro for the program it is
assign to. You define a transaction code as a unique combination of one to eight characters. IMS creates a message
queue for each transaction code. As messages are generated for the transaction code, messages are stored in the
appropriate message queue pending processing. Here is an example of a TRANSACT macro for transaction code
TRANS1:
TRANSACT
CODE=TRANS1
multiple users of the same terminal. When you define a TERMINAL macro, you can follow it with one or more NAME
macros that list the LTERM names associated with that terminal.
In IMS online processing, LTERM names are used as message destinations in much the same way that transaction
codes are used. IMS creates a message queue for each LTERM name. Messages addressed to that LTERM are
held in the LTERM message queue. LTERM messages can be sent by MPPs, BMPs, or another logical terminal.
The use of message queues allows the application program to be independent of the time of transmission or arrival
of messages.
An application program interacts with a logical terminal in much the same way it does with a database. A GU call, for
instance, retrieves a message segment from a queue, and an ISRT call inserts a message segment into a queue.
Here is an example of IMS data communications macros defining the line groups, lines, control units, physical
terminals, and logical terminals on a network:
LINEGRP
DDNAME=LINEDD,UNITTYPE=3270
LINE
ADDR=L03
CTLUNIT
ADDR=CT4,MODEL=1
TERMINAL ADDR=65
NAME
LTERM5
TERMINAL ADDR=66
NAME
LTERM11
NAME
LTERM15
NAME
LTERM22
Message Types
Units of communication that flow between terminals and the host computer in an online environment are referred to
as messages. Most of our discussion of online processing revolves around the format and processing of messages.
In IMS online processing there are three message types, based on their destination:
transaction code messages
logical terminal messages
IMS terminal commands
Transaction Code Messages
Transaction code messages are used to communicate with application programs. Transaction code messages can
originate from a terminal or from another program. Transaction codes are used to link transactions to the program
that will execute them. A transaction can be assigned to only one program, but a single program can be assigned
many types of transactions. The code is recognized by the system and is used to route the message to the
transaction's message queue for processing by the application program.
Logical Terminal Messages
During IMS TM system definition, physical terminals are assigned logical names. A physical terminal can have more
than one logical name, and a logical name can be changed, removed, or assigned to another physical terminal. The
logical terminal name plays a similar role to the transaction code. The logical terminal name is used by the system to
place the message in the right message queue for further processing. Logical terminal name messages are those
messages addressed to a logical terminal. They can be sent by the host processing unit or by another terminal.
IMS Terminal Commands
Certain commands are reserved for specified IMS operating functions. They are used for operations such as starting,
stopping, restarting, controlling, or changing IMS online. They are also used to run IMS utilities. Most of these
commands are used by the master terminal operator (MTO) only. Their format is a slash followed by the command.
The command /STOP, for example, prevents new IMS transactions from scheduling.
Message Segments
Although messages are transmitted as a single unit, they can be divided into one or more message segments. MPP
and BMP programs actually retrieve messages one segment at a time, in much the same way that database records
are retrieved one segment at a time. Input and output messages have segments reserved for IMS control
information. Figure 3-2 shows the structure of a message segment.
Length: A binary number that expresses the total length of the segment, including LL and ZZ bytes.
ZZ: Two bytes of control information used by IMS.
DEST-CODE: A 1- to 8-character destination code. For input messages, the destination code is normally a
transaction code, but it can be an IMS command or LTERM name. For outgoing messages, the destination is
normally the originating LTERM name as specified in the I/O PCB or a different LTERM specified by an alternate
PCB.
b: A trailing blank.
Text: The text of the message. Length may vary, but each text segment has a maximum size of 132 bytes.
The message may consist of only one segment; the application program may require more information for
processing than can be contained in one segment. If so, a sequence of several segments will be sent. When IMS
receives an input message, it examines each segment for the end-of-segment indicator. If the message is a single
segment, the end-of-segment is also interpreted as the end-of-message.
Message Processing
Application programs can use DL/I calls to retrieve and process messages. A GU function accesses the first
message segment and a GN accesses subsequent message segments. The application program inserts the
response to the input message into the I/O PCB, where it is retrieved by IMS and returned to the entering terminal.
The application program can send output messages to a destination other than the originating terminal by using an
alternate I/O PCB. Use of the alternate I/O PCB has the effect of placing the outgoing message in the message
queue of a different LTERM name. When the message has been received by a terminal or by another program, IMS
dequeues (deletes) it. If the message is not delivered successfully, IMS saves it in the appropriate message queue
for future delivery. If you are using the message formatting service (MFS), the outgoing message is processed by
MFS before being routed to the LTERM. MFS converts program output format to device output format (DOF).
I/O PCB
IMS has two types of PCB areas, a database PCB and a data communications PCB. The database PCB is defined
as part of the PSB and describes the hierarchical structure of the database, the sensitive segments, and the types of
DL/I calls that can be used (see "Program Specification Block" on page 2-5). The data communications PCB is used
to allow the application program to communicate with remote terminals. This function is performed by a specific type
of data communications PCB called an I/O PCB. You do not have to define the I/O PCB in an application program's
PSB; IMS automatically generates it for you. You must, however, include an I/O PCB area in the application
program's linkage section. In a batch program, you do not have to be concerned with the I/O PCB; only the
database PCB is required.
The I/O PCB is generated by IMS and inserted automatically as the first PCB in the PSB parameter list for a BMP or
MPP. Application programs use the I/O PCB to receive messages from the input message queue and to transmit
messages back to the originating terminal. An application program uses a GU or GN call to retrieve messages from
the message queue and an ISRT call to send messages to a terminal.
The I/O PCB generated by IMS resides outside your program. It is not added to the PSB source code. To use the I/O
PCB, you must define a mask of the I/O PCB in your program to check the results of IMS calls. Your mask must
contain the same number and size of fields as the I/O PCB, and they must be in the same order.
To match the I/O PCB, the mask in your program should have the following fields:
Logical Terminal Name: An 8-byte field containing the name of the LTERM that sent the message or that the output
message should be sent to.
Reserved Field: A 2-byte field reserved for IMS.
Status Code: A 2-byte field that describes the results of a DL/I call.
Current Date: A 4-byte field that gives the Julian date the message was originated in a packed, right-aligned YYDDD
format.
Current Time: A 4-byte field that gives the time the message was originated in a packed HHMMSST format.
Input Message: Sequence Number
A 4-byte field containing the message sequence number assigned to the message by IMS.
Message Output Desciptor (MOD) Name: An 8-byte field used only with MFS to specify the MOD to be used.
User Identification: An 8-byte field usually associated with RACF sign-on authority to contain the user's ID.
Group Name: An 8-byte field used by DB2 to provide security for SQL calls.
Figure 3-3 shows a sample I/O PCB mask as defined in the Linkage Section of a COBOL application program.
Message Switching
It is possible for an application to send a message to another application program. To do this, you must use an
alternate PCB and use a transaction code rather than an LTERM name as the destination. When your application
program issues an ISRT call to the alternate PCB and specifies a transaction code as the destination for the
message, the message is placed in the transaction code message queue rather than an LTERM queue. The
application program receiving the message will process it as with any other message.
Multiple Systems Coupling
You can communicate with terminals and programs in an IMS TM system other than your own through the use of an
IMS facility called Multiple Systems Coupling (MSC). MSC establishes links between the two (or more) IMS TM
systems and keeps track of the terminals and transaction codes belonging to each one. You can refer to terminals
and transaction codes in your IMS TM system as local and to those in other IMS TM systems as remote.
In most cases, you will not need to make program changes to communicate with programs or terminals in a remote
system. You perform an ISRT of the destination against the I/O PCB. MSC handles the message routing. You can
determine whether an input message is from your system or a remote system, and you can set an alternate
destination in a remote system for the outgoing message. IMS uses bits in the message reserved field to keep track
of the origin and destination of messages to and from other IMS TM systems.
Message Scheduling
Message scheduling refers to the process by which an input transaction is united with its associate application
program and is processed. All input and output messages are queued in message queues in virtual storage by IMS.
Messages that are identified by transaction code or logical terminal can be queued in the order in which they are
received. Distinct serial queues are created for each transaction or LTERM.
When a message has been processed or received by its destination, it is removed from the queue (dequeued) and
the space in the queue is made available for another message. Figure 3-5 shows the flow of a transaction message.
The scheduling of messages for processing is influenced by a number of factors, including parameters set in the
PSB and others that can be grouped under the general heading of workload control.
PSB Scheduling
Each MPR can have from one to four message classes. You can assign messages to these classes by JCL when the
PSB is created. Every transaction has a message class, which is assigned at system definition. Within each
message class, messages can be assigned a priority that is defined at system definition. The control region uses all
of these elements in scheduling messages for processing.
Workload Control
Workload control is based on the combination of a number of parameters that establish the processing schedule for
messages:
Processing Limit
A processing limit can be set for each program. It establishes the maximum number of messages for that program
that can be processed in one scheduling. It is set at system definition.
Limit Priority
If a transaction gets bumped by higher priorities for a certain length of time, its priority is raised, so that it can be
processed eventually. Limit priority is assigned at system definition.
Parallel Processing
A program may be scheduled for serial or parallel message processing. If it is set for parallel processing, a parallel
limit count establishes when to schedule an additional region for the program. The limit count is assigned at system
definition.
Wait for Input
When an application program is loaded into an MPR, it is left there in a Wait for Input (WFI) status until its PROCLIM
(maximum processing time) is reached. This is true even if no messages are in the queue.
Quick Reschedule
If no higher class or priority message is waiting and an application program reaches its PROCLIM, IMS resets the
counter to zero without terminating the transaction. This can be disabled by setting the processing limit to 1.
Pseudo Wait for Input
Pseudo WFI (PWFI) allows the application to remain in the MPR until another input message is received, even
though its PROCLIM has expired. When the next message is for the PWFI program, this eliminates the unnecessary
overhead of terminating the program and then reloading it for the message. If the message is not for the PWFI
program, the program is terminated.
top
#Application Programs
The value of a database management system lies in its use by application programs to execute business processes.
You can use several types of application programs to access the data stored in the database:
MPPs
BMPs
interactive Fast Path programs (IFPs)
batch programs
The types of application programs you can use allow you to use the database in batch mode only, in online mode, or
in a combination of the two. MPPs, BMPs, and IFPs are online programs that execute in the IMS TM online
environment. Batch programs are executed in the IMS batch environment, as discussed in "Online Configuration" on
page 3-5. Programs that execute in the IMS TM environment must be defined to IMS before they can be used. This
is done at system definition time in APPLCTN definition macros. Application programs can be written in COBOL,
PL/1, C, VS Pascal, Ada, REXX, or Assembler language. The databases are accessed through DL/I statements, or
calls, embedded within the application program code.
Message Processing Programs
MPPs are online transaction-initiated programs. They run in real time and can be interactive with the user. MPPs are
loaded dynamically by IMS when a message for the program is initiated by a user or by another program. Although
they are executed differently, they have the same basic structure as batch programs.
Batch Message Processing Programs
BMPs are initiated by JCL and can access operating system files and IMS databases. Messages directed to BMPs
are held in a message queue until the BMP is scheduled by the operator. The BMP then reads the messages from its
message queue and processes them.
Interactive Fast Path Programs
IFPs are used for applications that are identified with DEDB databases. IFPs process and reply quickly to messages
from terminals. IFPs bypass IMS scheduling and are processed by the Fast Path EMH facility. IFPs are used for
large transaction volumes that require rapid response.
DL/I Calls
The purpose of a DL/I call is to instruct DL/I to perform a certain action involving the data stored in the IMS database.
Although a complete description of how to code DL/I calls is beyond the scope of this manual, you should
understand certain concepts regarding the calls and how they are used. A DL/I call includes four parts:
CALL FUNCTION: Tells DL/I what needs to be done (for example, retrieve, update, insert, delete).
PCB: Gives the name of the PCB of the database that will be referenced by the call.
I/O AREA: Specifies the work area for the requested segment.
SSA: Specifies the segment and path of the data to be accessed.
Figure 3-6 shows the format of a DL/I call in a COBOL application program.
REPL (replace): Replaces current data in a selected segment with new data from the I/O area. Like DLET, it must be
preceded by a GHU, GHN, or GHNP call and generally does not use an SSA. The segment's key fields cannot be
changed.
GET HOLD calls: GET HOLD calls have the same format as GET calls:
GHU (get hold unique)
GHN (get hold next)
GHNP (get hold next within parent)
The calls hold the segment until it is replaced or deleted or until another segment is retrieved using the same PCB.
GET HOLD calls must be performed before a DLET or REPL can be issued.
Database PCB Area
The database PCB specifies which database will be referenced by a DL/I call. The database PCB tells IMS which
database view to use and provides a place for IMS to return results of the call to the application. Figure 3-7 shows
an example of the database PCB entry for a DL/I call in a COBOL application program. The KEY-FEEDBACK field
must be large enough to hold the longest possible concatenated key of the sensitive segments involved in the SSA.
Figure 3-8 gives an example of a typical SSA entry in a COBOL application program. The KEY-FIELD-VALUE
depends on the length of the key field of the segment being searched.
Length: Two-byte field that gives the length of the SPA, including the variable-length text area.
Reserved: Four-byte field reserved for IMS. This field should not be changed by the
application program.
Trancode: Eight-byte transaction code field. This field is necessary for both input and output messages.
Text: Variable-length field for use by the application program. This field is also
called the user work area.
Expedited Message Handling
The expedited message handling (EMH) facility allows Fast Path transaction messages to circumvent normal IMS
message processing. Use of EMH comes with certain restrictions. First, you must identify the transaction as a Fast
Path type. Second, the message being processed must meet the criteria of a Fast Path message:
single segment
not edited by the MFS
not an IMS command
from a VTAM terminal
When you have satisfied these conditions, IMS acquires an EMH buffer and allocates it for use by the originating
terminal for all Fast Path message processing until the session ends. You can specify the size of the EMH buffer
but, if the buffer proves too small, EMH will return it to the EMH pool and obtain a larger one.
Message Format Service
The MFS facility can be used in formatting messages to and from terminals. MFS removes device-specific
characteristics in input and output messages and eliminates the necessity of tying all screen panel formatting
information to the application program. This not only makes the program more device-independent but also makes
design and modification of panels easier.
MFS uses four control blocks to separate panel formatting information before a message goes to the application
program for processing and to return it to the message when it goes to the terminal for display. The four control
blocks are as follows:
Device Input Format: Device input formats (DIFs) describe the formats of messages that MFS
receives from devices.
Message Input Descriptor: Message input descriptors (MIDs) describe how MFS formats messages for the MPP
application to process.
Message Output Descriptor: Message output descriptors (MODs) describe the layout of the message as it is sent by
the MPP application program.
Device Output Format: DOFs describe how MFS formats the message for the device.
Figure 3-10 illustrates the role of the four control blocks in the routing of messages from terminal to program and
back.
A specific DIF, DOF, MID, and MOD must be defined for each unique message used by an application program.
Creating the control blocks can be simplified through the use of SDF II, an interactive tool for use in designing and
generating MFS control blocks. SDF II provides a panel editor for you to use in creating and testing panels.
Data Sharing
You can allow more than one IMS online system or batch system to have concurrent access to data stored in a
common database. This capability is referred to as data sharing. If you use IMS to control access to the common
data, you will be required to use the data sharing support provided by DBRC. See "Share Control" on page 3-41.
The databases that can be accessed by an application program must be defined in the program's PSB. To ensure
data integrity, changes to a databases record segment must be fully committed before the segment is released for
access by another program. This data integrity protection is provided by IMS lock management.
Lock Management
You can choose one of two methods for controlling access to database segments. A program isolation lock manager
can control lock requests for a single IMS system. This is called local locking. An Internal Resources Lock Manager
(IRLM) component can control lock requests for multiple IMS systems or a single IMS system. This is called global
locking. If you want the dB/DC environment to take part in block-level sharing, you will be required to use IRLM.
When you specify database locking, the entity protected is the database record and the specific item locked is the
root segment. (For HDAM databases, the item locked is the anchor point, which means that all records chained from
that anchor point are also locked.) Locking occurs when IMS obtains position in the database, and it is held until
position is changed to another database record or until a commit occurs. Whether another program can obtain
concurrent access to the locked record is determined by the processing option (PROCOPT) defined in the database
PCB.
top
Backup and Recovery
Despite our best efforts and automated procedures, data can sometimes be lost or corrupted because of a variety of
causes, including hardware failure, procedural errors, abnormal system termination, or faulty application logic. IMS
provides processes that allow data to be recovered to its original state:
Logging allows IMS to reprocess data from a given point in time.
Backup utilities create and store valid copies of the database for use in recovery
operations.
Recovery utilities recreate the recovered database.
DBRC manages the logs and can be used to manage backup, recovery, and data
sharing.
Backing up a database is like taking out an insurance policy. If you never need to recover a database, you do not
need a backup. However, because most databases are updated and used regularly, they are subject to disasters. If
disaster strikes, you need to be prepared to recover from it. A copy of a database, referred to as an image copy,
provides a complete backup of the database. When you take an image copy, you create a duplicate of the database
as it exists at that moment in time.
After you discover a problem, you must begin the recovery process. The problem may be that IMS or the database
validation program found a pointer error. A hardware malfunction may have physically damaged a data set or
disabled a disk pack filled with IMS database data sets. Or someone might have discovered a logic error in an IMS
application program that has improperly updated several databases.
Whatever the reason, the database must be recovered to its exact state before the failure occurred. Because the
database must be taken offline for recovery, it becomes unavailable to IMS users.
You can recover a database to its exact state before the failure occurred, or you can recover it to a particular point in
time. In either scenario, you must complete the following steps:
1. Apply the most recent image copy or the image copy taken at the time to which you want to recover.
2. Apply the changes made after the image copy was taken. These changes may be in logs or change
accumulation data sets or both.
3. Take an image copy of the recovered database, and verify the pointers. You must have a backup in case
you need to recover again in the future, and you must ensure that the recovered database is valid. The
following sections describe each of these processes in more detail. Remember that the IMS utilities require
you to take the database offline (making it unavailable to users) during some or all of the process,
depending on the utilities you choose to use. This unavailability can be a key factor in organizational
operations when it affects business-critical applications.
Image Copy
IMS provides two utilities to make copies of a database. The Database Image Copy Utility (DFSUDMP0) creates an
as-is image copy of a database. The Online Database Image Copy Utility (DFSUICP0) can be used to create an
image copy of a database while it is being updated online. Both utilities operate at the data set level, so if the
database consists of multiple data sets or areas, they all must be supplied to the utility. It is generally recommended
that you copy all data sets (the entire database) at the same time. The frequency you choose to take image copies
depends on the recovery requirements of your organization. You should always create an image copy by using your
choice of utilities after a database reorganization, reload, or initial load.
Logging
IMS automatically keeps a running record, a log, of all significant events that occur during processing. The events
written to the log include IMS startup and shutdown, program starts and stops, changes to a database, transaction
requests received, responses generated and sent, application program checkpoints, and system checkpoints.
Log Contents
Table 3-1 lists common log record types and their meanings.
Log Code
Meaning
X'07'
X'08'
X'10'
security violation
X'20'
database opened
X'21'
database closed
X'31'
X'41'
X'50'
database updated
X'52'
X'59'
X'5F'
Change Accumulation
To recover a database by applying log records to an image copy, you must wait while IMS reads and applies each
change to every changed segment in the database. You can shorten this procedure significantly if you could skip all
the interim changes and read and apply only the most recent change, because that is all you really need to make
the database current.
You can consolidate the records in the SLDS and RLDS by running the IMS Change Accumulation utility (or the BMC
Software CHANGE ACCUMULATION PLUS product). The Change Accumulation utility reads the log records and
summarizes the segment changes. The utility produces a change accumulation data set that includes only the most
recent changes organized in sequential order by block number for each data set summarized. Because the change
accumulation data set will be much smaller than the log data sets, a database recovery will require much less time.
You can update change accumulation data sets by applying new log records periodically. This creates a new, current
change accumulation data set that incorporates any changes since the last change accumulation was done. To
perform a recovery, apply the latest change accumulation data set to the most recent image copy of the database,
with any log records written since the last change accumulation. Figure 3-13 shows the change accumulation
process.
Commit Points
Although IMS allows multiple application programs to access a database at one time, it allows only one program at a
time to update individual segments. While your application has access to a segment, other programs are prevented
from accessing the segment until your program has reached a commit point. A commit point is the point in the
program processing sequence at which the program has completed a unit of work. IMS issues commit points under
the following conditions:
A program terminates normally. Normal termination always results in a commit point,
except that for Fast Path databases a commit point must occur before normal termination.
A Checkpoint call is issued. A Checkpoint call is a means by which an application
program can specifically tell IMS that it has reached a commit point.
A new input message is retrieved by an MPP processing in single mode. At the commit
point, IMS makes the changes to the database permanent and releases the segment for
access by other application programs. For example, your program may receive a
message to update the data contained in a segment or number of segments located in a
database. While the program is retrieving and updating a segment, IMS protects the
segment from processing by other programs. When the program completes processing,
IMS issues a commit point. Several things happen when the commit point is reached:
IMS makes the changes to the database permanent.
IMS releases the segment or segments it has locked since the last
commit point.
The current position in the database (except GSAM) is reset to the
beginning of the database.
Checkpoints
Because some programs do not have built-in commit points, IMS provides a means whereby an application program
can request a commit point. This is done through a Checkpoint call. A Checkpoint call tells IMS that the program has
reached a commit point. A checkpoint provides a point from which the program can be restarted. Checkpoint calls
are primarily used in the following programs:
multiple-mode programs
batch-oriented BMPs
batch programs
programs running in a data sharing environment
Checkpoint calls are not needed in the following programs:
single-mode programs
database load programs
programs that access the database in read-only mode and with PROCOPT=GO that are
short enough to be restarted from the beginning
programs that have exclusive use of the database IMS provides for two types of
Checkpoint calls-basic Checkpoint calls and symbolic Checkpoint calls.
Basic check point calls can be used by any type of program, but they are the only type of Checkpoint call allowed for
MPPs and IFPs. Basic Checkpoint calls do not support MVS or GSAM files and do not support the Restart call.
Symbolic Checkpoint calls can be used by BMPs and batch programs. Symbolic checkpoints allow a program to
specify as many as seven data areas to be checkpointed. The Restart call restores these designated areas to the
condition they were in when the symbolic Checkpoint call was issued.
A Checkpoint call produces the following results:
IMS makes the changes to the database permanent.
IMS releases the segment or segments it has locked since the last commit point.
The current position in the database (except GSAM) is reset to the beginning of the
database.
IMS writes a log record (containing the checkpoint identification) to the system log.
IMS sends a message (containing the checkpoint identification) to the system console
operator and to the IMS master terminal operator.
IMS returns the next input message to the program's I/O area.
If your program also accesses DB2, IMS tells DB2 that the changes your program has
made can be made permanent. DB2 makes the changes to the DB2 database
permanent.
Backout
IMS will back out changes to a database automatically if a MPP or BMP application program terminates abnormally
before reaching a commit point. IMS also performs a backout if an application program issues a Roll backout call
(ROLL), Roll Back backout call (ROLB), or Roll Back to SETS (ROLS) call. So that IMS can perform the backout if
needed, and so users will not receive information that may prove to be inaccurate, IMS holds output messages until
a program reaches a commit point. In an abnormal termination of the program, IMS discards any output messages
generated since the last commit point.
If an application program terminates abnormally while processing an input message, IMS may discard the input
message, depending on the type of termination. In all cases, IMS backs out uncommitted changes and releases
locks on any segments held since the last commit point. You can use DL/I calls to manually back out database
updates. The backout calls include
ROLB
ROLL
ROLS
Set a Backout Point (SETS)
SET Unconditional (SETU) ROLB, ROLL, and ROLS calls produce three common results:
All database changes since the last commit are backed out.
All output messages (except EXPRESS PURG) since the last commit point are
discarded.
All segment locks are released.
ROLB, ROLL, and ROLS calls differ in the following ways:
ROLB returns control to your program and places the first segment of the first message
after the last commit point into the I/O PCB.
ROLL abends with user code 0778. All messages retrieved since the last commit point
are discarded.
ROLB abends with user code 3303. All messages retrieved since the last commit point
are returned to the message queue.
A SETS call can be used to set up to nine intermediate backout points to be used by the ROLS call. It can also be
used to cancel all existing backout points. SETS can be combined with a ROLS call to back out pieces of work
between the intermediate backout points.
To set the intermediate backout point, issue the SETS call by using the I/O PCB and including an I/O area and a 4byte token. To back out database changes and message activity that has occurred since a prior SETS call, issue a
ROLS call that specifies the token that marks the backout point you have selected. IMS then backs out the database
changes made since the SETS token specified. It also discards all non-express messages since the token. A SETU
call operates like a SETS call except that it ignores certain conditions under which the SETS call is rejected. A SETS
call is not accepted when unsupported PCBs exist in the PSB (PCBs for DEDB, MSDB and GSAM organizations) or
an external subsystem is used.
Restart
A Restart call lets you restart a program after an abnormal termination. It must be coded as the first call in the
program. When you use the Restart call the following actions occur:
Recovery Control
DBRC controls the recovery of databases by supplying the necessary input for the IMS Recovery utility. To use the
recovery control portion of DBRC, you must register your databases with DBRC. Recovery control does not choose
the correct utility to be run at the correct time. For example, you must select the correct utility to run in the following
circumstances:
image copy after reorganization
recovery after database I/O error
backout after batch failure
/ERE after online failure
DBRC performs two types of recovery-full recovery and time stamp recovery.
A full recovery means that you have restored all of the database updates that were performed since the image copy
was taken. It requires a valid image copy of the database, all log data sets created since the image copy was taken,
and any change accumulation data sets.
A time stamp recovery recovers the database to a selected point in time. A time stamp recovery can use any image
copy of the database. Then updates (using logs and change accumulation data sets) are applied up to a selected
point in time. A time stamp recovery results in an older version of the database. You may need an older version
because of application logic that corrupted the most current database. Or the point in time you have selected to
recover to may have been the last time the database was valid.
A time stamp recovery is usually used when the database has been corrupted through a processing error such as
faulty application logic. A full recovery is most often used when the data has not been corrupted but the database has
been lost through something like a hardware or reorganization failure. The data was not corrupted; the database
simply crashed.
Share Control
IMS lets you determine the degree to which database records can be shared by application programs or users.
When using DBRC in the share control mode, DBRC enforces the share level you have defined. To use DBRC share
control, you must register the database to DBRC and define the level of sharing you want. IMS allows four levels of
data sharing:
SHARELEVL 0 No sharing. The database can be accessed only by the subsystem to which it has been authorized.
SHARELEVL 1
Database-level sharing. The owner subsystem can perform updates, but other subsystems are read
only.
SHARELEVL 2
Intra-host block-level sharing. Subsystems executing on the same MVS have full update authority.
SHARELEVL 3
Inter-host block-level sharing. Subsystems operating on the same (or any other) MVS have full
update authority.
Levels 2 and 3 require use of the IRLM. You specify the share level when you register the database with DBRC. Use
of share control automatically invokes DBRC log control and recovery control.