IDMS

Integrated Database
Management
System
Topics Covered
 Introduction to DBMS
 Logical and Physical Database Structure
 Record Characteristics
 Set Characteristics
 IDD and DDDL
 Data Description Language (DDL)
 Data Manipulation Language (DML)
 Recovery & Restart of Database
 Locking Facilities
2
Introduction to DBMS

3
TYPES of DBMS
 Inverted List (e.g. Datacom DB)

 Hierarchical (e.g. IMS)

Data records are typically connected
with embedded pointers to form a tree
structure. Each node (except root) can
have one and only one parent

4
Continue …..
• Network (e.g. IDMS)
The database forms a mesh structure
Entity-Relationship is implemented
using Record type and Set.

• Relational (e.g. Oracle, Sybase, etc)

Entity-Relationship is implemented in
the normalized form. Data represented
in the form of rows and columns (two
dimensional table)

5
Logical & Physical
Database Structure

6
LOGICAL DATABASE STRUCTURE

A database can be viewed as consisting of

Entities. An entity is an object about which
we are storing data. Every entity has
attributes. e.g. Employee is an entity which
has attributes like, emp-code, emp-name,
emp-address, emp-sex, emp-dept etc. There
exists relationship between different
entities. We can represent the relationship
between our entities using an entity-
relationship (E-R) diagram as below.
7
E-R Diagram

SALARY TEAM

PLAYER GAME

BONUS

8
THE EXAMPLE
The example discussed here:
 Taken from a typical American baseball
league.
 A team has many players but at a given
time, a player is attached to only one team.
 A team plays many games. Games can be
further identified by Game-Home and
Game-Away.

9
Continue …..
 A player plays many games and same way
a game is played by many players.
 A player has many salary records since his
salary (contracts) may have undergone
changes during a season. Similarly, a
player might have many bonuses awarded
to him.
 Team, Player, Game, Salary and Bonus
represent Entities.
10
Continue …..
 Attributes of Team could be Team-
Name, Team-City, Team-Address etc.
 The relationship between entities is
shown by line diagram. We use
cardinality symbols to represent type of
relationship. The crow-foot end of the
line diagram represents Many type and
single line represents One type of the
relationship.

11
Continue …..
 For example, consider relationship
between Team and Player. Team end
has a single line whereas Player end
has a crow-foot. This represents a
One-to-Many relationship. It means a
team has many players. But a player
is attached to only one team.
 Note that relationship between Player
and Game is Many-to-Many. i.e a
game has many players and a player
plays many games.
12
Continue …..

 In IDMS, entities are implemented

using Record types and
relationships are implemented using
Set types.
 IDMS does not allow direct
implementation of many-to-many
relationship.

13
JUNCTION RECORD
It is a way of implementing many-to-
many relationship in IDMS. It is a
record type having attributes that are
common (intersection) to both record
types participating in many-to-many
relation.
Thus, many-to-many relation between
player and game can be resolved as
below.
14
Continue …..

PLAYER GAME

POSITION

NOTE:
Here, referring to our earlier example of
American baseball league, we had many-
to-many relationship between entities
player and game.
15
Continue …..

That is to say, a player has played in

many games and conversely, a game
has many players in it. To resolve this
M:M relationship, we introduce a
junction entity, Position record.
Position is called Junction record
because it represents junction or
intersection between Player and Game
record.

16
Continue …..
A player has many positions assigned to
him for different games. But for a game
he has a fixed position. Main attribute of
the record is “player-position” for a
game. It thus resolves many-to-many
relationship between player and game.
In other words, we can easily move
from a player record occurrence to a
game record occurrence using the
position record occurrence.

17
BACHMAN DIAGRAM
Most installations use a line with an arrow
at one end to show each one-to-many
relationship instead of using crow’s foot
notation. Such a diagram is called
Bachman Diagram. Here, the end of the
relationship without an arrow always
represents “One” side of the relationship
and the end with arrow always represents
“Many” side of the relationship.
Our earlier E-R diagram is represented
using Bachman diagram as:
18
BACHMAN DIAGRAM

TEAM
SALARY

PLAYER GAME

BONUS POSITION

19
PHYSICAL DATABASE STRUCTURE
Database Area, Page and File

 IDMS database is divided into one or

more areas. An area is defined as the
major named subdivision of addressable
storage in database.
 An area is further subdivided into
pages. Page is a smallest unit of data
transfer between main memory and
hard disk.
20
Continue …..

 Each page stores control information

and can store up to a maximum 255
database records.
 Database areas can be of different page
sizes. e.g AREA-A can be of page
size 2048 bytes where as AREA-B of
same database can be of page size
4096 bytes.

21
Continue …..
 Page size for an area is decided based
on the record types that will be
residing within that area.
 ALL record occurances of a
particular record type are stored
within the SAME area.
 But, an area may store occurances of
multiple record types. Hence this
holds true for a database page as well.

22
Continue …..
 Record types are assigned to areas by
designer.
 Areas are mapped to files.
 Many or all areas can be mapped
into one file if all areas have the
same page size.
 Each area can be mapped into a
different file.
 One area can be mapped into
several files.
23
AREAS and FILES MAPPING
Area

Page Logical Database

File
Physical Database

Block

24
 Area and File Mapping…..
Team Area Position Area Salary Area
921 922 … 930 1021 1022 … 1040 821 822 ... 830

IDMS File 1 IDMS File 2

25
ADVANTAGES OF MULTIPLE AREAS
TEAM-AREA
SALARY
TEAM

PLAYER GAME

BONUS
POSITION
SALARY-AREA
POSITION-AREA

26
Continue …..
As shown in the previous slide, our
example of baseball database is divided into
three physical areas namely Team-area,
Position-area and Salary-area.
The advantages of dividing a database into
separate physical areas are:
 Processing efficiency
Records those are accessed together
during most of the processing can be
grouped together into same area for
efficiency. 27
Continue …..
 Security
One can restrict access to certain
record types. e.g. salary-area can be
restricted to only finance department.
 Database recovery and backup
Database can be initialized,
reorganized and backed up on area-
by-area basis. Backup of most
updated areas can be made more
frequent than other areas.
28
Continue …..

 Concurrent updating
A program can request exclusive
use of an area and prevent other
programs from accessing it
concurrently.

29
CONCEPT of DB-KEY
Each Record occurrence stored in the
database is assigned an unique numeric
identifier, called Database Key (db-key).
A record’s db-key consists of a 32-bit field
that contains a 23-bit page number and an
8-bit line number. The page number
identifies the page in which the record is
stored and the line number identifies
location of the record occurrence within
the page.
The format of db-key is as below:
30
Sign Bit Database Page Number Line Number
1-bit
23-bits 8-bits
(Not
Used)

31
RECORD TYPE v/s RECORD
OCCURRENCE
It is important to make distinction
between Record Type and Record
Occurrences.
Record type is like a template. It
describes the format of all occurrences of
a given record type stored in database.
Record occurrence represents the smallest
directly addressable unit of data. It
consists of fixed or variable number of
characters that are subdivided into units
called Data Elements.
32
Example of Record Type versus Record
Occurrences
Employee Record Type ……….

Emp-code Emp-name Sex Emp-dept

PIC 9(4) PIC X(30) PIC X PIC X(10)

Employee Record Occurrences …..…...

1000 ABC M TECH

1500 XYZ F SALES

33
STRUCTURE of DATABASE RECORDS
Database consists of collection of record
occurrences.
The physical records stored in a database
consist of more than the data elements
used by the application program.
IDMS also maintains information about
relationships that exists between records.
Relationships are implemented by linking
record occurrences together with pointers.
34
Continue …..
Pointers contain addresses of related
record occurrences and are stored along
with the data portion of the record
occurrences.
A record occurrence in database consists
of two parts.
 Data portion and
 Prefix portion.

35
Continue …..
Data elements values are stored in data
portion. Pointers to related record
occurrences are stored in prefix portion.
Application programs deal only with data
portion of the record occurrence.
Whereas, IDMS system maintains the
pointers in the prefix portion.

PREFIX Portion DATA Portion

Data Data
Pointer Pointer Pointer
….. element 1 element 2
...
1 2 3

36
SCHEMA and SUBSCHEMA

 Schema is the logical definition of a

database. A schema is a complete
database description (all records types &
record elements, set types, files and
areas).
 There is ONE and ONLY ONE schema
for a given database.

37
Continue …..
 A subschema defines a subset of the
schema. One or more subschemas can
be associated with a schema. A load
module is created for each subschema.
At runtime, a program can access only
one subschema. A program can not
access IDMS database by referring to
the schema.
 A subschema is similar to a view in a
relational database.

38
Continue …..
 Even if a program requires access to
ALL record types, data elements and
ALL set types defined in the schema,
the designer must still define a
subschema that includes all the
entities defined in the schema.
 A subschema can restrict access to a
program. For example, it may give
only read-only access to an area, or it
may not allow deletion of some record
types.
39
Record Characteristics

40
The characteristics that apply to record
types are:
Record Name


Record Identifier


Storage Mode


Record Length


Location Mode


Duplicates Option


Area Name


41
RECORD NAME
Each record type must be assigned a 1
to 16 character name that identifies the
record type. The name must begin with
an alphabetic character. The
application program must reference the
record’s name in DML (Data
Manipulation Language).

42
RECORD IDENTIFIER
It is a number that serves as in internal
identifier for the record type. It is in the
range 100 through 9999. Each record
type must be assigned an unique record
identifier within the installation. DBAs
assign this number to each record type.
Application programs do not refer to
record type using this number.
43
STORAGE MODE
It indicates whether record occurances
of the record type are fixed or variable
length and whether they are stored in
compressed format.
Allowable codes are:
 F (fixed length)
 V (variable length)
 C (compressed)
44
Continue …..

NOTE:
Compressed mode can be used along
with fixed or variable length storage
modes. For example, one can mention
storage mode as ‘FC’ or ‘VC’. DBMS
takes care of compression and
decompression of data.

45
RECORD LENGTH

It is expressed in BYTES. It is the

actual data length for fixed-length
record or the maximum data length
for variable-length record.

46
LOCATION MODE
It defines the way record occurances
are stored in the database.
Allowable location modes are:
 CALC
 VIA
 DIRECT

47
CALC Mode
 In CALC mode, a particular data
element within the record is declared as
the CALC-key. At the time of storing
the record in the database, IDMS
system uses value of the data element
to calculate the page number for
storing a record. Records stored with a
CALC mode can be retrieved from disk
in a single access.
48
Continue …..
 IDMS system uses randomizing routine
to distribute records evenly over its area,
minimizing overflow conditions and
leaving space for adding new records.
 For retrieving the record (stored with
CALC location mode), appropriate
value for the data element is moved to
the storage area in the application
program and then DML retrieval
function is executed. 49
VIA Mode
 Records stored with VIA location mode
are stored near another database record.
 This mode is generally used for storing
member records on the same page
containing owner record or on a page
near their owner record.
 This mode tends to reduce disk accesses
needed to retrieve all the records of a set
occurrence.
50
Continue …..

 CALC retrieval is not possible in

case of records stored with VIA
location mode. Generally the owner
record is assigned CALC location
mode for easy access of member
records.

51
DIRECT Mode

 In DIRECT location mode, application

program explicitly specifies the page
into which the record should be stored.
To retrieve this record, programmer
must specify its database address, i.e
db-key of the record.
 This mode is less often used than
CALC and VIA mode.
52
DUPLICATES OPTION

It is specified only for record types that

are stored using CALC location mode. It
specifies whether records with duplicate
CALC-key values are allowed and if so,
how would they be stored in the
database.

Possible codes are as on next slides:

53
Continue …..

 DN (Duplicates Not Allowed)

Record occurances with

duplicate CALC-key value will
not be accepted. IDMS will
give an error if application
program tries to store a record
with duplicate CALC-key.

54
Continue …..

 DF (Duplicates First)

IDMS will store the record with

duplicate CALC-key value Before
any record in the database that has
matching CALC-key value. When
CALC retrieval is made using
CALC-key value, newly stored
record will be retrieved first.
55
Continue …..

 DL (Duplicates Last)

IDMS will store the record with

duplicate CALC-key value After
any record in the database that has
matching CALC-key value. When
CALC retrieval is made using
CALC-key value, newly stored
record will be retrieved last.
56
AREA NAME

It is the name of the area into which all

record occurances of the record type are
to be stored. e.g. CUST-AREA,
SALARY-AREA, SALES-AREA etc.

57
Data Structure Diagram (DSD) for
Documenting Record Characteristics
Record name

Record-id Storage Record Location mode

mode length
Calc key or VIA set name Duplicates option

Area name

58
Example : DSD for Employee Record
Type

EMPLOYEE

1000 F 150 CALC

EMP-CODE DN

HR-AREA
59
Set Characteristics

60
WHAT IS A SET ?
A Set consists of an OWNER record
type and one or more MEMBER record
types.

SET OCCURRENCE ?

A Set Occurrence consists of one

occurrence of owner record type and any
number of member record occurrences.

61
Walking a Set
Records in each set occurrence are
physically linked together by pointers.
Accessing members by following the
pointers from one record occurrence to
the next is called Walking the Set.
Empty Set Occurrence
A set occurrence that consists only of an
owner record occurrence and no
member record occurrences is called
Empty Set occurrence.
62
RULES & FEATURES FOR SET
RELATIONSHIP
• Any record type can be member in one
or more sets.
• Any record type can be owner of one or
more sets.
• Any record type can be member in one
set and owner in another set.
• An owner record can own the same
member record in more than one set.
• A record cannot be both owner and
member in the same set.
63
Any record type can be member in one or more sets

Department Office

Dept-Employee Office-Employee

Employee

64
Any record type can be owner of one or more sets

Customer

Cust-Order Cust-Parts

Order Parts

65
Any record type can be member in one set and
owner in another set

Customer

Cust-Order

Order

Ord-Items

Items
66
An owner record can own the same member
record in more than one set

Teacher

Teach-Class Examiner-Class

Class
67
Set Characteristics
DBA typically assigns characteristics to
each set when defining the IDMS
database in the schema DDL.
The characteristics are:
 Set Name
 Linkage Options
 Membership Options
 Order Option
 Duplicates Option
68
SET NAME

A unique name must be given to each set

type in the database. The name can be
maximum of 16 characters. The set name
must be referenced whenever an application
program accesses records using that set
relationship. Usually it will be owner record
name followed by member record name e.g.
CUST-ORDER.
69
LINKAGE OPTIONS

It indicates the types of pointers that

are used to implement the set.
Pointers provide flexibility in
accessing records in a set occurrence.
Pointers are stored in the prefix part
of the database record occurrences.
Available options are:

70
Continue …..

 N (NEXT pointer)
Each record in the set contains a
pointer to the next record
occurrence. This option allows to
access member records only in the
forward direction. Next pointer is
mandatory for all sets. All other
pointers are optional.

71
Continue …..

 NP (NEXT and PRIOR pointer)

With this, in addition to Next
pointer, each record contains
pointer to prior record occurrence
in the set. This allows us to access
member records in both forward
and backward direction.

72
Continue …..

 NO (NEXT and OWNER pointer)

With this, in addition to Next
pointer, each record contains pointer
to owner record occurrence in the
set. This allows us to access the
owner record directly from any
member record occurrence.

73
Continue …..

 NPO (NEXT, PRIOR and

OWNER pointer)
Each record in the set contains all
three pointers. This option allows
to access member records in both
forward and backward direction
and also allows to access the owner
record directly from any member
record occurrence.

74
 Office

Office-Employee

Employee

Record Occurrences with Next, Prior & Owner Pointers

N P Xansa Mumbai DATA

N P O EMP-A DATA

N P O EMP-B DATA

N P O EMP-C DATA

75
MEMBERSHIP OPTIONS
The Membership options specify how a
member record may be connected to or
disconnected from a set occurrence.
The option is defined in two parts.
 First part is a Disconnect Option,
indicating the way a record is
disconnected from a set.
 Second part is the Connect Option,
indicating how a record is connected to
a set.
76
Disconnect Option
It specifies whether a member record can
be later disconnected from a set once its
membership has been established.
Possible values are:
 M (Mandatory)
The record cannot be disconnected
from a set unless that record is
deleted (erased) from the database
using the ERASE command.
77
Continue …..

 O (Optional)
A record occurrence can be
disconnected from a set. The
record remains in the database. It
can be connected to some other
set occurrence. It is optional to
use ERASE for such records.

78
Connect Option

It specifies whether or not a member

record is automatically connected to a set
occurrence when it is added to the
database.Possible values are:
 A (Automatic)
Automatic means when a member
record is inserted in database, IDMS
will automatically connect it to all its
owner records (provided currencies
have been established for owners).
79
Continue …..

 M (Manual)
Manual option specifies that after
inserting a record, programmer
must explicitly connect it to its
owner record by issuing
CONNECT statement.

80
Combinations for Membership Options

 MA - Mandatory Automatic

 MM - Mandatory Manual

 OA - Optional Automatic

 OM - Optional Manual

81
ORDER OPTION
The order option specifies logical order
in which member record occurrences
are placed within a set occurrence.
Options available are:
 FIRST
Each new member record
occurrence is placed immediately
after the owner record (in the next
direction). This option achieves a
member record in LIFO.
82
Continue …..
 LAST
Each new member record occurrence
is placed immediately before the
owner record (in the prior direction).
This option achieves a member record
in FIFO. Prior pointer is a must to
specify this option.
 NEXT
Each new member record occurrence
is placed immediately after the
member record occurrence that was
last accessed (in the next direction). 83
Continue …..

 PRIOR
Each new member record occurrence
is placed immediately before the
member record occurrence that was
last accessed within the set (in the
prior direction). Prior pointer is a
must to specify this option.

84
Continue …..
 SORTED
Each new member record occurrence
is placed in ascending or descending
sequence, based on the value of
designated sort-control data element
(sort-key) in each record occurrence.
When the record is placed into a set,
DBMS examines the sort-key value
in each member to find the logical
position of new member record in
the set.
85
DUPLICATES OPTION
This option is useful only in case where
set is defined with order option as Sorted.
It indicates the action to be taken when a
duplicate sort-key value occurs.
 DN (Duplicates Not Allowed)
Record occurances with duplicate
sort-key value will not be stored in
the set. IDMS returns an error code
if program tries to store such a
record.

86
Continue …..

 DF (Duplicates First)

Record with duplicate sort-key

value is stored Before any
existing record in the set that has
matching sort-key value. Most
recently stored duplicate record
will be retrieved first.

87
Continue …..

 DL (Duplicates Last)

The record occurrence with

duplicate sort-key value is stored
After existing record in the set that
has matching sort-key value. Most
recently stored duplicate record
will be retrieved last.

88
INDEXED SETS
 IDMS allows retrieval of records using
an index.
 In conventional sets, member records
are chained together by pointers. In an
indexed set, DB-key values of member
record occurrences are stored in a
specified order in one or more index
records.
 Adds flexibility to data retrieval and
retrieval is made faster in some cases.
89
Continue …..
 Indexed sets are useful in cases where:
 Records need to be accessed using

alternate-key (apart from CALC

key).
 Walking very long sets and when

only key values of a member

record is required.
 Member records need to be

retrieved randomly using partial

key value.
90
Continue …..
 Indexed sets can be implemented
using two database record types or
a single record type and a system
defined record type.

91
Continue .....

User-defined
Owner Record Player

Player-Position-Index
(Position-Name)

Position

92
Continue .....

SR7
System-defined owner
record
(Employee-Name)

Employee

93
Continue …..

 Index between Player and Position

records allows to access position
records using Position-name values.
 System owned index on employee
implements alternate index on
employee-name.

94
 TEAM-PLAYER TEAM-GAME
NPO NPO
SALARY
OM TEAM
MM
2000 F 40 VIA LAST 1100 F 80 CALC NEXT
PLAYER-SALARY TEAM-NAME DN
SALARY-AREA TEAM-AREA
PLAYER-SALARY
NPO
OA
PLAYER GAME
NEXT
1000 F 70 CALC 1200 F 70 CALC

PLAYER-BONUS PLAYER-NAME DN GAME-PLAY-DATE DN

NPO TEAM-AREA TEAM-AREA
OA
NEXT
BONUS POSITION
3000 F 50 VIA
2500 F 25 VIA
PLAYER-POSITION GAME-POSITION GAME-POSITION
PLAYER-BONUS
NPO NPO
POSITION-AREA
SALARY-AREA OA MA
NEXT NEXT 95
IDD & Data Dictionary
Definition Language
(DDDL)

96
INTEGRATED DATA DICTIONARY (IDD)
 IDD stores meta-data about all the data items
in the database (The data values are not stored
in IDD).
 Stores information about users, application
programs, files, record, data element, module
(date routine, error handling routine) and
application systems.

 IDD is integrated with every software

component provided in IDMS like ADSO,
OLQ and Report Generator. Each software
component accesses IDD to get information
about data items and programs. 97
DATA DICTIONARY DEFINITION
LANGUAGE (DDDL)

The data dictionary definition language

(DDDL) is used to create, update or delete
entity occurrences in IDD.

DDDL provides five verbs to manipulate

entities:
 ADD to add a new entity.

 MODIFY to change entity description.

98
Continue …..

 DELETE to remove an entity.

 DISPLAY to display an entity
description.
 PUNCH to copy entity
information from IDD to a file.

99
Examples of DDDL

 ADD ELEMENT CITY-NAME

ELEMENT DESCRIPTION ‘TEAM CITY’
PICTURE X(20)
USAGE DISPLAY.

 DISPLAY PROGRAM STATSEDIT.

 DELETE PROGRAM NAME IS STATSEDIT.

100
Continue …..
 MODIFY ELEMENT CITY-NAME
PICTURE X(25).

 MODIFY PROGRAM NAME IS STATSEDIT

VERSION IS 1
LANGUAGE IS COBOL
ESTIMATED LINES 5000.

 SIGNOFF. ( to exit from IDD )

101
Data Description
Language (DDL)

102
Data Description Language (DDL) is
used to define:

 SCHEMAS
DBA describes the logical
structure of the database by coding
set of schema DDL statements.
There is a single schema for a
given database.

103
 DEVICE-MEDIA CONTROL
LANGUAGE (DMCL) MODULES
Many aspects of the database’s
physical structure, such as disk
device assignments and page sizes
are described in DMCL module
definition.

104
 SUBSCHEMAS
The views that individual
applications programs have of the
database are defined in
subschemas and described with set
of subschema DDL statements.
Any number of subschemas can be
defined for a given database.

105
SCHEMA DDL STATEMENTS
The logical structure of a database is defined
in a set of schema DDL statements.
Schema DDL statements define the
following:
 Schema name
 Database file names
 Database areas
 Data elements and records
 Sets
106
Process
 The schema DDL is processed by the
schema compiler. The schema
compiler reads the schema DDL
statements and stores a description of
the schema in the data dictionary.
 The data dictionary is the central
repository of information that IDMS
maintains about the databases under its
control.
107
Continue …..
 The schema compiler can also copy from
the data dictionary descriptions of records
that have been previously defined and
stored in the data dictionary.

Schema
Schema Data
DDL Compiler Dictionary
Statements

108
Example Of Schema DDL
ADD SCHEMA NAME IS DDSCHEMA VERSION 1

ADD FILE NAME IS CUST-FILE

ASSIGN TO CUST.
ADD FILE NAME IS ORDER-FILE
ASSIGN TO ORDER.

ADD AREA NAME IS CUST-AREA

PAGE RANGE IS 505000 FOR 100
WITHIN FILE CUST-FILE.
ADD AREA NAME IS ORDER-AREA
PAGE RANGE IS 809000 FOR 100
WITHIN FILE ORDER-FILE.
109
Continue …..
ADD RECORD NAME IS CUST-REC RECORD ID IS 3000
LOCATION MODE IS CALC USING (CUST-NO)
DUPLICATES ARE NOT ALLOWED
WITHIN AREA CUST-AREA.
02 CUST-NO PICTURE IS 9(6) USAGE IS DISPLAY.
02 CUST-NAME PICTURE IS X(40) USAGE IS DISPLAY.

ADD RECORD NAME IS ORDER-REC RECORD ID IS 3100

LOCATION MODE IS CALC USING (ORDER-NO)
DUPLICATES ARE NOT ALLOWED
WITHIN AREA ORDER-AREA.
02 ORDER-NO PICTURE IS 9(7) USAGE IS DISPLAY.
02 ORDER-STATUS PICTURE IS X(1) USAGE IS DISPLAY.
02 ORDER-REQ-DT PICTURE IS 9(8) USAGE IS DISPLAY.
110
Continue …..

ADD SET NAME IS CUST-ORDER

ORDER IS NEXT
MODE IS CHAIN LINKED TO PRIOR
OWNER IS CUST-REC
MEMBER IS ORDER-REC LINKED TO OWNER
MANDATORY AUTOMATIC.

111
DMCL DDL STATEMENTS
It completes the mapping of logical areas
into physical files.
It also identifies and describes the journal
files that are used by IDMS for recording
changes made to the database. Journal
files are used to implement IDMS backup
and recovery facilities.

112
Continue …..

DMCL DDL statements define the

following:
 DMCL module name
 Schema name associated with this
DMCL module
 Sizes of the I/O buffers
 Information about database areas
 Information about journal files used
for backup and recovery
113
Process
 The DMCL definition is processed by
the DMCL compiler. The DMCL
compiler reads the DMCL source
statements and stores a description of the
DMCL module in the data dictionary.
 As the DMCL compiler processes
DMCL source, it must have access to the
corresponding schema definition in the
data dictionary. For this reason, schema
must be compiled before its associated
DMCL module.
114
Continue …..
 The DMCL compiler also generates a
set of assembler language source
statements. These are in turn processed
by assembler and the linkage editor to
form an executable DMCL load
module. The linkage editor places the
load module into a load module library.
The DMCL load module is used by
IDMS at run-time when an application
program accesses the database files
described by the DMCL module. 115
Continue …..

DMCL DMCL
Source Compiler Data
Statements Dictionary

Assembler

Load
Linkage Library
Editor
116
Continue …..
DMCL DDL statements contain following
four sections:
 Device-Media Description section

This sections gives name to the DMCL

statements. It further provides other
documentary details about the DMCL
module.
 Buffer section

It assigns page size and defines buffers

that IDMS will use to handle database
accesses.
117
Continue …..
 Area section
Information about each area is copied
from the schema into this section of the
DMCL. The section assigns each area
to buffers that were defined in the
buffer section.
 Journal section
The section describes disk files to be
used for journaling. Journal files are
used to keep track of database activity.
118
Example Of DMCL DDL
DEVICE-MEDIA DESCRIPTION.
DEVICE-MEDIA NAME IS DMCLBASE OF
SCHEMA NAME SCHBASE VERSION 1.
DATE. DD/MM/YY.
INSTALLATION. XANSA MUMBAI
INDIA.
BUFFER SECTION.
BUFFER NAME IS XXBUFF
PAGE CONTAINS 4096 CHARACTERS
BUFFER CONTAINS 5 PAGES.

JOURNAL BUFFER NAME IS JJBUFF

PAGE CONTAINS 3188 CHARACTERS
BUFFER CONTAINS 3 PAGES.

119
Continue …..

AREA SECTION.
COPY SALARY-AREA AREA
BUFFER IS XXBUFF
JOURNAL SECTION.
JOURNAL BUFFER IS JJBUFF.
FILE CONTAINS 3000 BLOCKS.
FILE NAME IS XANJRNL1
ASSIGN TO SYSJRNL1.
FILE NAME IS XANJRNL2
ASSIGN TO SYSJRNL2.

120
SUBSCHEMA DDL STATEMENTS

Subschema DDL statements specify the

following:
 Subschema, Schema and DMCL

module name
 Areas accessible in this

subschema
 Records and data elements

accessible and
 Sets included in the subschema

121
Process
 The subschema compiler reads
subschema source statements and
stores a description of the subschema
in the data dictionary.
 The compiler also stores an executable
load module in an area of the data
dictionary, known as Load Area.
 IDMS uses this load module whenever
an application program using this
subschema is under execution.
122
Continue …..
 Like DMCL compiler, subschema
compiler must have access to the
corresponding schema definition in the
data dictionary. Thus, schema must
have been compiled before any of its
associated subschemas can be
compiled.
 After compiling subschema, data
dictionary has all the required
information about the logical and
physical structures of the database.
123
Continue …..

Subschema Subschema Data

DDL Compiler Dictionary

Load Area

124
Example Of Subschema DDL
ADD SUBSCHEMA NAME SUBSCHA OF SCHEMA
NAME SCHDBA VERSION 1
DMCL NAME SUBADMCL OF SCHEMA NAME
SCHDBA VERSION 1
COMMENTS ‘LIMITED VIEW OF SCHDBA’

ADD AREA NAME IS CUST-AREA.

ADD AREA NAME IS ORDER-AREA.
ADD RECORD NAME CUST-REC
ELEMENTS ARE CUST-ID CUST-NAME.
ADD RECORD NAME ORDER-REC
ELEMENTS ARE ALL.
ADD SET NAME ORDER-ACTION.
ADD SET NAME CUST-ORDER.
GENERATE.

125
Data Manipulation
Language
(DML)

126
In an IDMS application program, there
are no file description statements or Open
and Close statements found in a typical
batch Cobol file processing application
system.
To access data stored in the database,
DML verbs are used.
Two new terms Run Unit and Currency
are important to understand.

127
CONCEPT of RUN UNIT

The run unit is that portion of program’s

processing during which it has access to
one or more database areas and services.

 The BIND RUN-UNIT statement is

used to specify the start of a run unit.
 A run unit ends when program
completes all database processing and
issues a FINISH statement.

128
Continue …..

 The program may perform some

processing before it begins a run
unit.
 The program may perform some
processing even after it finishes a run
unit.
 A program may begin and end more
than one run unit.
129
CONCEPT of CURRENCY

 IDMS internally stores pointers to

the most recently accessed records.
It uses these pointers to access
subsequent records. These pointers
are referred to as CURRENCY.
 At the beginning of a program, all
currencies are null.

130
Continue …..
 Currency is established by DML verbs
FIND, OBTAIN, STORE,
CONNECT, DISCONNECT and
ERASE.
 There are four currencies maintained
for a database:
 current of run unit
 current of record type
 current of set
 current of area
131
Continue …..
 Current of Run Unit is a record
which was most recently accessed.
 Current of Record type is the most
recently retrieved or inserted record
of that record type.
 Current of Set is the most recently
retrieved or stored record of that
set. Record may be a member or
owner of that set.

132
Continue …..
 Current of Area is the most recently
retrieved or stored record of that area.

 When a record is erased, currency of its

record type and its sets is set to null. Run
unit and area currencies are unchanged.

133
IDMS APPLICATION PROGRAM PREPARATION

Source DML
Statements Processor Data
Dictionary

Compiler

Load
Linkage Library
Editor
134
The previous slide shows how an IDMS
application program written in Cobol host
language is compiled and made ready for
execution.
Application program with embedded
DML statements is first read by DML
processor. It validates DML statements
and creates translated version of the source
program where in DML statements are
replaced by appropriate calls to IDMS.

135
Continue …..
DML processors are available for a
number of commonly used programming
languages. DML processor may also
generate a listing of errors. DML
processor interacts with data dictionary
for copying descriptions of various
database elements like schema,
subschema, record types etc.
Output from the DML processor acts as
input to the host programming language
compiler like a Cobol compiler.
136
Continue …..

After the translated source program is

compiled by host language compiler, the
resulting object module is processed by
Linkage editor to create an executable
load module.

The Linkage editor also includes copy of

a routine called IDMS Interface Module
in final load module. IDMS service
requests from the program are converted
in to calls to IDMS Interface Module.
137
Continue …..

Following are typical changes one

notices in a n IDMS Cobol application
program.
 IDENTIFICATION DIVISION
remains exactly the same as before.
 ENVIRONMENT DIVISION has
IDMS-CONTROL section.

138
Continue …..
 DATA DIVISION begins with
SCHEMA SECTION which gives
the subschema used by the
program.
 PROCEDURE DIVISION has
DML verbs for data retrieval and
data updation.

139
IDMS-CONTROL SECTION
.….
ENVIRONMENT DIVISION.
IDMS-CONTROL SECTION.
PROTOCOL.
MODE IS BATCH DEBUG.
IDMS-RECORDS WITHIN WORKING-STORAGE SECTION.
CONFIGURATION SECTION.
…..
INPUT-OUTPUT SECTION.
FILE CONTROL.
…..
140
Continue …..

The PROTOCOL statement is a

compiler-directive statement that
specifies the manner in which DML
processor will generate CALL
statements.

Application program must specify one

of the following modes to access
database:
141
Continue …..

 BATCH (a batch program with

database processing)
 IDMS-DC (a non-batch program i.e.
an online program called by a dialog
process)
 DC-BATCH (a batch program with
access to DC queues)

142
Continue …..

‘DEBUG’ instructs DML processor to

produce additional code in the resulting
source code which is helpful during
program debugging.
The IDMS-RECORDS clause specifies
that the data definitions for records and
data elements will be copied automatically
from the data dictionary and placed at the
end of working storage section.
143
DATA DIVISION
.….
DATA DIVISION.
SCHEMA SECTION.
DB SUBEMP WITHIN SCHEMP.
FILE SECTION.
…..
WORKING-STORAGE SECTION.
…..

144
Continue …..

As explained earlier, DATA DIVISION

begins with SCHEMA SECTION which
gives the subschema used by the
program.

As shown in previous slide, SUBEMP is

the name of the subschema which will be
used by the program.

Further, the SCHEMP is the schema

from which SUBEMP subschema is
145
derived.
BIND STATEMENT

BIND RUN UNIT.

BIND EMPLOYEE.
BIND MANAGER.
BIND PROJECT.
BIND SALARY.

Above example displays the typical

code that might be found in the
Procedure Division of an IDMS
Cobol program.
146
Continue …..

The first statement BIND RUN-UNIT

establishes addressability for the IDMS
communications block and causes
IDMS to load the subschema identified
in the Schema section. Next four BIND
statements establish addressability for
the working-storage areas that will be
used to contain record occurrences.
147
Continue …..
Generally, following one statement is
found in the source code.
COPY IDMS SUBSCHEMA-BINDS.
When the source is pre-compiled, the
above single statement is replaced by
previous set of five Bind statements.
BIND statement identifies the record
types that the program will access.

148
COPY STATEMENT

COPY IDMS SUBSCHEMA-BINDS.

COPY IDMS IDMS-STATUS.

Copy statement is a compiler directive

statement.

In first example above, the copy

statement generates appropriate Bind
statements at the time of pre-compile.

149
Continue …..

As in second example, the copy

statement copies module called
IDMS-STATUS from data
dictionary into the source code
when it is pre-compiled. This
particular module (routine) checks
result of DML statement.

This helps in reducing coding effort.

150
READY STATEMENT

READY EMPLOYEE-AREA USAGE IS RETRIEVAL.

READY SALARY-AREA USAGE EXCLUSIVE UPDATE.
READY USAGE IS RETRIEVAL.

Ready statement can be thought as an

equivalent to Open statement for a
conventional file. It gives the program
access to all or named areas defined in
the subschema and begins a run-unit.

151
Continue …..

The usage-mode clause in the Ready

statement indicates whether the program
will only retrieve data or update it as
well.

If no areas are mentioned in the Ready

statement, then all areas mentioned in
the subschema will be made available to
the program by default in the mode
specified in the Ready statement.
152
FINISH STATEMENT

FINISH.

Finish statement is used to end a run

unit by releasing database resources and
terminating database processing.

Non-database processing of the program

may continue after the Finish statement,
but database can not be accessed (unless
a fresh run unit is started).
153
FIND STATEMENT

MOVE INPUT-EMP-CODE TO EMPLOYEE-CODE.

FIND CALC EMPLOYEE.

Find statement is used to locate a record

occurrence in the database. The record
occurrence is placed in the system
buffers but the data element values are
still not available in the variable storage
of the program.
154
Continue …..

There are situations when we do not need

actual values of a record occurrence like:
 We may need to verify that a
particular record occurrence exists
 We need to establish currencies for
some subsequent record retrieval
In the example, the required employee
information is moved to the CALC-key
data element of Employee.
155
Continue …..

Next, Find statement will locate the record

occurrence with matching employee-code.

If the Find is successful, currencies are set

appropriately but the individual data
element values for the located record are not
yet made available to the program.

In case, data element values are required

then Find can be followed by Get statement.
156
GET STATEMENT

MOVE INPUT-EMP-CODE TO EMPLOYEE-CODE.

FIND CALC EMPLOYEE.
GET.

Get statement is used to make available to

the program a record occurrence that was
previously located by the Find statement.
Get statement can qualify the record type
or it can be unqualified as in this case.
157
Continue …..

To continue with our earlier Find example,

we have followed it with unqualified Get.
This will transfer record occurrence values
to the variable storage.

If Get is qualified then IDMS will verify

whether the previously located record is
Employee record or not. If it does not
match then IDMS will return error code.
158
OBTAIN STATEMENT

The Obtain statement is equivalent of a

Find followed by a Get.
It is most widely used statement for
data retrieval in IDMS.
There are many syntax variations
available for Obtain statement, based
on location mode of records and mode
of retrieval.

159
Continue …..

CALC-key Retrieval
To perform Calc-key retrieval, the record
must have location mode specified as
CALC and we must know the Calc-key
value for the record to be retrieved.

MOVE INPUT-EMP-CODE TO EMPLOYEE-CODE.

OBTAIN CALC EMPLOYEE.

160
Continue …..

As shown in previous example, we move

the Calc-key value for the record to be
retrieved to the data element of Employee
record type that is defined as Calc-key
(Employee-Code) and issue Obtain
statement to get the record contents.
IDMS uses the Calc-key value supplied to
calculate the target page for the data
retrieval.
161
Continue …..

Duplicate CALC-key Retrieval

Sometimes the record type is defined
with duplicate allowed option. We can
try and find out if duplicate record exists
for a given Calc-key value.

MOVE INPUT-EMP-NAME TO EMPLOYEE-NAME.

OBTAIN CALC EMPLOYEE.
OBTAIN DUPLICATE EMPLOYEE.

162
Continue …..

As shown in previous example, we

obtain the first record with matching
Calc-key value in normal way.
The second Obtain statement tries to
obtain duplicate record with same
Calc-key value. If it exists then IDMS
fetches the record, else an error code is
returned.
163
Continue …..

Member Record Retrieval

Many times, we need to retrieve owner
record for a set occurrence and then
proceed to retrieve one or more of its
member records.
Following are some of the examples of
such typical member retrieval criteria.

164
Continue …..

OBTAIN FIRST EMPLOYEE WITHIN DEPT-EMP.

OBTAIN LAST EMPLOYEE WITHIN DEPT-EMP.

OBTAIN NEXT EMPLOYEE WITHIN DEPT-EMP.

OBTAIN PRIOR EMPLOYEE WITHIN DEPT-EMP.

OBTAIN OWNER WITH DEPT-EMP.

OBTAIN 5 WITHIN DEPT-EMP.

165
Continue …..

By first retrieving the owner record, we

establish the currency for the subsequent
member retrievals. Owner becomes
current of run unit, record type and set
type. Now to access members within the
set becomes relatively simple task.
“Obtain First” gets the first member
record within the set.
166
Continue …..

“Obtain Last” gets the last member

record within the set. For this, the set
must have been defined with prior
linkage option.
Next option is known as Walking the Set.
“Obtain Next” gets each member in
sequence. This statement is executed in a
loop generally till end-of-set is reached.
167
Continue …..

“Obtain Prior” gets the prior member

record within the set. For this, the set
must have been defined with prior
linkage option. This works in same
manner as Next option, except that it
is in the reverse direction.

168
Continue …..

We can obtain owner of the set by

“Obtain Owner” statement.
If set is defined with Owner linkage
pointer then owner is obtained directly.
In case such pointer is absent, IDMS
walks through the entire set and
obtains the set owner.

169
Continue …..

We can obtain specific member record

within the set by its relative position with
respect to owner in the ‘next’ direction.

“Obtain 5” will fetch the fifth member

record in the set.

170
Continue …..

Current Record Retrieval

Many times, we need to retrieve records

based directly on various currency.

OBTAIN CURRENT EMPLOYEE.

OBTAIN CURRENT WITHIN DEPT-EMP.
OBTAIN CURRENT WITHIN EMPLOYEE-AREA.

171
Continue …..

 In first case, IDMS obtains the record

that is current of the Employee record
type.
 In second case, current of the Dept-Emp
set type is fetched. Depending on
currency established, either Dept record
or an employee record is obtained.
172
Continue …..

 In last case, current of employee-area

is obtained. e.g. if employee-area
contains employee, project, salary
record types then depending on
currency, the statement will fetch
record occurrence of any one of these
record types.
173
Continue …..

Area Sweep Retrieval

Sometimes, we need to retrieve records by

doing an area sweep. IDMS scans through
the area in physical sequence. Area sweep
is used when we need to access all records
within an area, irrespective of the record
types and/or their sequence.
174
Continue …..

OBTAIN FIRST WITHIN EMPLOYEE-AREA.

OBTAIN NEXT WITHIN EMPLOYEE-AREA.
OBTAIN LAST WITHIN EMPLOYEE-AREA.

In first case, the record having lowest

db-key value within the employee-area
will be fetched. In second case, record
having next highest db-key value will
be obtained. The sweep in reverse
direction as in last case can also be
made. 175
Continue …..

OBTAIN FIRST EMPLOYEE WITHIN

EMPLOYEE-AREA.
OBTAIN LAST EMPLOYEE WITHIN
EMPLOYEE-AREA.

As shown above, the record type can

also be qualified during the area sweep.
Only record type mentioned in the
statement (employee) are obtained
during the sweep. Occurrences of other
record types are ignored.
176
Continue …..

Sort-Key Retrieval

We can retrieve records based on sort-

key values, provided the set is defined as
Sorted order option.

In our earlier example of American

baseball league database, suppose that
set Player-Position is defined as Sorted.
177
Continue …..

The sort-key data element is Position-

name of Position record.
Then we can retrieve Position record
directly based on sort-key value as below.
….
OBTAIN CALC PLAYER-REC.
MOVE INPUT-POSITION-NAME TO POSITION-NAME.

OBTAIN POSITION-REC WITHIN PLAYER-POSITION

USING POSITION-NAME.
178
Continue …..

In the example, a position-name value is

moved to sort-key data element and then
Obtain statement is issued using reference
to the sort-key element.
The retrieval appears similar to CALC, but
in this case the search is made only within
the current set occurrence and not within
entire record type.
179
Continue …..

DB-Key Value Retrieval

If we know the dB-key value of a record

then we can directly obtain the record.
This is useful in cases where we know
that a particular record would be
processed again later on during the
execution of the program.
180
Continue …..

When a record is successfully retrieved

or located, its dB-key value is available
in the IDMS Communication Block. We
can store this value in a variable storage
area for later use. Later on, we can use
the stored dB-key value to retrieve the
record and process it.
181
Continue …..
…..
MOVE INPUT-PLAYER-NAME TO PLAYER-NAME.
OBTAIN CALC PLAYER-REC.
…..
MOVE DBKEY TO SAVE-DBKEY.
…..
OBTAIN DB-KEY IS SAVE-DBKEY.

182
Continue …..

Note that the dB-key of a record may

undergo change whenever a database is
reorganized. Hence it is not always
advisable to save dB-key values for a
long time with an intention of using
them later on.

183
Continue …..

Index Set Retrieval

Using index sets, following types of

retrieval is made possible which is
otherwise very difficult.
 Generic key retrieval.
 Random and sequential retrieval based
on a key other than Calc-key.
184
Continue …..

Suppose in our baseball example, Player

record has a system indexed set IX-
PLAYER-NAME on Player-Name
element, then we can retrieve a player
record by supplying a partial key to
IDMS. Such retrieval is not possible
unless we have index set. In Calc, we
have to supply complete key value.
185
Continue …..
01 WS-PLAYER-NAME.
05 FIRST-INITIAL PIC X.
05 FILLER PIC X(29).
…..
MOVE LOW-VALUES TO WS-PLAYER-NAME.
MOVE WS-INITIAL-LETTER TO FIRST-INITIAL.
MOVE WS-PLAYER-NAME TO PLAYER-NAME.
OBTAIN PLAYER-REC WITHIN IX-PLAYER-NAME
USING PLAYER-NAME.
…..
OBTAIN NEXT PLAYER-REC WITHIN IX-PLAYER-NAME.

186
Continue …..

Say we want to retrieve all players

starting with ‘C’.

We move ‘C’ to ws-initial-letter and rest

is filled with low values. This is called
Partial key value.

Then the program will obtain first player

starting with name ‘C’.
187
Continue …..

First obtain statement is random retrieval

using index set. Whereas the second
obtain statement is the example of the
sequential retrieval using index set.

Program has to check name field after

every retrieval to determine if it has
reached the last record with specific name.
188
MODIFY STATEMENT

The Modify statement is used to

change data element values in an
existing record occurrence.

Important considerations for a record

to be successfully modified are:
 Ready the concerned area(s)
with one of the update options.

189
Continue …..
 Making the record to be modified
as current of run unit. This is done
by retrieving the record before
modifying it, by issuing Obtain.

190
Continue …..
MOVE INPUT-EMP-CODE TO EMPLOYEE-CODE.
OBTAIN CALC EMPLOYEE.
IF DB-STATUS-OK
MOVE NEW-EMP-ADDRESS
TO EMPLOYEE-ADDRESS
MODIFY EMPLOYEE
PERFORM IDMS-STATUS.

Above example shows how an existing

Employee record is modified.

191
STORE STATEMENT

The Store statement is used to add new

record occurrence to the database.
Adding a new record involves:
 Constructing new record
occurrence in the record’s area in
variable storage.

192
Continue …..

 Establish currency with correct set

occurrences in which the new
record participates as automatic
member. FIND is used to set
currencies.
 Issue Store statement specifying
the name of the record type we are
adding.

193
Continue …..

Syntax for Store is :

STORE EMPLOYEE.

While adding a new record, following

information is analyzed.

194
Continue …..

 Location where new record is added.

If location mode is CALC, then based
on Calc-key value, storage page is
calculated. For VIA, optimum
location is found based on the
location of owner record. If its
DIRECT, then program specifies the
page number through db-key.
195
Continue …..

 Where in the set occurrences the new

record should be inserted.
Before issuing Store, set order option
is also examined. Depending on
order option like first, last, next etc,
the new record is inserted in
appropriate position within the set.

196
ERASE STATEMENT

The Erase statement is used to delete

a record occurrence from the
database.
Erase statement often affects not only
the record that is being deleted but, in
some cases, also members of sets
owned by that record.

197
Continue …..

There are four options available for the

Erase statement.
 ERASE
 ERASE ALL MEMBERS
 ERASE PERMANENT MEMBERS
 ERASE SELECTIVE MEMBERS

198
Continue …..

ERASE
We first begin by retrieving the record
we want to delete and thus the record is
made current of run unit. Then Erase is
issued naming the record type.
The record is first disconnected from all
sets in which it participates as a
member.

199
Continue …..

Then the record occurrence is

removed (erased) from the database.
If the record is the owner of any sets,
then the record will be erased ONLY
IF those sets are empty. If we try to
erase an owner record of a non-empty
set, IDMS returns an error status code.

200
Continue …..
MOVE INPUT-EMP-CODE TO EMPLOYEE-CODE.
OBTAIN CALC EMPLOYEE.
IF DB-STATUS-OK
ERASE EMPLOYEE
PERFORM IDMS-STATUS.

Above example shows how an existing

Employee record is erased from the
database with unqualified Erase statement.

201
Continue …..

ERASE ALL MEMBERS

First the record occurrence is removed
from the database.
Then all its members, both mandatory
and optional, are also removed from
the database.

202
Continue …..

ERASE PERMANENT MEMBERS

First the record occurrence is erased from
the database.
Then all mandatory members in all sets
owned by the record are also removed.
Optional members are NOT removed but
they are disconnected from their respective
set occurrences.
203
Continue …..

Lastly, if the erased member is the

owner of any sets then it is treated as if
an Erase Permanent is issued for it. Its
mandatory members are removed and
optional members are disconnected.
This process continues until all
members have been processed.

204
Continue …..

ERASE SELECTIVE MEMBERS

First the record occurrence is erased from
the database.
Then all mandatory members in all sets
owned by the record are also removed.
Optional members are removed, provided
they do not participate in any other sets.

205
Continue …..

Lastly, if the erased member is the

owner of any sets then it is treated as
if an Erase Selective is issued for it. Its
mandatory members are removed and
optional members are removed if they
do not participate in any other sets.

206
CONNECT STATEMENT

CONNECT EMPLOYEE TO DEPT-EMP.

Connect statement is used to link a record

occurrence into a set.
Here, we name both the record type and
the set type.
The statement causes the current of
record type to be connected to the set
occurrence that is current of set type.
207
Continue …..

In case of set defined with Automatic

member option, the member record gets
connected automatically at the time of
addition to the database.
With set defined with Manual member
option, Connect statement is used to
manually set up link with a set
occurrence.
208
DISCONNECT STATEMENT

Disconnect statement cancels the membership

of a record in a set occurrence in which it
currently participates as a member.
The record that is being disconnected, must be
defined as an Optional member of that set. If
not then IDMS returns an error code.

DISCONNECT EMPLOYEE FROM DEPT-EMP.

209
QUEUE RECORDS
 We write temporary data to a queue
record in data dictionary and make this
data available to other IDMS COBOL
programs (DC-BATCH Mode).
 Queue records are relatively
permanent records in that they are not
deleted when the system is shutdown
or when the system crashes. They are
deleted either explicitly by
programmer or after the retention
period specified for the queue is over.
210
Continue …..

 As the data remains permanent, it is

global in a sense. Thus, queues are
used to pass data information from
one application to another.
Specifically this feature is very
widely used in online applications
using ADSO.

211
QUEUE MANAGEMENT COMMANDS

Commands to write a record to a queue,

retrieve a queue record and delete a
queue record are:

 PUT QUEUE ID queue-id

 GET QUEUE ID queue-id
 DELETE QUEUE ID queue-id

212
Continue …..

PUT QUEUE ID queue-id

This command is used to store a
queue record in the data dictionary in
the queue identified by the queue-id.
An added parameter of Last or First
can be mentioned to instruct whether
the new queue record will be placed
at the beginning or end of the queue.
Default is Last.

213
Continue …..

GET QUEUE ID queue-id

This command is used to transfer the
contents of a queue record to a
specified location in the variable
storage. Added parameter is Delete or
Keep. Delete will remove the record
from the queue after retrieval. Keep
will retain the record in the queue.
Default is Delete.

214
Continue …..

DELETE QUEUE ID queue-id

This command is used to delete one
or all queue records in a specified
queue. Added parameter is Current or
All. Current will delete only the
current record of the queue. All will
delete all queue records, including the
header record.
Default is Current.

215
MAJOR CODES OF ERROR-STATUS
01 : FINISH
02 : ERASE
03 : FIND/OBTAIN
05 : GET
06 : KEEP
07 : CONNECT
08 : MODIFY
09 : READY
216
Continue …..

11 : DISCONNECT
12 : STORE
14 : BIND
18 : COMMIT
19 : ROLLBACK

217
Recovery and Restart
of Database

218
 IDMS provides facilities for recovering
from problem situations and for restarting
after failures occur.
 Journal files are used for the recovery
and restart facilities.
 These facilities are dependant on the two
operating environments in which an
IDMS run unit executes.

219
IDMS OPERATING ENVIRONMENTS
IDMS application program can be run in
two operating environments: Local Mode
and Central Version.
All online applications that use IDMS/DC
or some other telecommunication facilities
must run under central version.
An application program that operates in
batch mode can be run either under the
control of central version or in local mode.
220
Central Version
 In central version, a single copy of the
IDMS DBMS controls the operation of a
particular set of IDMS application
program run units.
 No two central version are allowed to
update the same database area. All run
units that execute under the control of a
particular central version are chosen such
that they all access the same group of
database areas.
221
Continue …..
 Multiple copies of IDMS central version
can execute in same region with each
copy accessing different set of database
areas.
 Central version implements facilities for
recovering from system failures.
 It is the preferred method of running an
IDMS application.
222
Local Mode
 A batch program that operates in local mode
has its own copy of IDMS DBMS loaded
into its partition, region or address space.
 IDMS provides no automatic restart and
recovery facilities for applications running
in local mode.
 Batch retrieval programs are good
candidates for running in local mode.
 An application runs faster in local mode.
223
JOURNAL FILES
 IDMS maintains set of journal files that
are used to recover from failures and to
restart aborted run units.
 IDMS provides automatic restart and
recovery facilities for applications
running under central version AND for
run units those use journal files.
 Journal files can be put on disk or tapes.
224
CHECKPOINTING
When a run unit begins by issuing BIND
run-unit statement, IDMS system writes
Begin checkpoint record on the journal
file. This contains information about
current status of the run-unit.
As run-unit executes, it may update
records in database. As each update
request is processed, IDMS writes
Before Image and After Image of the
updated record to the journal file.
225
Continue …..
When applications ends the run-unit by
issuing FINISH statement, IDMS writes
End checkpoint record on to the journal file.
Thus, at the end of execution of a run-unit
the journal files contains:
 Begin checkpoint
 Before and After images of all
updated records and
 End checkpoint
226
RECOVERY and RESTART
Following are typical scenarios when run
unit is terminated abnormally.
 Program error may cause the run unit
to terminate abnormally.
 IDMS system may encounter
situations that require it to terminate
one or more run units abnormally. e.g.
Wait time limit has been exceeded to
avoid deadlock.
227
Continue …..

In situations like these, when a run unit is

terminated abnormally after it has updated
one or more database records; IDMS
works backwards in the journal file until it
reaches the Begin checkpoint record and
uses the information in the Before images
to reverse effect of database updates
already made by the aborted run unit. The
run unit can then be restarted from the
beginning.
228
RECOVERY UNIT
All run units that terminate normally,
create at least two checkpoint records
on the journal file: BEGIN
CHECKPOINT when Ready/Bind
statement is executed and END
CHECKPOINT when FINISH
statement is executed. Before and After
images that are recorded between these
two checkpoints constitute a record of
all updating the run unit performed.
229
Continue …..

The processing that a run unit performs

between checkpoints is called Recovery
Unit.
In the simplest form, the entire run unit
constitutes a single recovery unit.

230
INTERMEDIATE CHECKPOINTS

In real life scenario (for online

applications), a separate run unit is started
for each incoming transaction. Very few
database updates are made during each run
unit. Each run unit is a single recovery
unit.
At times, it is required to divide the run
unit into many smaller run units to reduce
the time for recovery in case of run unit
failure.
231
Continue …..

This leads us to the concept of

Intermediate checkpoints.

To create intermediate checkpoints, run

unit periodically issues a COMMIT
statement to make permanent all
database updates that has already been
made.

232
THE COMMIT VERB
Commit verb is used to write Intermediate
checkpoints on the journal file.
There are two forms of Commit verb:
COMMIT and
COMMIT ALL

233
Continue …..
In COMMIT, IDMS releases all locks
except those placed on current records.
In COMMIT ALL, IDMS releases all
locks including those on current records.
In case of abnormal termination of run
unit, IDMS works backwards in the
journal file and reads till the most recent
COMMIT checkpoint is encountered.

234
Continue …..

Now the journal file is not read till

Begin checkpoint. The run unit can
now be restarted from the point at
which it wrote the most recent Commit
checkpoint.

A simple thumb rule of 500 or 1000

database updates is used to issue a
Commit statement.
235
THE ROLLBACK VERB
Sometimes an application program may
itself decide to back out all the updates it
made to the database since it wrote the last
intermediate (commit) checkpoint.
To back out the changes, we can issue a
ROLLBACK statement.
It has two forms:
ROLLBACK and
ROLLBACK CONTINUE
236
ROLLBACK

It writes a checkpoint record to the

journal file, nullifies all currencies,
automatically restore the database
using the before images from the
journal and terminate the run unit.

After issuing the unqualified Rollback,

to access the database again, we must
reissue the Bind.

237
ROLLBACK CONTINUE

This form causes IDMS to restore the

database but does not terminate the run
unit.

One can access the database immediately

without reissuing the Bind.

238
Locking Facilities

239
Locking facilities are provided for
controlling access to areas and to individual
records when two or more run units require
access to the same database areas.
IDMS provides three levels of locking
facilities.
 Area Locks
 Area Usage Modes
 Record Locks
240
AREA LOCKS
 Area locks are used to prevent areas
from being updated by more than one
IDMS central version or by more than
one application running in local mode.
 If an area is locked that is required by a
local mode application, that local mode
application ABENDS.

241
Continue …..

 If required area is NOT locked, area

lock is set by the local mode
application and no other local mode
application is given access to that area.
 An area locked by a local mode
application is released when that
application executes its FINISH
statement (end of run-unit).

242
Continue …..
 If required area is locked that is
required by an IDMS central version,
execution of that central version
continues, but no run-unit executing
under the control of that central version
will be given access to the already
locked area. The area is said to be
Varied Offline to that central version.
Run-units that attempt to access an area
that is varied offline are abnormally
terminated.
243
Continue …..
 If required areas are NOT locked, then
those areas are locked by the central
version. Run-units executing under the
control of that central version can
access those areas. No other central
version will be given access to locked
areas.
 An area that is locked by a central
version is released only when the
central version is shut down.

244
AREA USAGE MODES

Area usage modes control how

database areas under the control of a
central version can be accessed.
The six possible usage modes for a
database area are as follows:

245
Continue …..
 (Shared) Retrieval
 Protected Retrieval
 Exclusive Retrieval
 (Shared) Update
 Protected Update
 Exclusive Update

The ‘Shared’ word is optional.

246
Retrieval or Shared Retrieval

We are requesting only retrieval access

to the area. All other run units under
the same central version will be
allowed to RETRIEVE or UPDATE
records in the same area, provided they
do no specify usage mode Exclusive.

247
Protected Retrieval

We are requesting retrieval access to the area

and it also specifies that no other run unit
should update records in the same area for the
duration of our run unit. All other run units
under the same central version will be allowed
to retrieve records in the same area provided
they did not specify usage mode Exclusive.

If another run unit is already updating records

in the area, our run unit will wait till that run
unit finishes. 248
Exclusive Retrieval
We are requesting retrieval access to the area
and it also specifies that no other run unit
should retrieve or update records in the same
area till our run unit finishes execution. If
another run unit is already accessing the
area, our run unit will wait till that run unit
finishes.

This mode is not often used.

249
Update or Shared Update

We are requesting updating access to the

area. All other run units under the same
central version will be allowed to retrieve
or update records in the same area as long
as they do not specify Protected or
Exclusive usage mode options in Ready
statements.

250
Protected Update
We are requesting update access to the area and
specifying that other run units should not be able
to update records in the same area till our run unit
finishes. All other run units will be allowed to
retrieve records in the same area as long as they
do not specify Protected or Exclusive as usage
modes.

If another run unit is already accessing the area,

our run unit will wait till that run unit finishes. 251
Exclusive Update

We are requesting update access to the area

and further specifying that no other run unit
should either retrieve or update records in the
same area while our run unit is executing.
This option gives our run unit exclusive use
of the area.

252
 Run Unit 2

Protected Retrieval

Exclusive Retrieval
Protected Update

Exclusive Update
Shared Retrieval
Shared Update
Shared Update Y Y N N N N
Shared Retrieval Y Y Y Y N N
Run Unit 1

Protected Update N Y N N N N

Protected Retrieval N Y N Y N N

Exclusive Update N N N N N N

Exclusive Retrieval N N N N N N

253
IMPLICIT RECORD LOCKS

It is maintained only for run-units

operating under Central Version.
When we use usage mode options that
allow more than one run-unit to access
the same area while updating is taking
place, IDMS sets Implicit record locks
to prevent same record from being
updated simultaneously by two or more
run-units.

254
Continue …..
 Record locks are generally maintained
for shared and protected update mode
and shared retrieval mode.
 Implicit locks can be either Shared or
Exclusive.
 Implicit Shared lock guarantees that only
one run-unit is allowed to update a
record while others can retrieve the same
record.
 Implicit Exclusive lock ensures that no
other run-unit can either update or
retrieve the record.
255
Continue …..
 Implicit shared locks is placed on a
record when it is retrieved and
Implicit Exclusive lock is placed on a
record when it is accessed through a
DML update verb.
 Shared Lock remains in effect till
currency changes.
 Exclusive Lock remains in effect till
run-unit ends (Finish) or until
Commit is issued.
256
EXPLICIT RECORD LOCKS
Explicit locking is the most efficient way of
placing record locks. It can be set by coding the
KEEP statement or by the KEEP clause of the
FIND/OBTAIN statement.
Explicit lock remain is effect until Finish is
executed or Commit is issued.
e.g. Obtain Keep Calc Employee.
Obtain Keep Exclusive Calc Employee.
First is explicit shared lock and second is
explicit exclusive lock.
257
Continue …..

Another way of setting explicit locks is to code

separate Keep statement after a record is
retrieved.
e.g.
Keep exclusive current.
Keep current within Dept-Employee.
Keep exclusive current within employee-area.

258