IDMS Mat

IDMS/R
Version 2.0
16-May-2002
1
IDMS/R
Table of Contents
1. Overview.....................................................................................................................6
1.1. IDMS/R and DBMS...........................................................................................6
1.2. Database Approach...........................................................................................6
1.2.1. Data Integrity.............................................................................................6
1.2.2. Application Development Productivity....................................................7
1.3. Different Database Architectures.....................................................................7
1.3.1. Hierarchical................................................................................................7
1.3.2. Network......................................................................................................7
1.3.3. Relational....................................................................................................8
1.3.4. Difference Between RDBMS and Network, Relations, Chain Pointers9
1.4. IDMS/R: - Network and Relational Facilities, DBMS.................................10
2. Logical Database Structure....................................................................................12
2.1. Entity, Logical and Physical Structure..........................................................12
2.2. Attributes, Relationships – Training Database.............................................12
2.3. Entity-Relationship Diagrams........................................................................13
2.4. IDMS Database Records, Record Type, Record Occurrences....................14
2.5. One-To-Many and Many-To-Many Relationships.......................................15
2.6. IDMS Set, Set Type, Set Occurrence, Bubble Diagram...............................15
2.7. Schema, Subschema.........................................................................................19
3. IDMS/R Batch Program..........................................................................................20
3.1. Operating Environment..................................................................................20
3.2. DML Statements: Executable and Compiler Directive................................20
3.3. Three Steps Compilation: DML Pre-processor, Compilation and Linking20
3.4. Compiled Listing of Sample IDMS/R Program............................................22
3.5. Run-Unit...........................................................................................................28
3.6. Virtual Storage Layout....................................................................................29
3.7. DML Execution Steps......................................................................................30
4. Physical Database Structure...................................................................................32
4.1. Areas.................................................................................................................32
4.2. Pages..................................................................................................................32
4.3. DB-Key..............................................................................................................34
4.4. Multiple Areas..................................................................................................34
4.5. Files...................................................................................................................35
4.6. Record occurrence – Prefix, Data..................................................................35
5. Record.......................................................................................................................37
5.1. Record Name....................................................................................................37
5.2. Record Identifier..............................................................................................37
5.3. Storage Mode...................................................................................................37
5.4. Record Length..................................................................................................38
5.5. Location Mode.................................................................................................38
5.6. Duplicates Option............................................................................................40
5.7. Area Name........................................................................................................41
5.8. Bachman Diagram For Record Type.............................................................41
6. Set..............................................................................................................................43
2
IDMS/R
6.1. Set Name...........................................................................................................43
6.2. Linkage Options...............................................................................................43
6.3. Order Options..................................................................................................46
6.4. Bachman Diagram For Set.............................................................................50
7. Retrieval: Basic, By Sort-key, Indexed Set, Sweeping Areas..............................51
7.1. Basic Retrieval: CALC, Through Relationship............................................51
7.2. CALC Retrieval: Random access...................................................................51
7.3. Error Handling................................................................................................52
7.4. Access By Walking Sets i.e. Access Through Set Relationship....................53
7.5. Retrieval By Sort-Key Value..........................................................................58
7.6. Generic Key Retrieval.....................................................................................59
7.7. Indexed Set.......................................................................................................59
7.8. Retrieval Using Indexed Set............................................................................60
7.9. Bachman Diagram: Indexed Set.....................................................................61
7.10. Retrieval By Sweeping Areas......................................................................62
8. Currency...................................................................................................................64
8.1. Currency Table................................................................................................64
8.2. Currency Loss..................................................................................................66
8.3. Storing and Retrieval By DB-Key Value.......................................................68
8.4. Obtain Vs. Find and Get.................................................................................69
8.5. IF <set-name> EMPTY / MEMBER:............................................................71
9. Types of Set Relationships......................................................................................74
9.1. Hierarchies.......................................................................................................74
9.2. Junction Record: Multiple Set Membership.................................................76
9.3. Nested Structure – Bill Of Material...............................................................77
10. Set Membership Options.....................................................................................84
10.1. Disconnect option.........................................................................................84
10.2. Connect option.............................................................................................85
10.3. Bachman Diagram and Examples..............................................................86
11. DML Data Update Functions.............................................................................88
11.1. Ready............................................................................................................88
11.2. Store..............................................................................................................88
11.3. Modify...........................................................................................................91
11.4. Erase..............................................................................................................92
11.5. Connect.........................................................................................................94
11.6. Disconnect.....................................................................................................95
12. Recovery and Restart..........................................................................................97
12.1. IDMS/R Operating Environments.............................................................97
12.2. Journal Files, Checkpoints..........................................................................98
12.3. Recovery / Restart........................................................................................98
12.4. Commit.........................................................................................................99
12.5. Recovering From Failures........................................................................101
12.6. Rollback......................................................................................................101
13. Locking...............................................................................................................103
13.1. Area Locks..................................................................................................103
13.2. Area Usage Modes.....................................................................................103
3
IDMS/R
13.3. Record Locks – Implicit, Explicit.............................................................105
14. Utilities................................................................................................................110
14.1. DMLO.........................................................................................................110
14.2. OLQ............................................................................................................111
15. Appendix A: Employee Database.....................................................................113
16. Appendix B: Compilation and Run JCL.........................................................115
17. Appendix C: IDMS/R ERROR-STATUS VALUES......................................118
18. Appendix D: References......................................................................................121
4
IDMS/R
Day-Wise Schedule
Day 1
Overview
Logical Database Structure
IDMS/R Batch Program
Day 2
Physical Database Structure
Record
Set
Day 3
Retrieval: Basic, By Sort-key, Indexed Set, Sweeping Areas
Day 4
Currency
Day 5
Types of Set Relationships
Day 6
Set Membership Options
DML Data Update Functions
Day 7
Recovery and Restart
Locking
Day 8
Utilities – DMLO, OLQ
5
IDMS/R
1. Overview
1.1. IDMS/R and DBMS

IDMS/R (Integrated Database Management System/Relational) is a software product
on IBM mainframe that offers capabilities for working with well-organized data.
IDMS/R is one of a number of software systems that can be classified as a DBMS
(Database Management System).
A DBMS is a software subsystem that manages a collection of interrelated data

elements, stored in a database, that can be accessed in a shared manner by a collection
of application programs.
Components of IDMS/R work around a central software subsystem called IDD

(Integrated Data Dictionary). In IDMS/R environment, all data elements used in
application system are defined in the data dictionary.
1.2. Database Approach

There are many advantages to maintaining all an organization data in a central pool or
reservoir, so that it can be shared by a number of application programs. We can place
the advantages of the database approach into two categories: Data integrity and
Application development productivity.
1.2.1. Data Integrity
Reducing / eliminating data redundancy: - There is no duplication of

information. Each piece of information is stored only once in the central pool and
application programs access it via the database management system. E.g.
information about employees is stored centrally in Employee table or structure.
Multiple copies of same data do not exist in different stages of updating.
Recovery and Restart: - A database management system provides powerful tools

for automatically recovering from system failures, restoring the database to its
original form, and restarting jobs that were affected by failures.
6
IDMS/R
1.2.2. Application Development Productivity
Simplified Programming: - In a program that uses conventional files, much of

the program logic must deal with the way in which files are read and written, and
the order in which data is processed. With a DBMS, application programs make
simple requests for data, and the DBMS performs all the necessary steps to locate
the required data. This results in application programs that are less complex than
those that work with conventional files.
Reduced Maintenance: - The application programs using conventional files are

tied tightly to the formats of files they process. If a record format changes, all
programs that access the record must also be modified. With a DBMS, since
programs do not access data directly, changes can be made to the structure of the
database without requiring that applications programs be modified. Data and
programs are independent.
These two things increase programmer productivity.
1.3. Different Database Architectures
1.3.1. Hierarchical
In a hierarchically structured database, data records are typically connected with
embedded pointers to form a tree structure / configuration, in which a dependent
record type has one and only one parent. IMS is an example of hierarchical
DBMS.
Supplier
Order
Line Item
Fig. 1.1.
1.3.2. Network
A network-structured database typically uses embedded pointers to create a mesh
structure / configuration, in which a dependent record type can have more than
one parent. IDMS/R is an example of network DBMS.
7
IDMS/R
The term network in this context has nothing to do with a communications
network! It refers rather to the kinds of data structures and operators (e.g. for
retrieval) supported by the system.
Supplier Part
Order
Line Item
Quotation
Fig. 1.2.
Dependent records Line-Item and Quotation have more than one parent.
1.3.3. Relational
In a relational DBMS, data is represented in the form of tables in which all
associations are expressed using values in the stored data and no embedded
pointers are required to represent relationships between records.
Supplier
Order Part
Quotation Line-Item
Fig. 1.3.
8
IDMS/R
1.3.4. Difference Between RDBMS and Network, Relations, Chain
Pointers
The reason “relational systems” are called “relational” is that the term relation is
basically just a mathematical term for a table.
In the relational model, the data and the relationships among data are represented
by a collection of tables. The network model differs from the relational model in
that data are represented by collection of records, and relationships among data
are represented by links.
Relational model supports one-to-many and many-to-many links. But, Network

model supports only one-to-many links and it does not support many-to-many
links.
Links are implemented in the Network model by adding pointer fields to records
that are associated via a link.
To illustrate the implementation of the Network model, suppose the Dept-

Employee relationship is one-to-many from Dept to Employee. An Employee
record occurrence can be associated with only one Dept record occurrence. Thus,
we need only one pointer in the Employee record occurrence to represent the
Dept-Employee relationship. However, a Dept record occurrence can be
associated with many Employee record occurrences. Rather than using multiple
pointers in Dept record, we can use a ring structure or chain pointers to represent
all employees in the given department. Chain pointers form a circular list.
Consider another example given below about chain pointers.
In the Training department, many courses are conducted for different subjects.
There are two record types, namely Subject and Course, which are linked.
SUBJECT
Address Sub-Id Sub-Name First Last
#0 S001 MVS *0 *6
#1 S002 JCL *1 *7
#2 S003 VSAM *2 *2
#3 S004 IDMS *3 *3
9
IDMS/R
COURSE
Address Course-Id Course-Name Next Prior Owner
*0 C0701 FIT-MVS *4 - #0
*1 C0702 FIT-JCL *5 - #1
*2 C0703 FIT-VSAM - - #2
*3 C0804 FIT-IDMS - - #3
*4 C0901 EXP-MVS *6 *0 #0
*5 C0902 EXP-JCL *7 *1 #1
*6 C1001 FIT-MVS - *4 #0
*7 C1002 FIT-JCL - *5 #1
Consider subject MVS with Sub-Id S001: - “First” pointer points to first MVS
course C0701. “Next” pointer of course C0701 points to next MVS course i.e.
C0901 and so on.
It is clear from the preceding discussion that the Network model is closely tied to
the implementation. Querying is simple in the relational model, while it is
significantly more complicated in the network model. The programmer is forced
to think in term of links, and how to traverse them to get at needed information.
Data manipulation in the network model is hence said to be navigational.
1.4. IDMS/R: - Network and Relational Facilities, DBMS

IDMS/R was originally designed to be an implementation of the network database
model, but the addition of relational capabilities through a software subsystem called
the Automatic System Facility (ASF) has given it a dual nature.
Network structured databases can be used to handle high volume transaction

processing applications which have demanding performance requirements. Relational
databases can be used to accommodate user-generated applications. Combining both
network and relational capabilities in one system provides the installation with a
versatile tool for meeting both production requirements and the ease-of-use
requirements of end users.
The relational and network capabilities of IDMS/R are supported by a single database
management system product. This means that data stored in the form of network
structures can be accessed by conventional application programs, but can also be
accessed by the relational facilities for those applications that require a relational
view of the network structured data. In turn, data entered through the relational
facility can be used to update the production, network-structured database. In either
10
IDMS/R
case, all database access, input/output operations, and space management are
performed by the same system components.
The heart of any database product is the software component that manages access to
the database. This component is most commonly called the DBMS. IDMS/R consist
of a set of software modules that manage the data elements that are stored in the
database and maintains the relationships that exist between them. A major purpose of
a DBMS is to isolate application programs from the details concerning how data
elements are physically stored. To this end, the data stored in an IDMS/R database is
accessed only by the DBMS and never directly by an application program.
IDMS/R support for a networked structured database is provided via two common
languages that designers and programmers use to control access to the database: data
description language (DDL) and data manipulation language (DML). The DDL is
used by database designers to describe the logical and physical structure of the
database to DBMS software and to application programs. Application programs use
DML to specify how the database is accessed. Application programs make requests
for access to the database by executing DML statements; the DBMS intercepts these
requests and performs the required accesses to the database to satisfy these requests.
IDMS/R uses a software subsystem called Automatic System Facility (ASF) to

provide users with a relational view of the database. ASF is menu oriented and
relatively easy to use.
11
IDMS/R
2. Logical Database Structure
2.1. Entity, Logical and Physical Structure

When we are using a powerful DBMS, such as IDMS/R, to manage a central pool of
data, we can view the database on a number of different levels. At the highest level is
the application environment, where we discuss the nature of the entities that we are
representing in the database. Entities consist of those objects, people, or ideas about
which we are storing data.
On a lower level we are concerned with software, where we describe the logical
structure of the database that we are using to represent information about entities in
the database.
On a still lower level is the hardware, where we describe the physical structure of the
database and the way in which logical records are implemented in computer storage.
2.2. Attributes, Relationships – Training Database

We will be using a hypothetical Training Department database that might be used to
maintain information about courses conducted and faculties.
Please consider the following scenario for the Training Department.
 The Training Dept conducts courses for various subjects. At any given point
of time, multiple courses can be in progress.
 There are 10 faculties in the department. A faculty can teach multiple subjects.
A subject can be taught by multiple faculties.
 There are many participants for a course.
 Performance of a participant in a course is measured in terms of attendance,
assignments and test marks.
The database will store information about the following entities.
Faculty: - Information about faculties in Training department

Subject: - Information about subjects taught
Course: - Information about courses of diff subjects
Participant: - Information about participants in a course
Performance: - Information about performance of a participant
12
IDMS/R
In discussing entities, we can discuss the attributes that an entity has and the
relationships that exist between the entities.
Entity Attributes:
An attribute is a particular piece of information that is associated with an entity. E.g.,

possible attributes of the Subject entity are Subject-Id, Subject-Name, Subject-
Stream, etc.
Entity Relationships:
We can identify a number of relationships between the entities about which we are
storing information. E.g. the Faculty and Course entities participate in one-to-many
relationship. Each course is conducted by one faculty, but each faculty conducts
many courses. The Course and Participant entities form another one-to-many
relationship. Each participant attends one course, and each course has many
participants. The Participant and Performance entities also form one-to-many
relationship. The Faculty and Subject entities form a many-with-many relationship.
One faculty can teach many subjects, and a subject can be taught by many faculties.
2.3. Entity-Relationship Diagrams

We can represent the relationships between the entities (discussed above) using an
entity-relationship diagram.
An entity-relationship diagram for Training Department information is given below.
Faculty Subject
Course
Participant
Performance
Fig. 2.1.
Each entity is represented by a square-cornered box. We use arrow symbols for
connecting the boxes to represent relationships. The “arrow head” points to the many
13
IDMS/R
side of a relationship and the other end of the arrow indicates the “one” side of a
relationship.
2.4. IDMS Database Records, Record Type, Record Occurrences

Database Records: - In representing the Training Department database using a
network-structured IDMS/R database, we begin by defining a separate database
record for each entity. Consider the Subject entity and its attributes. We represent the
Subject attributes using a Subject record and we represent each Subject attribute as a
data element within the Subject record as shown below. Data elements are sometimes
called data items or fields. We name each data element, define its length and define
the type of data that it will contain.
Subject Record
Subject-Id Subject-Name Subject-Stream
PIC X(04) PIC X(10) PIC X(06)
(Subject record type)
Record Types Vs. Record Occurrences: - There is a clear distinction between a

record type and a record occurrence. We can think of a record type as a template. It
describes the format of all occurrences of a given record type that will be stored in the
database. Each occurrence of the Subject record type consists of a single set of values
for the Subject-Id, Subject-Name and Subject-Stream data elements as shown below.
Subject Record Type

Subject-Id Subject-Name Subject-Stream
PIC X(04) PIC X(10) PIC X(06)
Subject Record Occurrences

S002 JCL IBM
S003 VSAM IBM
S004 IDMS IBM
2.5. One-To-Many and Many-To-Many Relationships

IDMS/R supports one-to-many relationship. IDMS/R does not support directly many-
to-many relationships. For each many-to-many relationship between two entities, we
will almost always identify additional attributes that are not associated with either of
14
IDMS/R
the two entities alone, but are associated with the intersection between the two entity
types. This intersection is represented by another record type, called junction record
type, which has one-to-many relationships with the two entity types. The junction
record resolves the many-to-many relationship and implements this many-to-many
relationship indirectly.
The junction record type is described in more details in Section 9.2.
2.6. IDMS Set, Set Type, Set Occurrence, Bubble Diagram

A one-to-many relationship in an IDMS/R network database is implemented by
defining a set. A set consists of two or more record types that participate in one-to-
many relationships with one another. The record type on the “one” side of the
relationship is designated the owner of the set; the record type on the “many” side is
designated the member record type. Each set must be assigned a unique name.
The names of all the sets for Training Dept database are shown in the diagram below.
Faculty Subject
Faculty-Course Subject-Course
Course
Course-Participant
Participant
Participant-Performance
Performance
Fig. 2.2.
A set that consist of only two record types is generally given a name that is a
concatenation of the names of Owner and Member record types separated by hyphen.
E.g. Faculty-Course, Course-Participant.
Also, please refer to Employee Database in Appendix A.
Set Type Vs. Set Occurrence:
As with record types and record occurrences, there is an important distinction

between a set type and a set occurrence. Like a record type, a set type can be thought
of as a template that describes the general nature of the set. A set occurrence, on the
15
IDMS/R
other hand, consists of a specific single occurrence of the owner record type and all
occurrences of the member record type that are associated with it.
A specific occurrence of the set Faculty-Course is shown in a diagram given below. It

is called a bubble diagram.
Faculty
Sudhir
Course
C0702 Course
C0804
Course
C0703
Fig. 2.3.
There exists one occurrence of the Faculty-Course set for each occurrence of the set’s
owner record type.
A set consists of an owner record type and one or more member record types. A set
occurrence consists of one occurrence of the owner record type and any number of
member record occurrences. Records in each occurrence of the set are physically
linked together by pointers. Above figure shows an example of a set occurrence.
Notice that the set occurrence begins with an owner record occurrence. The owner
record occurrence points to the first occurrence of the member record type, that
occurrence points to the next member record occurrence, and so on until the last
member record occurrence is encountered. The last member record occurrence then
points back to its owner. Accessing members by following the pointers from one
record occurrence to the next is called walking the set. A set occurrence can also
consists only of an owner record occurrence and no member record occurrences, in
which case the set occurrence is said to be empty. In the following figure, the Faculty
record for Raju is the owner record of an empty set.
Faculty
Raju
16
IDMS/R
Fig. 2.4.
Following is another example of bubble diagram.
MVS JCL
CO701 C1001 CO702 C1002
CO901 CO902
JCL
MVS
CO702 C1002
C1001
CO701 CO902
Shilpa CO901
Kishore
Fig. 2.5.
17
IDMS/R
Fig. 2.6.
18
IDMS/R
2.7. Schema, Subschema

Schema: - The definition of all record types and all set types that make up an
IDMS/R network database is called a schema. We can represent a schema visually by
using a Bachman diagram. Refer to Section 5.8 for more details of Bachman diagram.
Subschema: - In real-world systems, most application programs do not require access

to all record types and all set types that are defined in a schema. One or more
subschemas are defined such that each subschema specify the particular record types,
data elements and set types, that each group of application programs needs access to.
E.g. In a big manufacturing company, there would be a different subschema for

Inventory Dept, Payroll Dept, Sales Dept, etc. Users in a particular department work
only on record types, data elements, set types that are required for their application or
function. Users in Payroll Dept do not work on data of Inventory dept functions.
Users in any particular department do not need access to the entire schema, but they
work on some portion of the schema.
Subschemas provide a means of simplifying the view of the database for each
application program. Subschemas also provide the ability to restrict access to only
those record types, data elements and set types that a particular application program is
authorized to access.
An application program always accesses the database by referring to a subschema. So

even if a program requires access to all the record types, data elements and set types
defined in the schema, there should be a subschema defined such that includes all the
elements defined in the schema.
19
IDMS/R
3. IDMS/R Batch Program
3.1. Operating Environment

A conventional application program generally begins by issuing one or more OPEN
statements. OPEN statements prepare files for processing and establish linkages
between the application program and the operating system data management routines.
The program then makes requests for file accesses by issuing READ, WRITE
statements. These statements result in calls to the operating system data management
routines that handle the requests.
In an IDMS/R application program, there are no file description statements or OPEN

or CLOSE statements for the database. The reason for this is that the application
program does not interface directly with the operating system data management
routines that handle data transfer operations. Instead, the application program issues
DML statements that direct IDMS/R to access the database.
3.2. DML Statements: Executable and Compiler Directive

An IDMS/R program uses DML statements for database access. The IDMS/R DML
provides a number of statements that enable the programmer to access an IDMS/R
database and to perform a number of support functions.
Some DML statements are carried out during the program’s execution.
Some DML statements are compiler-directive statements. Compiler-directive

statements control compilation of a program. E.g. a compiler-directive statement is
used to identify the subschema that the program should use.
3.3. Three Steps Compilation: DML Pre-processor, Compilation

and Linking
Following diagram illustrates the steps required to prepare an application program for
execution.
An IDMS/R application program has DML statements embedded in the source code
to request database access and other support functions. Before the source program is
compiled, the program is first read by a DML processor. The DML processor
validates the DML statements and creates a translated version of the source program
20
IDMS/R
in which DML statements have been replaced by appropriate calls to IDMS/R. Output
from the DML processor is a new source program, which serves as the input to the
compiler. In addition, the DML processor can optionally generate a source statement
listing containing error diagnostics. The source program that the DML processor
generates differs from the input IDMS/R source file in the following way:
 Database record descriptions have been copied into the program from the data
dictionary.
 IDMS/R DML statements have been changed to comments.
 DML requests that involve the transfer of control to IDMS/R have generated
appropriate CALL statements.
After the translated source program has been compiled, the resulting object module is
processed by the linkage editor to create an executable load module. The linkage
editor also includes a copy of a routine called the IDMS Interface Module in the
finished load module. Requests that the program makes for IDMS/R services result in
calls to the IDMS Interface module.
Source
DML Data
Statements Dictionary
Processor
Error
COBOL
Listing
Source
DML Processor Errors
COBOL
Compiler
Error
Object
Listing
Module
Compilation Errors
Linkage
Editor
Error
Load
Listing
Module
Linking Errors
Fig. 3.1.
The DML processor must have access to the data dictionary as it processes the source
program. The programmer can use COPY or INCLUDE statements to merge in
21
IDMS/R
predefined program modules, record descriptions. The DML processor automatically
includes record description entries defined by the subschema the program is using. In
addition, the DML processor automatically updates the data dictionary. E.g. the DML
processor stores into the data dictionary information about the types of DML
statements that the program executes against database records.
3.4. Compiled Listing of Sample IDMS/R Program

IDENTIFICATION DIVISION.
PROGRAM-ID. IDMSTEST.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. IBM-3090.
OBJECT-COMPUTER. IBM-3090.
*IDMS-CONTROL SECTION.
*PROTOCOL. MODE IS BATCH.
* IDMS-RECORDS MANUAL.
DATA DIVISION.
*SCHEMA SECTION.
* DB EMPSS01 WITHIN EMPSCHM VERSION 100.
WORKING-STORAGE SECTION.
01 WS-DEPT-ID PIC 9(04) VALUE 0.
* COPY IDMS SUBSCHEMA-CONTROL.
01 SUBSCHEMA-CTRL.
03 PROGRAM-NAME PIC X(8)
VALUE SPACES.
03 ERROR-STATUS PIC X(4)
VALUE '1400'.
88 DB-STATUS-OK
VALUE '0000'.
88 ANY-STATUS
VALUE ' ' THRU '9999'.
88 ANY-ERROR-STATUS
VALUE '0001' THRU '9999'.
88 DB-END-OF-SET
VALUE '0307'.
88 DB-REC-NOT-FOUND
VALUE '0326'.
03 DBKEY PIC S9(8) COMP SYNC.
03 RECORD-NAME PIC X(16)
VALUE SPACES.
03 RRECORD-NAME REDEFINES RECORD-NAME.
05 SSC-NODN PIC X(8).
05 SSC-DBN PIC X(8).
03 AREA-NAME PIC X(16)
VALUE SPACES.
03 AREA-RNAME REDEFINES AREA-NAME.
05 SSC-DNO PIC X(8).
05 SSC-DNA PIC X(8).
03 ERROR-SET PIC X(16)
VALUE SPACES.
03 ERROR-RECORD PIC X(16)
VALUE SPACES.
03 ERROR-AREA PIC X(16)
22
IDMS/R
VALUE SPACES.
03 IDBMSCOM-AREA PIC X(100)
VALUE LOW-VALUE.
03 IDBMSCOM REDEFINES IDBMSCOM-AREA
PIC X
OCCURS 100.
03 RIDBMSCOM REDEFINES IDBMSCOM-AREA.
05 DB-SUB-ADDR PIC X(4).
05 FILLER PIC X(96).
03 DIRECT-DBKEY PIC S9(8) COMP SYNC.
03 DIRECT-DBK REDEFINES DIRECT-DBKEY
PIC S9(8) COMP SYNC.
03 DATABASE-STATUS.
05 DBSTATMENT-CODE PIC X(2).
05 DBSTATUS-CODE PIC X(5).
03 FILLER PIC X.
03 RECORD-OCCUR PIC S9(8) COMP SYNC.
03 DML-SEQUENCE PIC S9(8) COMP SYNC.
01 SUBSCHEMA-SSNAME PIC X(8)
VALUE 'EMPSS01 '.
01 SUBSCHEMA-RECNAMES.
03 SR460 PIC X(16)
VALUE 'STRUCTURE '.
03 SR455 PIC X(16)
VALUE 'SKILL '.
03 SR450 PIC X(16)
VALUE 'OFFICE '.
03 SR445 PIC X(16)
VALUE 'NON-HOSP-CLAIM '.
03 SR440 PIC X(16)
VALUE 'JOB '.
03 SR435 PIC X(16)
VALUE 'INSURANCE-PLAN '.
03 SR430 PIC X(16)
VALUE 'HOSPITAL-CLAIM '.
03 SR425 PIC X(16)
VALUE 'EXPERTISE '.
03 SR420 PIC X(16)
VALUE 'EMPOSITION '.
03 SR415 PIC X(16)
VALUE 'EMPLOYEE '.
03 SR410 PIC X(16)
VALUE 'DEPARTMENT '.
03 SR405 PIC X(16)
VALUE 'DENTAL-CLAIM '.
03 SR400 PIC X(16)
VALUE 'COVERAGE '.
01 SUBSCHEMA-SETNAMES.
03 COVERAGE-CLAIMS PIC X(16)
VALUE 'COVERAGE-CLAIMS '.
03 DEPT-EMPLOYEE PIC X(16)
VALUE 'DEPT-EMPLOYEE '.
03 EMP-COVERAGE PIC X(16)
VALUE 'EMP-COVERAGE '.
03 EMP-EXPERTISE PIC X(16)
VALUE 'EMP-EXPERTISE '.
23
IDMS/R
03 EMP-NAME-NDX PIC X(16)
VALUE 'EMP-NAME-NDX '.
03 EMP-EMPOSITION PIC X(16)
VALUE 'EMP-EMPOSITION '.
03 JOB-EMPOSITION PIC X(16)
VALUE 'JOB-EMPOSITION '.
03 JOB-TITLE-NDX PIC X(16)
VALUE 'JOB-TITLE-NDX '.
03 MANAGES PIC X(16)
VALUE 'MANAGES '.
03 OFFICE-EMPLOYEE PIC X(16)
VALUE 'OFFICE-EMPLOYEE '.
03 REPORTS-TO PIC X(16)
VALUE 'REPORTS-TO '.
03 SKILL-EXPERTISE PIC X(16)
VALUE 'SKILL-EXPERTISE '.
03 SKILL-NAME-NDX PIC X(16)
VALUE 'SKILL-NAME-NDX '.
03 CALC PIC X(16)
VALUE 'CALC '.
01 SUBSCHEMA-AREANAMES.
03 EMP-DEMO-REGION PIC X(16)
VALUE 'EMP-DEMO-REGION '.
03 INS-DEMO-REGION PIC X(16)
VALUE 'INS-DEMO-REGION '.
03 ORG-DEMO-REGION PIC X(16)
VALUE 'ORG-DEMO-REGION '.
* COPY IDMS RECORD DEPARTMENT.
01 DEPARTMENT.
02 DEPT-ID-0410 PIC 9(4).
02 DEPT-NAME-0410 PIC X(45).
02 DEPT-HEAD-ID-0410 PIC 9(4).
02 FILLER PIC XXX.
PROCEDURE DIVISION.
0000-MAIN.
PERFORM 1000-INIT THRU 1000-EXIT.
PERFORM 2000-PROCESS THRU 2000-EXIT.
PERFORM 8000-WRAP-OFF THRU 8000-EXIT.
STOP RUN.
0000-EXIT.
EXIT.
1000-INIT.
* BIND RUN-UNIT.
CALL 'IDMS' USING SUBSCHEMA-CTRL
IDBMSCOM (59)
SUBSCHEMA-CTRL
SUBSCHEMA-SSNAME.
PERFORM IDMS-STATUS.
* BIND DEPARTMENT.
IDBMSCOM (48)
SR410
DEPARTMENT.
24
IDMS/R
* READY ORG-DEMO-REGION.
IDBMSCOM (37)
ORG-DEMO-REGION.
ACCEPT WS-DEPT-ID.
1000-EXIT.
EXIT.
2000-PROCESS.
MOVE WS-DEPT-ID TO DEPT-ID-0410.
* OBTAIN CALC DEPARTMENT.
IDBMSCOM (32)
SR410
IDBMSCOM (43).
IF DB-STATUS-OK
DISPLAY 'DEPARTMENT : ' DEPT-NAME-0410
ELSE
IF DB-REC-NOT-FOUND
DISPLAY 'INVALID DEPARTMENT CODE'
ELSE
2000-EXIT.
EXIT.
8000-WRAP-OFF.
* FINISH.
IDBMSCOM (2).
8000-EXIT.
EXIT.
IDMS-ABORT SECTION.
DISPLAY 'PROGRAM ABORTED'.
* COPY IDMS IDMS-STATUS.
*********************************************************
IDMS-STATUS SECTION.
*********************************************************
IDMS-STATUS-PARAGRAPH.
IF DB-STATUS-OK GO TO ISABEX.
PERFORM IDMS-ABORT.
DISPLAY '**************************'
' ABORTING - ' PROGRAM-NAME
', ' ERROR-STATUS
', ' ERROR-RECORD
' **** RECOVER IDMS ****'
UPON CONSOLE.
DISPLAY 'PROGRAM NAME ------ ' PROGRAM-NAME.
DISPLAY 'ERROR STATUS ------ ' ERROR-STATUS.
DISPLAY 'ERROR RECORD ------ ' ERROR-RECORD.
DISPLAY 'ERROR SET --------- ' ERROR-SET.
DISPLAY 'ERROR AREA -------- ' ERROR-AREA.
DISPLAY 'LAST GOOD RECORD -- ' RECORD-NAME.
DISPLAY 'LAST GOOD AREA ---- ' AREA-NAME.
DISPLAY 'DML SEQUENCE ------ ' DML-SEQUENCE.
* ROLLBACK.
IDBMSCOM (67).
25
IDMS/R
CALL 'ABORT'.
ISABEX. EXIT.
Eg. 3.1.
Explanation of sample IDMS/R program:
Identification Division
The Identification Division of the IDMS/R program is similar to that of a

conventional COBOL program.
IDENTIFICATION DIVISION.
PROGRAM-ID. IDMSTEST.
The name of Program-id is generally the same name as the name of the load module
that is referenced in the EXEC statement of the run JCL.
Environment Division
This division contains the INPUT-OUPUT section, which contains references to the
files used by the program.
In addition to the normal INPUT-OUPUT section, the Environment division contains

a new section called the IDMS-CONTROL section:
IDMS-CONTROL SECTION.
PROTOCOL. MODE IS BATCH
IDMS-RECORDS MANUAL.
The PROTOCOL statement is a compiler-directive statement that specifies the

manner in which the DML processor will generate CALL statements. In this example,
BATCH indicates that the program will run in the batch rather than the online mode.
The IDMS-RECORDS MANUAL clause specify records whose data descriptions
(or record layout) will be copied from the data dictionary into the working-storage
section by using the statement ‘COPY IDMS RECORD <rec-name> in the Data
Division.
Note: - If we mention ‘MODE IS BATCH DEBUG’, then DEBUG indicates that the
DML processor will supply additional code in the resulting source program that will
be helpful in program debugging using the debugger.
Data Division
26
IDMS/R
This division begins with a new section called ‘Schema Section’ in addition to File
section and Working-Storage section. Schema Section specifies the names of the
subschema and the schema used in the program.
DATA DIVISION.
SCHEMA SECTION.
DB EMPSS01 WITHIN EMPSCHM VERSION 100.
The remaining DATA division sections are similar to those of a conventional

COBOL program.
The data descriptions that define the IDMS Communications Block (i.e. Subschema-
Control) and the Department record have been inserted by the DML processor.
Procedure Division
As in a conventional application program, the Procedure division defines the

processing that the program performs. The main difference between the
PROCEDURE division of an IDMS/R application program and that of a conventional
COBOL program is the inclusion of DML statements that request IDMS/R services.
BIND statements are required for database access.
The ‘BIND RUN-UNIT’ statement establishes addressability for the IDMS

Communications Block and causes IDMS/R to load the subschema identified in the
SCHEMA section.
The ‘BIND DEPARTMENT’ statement establishes addressability for the

WORKING-STORAGE area that will be used to contain Department record
occurrences.
The READY statement performs an equivalent function as an OPEN statement for a

conventional file.
The ‘READY ORG-DEMO-REGION’ statement indicates that the program will

retrieve data only and will not be allowed to execute database modification DML
statements for the specified area.
Status Checking:
The statement immediately following the READY statement performs a paragraph

named IDMS-STATUS.
READY ORG-DEMO-REGION.
27
IDMS/R
The IDMS-STATUS routine is brought into the program as a result of a COPY IDMS
statement that is coded toward the end of the source listing:
COPY IDMS IDMS-STATUS.
The program performs the IDMS-STATUS paragraph after each DML statement is
executed to determine if the requested operation executed successfully. IDMS/R
returns, in the ERROR-STATUS field of the IDMS Communications Block, a status
code that describes the results of the requested operation.
If IDMS/R completes a requested DML operation successfully, it returns an

error-status code zero. If IDMS/R detects an error condition, it returns a
nonzero error-status code. The data elements that define the layout of the
Communications Block specify a number of status code values. These represent the
status code values most often returned by IDMS/R. A status code value of "0000"is
labeled DB-STATUS-OK, and indicates a successful DML operation. An end-of-set
condition is indicated by “0307”. When a retrieval fails because a record is not found,
a value of “0326” is returned.
The IDMS-STATUS paragraph performs error-status code checking and abnormally

terminates the program if a nonzero error-status code is found. For the READY
statement, anything other than a zero status code is unacceptable.
Database access: - The program accepts the value of Dept-Id and moves that value to
Dept-Id field of Department record layout in working storage. The program then
issues a DML statement to read the appropriate Department database record:
OBTAIN CALC DEPARTMENT.
If IDMS/R cannot locate a Department record having the requested dept-id, the
program displays an error message. If the Department record is found, the program
displays department-name.
Finish statement: - The program ends the run unit by executing a FINISH statement.
The FINISH statement releases the database areas from the program's control.
Finally, the program ends by executing a STOP RUN statement.
3.5. Run-Unit
A run unit is the portion of the program’s processing during which it has access to
one or more database areas and can request IDMS/R services. The program may
perform some processing before it begins an IDMS/R run unit and it may perform
processing after the run unit is completed. Also the program may begin and end more
than one run unit in the same program execution.
28
IDMS/R
A run unit is a unit of work within IDMS/R. Each run unit represents a concurrently
executing task that is interacting with an IDMS/R database.
A run unit begins with the BIND RUN-UNIT statement and ends with the FINISH
statement. The BIND RUN-UNIT and FINISH statements are analogous to the
processing time between OPEN and CLOSE file statements. A program can consist
of any number of run units that are executed serially, but typically contains only one.
Note: - If your program consists of more than one run unit, you must reinitialize the
ERROR STATUS field in the IDMS Communication Block to the value 1400, before
reissuing the BIND RUN-UNIT and READY statements.
3.6. Virtual Storage Layout

Following diagram shows the layout of virtual storage when an IDMS/R program
executes.
IDMS/R is generally contained in its own area of virtual storage, i.e. an address space
in an MVS system. The IDMS/R area of virtual storage contains the IDMS/R
database management system and the system buffers. The system buffers are the
storage locations that IDMS/R uses in transferring database pages to and from direct
access storage. The IDMS/R area also contains the subschema tables for the IDMS/R
application programs currently in execution. Subschema tables are loaded when an
application program requests database access.
The area of virtual storage occupied by the IDMS/R application program contains
variable storage, the IDMS/R interface module and an executable code. Variable
storage contains the data areas to be modified by the program during execution. In
addition to other storage areas used by the program, variable storage contains a
control block called the IDMS communication block. IDMS/R stores into the IDMS
communication block information about the results of each request for an IDMS/R
service. Operating System
Variable IDMS Communication

Storage Block
IDMS/R
Executable Code Interface
Module
Subschema IDMS/R IDMS/R

Application Program
Tables Systems DBMS
Buffers
29
Operating System
IDMS/R
Address Space
IDMS/R
Address Space
Fig. 3.2. (Virtual Storage Layout)
3.7. DML Execution Steps

Following are the steps that are involved in the execution of a typical DML statement,
in this case for a retrieval.
i. Call the IDMS/R Interface Module: - The CALL statement generated by

DML processor passes control to IDMS/R Interface Module and provides it
with information that will be needed to perform the requested database access.
This information includes the type of database service desired and record, set,
and area names.
ii. Transfer control to IDMS/R: - The IDMS/R interface module transfers control
to IDMS/R DBMS, which performs the requested service. Since access to the
database is controlled by the subschema tables, the DBMS reads the tables to
determine record, set, and area definitions, currencies, and access restrictions.
iii. Retrieve database record and build subschema record: - The required
database record is retrieved, if required, and an image of the requested
subschema record is built in variable storage. It is not always necessary for the
DBMS to read the database to satisfy a retrieval request. E.g. the required
record may already be in a system buffer due to a previous retrieval. If the
desired record is not already in a buffer, the DBMS uses operating system data
management facilities to read the required database page from direct access
storage.
iv. Update currencies: - The DBMS updates run-unit, record type, set type and
area currencies, as required. This is done by moving the database key and other
control data from the system buffers to the subschema tables.
30
IDMS/R
v. Store status information: - The DBMS moves status information to

appropriate locations within the IDMS Communication Block. This information
describes the results of the requested DML function.
vi. Return to the program: - After updating the Communication block, control is
passed first from the DBMS to the IDMS/R Interface Module and then to the
application program at the statement following the DML statement just
executed.
vii. Test status information: - The application program should contain code to
check the results of each requested service. The ERROR-STATUS field of
IDMS Communication Block contains the status of DML statement just
executed.
31
IDMS/R
4. Physical Database Structure

Here, we discuss how an IDMS/R network-structured database is physically implemented.
4.1. Areas
An IDMS/R database is divided into one or more areas. An area is defined as the
major named subdivision of addressable storage in the database. Areas contain
occurrences of the records that make up networked-structured databases. Each area
can contain occurrences of one or more record types, but all occurrences of a
particular record type must be located in the same area.
4.2. Pages
An area can be further subdivided into pages, which constitute the smallest logical
units of database storage. A page is the unit of data that is moved between the
database and the system buffers that are used by IDMS/R to hold the retrieved
records. The diagram given below shows the structure of a page from a database area.
Header
Record Occurrences
Record Occurrences
Free Space
Line Index 3 Line Index 4 Line Index 5 Line Index 6

Line Index 2 Line Index 1 Footer
Fig. 4.1.
A database page contains record occurrences and control information.
Header of a page: 16 Bytes

32
IDMS/R
Page Number Next pointer Prior Pointer SA Unused

4 Bytes 4 Bytes 4 Bytes 2 Bytes 2 Bytes
Footer of a page: 16 Bytes

Line Index 0 Line Space Count Page Update Count Page Number
8 Bytes 2 Bytes 2 Bytes 4 Bytes
Line Index format: 8 Bytes

Record-Id Displacement Record Length Prefix Length
2 Bytes 2 Bytes 2 Bytes 2 Bytes
Each page can be considered as a mini-database since each normally stores several
records and contains its own control information. The IDMS/R database page is
broken into four distinct sections.
i. The header of a page is 16 bytes long, consisting of the page number (4 bytes),
the next pointer (4 bytes), the prior pointer (4 bytes), the space available count
(2 bytes) and a 2-byte unused space.
SA (Space Available Count) is the number of bytes of free space on the page.
Initial value of this field is (PAGESIZE – 32) bytes.
ii. The page body that contains all of the object data records being stored on the
page. The data stored in the page body is always concentrated at the front of the
page body. This feature, that continuously optimizes the available space on the
page, reduces unusable space to a minimum.
iii. The line index group contains one or more line index pointers, one for each
record stored on the page. The indexes move from the end of the page backward
into the page body as more records are placed on the page.
The line index itself is 8 bytes in length, broken into four 2-bytes fields: the
record identifier, the displacement of the beginning of the record from the start
of the page, the record length and the length of the record prefix (the pointers).
iv. The page footer consists of 16 bytes, broken into a line index for the header (8
bytes), the line space count (2 bytes), the page update count (2 bytes) and the
page number (4 bytes).
Note that the page number occurs as the first and last four bytes of each page. This is
added protection against undetected database damage. IDMS/R actually checks both
values each time a page is read; an unequal value causes immediately alarm within
DBMS.
33
IDMS/R
Each page has a unique page number. Within a page, each record occurrence has
unique line number.
Pages in an area must be sequentially numbered. Gaps in the page numbers can occur
between areas. Areas cannot overlap i.e. a page number can belong to one area only.
Valid page numbers:

AREA 1 Pages 1 – 500
AREA 2 Pages 601 – 1000
Invalid page numbers:
4.3. DB-Key
Each record occurrence is assigned a unique numeric identifier, called its database
key (db-key). Format of db-key is shown below.
A record occurrence’s db-key consists of a 32-bit field that typically contains a 23-bit
page number and an 8-bit line number. The page number identifies the page in which
the record occurrence is stored and the line number identifies the location of the
record occurrence within that page.
IDMS/R uses database keys to keep track of where in the database record occurrences
are physically stored.
Sign Bit (Not used)
Database Page Number Line Number

0 1 23 24 31
4.4. Multiple Areas

A database could be divided into multiple areas for many reasons.
 Processing efficiency. Programs can open areas individually. If we group record-

types into areas appropriately, programs can open only the areas that contain the
record types they need. E.g. programs of Payroll function do not need any record
types pertaining to Inventory / Stock data of Parts. So, record-types associated
with Payroll data would be in one area. Record-types associated with Inventory
data can be in another area.
34
IDMS/R
 Security. If we need to restrict access to certain record types, we can place them
together in an area that is protected using IDMS/R security facilities. E.g. access
to Payroll-Area is restricted.
 Search efficiency. Efficiency of sequential scan through the database improves if

the record type is assigned to a separate area.
 Concurrent updating. A program can request exclusive use of an area and

prevent other programs from accessing it concurrently.
 Database recovery and backup. The database can be initialized, restructured and
backed up on an area-by-area basis. Areas assigned to highly volatile record types
can be given different treatment from areas that are assigned to record types
whose occurrences are changed little.
4.5. Files
Each page corresponds to a physical record that is stored in a file, and all data
transfers between the database and the system buffers are accomplished a page at a
time.
The ways in which areas can be mapped into files in direct access storage are as
follows:
 Many (or all) areas can be mapped into one file if all the areas have the same page
size.
 Each area can be mapped into a different file.
 One area can be mapped into many files.
4.6. Record occurrence – Prefix, Data

An IDMS/R database consists physically of a collection of record occurrences. The
record occurrence represents the smallest directly addressable unit of data. A record
occurrence consists of a fixed or variable number of characters that are subdivided
into units called data elements or fields. These data element values follow the formats
that were defined in the schema for this record type. Application programs work on
these fields. In an application program, we cannot address an individual data element
without first retrieving the record occurrence in which it is stored.
The physical records stored in the database consist of more than the data elements
used by the application program. IDMS/R also maintains information about the
relationships that exist between records. These relationships are physically
implemented by linking record occurrences together with pointers. Pointers contain
35
IDMS/R
the addresses of related record occurrences and are stored with the data elements that
make up each record occurrence.
Following diagram shows the format of a record occurrence, as it is physically stored

in the database. A record occurrence in the database is made up of two parts: a data
portion and a prefix portion. Data element values are stored in the data portion.
Pointers to related record occurrences are stored in the prefix portion. Application
programs generally work only with the data element values that are stored in the data
portion. IDMS/R DBMS automatically maintains the pointers in the prefix portion.
Prefix Data
Pointer 1 Pointer 2 Pointer 3 ………. Data Data Data ……..
Element 1 Element 2 Element 3
36
IDMS/R
5. Record
Here, we discuss the characteristics that apply to record types.
5.1. Record Name

Each record must be assigned a 1- to 16-character name that identifies the record
type. It should be a unique name. The name must begin with an alphabetic character.
The application program must reference the record’s name in requesting that some
DML function be performed on one or more occurrences of a record type.
5.2. Record Identifier

The record identifier is a number (in the range 100 through 9999) that serves as an
internal identifier for the record type. Each record type must be assigned a unique
record identifier within the installation. A database administrator assigns record
identifiers for each record type that the installation creates. Application programs do
not refer to records using their record identifiers.
5.3. Storage Mode

The storage mode indicates whether occurrences of this record type are fixed or
variable in length and whether they are stored in compressed format. Codes used to
represent a record’s storage mode are as follows:
 F (fixed length)
 V (variable length)
 C (compressed)
The compressed storage mode can be used in conjunction with the fixed-length or
variable-length storage mode. E.g. a storage mode of FC indicates that record
occurrences are fixed length and compressed. When data compression is used, an
IDMS/R module automatically compresses and decompresses the data. Application
programs are not aware that compression and decompression is taking place.
5.4. Record Length
37
IDMS/R
The record length, expressed in bytes, is the actual data length for a fixed-length
record or the maximum data length for a variable-length record.
5.5. Location Mode

The location mode defines the way a record is stored in its database area and tells the
application programmer the way in which occurrences of this record type must be
accessed. The three possible location modes are:
 CALC
 VIA
 DIRECT
CALC Location Mode
With the CALC location mode, a particular field (data element) within the record
itself must be declared as the CALC-key. When the application program requests that
record occurrences be stored into the database, IDMS/R uses the CALC-key value to
calculate the page into which the record should be placed. IDMS/R uses a
randomizing routine to distribute records evenly over its area. To retrieve a record
later, the application program supplies IDMS/R with a CALC-key value, and
IDMS/R uses the randomizing routine to locate the proper page and directly retrieve
the record occurrence that has the supplied CALC-key value.
E.g., Department record type with CALC location mode and Dept-Id-0410 field as
CALC-key. When we add each new Department record occurrence to the database,
IDMS/R uses the Dept-Id-0410 value contained in the record we are adding to
calculate the specific page within the database to store the record. It then stores the
record occurrence on that page. To retrieve the record for a particular department
later, the application program moves the Dept-Id-0410 value for the desired
department into a designated application program storage area and executes a DML
retrieval function. IDMS/R then uses the randomizing routine to locate the page on
which the desired record is stored, searches through the page for the desired
Department record occurrence, and builds an image of the required subschema record
in an application program storage area.
The use of the CALC location mode results in record occurrences being distributed
relatively evenly over the pages in the area, thus minimizing overflow conditions and
leaving space for adding new records. Secondly, it allows us to retrieve records
directly by supplying a CALC-key value. A desired record is typically retrieved with
a single access rather than requiring IDMS/R to search through the database for it.
VIA Location Mode
38
IDMS/R
With the VIA location mode, each member record in a set is stored on or near the
page that contains the member record’s owner. The use of the VIA location mode
tends to group together in close physical proximity records that are likely to be
accessed together and minimizes the number of disk accesses needed to retrieve all
the records that belong to a given set occurrence.
Following diagram shows records stored using the VIA location mode. Each new
Expertise record occurrence is stored as close as possible to its owner Employee
record occurrence. When an occurrence of the Employee record is retrieved, some or
all of its member record occurrences will tend to be on the same page. Since IDMS/R
transfers data into its buffers one page at a time, only a single physical I/O operation
is needed, in many cases, to retrieve an owner record and all of its members.
Area 1
Employee Employee Expertise

Employee
Expertise Expertise Expertise
Emp-Expertise
Expertise
Expertise Expertise
Fig. 5.1.
If the owner and member record types are assigned to different areas, or to different
page ranges in the same area, record occurrences are distributed within their
associated page range in the same relative position as their owner occurrences is in its
associated page range. Or, in other words – When occurrences of a VIA member
record type are stored in a different area from occurrences of the owner record type,
IDMS/R clusters together the VIA member records of each owner and stores each
cluster at a point that is proportionally as far from the beginning of the area as the
owner record is from the beginning of its area. Following diagram shows records
stored using the VIA location mode when owner and member record types are
assigned to different areas.
Area 1 Area 2
Employee Expertise Expertise
Employee

Emp-
Expertise Employee Expertise

39 Expertise Expertise
Expertise
IDMS/R
Expertise
Fig. 5.2.
When the VIA location mode is assigned to a record type, no CALC-key can be
defined for that record type. This means that CALC retrievals cannot be requested for
record types that are assigned VIA location mode. In many cases, the owner record
type of a set type is assigned the CALC location mode, and the member record type is
assigned the VIA location mode. This allows an owner record type to be retrieved
directly, after which all the owner’s member record occurrences can then be quickly
located.
DIRECT Location Mode
When storing records into the database using the DIRECT location mode, the
application program explicitly specifies the page number into which the record
occurrence should be stored. Then when retrieving a record occurrence, the program
must specify the db-key value of the desired record occurrence. Since it is often
difficult for the program to determine the db-key value of the record it wants, this
location mode is less often used than CALC or VIA.
5.6. Duplicates Option

The duplicates option is specified only for records that are stored using the CALC
location mode. This option specifies whether records having duplicate CALC-keys
are allowed, and if duplicates are allowed, where records having duplicate CALC-key
values are to be placed in the area. Codes used to represent the duplicates options are
as follows:
 DN (Duplicates Not Allowed). With this option, a record occurrence with a

duplicate CALC-key value will not be accepted. IDMS/R will signal an error if
the program attempts to store a record that has the same CALC-key value as an
existing record in the database.
 DF (Duplicates First). With this option, a record occurrence with a duplicate

CALC-key value will be accepted. IDMS/R will store the record before any
record in the database that has a matching CALC-key value. When a CALC
retrieval is made using that CALC-key value, the new record will be retrieved
first.
40
IDMS/R
 DL (Duplicates Last). With this option, a record occurrence with a duplicate
CALC-key value will be accepted. IDMS/R will store the record after any record
in the database that has a matching CALC-key value. When a CALC retrieval is
made using that CALC-key value, the new record will be retrieved last.
5.7. Area Name

The area name is the name of the area into which all record occurrences of the
record type are to be stored.
5.8. Bachman Diagram For Record Type

Please refer to Employee Database mentioned in Appendix A. It is called a Bachman
diagram. A rectangle box is used to describe characteristics of a record. Following
diagram shows how characteristics of a record are mentioned in the rectangle box.
Record Name
Record Id Storage Record Location

Mode Length Mode
CALC-key or Duplicates
VIA Set Name Option
Area Name
Fig. 5.3.
The information for Department record type is as follows.
DEPARTMENT
410 F 56 CALC
DEPT-ID-0410 DN
ORG-DEMO-REGION
Fig. 5.4.
41
IDMS/R
 Department – The record name.

 410 – The unique record identifier assigned to the record type.
 F – The storage mode, indicating fixed-length records.
 56 – The record length.
 CALC – The location mode, indicating records are stored in the database area
using the CALC location mode.
 Dept-Id-0410 – The data element (field) name designated as the CALC-key.
For a record that is defined with the VIA location mode, this space is used to
specify the name of the set that is used in locating and storing record
occurrences.
 DN – The duplicates option, indicating duplicates not allowed.
 Org-Demo-Region – The name of the area in which the Department records
are stored.
42
IDMS/R
6. Set
Set relationships are defined according to the following rules:
 Any record type can be a member of any number of sets.

 Any record type can be the owner of any number of sets.
 Any record type can be a member of one set and the owner of another.
 A record need not be part of any set.
Set characteristics:
Set characteristics are assigned to each set when defining the database to IDMS/R. These
characteristics are:
 Set name
 Linkage options
 Membership options
 Order options
6.1. Set Name

The unique name must be assigned to each set type in the database. The set’s name
must be referenced whenever an application program accesses records using that set
relationship. Generally, a set name is formed by concatenation of names of the owner
and the member record types separated by a hyphen. E.g. in the Employee database,
the set Dept-Employee implements the one-to-many relationship between the
Department record and the Employee record.
6.2. Linkage Options

The linkage option indicates the types of pointers that are used to implement the set.
Pointers control flexibility in accessing records within a set. Codes used to represent
the linkage options are as follows:
 N (NEXT pointers). With this linkage option, the pointers in the set identify the
NEXT record occurrence. Following figure shows the use of NEXT pointers in
implementing a set occurrence. This option allows access to member records only
in the forward direction. To access a particular member record occurrence, we
must typically begin with owner record and then walk through all the member
records until we access the one we want. When only NEXT pointers are used to
43
IDMS/R
implement a set, space is required in the prefix of each record for only one
pointer. NEXT pointers must be specified for all sets; all other types of pointers
are optional.
Prefix Data
N Dept. 1000 Rec. occurrence
N Emp-Id 0001 Sudhir
N Emp-Id 0002 Pai
N Emp-Id 0003 Anil
Fig. 6.1.
 NP (NEXT and PRIOR pointers). With this linkage option, a set of PRIOR
pointers are used in addition to the set of NEXT pointers, as shown in the figure
below. This linkage option allows us to access member records in both forward
and backward direction.
Prefix Data
N P Dept. 1000 Rec. occurrence
N P Emp-Id 0001 Sudhir
N P Emp-Id 0002 Pai
N P Emp-Id 0003 Anil
Fig. 6.2.
 NO (NEXT and OWNER pointers). With this linkage option, a set of OWNER
pointers are used in addition to the NEXT pointers. Member record occurrences
contain two pointers, Next and Owner, in the prefix part. Owner record
occurrences contain only Next pointer. Owner pointers provide direct access from
any member record occurrence to its owner record occurrence.
44
IDMS/R
 NPO (NEXT, PRIOR and OWNER pointers). With this linkage option, the set
includes all three pointer options as shown in the following figure. This linkage
option allows access to member records in a set occurrence in both the next and
prior directions and direct access from a member record to the owner record.
Prefix Data
N P Dept. 1000 Rec. occurrence
N P O Emp-Id 0001 Sudhir
N P O Emp-Id 0002 Pai
N P O Emp-Id 0003 Anil
Fig. 6.3.
Ex.: Consider the following set.
Department
Dept-Employee
Employee
Emp-Expertise
Expertise
Fig. 6.4.
Pointers in Employee record occurrence:
45
IDMS/R
N P O N P Emp-Id 0001 Sudhir
Prior in Emp-Expertise set

Next in Emp-Expertise set
Owner in Dept-Employee set
Prior in Dept-Employee set
Next in Dept-Employee set
Fig. 6.5.
6.3. Order Options

The Order option specifies the logical order in which member record occurrences are
placed within a set occurrence. The logical order of member record occurrences is
independent of the physical placement of the records themselves. The order options
are as follows:
 FIRST. Each new member record occurrence is placed immediately after the
owner record (in the next direction). While retrieving, this option achieves a
member order of LIFO.
Before Insertion
D1
After Insertion
E1 E3
E15 is inserted
E2
D1
Fig. 6.6. E1 E3
5
 LAST. Each new memberE1 record occurrence is placed immediately before the
owner record (in the prior direction).E2While retrieving, this option achieves a
46
IDMS/R
member order of FIFO. PRIOR pointers are required (NP or NPO linkage option)
to satisfy the LAST order option.
Before Insertion
D1
After Insertion: E15 is inserted

E1 E3
E2
D1
E1 E1
Fig. 6.7. 5
E2
 NEXT. Each new member record occurrence E3 is placed immediately after the
member record occurrence that was last accessed (in the next direction) within the
set occurrence i.e. next to the current of set.
Before Insertion
Current of set: - E2
D1
E1 E3
E2
D1
E1 E3
Fig. 6.8.
E2
E1
5
47
IDMS/R
 PRIOR. Each new member record occurrence is placed immediately before the
member record occurrence that was last accessed (in the prior direction) within
the set occurrence i.e. prior to the current of set. Prior pointers are required in
order to specify the PRIOR order option.
Before Insertion: current of set is E2
D1
E1 E3
E2
D1
Fig. 6.9. E1 E3
 SORTED. With this option, a new member record occurrence is placed in

E1
ascending or descending sequence, based
5 E2 on the value of a designated sort-control
data element, or sort key, contained in each record occurrence. When a record is
placed into a set, the DBMS examines the sort key in each member record
occurrence to determine the logical position of the new member record
occurrence in the set occurrence.
A sorted set order is defined by the keywords ASC (ascending) or DES

(descending), followed by the data element name of the sort key.
D1
Consider Dept-Employee set. Order option is sorted, ASC, and sort-key is EMP-
LAST-NAME-0415.
Josh Verm
i aE3
Patil
D1
Jos Verm
hi a
Kam
at Pati
l
48
IDMS/R
Before insertion:
Insert “Kamat”. After insertion:
Fig. 6.10.
Duplicates Option: - A duplicates option indicates the action to be taken by the

DBMS when a duplicate sort-key value occurs. Codes used to represent the
duplicates option for sorted sets are as follows:
 DF (Duplicates First). With the DF duplicates option, a record with a

duplicate sort-key value is stored immediately before the existing duplicate
record in the set. The first duplicate record encountered in the next direction is
always the most recently stored duplicate record.
After insertion. Patil(2) inserted.
Fig. 6.11. D1
Jos Verm
 DL (Duplicates Last). hi With the DL duplicates a option, a record with a
duplicate sort-key value is stored immediately after the existing duplicate
Patil(2)
record in the set. The last duplicate record encountered in the next direction is
Patil(1)
always the most recently stored duplicate record.
49
IDMS/R
Ex.: After insertion. Patil(2) inserted.
D1
Fig. 6.12
Jos Verm
hi a
 DN (Duplicates Not Allowed). With the DN duplicates option, a record with
a duplicate sort-key value cannot be stored in the set. When a program
Patil(1)
attempts to store a record with a duplicate sort-key value, the DBMS returns
Patil(2)
an error code.
Ex.: Try to insert Patil(2). It is rejected. IDMS/R returns an error code.
D1
Fig. 6.13.
Josh Verm
6.4. i
Bachman Diagram For Set aE3
Patil(1)
Please refer to Employee Database Bachman diagram in Appendix A. Please check
up Dept-Employee set. All the set characteristics for Dept-Employee set are shown
along side the arrow, which represents the set. The set characteristics shown are as
follows:
Dept-Employee – The set name.

NPO – The linkage options. The set has Next, Prior, and Owner pointers.
OA – Membership options.
ASC (Emp-Last-Name-0415 Emp-First-Name-0415): - The Order option for the set is
‘Sorted’ in ascending sequence. Sort-key is Emp-Last-Name-0415 Emp-First-Name-
0415.
DL – The duplicates option of the sorted set.
50
IDMS/R
7. Retrieval: Basic, By Sort-key, Indexed

Set, Sweeping Areas
7.1. Basic Retrieval: CALC, Through Relationship

Here, we discuss how to code the specific DML statements that are used to retrieve
information from an IDMS/R database. There are various ways to access the data.
Two of those methods are given below.
 By performing a CALC retrieval. It is a random access.

 By walking sets i.e. access through set relationship.
The DML statement used for these retrievals is OBTAIN. The “OBTAIN” statement
causes IDMS/R to locate the appropriate record occurrence in the database and moves
data element values into application program’s variable storage i.e. working-storage
section. It makes the data available to the program.
7.2. CALC Retrieval: Random access

The syntax is as follows.
OBTAIN CALC <Record-Type-Name>.
Ex.: Retrieve a Department record occurrence, given Dept-Id (CALC-key).
MOVE 2000 TO DEPT-ID-0410.


In the above example, it retrieves a particular Department record occurrence.
Coding steps are as follows.

 Move / assign value to the CALC key-field
 Issue “OBTAIN” DML statement
51
IDMS/R
To perform a CALC retrieval, the record type we are retrieving must have a CALC-
key defined for it, and we must know the CALC-key value of the record occurrence
we are retrieving. We cannot perform a CALC retrieval for EXPERTISE records.
IDMS/R uses the CALC-key value we supply to locate the appropriate page in the
database, retrieves the desired Department record occurrence and constructs a
subschema record in the program’s variable storage i.e. working-storage section.
7.3. Error Handling

The application program must check up status of any DML statement immediately
after its execution. ERROR-STATUS field of IDMS Communication Block contains
status information of the DML statement just executed. The ERROR-STATUS field
consists of 4 bytes. First two bytes (major code) identify the function performed. The
last two bytes (minor code) describe the status of that function. A value of “0000”
indicates that the DML statement was successful. Any non-zero value indicates
failure. There are some 88-level condition names associated with ERROR-STATUS
field in IDMS Communication Block as given below.
ERROR-STATUS Condition Name Explanation

Field Values
“0000” DB-STATUS-OK Successful
“0307” DB-END-OF-SET End of set, area or index
“0326” DB-REC-NOT-FOUND No record found for given key
“0001” To “9999” ANY-ERROR-STATUS Any error, Any non-zero value
Example given above is reproduced below.

If Department record occurrence with Dept-Id 2000 does not exist, it can be checked
with following IF conditions.
IF ERROR-STATUS = ‘0326’
DISPLAY ……
03 – Major code – For “OBTAIN” DML function

26 – Minor code – Function status: - No record found
Or, we can use condition name as follows.
IF DB-REC-NOT-FOUND
DISPLAY ……..
52
IDMS/R
Standard approach for error handling in the program:
DML statement
Expected
Status
IDMS-STATUS
Take Appropriate
Actions
End
Continue
Processing
Fig. 7.1.
Ex.: Coding for error handling.

IF DB-STATUS-OK
DISPLAY DEPT-NAME-0410
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘GIVEN DEPT-ID NOT FOUND’
ELSE
Eg. 7.1.
7.4. Access By Walking Sets i.e. Access Through Set

Relationship
There are two types of retrievals through set relationship.
 Retrieving members from owner
 Retrieving owner from members
Retrieving members from owner:
53
IDMS/R
In many application situations, it is necessary to retrieve a particular owner record
occurrence and then to retrieve one or more of that owner’s member record
occurrences. We choose the set occurrence that we wish to access by executing a
retrieval statement (either an OBTAIN or a GET) for a particular occurrence of the
set’s owner record type; a CALC-type retrieval is often useful for this purpose. Once
we have established the set’s owner record occurrence as current of its record type
and also current of its set type, then to retrieve member record occurrences from the
set occurrence, following syntax is used.
OBTAIN First <Record-Name> within <Set-Name>

Last
Next
Prior
Nth
Ex.: First
OBTAIN FIRST EMPLOYEE WITHIN DEPT-EMPLOYEE
IDMS/R retrieves the first Employee record in the Dept-Employee set, which then
becomes current of the Dept-Employee set. The original Department record remains
current of its record type.
Ex.: Last
OBTAIN LAST EMPLOYEE WITHIN DEPT-EMPLOYEE
If a set is defined with prior pointers, we can retrieve the last member record
occurrence of a set as mentioned above.
Ex.: Next
OBTAIN NEXT EMPLOYEE WITHIN DEPT-EMPLOYEE
To retrieve each of an owner record’s members in sequence is very useful. This is

called as walking the set or navigating the set. The retrieval statement, given above,
can be repeatedly executed to retrieve all of an owner record’s members until it
reaches end-of-set.
D1
E1 E3
Department D1
E2
54
IDMS/R
Employee E1 Employee E3
Employee E2
Fig. 7.2.
The particular record occurrence that this statement retrieves depends on which
record occurrence in the set is established as current of the Dept-Employee set; it
always retrieves the record that follows the record occurrence that is current of the
Dept-Employee set in the next direction.
IDMS/R sets an end-of-set condition code that the program must test to avoid
walking the set a second time.
Example: Display all employees’ names for a given department.
MOVE ‘N’ TO WS-END-SET.

IF DB-STATUS-OK
PERFORM RETRIEVE-REC UNTIL WS-END-SET = ‘Y’
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘GIVEN DEPT-ID NOT FOUND’
ELSE
………
………
RETRIEVE-REC.
OBTAIN NEXT EMPLOYEE WITHIN DEPT-EMPLOYEE.
IF DB-STATUS-OK
DISPLAY EMP-NAME-0415
ELSE
IF DB-END-OF-SET
MOVE ‘Y’ TO WS-END-SET
ELSE
Eg. 7.2.
Note: - If the <Record-Name> clause is omitted from the above mentioned OBTAIN
syntax, then in case of a multimember set, member record occurrences of any record
type will be retrieved.
Including a qualifying a record name is useful when walking sets that have more than
one member record type.
55
IDMS/R
Ex.: Prior
OBTAIN PRIOR EMPLOYEE WITHIN DEPT-EMPLOYEE
If a set has been defined as having PRIOR pointers, we can walk the set in the prior
direction by repeatedly executing a statement of the above-mentioned type.
OBTAIN PRIOR works in the same manner as OBTAIN NEXT, except in the reverse
direction. OBTAIN PRIOR statements cannot be issued for a member record type if
the member’s set does not include PRIOR pointers.
Ex.: Nth
We can retrieve a particular member of a set by a number that specifies the relative
sequence in the set of the desired member.
OBTAIN 3 EMPLOYEE WITHIN DEPT-EMPLOYEE
Or, we can use a variable (of PIC S9(5) COMP) in place of sequence number.
01 SEQ-FIELD PIC S9(5) COMP.
MOVE SEQUENCE-NUMBER TO SEQ-FIELD.

OBTAIN SEQ-FIELD EMPLOYEE WITHIN DEPT-EMPLOYEE
Retrieving owner from members:
We can use the following DML statement to retrieve the owner of a set occurrence:
OBTAIN OWNER WITHIN <Set-Name>
OBTAIN OWNER WITHIN DEPT-EMPLOYEE
If currency is established anywhere in the set occurrence (as shown in above bubble
diagram), OBTAIN OWNER will cause IDMS/R to retrieve the Department record
occurrence for D1.
An OBTAIN OWNER retrieval can be issued whether or not the set is defined as
having OWNER pointers. If owner pointers do not exist, IDMS/R walks the set, if
necessary, to locate the owner record. If the set is defined as having OWNER
pointers, IDMS/R can get directly to the owner from any member in the set
occurrence.
Example: Display department name for a given employee-id.
MOVE WS-EMP-ID TO EMP-ID-0415.

OBTAIN CALC EMPLOYEE.
IF DB-STATUS-OK
56
IDMS/R
OBTAIN OWNER WITHIN DEPT-EMPLOYEE
IF DB-STATUS-OK
DISPLAY DEPT-NAME-0410
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘DEPARTMENT NOT FOUND’
ELSE
PERFORM IDMS-STATUS
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘GIVEN EMPLOYEE NOT FOUND’
ELSE
Eg. 7.3.
Assignment 1: - Refer to Lab Book. Source code given.
Assignment 2: - Refer to Lab Book. Similar to 1.
Those participants, who finished these assignments, can continue to Assignment 3. The logic and
programming would be on similar lines.
57
IDMS/R
7.5. Retrieval By Sort-Key Value

If we are retrieving member records and the set type is with order option of SORTED,
we can base retrievals on sort-key values.
E.g. Dept-Employee set is with order option of SORTED in ascending sequence and
the sort-key is EMP-LAST-NAME-0415. Please check up above diagram of the set
occurrence for Department record occurrence D1. We want to access Employee
record occurrence “Patil” in the set occurrence of D1. With this sorted set, we can
retrieve a particular member of a set occurrence based on a sort-key value, as in the
example give below.
MOVE ‘PATIL’ TO EMP-LAST-NAME-0415.

OBTAIN EMPLOYEE WITHIN DEPT-EMPLOYEE USING
EMP-LAST-NAME-0415.
In this example, we move a last name value to the data element in the Employee
record description that defines the sort key and issues an OBTAIN statement that
references the sort-key data element. Note that although the retrieval appears similar
to a CALC retrieval, the search for a record is limited to the current set occurrence.
IDMS/R does not search other set occurrences for a member having the specified
sort-key value.
In the previous example, IDMS/R begins searching member records from the first
member record occurrence in the set occurrence, regardless of which record
occurrence is current of set type.
The general syntax is as follows:
OBTAIN <record-name> WITHIN <set-name> USING <sort-key>.
The expected return-codes are DB-STATUS-OK, DB-REC-NOT-FOUND.
MOVE ‘PATIL’ TO EMP-LAST-NAME-0415.

OBTAIN EMPLOYEE WITHIN DEPT-EMPLOYEE USING
EMP-LAST-NAME-0415.
IF DB-STATUS-OK
DISPLAY EMP-ID-0415 EMP-NAME-0415 EMP-ADDRESS-0415
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘GIVEN EMPLOYEE NOT FOUND’
ELSE
Eg. 7.4.
58
IDMS/R
7.6. Generic Key Retrieval
To perform a generic-key retrieval in a sorted set, we supply IDMS/R with a partial
key value. E.g. in Dept-Employee sorted set as mentioned above, we want to retrieve
all the Employee record occurrences whose last name value begin with the letter ‘S’.
Following is the partial code for this type of retrieval.
01 WS-LAST-NAME.
05 WS-FIRST-CHAR PIC X.
05 FILLER PIC X(14).
……..
……..
MOVE LOW-VALUES TO WS-LAST-NAME.
MOVE WS-INPUT-CHAR TO WS-FIRST-CHAR.
MOVE WS-LAST-NAME TO EMP-LAST-NAME-0415.
OBTAIN EMPLOYEE WITHIN DEPT-EMPLOYEE

USING EMP-LAST-NAME-0415.
IF DB-STATUS-OK
DISPLAY EMP-ID-0415 EMP-NAME-0415
Process all remaining Employee occurrences for which
last name starts with ‘S’
ELSE
IF DB-REC-NOT-FOUND
Obtain next employee occurrence within the set
If db-status-ok
If last-name starts with ‘S”
Display emp-id, emp-name
Process all remaining Employee occurrences
for which last name starts with ‘S’
else
display message ‘Not found’
else
display message ‘Not found’
ELSE
Eg. 7.5.
Please notice that the data element in which we store the generic key must be padded
to the right with low values.
7.7. Indexed Set

A special type of set is provided by IDMS/R that allows retrieval of records using an
index. In a conventional set, member records are chained together by pointers. In an
index set, database key values are stored in a specified order in one or more index
59
IDMS/R
records. E.g. Employee record has an index built on last-name and first-name fields,
apart from CALC key. Skill record has an index built on skill-name apart from CALC
key. We can have more than one indexes built on different fields, so that we can
retrieve record occurrences based on any index that we need.
With an index, retrieval of members can sometimes be more efficient because the
index can be traversed more quickly than the set of chained member records. Indexed
sets are used mainly to add flexibility to data retrieval.
To implement an index, IDMS/R builds an index file that contains the database key
values of member record occurrences. These db-key values are maintained in the
sequence specified for the index. i.e. IDMS/R uses an array of database pointers to
quickly access member records. DBMS locates the data by searching the index rather
than the actual member record.
The use of indexes can simplify processing in the following situations:
 Random retrieval by key value. Also a partial or generic key value can be used.
 Sorted retrieval by key value.
 Multiple-key access. Sometimes we need to access records based on more than
one key.
7.8. Retrieval Using Indexed Set

By using index sets, we can perform three types of retrieval that are difficult or
impossible without the use of an index:
 Sequential retrieval in symbolic-key sequence

 Generic-key retrieval
 Random retrieval based on the value of a symbolic key other than a CALC-key.
Each entry in the index contains a symbolic-key (or index-key) data element value
and the db-key value of its corresponding record occurrence.
Random Retrieval
To use the index to find the first record having a particular index-key (a field on
which the index is built) value, we can do a random retrieval in a similar manner to
the method we used for retrieving a member record having a particular sort-key value.
The syntax and the logic are similar to the sorted set. Please refer to Sec. 8.1.
We name the desired record type, specify the name of the index set and supply a data
element value for the indexed data element:
60
IDMS/R
OBTAIN SKILL WITHIN SKILL-NAME-NDX

USING SKILL-NAME-0455.
Expected return-codes are DB-STATUS-OK, DB-REC-NOT-FOUND.
Sequential Retrieval
Consider the index set EMP-NAME-NDX built on last-name field of Employee

record. There may be many Employee records all having the same last-name value.
Once the program locates the first one through random retrieval, it could issue a
series of sequential retrievals to locate additional records having that same name:
OBTAIN NEXT EMPLOYEE WITHIN EMP-NAME-NDX.
Expected return codes are DB-STATUS-OK, DB-END-OF-SET.
The program has to test the last-name field after each sequential retrieval to determine
when it has reached the last record with the specified last-name data element value.
Generic-Key Retrieval
The syntax and logic is exactly similar to Sorted set. Please refer to Sec. 8.2.
7.9. Bachman Diagram: Indexed Set

The set characteristics of an Indexed set are similar to the set with order option as
Sorted. The index set characteristics are shown along side the arrow representing the
indexed set in the Bachman diagram.
Please refer to Employee database in Appendix A. There are indexes built on Skill
record, Employee record and Job record.
Assignment 3: - Refer to Lab Book.
Assignment 4: - Refer to Lab Book.
7.10. Retrieval By Sweeping Areas
61
IDMS/R
In performing an area sweep, IDMS/R scans through all the records in an area in
physical sequence. The order in which records are retrieved will generally have little
relationship to the logical sequence of records. Area sweeps are useful when we want
to retrieve all the records in an area without regard to the order in which we get them.
E.g. when we are simply gathering statistics about the database.
Performing an area sweep in the forward direction:
OBTAIN FIRST <record-name> WITHIN <area-name>.
IDMS/R will simply retrieve the record occurrence of the given record-type having
the lowest database-key value in the area. In the following statement, IDMS/R uses
currency within the area to determine which record occurrence of the given record-
type to retrieve. It uses area currency to retrieve the record occurrence having the next
highest database-key value.
OBTAIN NEXT <record-name> WITHIN <area-name>.
Performing an area sweep in the reverse direction:
OBTAIN LAST <record-name> WITHIN <area-name>.

….
….
OBTAIN PRIOR <record-name> WITHIN <area-name>.
Pointers are not used in performing an area sweep, so prior pointers are not necessary
for executing OBTAIN PRIOR WITHIN AREA statements.
In the above mentioned OBTAIN syntax, record-name can be omitted.
We can also used the following syntax:
OBTAIN Nth <record-name> WITHIN <area-name>.
We can use a sequence number or a variable (of PIC S9(5) COMP) in place of a
sequence number as given below.
01 SEQ-FIELD PIC S9(5) COMP.
MOVE SEQUENCE-NUMBER TO SEQ-FIELD.

OBTAIN SEQ-FIELD EMPLOYEE WITHIN EMP-DEMO-REGION.
Expected return-codes are DB-STATUS-OK, DB-END-OF-SET.
Example: Retrieve all Course record occurrences.
OBTAIN FIRST COURSE WITHIN COURSE-AREA.
62
IDMS/R
PERFORM 2000-RETRIEVE-REC
UNTIL WS-END-OF-COURSE-AREA = ‘Y’.
….
….
2000-RETRIEVE-REC.
IF DB-STATUS-OK
DISPLAY COURSE-ID
OBTAIN NEXT COURSE WITHIN COURSE-AREA
ELSE
IF DB-END-OF-SET
MOVE ‘Y’ TO WS-END-OF-COURSE-AREA
ELSE
Eg. 7.6.
63
IDMS/R
8. Currency
To help keep track of where we are in the database, IDMS/R maintains pointers to a number
of different record occurrences as each run unit executes. We use the term currency to refer
to these pointers.
To enable a program to position itself and move about in the database, IDMS/R maintains a
Currency Table for each run unit.
The currency is the db-key of the most recently accessed record occurrence.
IDMS/R maintains four types of currency (Currency Table) for each run unit:
 Record Currency (Current of record type). The db-key of the most recent record
occurrence of each record type accessed by the program. IDMS/R maintains a separate
currency for each record type defined in the subschema.
 Set Currency (Current of set type). The db-key of the most recent record occurrence of
each set type accessed by the program. IDMS/R maintains a separate currency for each
set type defined in the subschema.
 Area Currency (Current of area). The db-key of the most recent record occurrence of
each area accessed by the program. IDMS/R maintains a separate currency for each area
to which the program has access.
 Run Unit Currency (Current of run unit). The db-key of the most recent record
occurrence accessed by the program.
8.1. Currency Table

Currency table is the table of four different types of currencies as explained above.
IDMS/R maintains a currency table for each run unit.
Record Set Area Run Unit Currency

Currencies Currencies Currencies
 BIND RUN-UNIT statement sets all the currencies to NULL.

 Successful DML statement changes the currencies involved. The other currencies
remain null until some future database access sets them.
64
IDMS/R
 Using the currencies and the NPO pointers stored in record occurrences, IDMS/R
DBMS accesses records in the database.
 FINISH statement nullifies all the currencies.
Subject Subject in Trg-Area
Sub-Course
Course Course in Course-Area
MVS
C0 C10
7
C09
Fig. 8.1.
CURRENCIES
Course
Sub-Course Set
Course-Area
Subject
Trg-Area
Run-Unit
Bind Run-unit - - - - - -
Move ‘MVS’ To Sub-Id
MVS - MVS MVS - MVS
OBTAIN CALC SUBJECT
65
IDMS/R
CURRENCIES
Course
Sub-Course Set
Course-Area
Subject
Trg-Area
Run-Unit
Move ‘MVS’ To Sub-Id
MVS - MVS MVS - MVS
OBTAIN CALC SUBJECT
Obtain next course within
MVS C07 C07 MVS C07 C07
Sub-course
Obtain last course within MVS
MVS C10 C10 C10 C10 DB-END-
Sub-course OF-SET
Obtain next course within
MVS C10 MVS MVS C10 MVS
Sub-course
Obtain course within sub-course MVS
MVS C10 MVS C10 MVS
using ‘C08’ (NPO)
DB-REC-NOT-
FOUND
8.2. Currency Loss

Following example uses retrieval by area sweeping.
Example: Display last Course of all Subjects.
….
….
Obtain first subject within course-area.
Perform next-subject-para until ws-course-area-end = ‘y’.
….
…..
Next-subject-para.
If db-status-ok
Perform disp-course-para
Obtain next subject within course-area
Else
If db-end-of-set
66
IDMS/R
Move ‘y’ to ws-course-area-end
Else
Perform idms-status.
Disp-course-para.
Obtain last course within sub-course.
If db-status-ok
Display course-id
Else
If db-end-of-set
Display ‘No Course’
Else
Perform idms-status.
Eg. 8.1.
COURSE-AREA: Record occurrences are as follows.
Page-1 Page-2 Page-3 Page-4

S1 C21 C31 C32
C11 C13 S4 C42
S2 C14 C22 S5
C12 S3 C41 C43
Sub-Course
Subject S1
Fig. 8.2.
C1 C1
1 4
Assumption: Both Record types, Subject and Course, are in Course-Area.
Course
The program displays courses C14C1 and C32. ButC1
it did not display courses C22 and
C43, which it was supposed to do. 2 3
This happened because of currency loss. Retrievals by sweeping areas work based on
area currency. Due to loss of Course-area currency, the Subjects S2 and S4 could not
be obtained by the area-sweeping logic. So, the courses C22 and C43 did not get
displayed.
67
IDMS/R
Course-Area Currency:
S1
C14
S3
C32
S5
The DML ‘Obtain first subject within course-area’ retrieves S1. Area currency is S1.
Then the DML ‘Obtain last course within sub-course’ is executed and it retrieves
C14. Now, area currency changes to C14. Then DML ‘Obtain next subject within
course-area’ is executed and it retrieves S3. Area currency becomes S3. We miss S2
here. Scan for next subject should have started from S1 onwards, but it started from
C14 onwards. This is currency loss. Same thing happened with S4 also.
Solution:
The record occurrences of both records, Subject and Course, are in the same area
Course-Area. So, any retrieval of Subject or Course record occurrence changes the
area Course-Area currency.
In the above program, we need to store / maintain the area currency. Find out the part
of code where currency loss takes place. The paragraph ‘Disp-course-para’ is the
place where currency loss happens. So before the execution of the statement ‘Perform
disp-course-para’, we need to store the area currency. After the execution of the
statement ‘Perform disp-course-para’, we need to reestablish the area currency from
the stored value.
8.3. Storing and Retrieval By DB-Key Value

We can save the db-key / currency value in a working-storage field for later use. The
syntax is as follows.
<record-name>
ACCEPT <ws-db-key-v> FROM <set-name> CURRENCY
<area-name>
Or
MOVE DBKEY TO ws-db-key-v.
68
IDMS/R
The field ws-db-key-v should be defined in working-storage as follows.
01 ws-db-key-v PIC S9(8) COMP SYNC.
To reestablish the currency to stored value, use following statement.
FIND / OBTAIN <record-name> DB-KEY IS ws-db-key-v.
The record-name is optional.
Ex.: The above-mentioned program is modified to take care of area currency loss.
Only affected code is given below.
Next-subject-para.
If db-status-ok
Accept ws-db-key-v from course-area currency
Perform disp-course-para
Obtain subject db-key is ws-db-key-v
Perform idms-status
Obtain next subject within course-area
Else
…..
Eg. 8.2.
Reestablishing Run-Unit Currency:
To reestablish the current record occurrence of record type, set type, or area as the
current record occurrence of run unit, use the following statement:
<record-name>
FIND / OBTAIN CURRENT WITHIN <set-name>
WITHIN <area-name>
After this statement, issue PERFORM IDMS-STATUS.
8.4. Obtain Vs. Find and Get

An OBTAIN statement performs the same function as a FIND followed by a GET.
The find function causes IDMS/R to locate the appropriate record in the database and
place it in the system buffers. We can latter follow a successful FIND with a GET.
GET causes IDMS/R to move the appropriate data element values from the system
buffers into our program’s variable storage – working-storage section.
69
IDMS/R
We may not follow a FIND with a GET. In some cases, we only wish to locate a
record, but do not need actually to retrieve it. E.g. we may need only to verify that a
particular record occurrence exists, or we may need to establish a starting point for
some subsequent retrieval sequence.
The syntax of FIND is similar to OBTAIN.

FIND CALC DEPARTMENT.
GET DEPARTMENT.
MOVE ‘SUDHIR’ TO FACULTY-ID.

FIND CALC FACULTY.
GET FACULTY.
70
IDMS/R
8.5. IF <set-name> EMPTY / MEMBER:

By using IF statement, you can determine
 If the set is empty
 If the record occurrence is member of the specified set occurrence.
Using the IF EMPTY statement:
IF <Set-Name> IS [NOT] EMPTY

Imperative statement
After you have retrieved a owner record occurrence in a set, you can issue the IF
EMPTY statement to determine if the set has any member record occurrences. This
allows you to control processing based on whether the set is empty.
IF DEPT-EMPLOYEE IS EMPTY
MOVE NO-EMP-MSG TO WS-MSG
ELSE
PERFORM 1000-DEPT-EMP THRU 1000-EXIT
UNTIL DB-END-OF-SET.
………
………
1000-DEPT-EMP.
…….
Eg. 8.3.
To determine if a set is empty, perform the following steps:
i. Establish currency for the set.

ii. Issue the IF EMPTY statement.
iii. Perform further processing as specified.
Using the IF MEMBER statement:
IF [NOT] <Set-Name> MEMBER

Imperative statement
You can issue the IF member statement to ensure that a record occurrence currently
participates as a member of a specified set occurrence.
To determine if a record participates as a member in a set, perform the following

steps:
i. Establish run unit currency for the specified member record.
71
IDMS/R
ii. Issue the IF MEMBER statement.
iii. Perform further processing, as specified.
1000-DEPT-EMP.
IF DB-STATUS-OK
NEXT SENTENCE
ELSE
IF DB-END-OF-SET
GO TO 1000-EXIT
ELSE
IF OFFICE-EMPLOYEE MEMBER
OBTAIN OWNER WITHIN OFFICE-EMPLOYEE
PERFORM IDMS-STATUS
DISPLAY OFFICE-ADDRESS-0450
ELSE
MOVE NO-OFF-MSG TO WS-MSG.
……….
……….
1000-EXIT.
EXIT.
Eg. 8.4.
Please consider the following data.
D1
Fig. 8.3. E5
Employees E1 and
E1 E2 are attached
E2to Dept D1. Employee E5 is not attached to any
Department.
If we do not use IF MEMBER:
72
IDMS/R
CURRENCIES
Dept-Employee Set
Run-Unit
Department
Employee
Bind Run-unit - - - -
Move E1 To Emp-Id-0415
- E1 E1 E1
Obtain calc Employee
Obtain owner within Dept-Employee D1 E1 D1 D1
D1 E2 E2 E2
D1 E5 E2 E5
This is a wrong result. Employee E5 is not attached to any Department, but the
program concludes that it is attached to Dept D1.
This is solved by using IF MEMBER statement as follows.
CURRENCIES
Dept-Employee Set
Run-Unit
Department
Employee
Bind Run-unit - - - -
- E1 E1 E1
D1 E2 E2 E2
D1 E5 E2 E5
IF Dept-Employee MEMBER
Obtain owner within Dept- Employee
D1 E5 E2 E5
Else
Display ‘No Owner’
The program will display error message ‘No Owner’.
73
IDMS/R
9. Types of Set Relationships
9.1. Hierarchies
Two-Level Hierarchies:
A single set implements a two-level hierarchy. The owner record type is on the first
level, and member record types are on the second level. A one-to-many relationship
exists between the owner record type and its member record types.
Department
Dept-Employee
Employee
Fig. 9.1.
Multilevel Hierarchies:
A member record of one set can also be the owner of another set. This results in a
multilevel hierarchy.
Department
Dept-Employee
Employee
Emp-Expertise
Expertise
Fig. 9.2.
Multiple Member Sets:
There are more than one member record types in a set type. While walking a set, we
can access all member record types.
74
IDMS/R
Coverage
Coverage-Claims
Hospital- Non-Hosp- Dental-

Claim Claim Claim
Fig. 9.3.
Note: - If the <Record-Name> clause is omitted from the OBTAIN syntax, then in
case of a multimember set, member record occurrences of any record type will be
retrieved.
Multiple Set Ownership:
This form of hierarchy uses one record type as the owner record in more than one set.
The common owner record provides the means of movement between the two
different member record types in different sets.
Employee
Emp-Emposition Emp-Expertise
Emposition Expertise
Fig. 9.4.
Multiple Sets:
It is quite possible for two record types to participate in multiple one-to-many

relationships with one another.
For example, in the diagram below about Customer and Invoice record types, it is
useful to separate overdue invoices from other invoices. This is implemented by
defining two different one-to-many relationships between the Customer record type
and the Invoice record type, with each being implemented by a different set type.
Customer
Cust-Invice Cust-Overdue-Invoice
Invoice
Fig. 9.5.
75
IDMS/R
The same two record types, Customer and Invoice, now participate in two different
sets. However, a given Invoice record occurrence will be a member of only one of the
two possible set types. For each Customer record occurrence, there are two different
groups of Invoice record occurrences associated with it.
Cust-Invoice
Cust-Overdue-Invoice
C1
I3 I2
Fig. 9.6 I1
I5
9.2. Junction Record:

I4 Multiple Set Membership
IDMS/R does not support many-to-many relationship directly. For each many-to-
many relationship that we identify among a set of entities in real world applications,
we will almost always identify additional attributes that are not associated with either
of the two entities alone, but are associated with the intersection between the two
entity types.
E.g. there is a many-to-many relationship between Supplier and Parts record types. A
supplier supplies many parts and a part is supplied by many suppliers. An additional
record type Quantity is provided, in which information about quantity supplied can be
stored. Supplier and Parts have a one-to-many relationship with Quantity. The record
type Quantity is called the junction record, because it represents a junction or
intersection between the Supplier and the Parts record types. The junction record
Quantity is the member record in the multiple sets Supplier-Qty and Parts-Qty. The
junction record resolves the many-to-many relationship and implements it indirectly.
Supplier Parts
Supplier-Qty Parts-Qty
Quantity
Fig. 9.7
S1 P1
76
IDMS/R
S2 P2
Q: S1P1 P3
Q: S1P2
Q: S1P3
Q: S2P1
Q: S2P2
Q: S2P3
Supplier-Qty Parts-Qty
Fig. 9.8.
9.3. Nested Structure – Bill Of Material

Nested structures arise when modeling bill-of-materials structures in the
manufacturing environment. In some applications, there exists a many-to-many
relationship among different occurrences of the same record type. Occurrences of a
record type are related to other occurrences of the same record type.
For example, consider a typical bill-of-material case of main-parts and sub-parts. A

main-part consists of many sub-parts and a sub-part belongs to (or takes part in
construction of) many main-parts. But, a main-part and a sub-part are basically Parts.
So, there exists a many-to-many relationship among Parts record occurrences. The
owner record and the member record both are the same record type. It can be shown
as follows.
Parts-Are Parts
Parts-For
Fig. 9.9.
In a set relationship in IDMS/R, a record type cannot be both an owner and a member
of the same set. The technique of junction record can be used to resolve this situation.
A possible intersection data is the quantities required of the Parts. A main-part
consists of many different sub-parts in certain quantity. Different quantities of a sub-
part are used in construction of many different main-parts. We can create a junction
record called Quantity.
Parts
77
Quantity
IDMS/R
Parts-Are Parts-For
Fig. 9.10.
The Quantity junction record is related to the Parts record using two sets. The set
Parts-Are allows us to find out sub-parts of a given part, and Parts-For helps to find
the main-parts where the given part is used as a sub-part.
P1
P2
P11
P21
P81
P82
Q: P1P81
Q: P1P82
Q: P1P11
Q: P2P81
Q: P2P82
Q:P2P21
Parts-Are Parts-For
Fig. 9.11.
Consider another example of bill-of-materials structure.
To learn a particular subject, the knowledge of some other subjects is a pre-requisite.

E.g. to learn IDMS, knowledge of Cobol, JCL, MVS is a pre-requisite. To learn DB2,
knowledge of Cobol, DBMS, JCL, MVS is pre-requisite. Given a particular subject,
say Cobol, it is a pre-requisite for IDMS, DB2, JCL. So, there exists a many-to-many
relationship among Subject record occurrences. The owner record and the member
record both are the same record type. It can be shown as follows.
Subject
Prereq-Are
78
IDMS/R
Prereq-For
Fig. 9.12.
We resolve this by creating a junction record Skill-Level. To learn IDMS,

prerequisite are knowledge of Cobol with skill-level of 3, JCL with skill-level of 2,
MVS with skill-level of 1. To learn DB2, prerequisite are knowledge of Cobol with
skill-level of 2, JCL with skill-level of 2, MVS with skill-level of 1, DBMS with
skill-level of 3. Cobol is a pre-requisite for IDMS (Cobol level 3), DB2 (Cobol level
2), JCL (Cobol level 1).
Subject
Prereq-Are Prereq-For
Skill-Level
Fig. 9.13.
The Skill-Level junction record is related to the Subject record using two sets. The set
Prereq-Are allows us to find out the subjects that are prerequisites of a given subject,
and the set Prereq-For helps to find the subjects for which the given subject is a
prerequisite.
Exercise: - Draw the diagram of Subject, Skill-Level record occurrences with Prereq-
Are and Prereq-For set occurrences (similar to Parts, Quantity shown above).
Coding for retrieval logic:
Please consider record types Parts and Quantity with two sets Parts-Are and Part-For
as explained above.
The owner record type is same for both the sets. The member record type is also the
same for both the sets. So, retrieval of any of the two record types, Parts or Quantity,
changes the set currencies of both the sets. If we want to walk along (navigate) a
particular set occurrence sequentially, then any retrieval through another set during
the processing will change the set currency of the set occurrence we are walking
along. This is a problem of set currency loss. So, we need to store the set currency for
the set occurrence we want to walk along and reestablish it later.
Ex.: List out all sub-parts of part-number P1.
MOVE P1 TO PART-NUMBER.
OBTAIN CALC PARTS.
IF DB-STATUS-OK
PERFORM 1000-WALK THRU 1000-EXIT
79
IDMS/R
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘PART NOT FOUND’
ELSE
….
….
1000-WALK.
IF PARTS-ARE IS EMPTY
DISPLAY ‘NO SUB-PARTS’
GO TO 1000-EXIT.
PERFORM 2000-PROCESS THRU 2000-EXIT
UNTIL WS-END-SET = ‘Y’.
1000-EXIT.
EXIT.
2000-PROCESS.
OBTAIN NEXT QUANTITY WITHIN PARTS-ARE.
IF DB-STATUS-OK
PERFORM 3000-DISPLAY THRU 3000-EXIT
FIND CURRENT QUANTITY
PERFORM IDMS-STATUS
ELSE
IF DB-END-OF-SET
MOVE ‘Y’ TO WS-END-SET
ELSE
2000-EXIT.
EXIT.
3000-DISPLAY.
IF PARTS-FOR MEMBER
OBTAIN OWNER WITHIN PARTS-FOR
IF DB-STATUS-OK
DISPLAY PART-NUMBER ‘ ‘ PART-NAME
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘OWNER NOT FOUND’
ELSE
PERFORM IDMS-STATUS
ELSE
DISPLAY ‘OWNER NOT AVAILABLE’.
3000-EXIT.
EXIT.
Eg. 9.1.
What will happen if we do not store the Parts-Are set currency i.e. if we do not write
the statements ACCEPT WS-DB-KEY ….. and OBTAIN QUANTITY DB-KEY
…..?
Consider the following data: Part P1 has three sub-parts as P11, P12, and P13. Parts
P11, P12, and P13 do not have any sub-parts i.e. those are stand-alone parts.
CURRENCIES
80
IDMS/R
Parts-For Set
Parts
Parts-Are Set
….-Area
Run-Unit
Quantity
Move P1 To Part-number
P1 - P1 P1 P1 P1
Obtain calc Parts
Obtain next Quantity within Parts-
P1 Q11 Q11 Q11 Q11 Q11
Are
Obtain owner within Part-For P11 Q11 P11 P11 P11 P11
P11 Q11 P11 P11 P11 P11
Are
DB-END-
OF-SET
First the program retrieves part P1. Parts-Are set currency is P1. Then DML
‘OBTAIN NEXT QUANTITY WITHIN PARTS-ARE’ retrieves Quantity
occurrence, say Q11. Parts-Are set currency is Q11. Then DML ‘OBTAIN OWNER
WITHIN PARTS-FOR’ is executed and retrieves P11. Parts-Are (and Parts-For) set
currency is P11. Then DML ‘OBTAIN NEXT QUANTITY WITHIN PARTS-ARE’
is executed and it encounters DB-END-OF-SET, since P11 Parts-Are set occurrence
is empty as per given data. Then program ends. So, the program does not display
parts P12 and P13.
To avoid such set currency loss and thereby wrong results, we have to store the set
currency and reestablish it later as shown in the program.
81
IDMS/R
CURRENCIES
Parts-For Set
Parts
Parts-Are Set
….-Area
Run-Unit
Quantity
Move P1 To Part-number
P1 - P1 P1 P1 P1
Obtain calc Parts
P1 Q11 Q11 Q11 Q11 Q11
Are
Find current Quantity P11 Q11 Q11 Q11 Q11 Q11
P11 Q12 Q12 Q12 Q12 Q12
Are
P12 Q13 Q13 Q13 Q13 Q13
Are
P1 Q13 P1 P1 P1 P1
Are
DB-END-
OF-SET
82
IDMS/R
Exercise:
P1 P2
P8
P5 (q3) P11 (q6) P4(q2) P7(q11) P5(q7)

P2(q9)
P4(q2) P7(q1)
P7(q11)
MAIN -PART SUB-PART QUANTITY
P1 P5 3
P1 P11 6
P1 P4 2
P2 P7 11
P8 P5 7
P8 P2 9
P11 P4 2
P11 P7 1
Fig. 9.14.
Write DML statement: -
 List all sub-parts for P8
 List all parts which consists of P5
 List all sub-parts and main parts for P2, P11
 List all parts that are not main parts
 List all parts that are only main parts
 List all parts that are main part as well as sub-part
Assignment 5: - Please refer to Lab Book.
83
IDMS/R
10. Set Membership Options

The membership option indicates the way a member record occurrence is connected to and
disconnected from a set occurrence is connected to and disconnected from a set occurrence.
It is defined in two parts. The first part is a disconnect option, which indicates the way a
record is disconnected from a set. The second part is a connect option, which indicates the
way a record is connected to a set.
10.1. Disconnect option

The disconnect option specifies whether a member record can later be disconnected
from a set once its membership has been established. Codes used to represent the
disconnect options are as follows:
 M (mandatory). With this option, the membership of a record occurrence in a set is

permanent once it is established. A record occurrence cannot be disconnected from a
set unless that record is erased from the database, as shown in figure below.
Please check up the set Emp-Emposition with this option in Appendix A.
To disconnect Empo3 from the Emp-Emposition set, we must erase the Empo3 record
from the database. Erasing Empo3 record also causes the record to be disconnected
from the set.
E1
Empo Empo
Erase Empo3:
1 3
Empo
2
E1
Fig. 10.1.
Empo
 O (optional).1 With this option, a record occurrence can be disconnected from a set,
as shown in the figure below. The record occurrence remains in the database and may
Empo
2
84
IDMS/R
be accessible in other way. For example, in Dept-Employee set, after disconnecting
one Employee record occurrence from one Department set occurrence, we might then
connect it to some other Department set occurrence, as when we are transferring a
employee from one department to another. To transfer employee E3 from D1
department to D2 department, we disconnect E3 from the set occurrence whose
owner record is D1 and connect it to the set occurrence whose owner record is D2.
D1
Disconnect E3:
E E
1 3
E
2
D1
Fig. 10.2. E
E 3
1
With the optional disconnect option, a record occurrence can be disconnected from a
set without erasing it. It can then beE later connected to some other set.
2
10.2. Connect option

The second part of the membership option indicates the type of connect option
defined for this set. A connect option specifies whether or not a member record is
automatically connected to a set occurrence when it is added to the database. Codes
used to represent the connect options are as follows:
 A (automatic). With this option, a new member record is automatically connected

to a set occurrence when it is added to the database. With the automatic connect
option, the program needs to indicate in which set the new member is to belong at the
time that it adds a new record occurrence.
 M (manual). With this option, a new member record is not automatically connected
to a set occurrence when it is added to the database. The application program must
execute an explicit connect function after it adds a new record occurrence to connect
the member record to a set occurrence.
85
IDMS/R
10.3. Bachman Diagram and Examples
Please refer to Bachman diagram of Employee database in Appendix A. The set
membership options are mentioned along with all the other set characteristics. The set
characteristics are shown by the side of the arrow representing the set.
E.g. the set Dept-Employee set has membership options as ‘OA’. The set Emp-
Expertise has membership options as ‘MA’. The first character represents the
disconnect option and the second character represents the connect option.
Examples:
MA: Mandatory / Automatic
Customer
Cust-Inv
Invoice
Fig. 10.3.
Mandatory: - Invoice occurrence cannot exist without Customer occurrence.

Automatic: - Customer must be known when invoice is created.
MM: Mandatory / Manual
Customer
Cust-Late-Paid
Invoice
Fig. 10.4.
Mandatory: - Once the invoice is late-paid, it must remain late-paid.

Manual: - Invoice when created may not be late-paid.
OA: Optional / Automatic
Customer
86
Invoice
IDMS/R
Cust-Unpaid-Inv
Fig. 10.5.
Optional: - Once the invoice is paid, it does not participate in this set occurrence.
Automatic: - All invoices are unpaid when created.
OM: Optional / Manual
Customer
Cust-Unpaid-And-Overdue-Inv
Invoice
Fig. 10.6.
Optional: - Once the invoice is paid, it is not unpaid.

Manual: - Invoice is not overdue when it is created.
Events Set Relation
Today’s date: 05-April-2002

Invoice created Does not participate in the set occurrence
Due date: 15-April-2002
On 16-April-2002
Not paid Now participating in the set occurrence
On 18-April-2002
Paid Now does not participate in the set
Occurrence
87
IDMS/R
11. DML Data Update Functions
11.1. Ready
The Ready statement performs an equivalent function as an OPEN statement for a
conventional file. It makes the required area of the database available to the
program. The syntax is as follows:
SHARED
READY <area-name> USAGE-MODE IS PROTECTED RETRIEVAL
ALL EXCLUSIVE UPDATE
This statement begins a run-unit.
The ‘Usage-Mode Is Retrieval’ clause indicates that the program will retrieve data
only and will not be allowed to execute any database modification DML
statement for the specified area.
The ‘Usage-Mode Is Update’ clause informs IDMS/R that the program intends to
update records from the specified area.
A READY statement for update can also specify additional usage mode options
that control the way in which database areas can be concurrently accessed by two
or more run units. Usage mode options for updating are discussed in the Section
13.2 on ‘Area Usage Modes’.
11.2. Store
The STORE statement is used to add a new record occurrence to the database.
Adding a new record to the database is a simple three-step process:
1. Construct the new record occurrence in the record's area in working-storage

section.
2. Establish currency within appropriate occurrences of the set types in which the
new record participates as an automatic member. We can use FIND for this
purpose, since we do not need the records to be moved to the program’s working-
storage section.
88
IDMS/R
3. Execute the store function, specifying the name of the record type we are
adding.
The syntax for the store function is simple; the only required parameter is
the name of the record type. The following STORE statement adds a new occur-
rence of the Employee record type:
STORE EMPLOYEE.
The syntax is as follows: STORE <rec-name>
However, IDMS/R must know more than the information we supply in the
STORE statement to add the new record occurrence correctly, including the
following:
 The location in the database in which the new record occurrence should be
written.
 Whether the new record should be made a member of any sets and, if so, to
which set occurrences it should be connected.
 Where in the set occurrences the new record should be inserted.
IDMS/R uses record currencies and the attributes assigned to records and sets to
obtain this information.
Determining Where to Write the New Record:
IDMS/R finds an appropriate location for a new record by examining the location
mode defined for the record type being added. If the location mode is CALC,
IDMS/R converts the CALC-key value to a database-key value and then stores the
new record as close as possible to the calculated page. If the location mode is
VIA, IDMS/R finds an optimum location for the new record based on the location
of the owner record occurrence in the VIA set type. If the location mode is
DIRECT, the program must have previously stored an appropriate database-key
value in the IDMS Communications Block. IDMS/R uses this value in finding a
place for the record.
Connecting the Record to Sets
IDMS/R next determines the set occurrences in which the new record should be a
member and where in each set to insert the record. As shown in Employee
Database, the Expertise record participates in two set types. It is an automatic
member of the Emp-Expertise set and a manual member of the Skill-Expertise set.
Before issuing a STORE, the program must establish currency within all the sets
in which the new record is an automatic member. Before storing an Expertise
record, we can establish currency within the Emp-Expertise set by accessing the
appropriate Employee record.
89
IDMS/R
IDMS/R connects the new record to an occurrence of each set for which it is an
automatic member; it does not automatically connect it to any sets in which it is a
manual member. For sets in which the record is a manual member, the program
can locate the appropriate set occurrences and issue CONNECT statements for the
record once the record has been stored. We will discuss the CONNECT statement
later.
Before connecting records to sets, IDMS/R examines the order option for the set.
Since the Emp-Expertise set is ordered DEC SORTED, each new Expertise record
occurrence is placed in the set in descending sorted order of sort-key Skill-Level-
0425.
To summarize, the STORE statement performs the following functions:
 Acquires space and a database key for a new record occurrence.
 Transfers data element values from working-storage to the database.
 Connects the new record occurrence to all sets in which it participates as an

automatic member.
Example:
Add a new occurrence in Expertise record.
Expertise record is an automatic member in Emp-Expertise and a manual member

in Skill-Expertise.
…..
FIND CALC EMPLOYEE.
IF DB-STATUS-OK
MOVE WS-SKILL-LEVEL TO SKILL-LEVEL-0425
MOVE WS-EXP-DATE TO EXPERTISE-DATE-0425
STORE EXPERTISE
PERFORM IDMS-STATUS
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘EMPLOYEE NOT FOUND’
ELSE
Eg. 11.1.
The new Expertise record will be automatically connected to the current oc-
currence of the Emp-Expertise set. The new Expertise record will not be auto-
matically connected to an occurrence of the Skill-Expertise set. We will have to
90
IDMS/R
later use a CONNECT statement to connect the Expertise record to an appropriate
occurrence of the Skill-Expertise set.
Remark: - Run unit, area, record-type and all sets in which its Connect option is
Automatic and sets in which it is an owner is affected.
11.3. Modify
Once we have readied one or more areas with one of the UPDATE usage mode
options, we can use the MODIFY statement to replace the data element values in
a record occurrence with new data element values. In modifying a record
occurrence we generally perform the following steps:
1. Execute an OBTAIN for the desired record. This establishes run-unit currency
on the record we are going to change and also places a copy of the record in
variable storage.
2. Make changes to the record by storing new data element values in working-
storage.
3. Execute the MODIFY function, naming the record type that we are modifying.
IDMS/R then replaces the data element values in the database with the new data
element values in working-storage.
There are two requirements for successful execution of the MODIFY statement:
1. We must execute a READY statement with one of the UPDATE usage mode
options for the area that contains the record we are modifying.
2. We must issue an OBTAIN for the record we are updating before we execute
the MODIFY statement.
The syntax is as follows: MODIFY <rec-name>
Example:
Modify address and phone-number for a given employee.

IF DB-STATUS-OK
MOVE WS-ADDRESS TO EMP-ADDRESS-0415
MOVE WS-PHONE TO EMP-PHONE-0415
MODIFY EMPLOYEE
PERFORM IDMS-STATUS
ELSE
91
IDMS/R
IF DB-REC-NOT-FOUND
ELSE
Eg. 11.2.
Remark: - After successful execution, object record becomes current of the run
unit, all sets in which it participates, its record type and area currencies are
affected.
11.4. Erase
This is used to delete a record occurrence from database.
The Modify and Store functions are fairly straight-forward; they each operate on a
single record occurrence. When we use the erase function, however, the ERASE
often affects not only the record that is the object of the ERASE statement but
also, in some cases, members of sets owned by that record.
The options with Erase statement are as follows:
PERMANENT
ERASE <rec-name> SELECTIVE MEMBERS
ALL
The ERASE statement with no member option is straightforward. We begin by

retrieving the record we want to erase, making it current of run unit. We then
issue an ERASE, naming the record type. IDMS/R first disconnects the record
from any sets in which it participates as a member, then removes the record
occurrence from the database. If the record we are erasing is the owner of any
sets, the record will be erased only if those sets are empty. If we try to erase an
owner record of a nonempty set, IDMS/R returns an error status code value.
Example:
Delete Employee record occurrence for a given employee-id.

IF DB-STATUS-OK
ERASE EMPLOYEE
PERFORM IDMS-STATUS
ELSE
IF DB-REC-NOT-FOUND
92
IDMS/R
ELSE
Eg. 11.3.
Notice that, in this case, we did not specify a member option in the ERASE. This
means that the Employee record occurrence will only be erased if it is the owner
of an empty set occurrence. We must use one of the other three ERASE options if
we want to erase an owner of one or more nonempty sets.
The ERASE ALL Option
Using ERASE ALL first causes the object record to be removed from the data-
base. Then all its members, both mandatory and optional, will be removed,
whether or not they are members in other set occurrences. If we execute an
ERASE ALL for an Employee record, IDMS/R also removes all its member
records, along with all their members.
The ERASE PERMANENT Option
With the other two ERASE options, the members that are automatically erased
depend on whether the members participate in other sets and what the set dis-
connect options are.
When we use ERASE PERMANENT, IDMS/R erases the record that is the object
of the ERASE. It also erases all mandatory members all sets owned by the object
record. It does not erase optional members; it disconnects them instead. If an
erased member is the owner of any sets, it is treated as if an ERASE
PERMANENT were issued for it. Its mandatory members will be erased, and its
optional members disconnected. This process continues until all members have
been processed.
The ERASE SELECTIVE Option
An ERASE SELECTIVE always erases the record that is the object of the
ERASE, and it always erases mandatory members in all sets owned by the object
record. It also erases optional members if they do not participate in any other sets.
If the erased member is the owner of any sets, it is treated as if an ERASE
SELECTIVE were issued for it. Its mandatory members will be erased, and its
optional members will be erased if they do not participate in any other sets.
Remark: - Run unit and area currencies remain unchanged. It nullifies current
pointers for:
- All record types involved in Erase
- All sets in which the erased record participates
93
IDMS/R
11.5. Connect
It is used to establish a record occurrence as a member in a set occurrence.
CONNECT <record-name> TO <set-name>.
The CONNECT function can be used in conjunction with STORE for records that
must be manually connected to sets. CONNECT connects the record that is
current of run unit to the named set.
The CONNECT statement names both a record type and a set type. The
CONNECT function causes the record that is current of the named record type to
be connected to the set occurrence that is current of the named set type.
Membership option must not be MA (mandatory automatic). All areas affected
must be readied in UPDATE usage mode.
Example:
Assumption: The Coverage record is a manual member of the Emp-Coverage set.
…..
IF DB-STATUS-OK
MOVE WS-SELN-DATE TO SELECTION-DATE-0400
MOVE WS-TERM-DATE TO TERMINATION-DATE-0400
MOVE WS-TYPE TO TYPE-0400
MOVE WS-PLAN-CODE TO INS-PLAN-CODE-0400
STORE COVERAGE
PERFORM IDMS-STATUS
CONNECT COVERAGE TO EMP-COVERAGE
PERFORM IDMS-STATUS
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘EMP-ID NOT FOUND’
ELSE
Eg. 11.4.
Remark: - On successful Connect, the set currency will become current of record
occurrence just connected.
11.6. Disconnect
94
IDMS/R
It is used to disconnect a record occurrence from a set occurrence of which it is a
member.
DISCONNECT <rec-name> FROM <set-name>.
The DISCONNECT statement removes the record occurrence that is current of

run unit from the named set.
The DISCONNECT statement cancels the membership of a record occurrence in

a set occurrence in which it currently participates as a member. The record that is
the object of a DISCONNECT function must be defined as an optional member of
that set. Otherwise, IDMS/R returns an error status code. All areas affected must
be readied in UPDATE usage mode.
The DISCONNECT and CONNECT functions are also often used together to
move a record occurrence from one set occurrence to another.
Example:
Transfer a given employee to another given department.
…..
IF DB-STATUS-OK
PERFORM 2000-TRANSFER
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘EMP-ID NOT FOUND’
ELSE
….
…..
2000-TRANSFER.
DISCONNECT EMPLOYEE FROM DEPT-EMPLOYEE.
IF DB-STATUS-OK
PERFORM 3000-CONNECT.
……
……
3000-CONNECT.
CONNECT EMPLOYEE TO DEPT-EMPLOYEE.
Eg. 11.5.
DML Statement Execution Steps:
95
IDMS/R
Please refer to Section 3.7 for the steps that are involved in the execution of a DML
statement.
96
IDMS/R
12. Recovery and Restart

IDMS/R provides the facilities for recovering from problem situations and for restarting
after failures occur. These facilities include procedures that IDMS/R automatically invokes
when certain types of failures occur and also services that application programs use to
handle restart and recovery.
12.1. IDMS/R Operating Environments

It is possible to run an IDMS/R application program in two operating
environments: local mode or central version. All online applications that use
IDMS/DC or some other telecommunications monitor to control access to remote
terminals 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.
The mode in which a particular application program is run is generally chosen by
the DBA group and is not of concern to the application developer. However, the
mode in which the application executes determines the restart and recovery
facilities that are available to it.
Central Version
In most situations, the preferred method of running an IDMS/R application is

under the control of IDMS/R central version. With central version, a single copy
of the IDMS/R DBMS controls the operation of a particular set of IDMS/R
application program run units. With central version, a single DMCL module
(which maps logical database areas into physical files in DASD) defines all
database areas that will be accessed by all the run units that will execute under a
particular IDMS/R central version. Multiple copies of IDMS/R central version
can execute in the same computing system with each copy normally accessing a
different set of database areas; no two central versions are allowed to update the
same database area. All the run units that will execute under the control of a
particular central version are chosen so that they all access the same group of
database areas. Central version implements facilities for recovering from system
failures and for automatically restarting aborted run units.
Local Mode
A batch program that operates in local mode has its own copy of the IDMS/R
DBMS loaded into its address space. A local mode run unit operates
independently of any other IDMS/R run units that may be operating in the system
at the same time. In general, an application runs faster when run in local mode,
but IDMS/R provides no automatic restart and recovery facilities for local mode
97
IDMS/R
applications. Batch retrieval programs are good candidates for running in local
mode, since they do not ordinarily require automatic restart and recovery
facilities.
12.2. Journal Files, Checkpoints

IDMS/R maintains a set of journal files that can be used to recover from failures
and to restart aborted run units. An IDMS/R application can choose to write the
journal files to direct access data sets, to tape tiles, or to ignore completely the
journaling facility. IDMS/R provides automatic restart and recovery facilities only
for run units that operate under the control of central version, and then only when
the run unit writes the journal files to direct access data sets. Applications, either
central version or local mode, that write tape journal files can use the journal files
to restart manually an aborted run unit. Applications that bypass the journaling
facilities are responsible for their own restart processing.
When a run unit begins by issuing the BIND RUN-UNIT statement, IDMS/R
writes a begin checkpoint record on a journal file. A checkpoint record contains
information about the current status of the run unit. As a run unit executes, it may
update records in the database. As IDMS/R processes each update request, it
writes to the journal file a before image and an after image of the updated record.
When the application ends the run unit by executing a FINISH statement,
IDMS/R writes out an end checkpoint record. At the conclusion of the run unit,
the journal file contains begin checkpoint, before and after images of all updated
records, and an end checkpoint.
Journal File
Begin Checkpoint Before After … … End Checkpoint
image image (FINISH)
Start of run unit of updated record ………
12.3. Recovery / Restart

There are many types of situations that may require recovery and restart
processing. A program may cause an error that causes the run unit to be
abnormally terminated. IDMS/R may also encounter situations that require it to
terminate abnormally one or more run units. For example, IDMS/R may terminate
a run unit after a wait time limit has been exceeded to prevent deadlocks from
occurring. If a run unit is abnormally terminated after it has updated one or more
database records, IDMS/R works backward in the journal file until it reaches the
begin checkpoint record and uses the information in the before record images to
98
IDMS/R
reverse the effect of the database updates already made by aborted run unit. The
run unit can then be restarted from the beginning.
15
Journal File 17
Begin Before After Checkpoint:
Checkpoint: image image Abnormal
Start of RU 15 17 termination
17
Journal File 15
Begin Before After Checkpoint:
Checkpoint: image image Abnormal
Fig. 12.1.
12.4. Commit
All run units that terminate normally create at least two checkpoint records on the
journal file, a begin checkpoint when the READY statement is executed and an
end checkpoint when the FINISH statement is executed. The before and after
record images that are recorded between these two checkpoints constitute a record
of all the updating the run unit performed. The processing that a unit performs
between checkpoints is called a recovery unit. In the simplest case, the entire run
unit constitutes a single recovery unit. Many online applications operate in this
manner. A separate run unit may be started to process each incoming transaction.
In such a case, no more than a few database updates are processed during the
execution of each run unit, and each run unit constitutes a single recovery unit.
In some situations, a single online run unit may process many transactions and
perform many database updates. Batch applications are even more likely to make
a great many updates during the execution of a single run unit. In such situations,
it is often necessary to divide a run unit into multiple recovery units to reduce the
time that it takes to recover from a run unit failure. To create intermediate
checkpoints, the run unit periodically issues a COMMIT statement to make
permanent all database updates that the run unit has already made: COMMIT.
Another form of the COMMIT statement is: COMMIT ALL.
99
IDMS/R
The COMMIT statement causes IDMS/R to release all locks except for those that
are placed on current records; COMMIT ALL releases all record locks.
Both forms of the COMMIT statement cause IDVIS/R to write a commit

checkpoint on the journal file. If the run unit is later abnormally terminated after it
has issued a COMMIT statement, IDMS/R again works backward in the journal
file and uses the information in the before record images to reverse the effect of
changes that the run unit made. This time, however, IDMS/R stops at the commit
checkpoint rather than proceeding all the way back to the begin checkpoint that
was written when the run unit began. Now, when the run unit is restarted, it can
be restarted from the point at which it wrote the most recent commit checkpoint.
Many different techniques can be used for determining how often a COMMIT
statement should be executed. One simple technique is simply to count the
number of updates the run unit processes. Every one hundred updates or so, the
run unit might issue a COMMIT statement, causing IDMS/R to write an inter-
mediate checkpoint to the journal file.
15
Journal File 17
Begin Before After Checkpoint: Checkpoint:
Checkpoint: image image Commit Abnormal
17
Journal File
Begin Before After Checkpoint: Checkpoint:
Checkpoint: image image Commit Abnormal
Fig. 12.2.
12.5. Recovering From Failures

If the run unit is operating under the control of central version and is writing the
journal files to direct access data sets, IDMS/R handles all the processing that is
necessary to roll back database changes and to restart run units that it aborts. No
special application programming is necessary to invoke the automatic recovery
and restart facilities in the central version environment with journal files written
to direct access data sets.
100
IDMS/R
In the local mode environment and in the central version environment with tapes
journal files, IDMS/R provides utility programs to handle manual restarting of
aborted applications.
Suppose a batch application is reading transactions from a sequential transaction

file and processing database updates based on the data read from the transaction
file. The application issues a COMMIT statement to write a commit checkpoint
every few hundred updates. Suppose the application now fails. A utility program
can be run that backs out the changes that the program made up to the previous
commit checkpoint that the aborted run unit wrote to the journal file. To restart
the run unit, the run unit must contain application logic that will reposition the
transaction file at the appropriate point so the run unit will reapply the changes
that were backed out. It may also need to reestablish the appropriate positions
within the database to resume processing at the appropriate point in the database.
12.6. Rollback
In some cases, a program may itself determine during program processing that it
needs to back out the changes that it has made to the database since it wrote the
most recent checkpoint record. In the central version environment with journal
files written to direct access data sets, the program can request that IDMS/R do
this automatically by simply abnormally terminating the run unit.
If we would like to back out the changes but not abend the run unit, we can issue
a ROLLBACK statement. There are two formats of ROLLBACK statement as
given below.
ROLLBACK.
This form of the ROLLBACK statement causes IDMS/R to write a checkpoint

record to the journal file, nullify all currencies, automatically restore the database
using the before images from the journal, and terminate the run unit. After issuing
this form of ROLLBACK, to access the database again, we must reissue the
BIND/READY sequence.
ROLLBACK CONTINUE.
If we issue this statement, IDMSIR restores the database but does not terminate
the run unit. We may now access the database immediately without reissuing the
BIND/READY sequence.
101
IDMS/R
13. Locking
IDMSIR provides locking facilities for controlling access to areas and to individual records
when two or more run units require access to the same database areas. IDMS/R provides
three levels of locks: Area locks, Area usage modes, and record locks.
13.1. Area Locks

IDMS/R uses area locks to prevent areas from being updated by more than one
IDMS/R central version or by more than one application running in local mode. This
lock works at operating environment level, i.e. at central version level and local mode
application level.
If an area lock is already set on an area that is required by a local mode application,
that local mode application abends; otherwise the local mode application locks those
areas, and no other local mode application or IDMS/R central version will be given
access to those areas. An area lock is released by FINISH statement of the local mode
application.
If an area lock is already set on an area that is required by an IDMS/R central version,
the execution of that central version continues with no access to those areas for the
run units of the CV. 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. If
all required areas are available, then CV locks those and are available to all run units
of that CV. No other local mode application or CV will be given access to locked
areas. An area that is locked by a particular CV is released only when the central
version is shut down or when the area is varied offline.
13.2. Area Usage Modes

All the run units that operate under the control of a particular IDMS/R central
version can access the same set of database areas. In the central version environment,
IDMS/R provides area usage mode options to control the concurrent access of
database areas by different run units. The area usage mode option is specified with
READY statement. Please refer to Section 12.1 for READY statement.
102
IDMS/R
SHARED
READY <area-name> USAGE-MODE IS PROTECTED RETRIEVAL
ALL EXCLUSIVE UPDATE
There are six usage modes as follows.
 Usage mode is RETRIEVAL. With the RETRIEVAL or SHARED

RETRIEVAL usage modes, we are requesting retrieval access to the area, and we
are specifying that other run units of our CV will also be allowed to retrieve or
update records in the same area.
 Usage mode is PROTECTED RETRIEVAL. With the PROTECTED RE-

TRIEVAL usage mode, we are requesting retrieval access to the area, and we are
specifying that no other run unit should update the records in the same area for the
duration of our run unit. However, other run units of our CV can retrieve the
records in the area as long as they did not specify a usage mode of EXCLUSIVE
for the same area. If another run unit is already updating the records in the
area, our run unit will wait until that run unit finishes.
 Usage mode is EXCLUSIVE RETRIEVAL. With the EXCLUSIVE RE-

TRIEVAL usage mode, we are requesting retrieval access, and we are specifying
that no other run unit be allowed to retrieve or update records in the area while
our run unit executes. If other run units are already accessing the area, our run
unit will wait until all other run units finish with the area. This usage mode is not
often used.
 Usage mode is UPDATE. With the UPDATE usage mode option, also called
shared update mode, we are requesting update access to the area, and we are
specifying that other run units also be allowed to retrieve or update records in the
area as long as they do not specify the PROTECTED or EXCLUSIVE options in
their READY statements.
 Usage mode is PROTECTED UPDATE. With the PROTECTED UPDATE

usage mode option, we are requesting update access to the area, and we are
specifying that no other run unit should be able to update records while our run
unit executes. Other run units may also be allowed to retrieve records in the same
area or areas as long as they do not specify the PROTECTED or EXCLUSIVE
usage mode options. If another run unit is already updating the records in the area,
or if other run units are accessing the area with the PROTECTED RETRIEVAL
or EXCLUSIVE RETRIEVAL usage mode, our run unit will wait until all other
run units finish with the area.
 Usage mode is EXCLUSIVE UPDATE. With the EXCLUSIVE UPDATE

usage mode option, we are requesting update access to the area, and we are
specifying that no other run unit should either retrieve or update records in the
103
IDMS/R
area while our run unit executes. This essentially gives the run unit exclusive
use of the area.
13.3. Record Locks – Implicit, Explicit

Preventing other run units from accessing the same areas can cause system wide
performance problems. When we use usage mode options that allow more than one
run unit to access the same area while updating is taking place, IDMS/R sets implicit
record locks to prevent the same record from being concurrently updated by two or
more run units. Implicit record locks are only maintained for run units operating
under central version. Central version always maintains record locks for run units
executing in shared update mode. Record locks are never maintained for run units
operating in local mode. In local mode, concurrent updates are prevented by setting
locks on entire areas.
Implicit record locks:
There are two types of implicit record locks: implicitshared record locks and implicit
exclusive record locks.
An implicit shared record lock is used to guarantee that only one run unit at a time
will be allowed to update a specific record occurrence; any number of run units will
be allowed to retrieve a record protected by a shared record lock. An implicit
exclusive record lock is used to guarantee that no other run unit can either update or
retrieve the record while the exclusive lock is in effect.
Implicit locks are placed on records as they are made current of run unit, record type,
set type, and area. An implicit shared lock is placed on a record when it is retrieved,
and an implicit exclusive lock is placed on a record when it is accessed via update
DML functions. In this way, IDMS/R guarantees that only one run unit at a time will
be allowed to access a record that is being updated, but that any number of run units
will be allowed to retrieve a given record.
Implicit shared locks remain in effect until currency changes; implicit exclusive locks
remain in effect until the run unit ends or until the run unit executes a COMMIT
statement.
Implicit lock example:
Two users are trying to update the same Employee record occurrence.
Run Unit 1 Run Unit 2
104
IDMS/R
Retrieve E1
E1 E1
Implicit shared lock

1. Run unit 1 retrieves the Employee record for E1. IDMS/R places an implicit
shared lock on the E1 record.
Retrieve E1
E1 E1 E1
Implicit shared lock

2. Run unit 2 retrieves the Employee record for E1. Since a shared lock does not
prevent other run units from accessing a record, IDMS/R gives the record to run
unit 2. IDMS/R places another shared record lock on the E1 record on behalf of
run unit 2.
Modify E1
E1 E1
3. Run unit 1 issues a MODIFY function to change address for E1. Since run unit
2 has placed a shared lock on the record, run unit 1 is not allowed to update the
record. Run unit 1 waits.
Wait Modify E1
E1 E1 E1
4. Run unit 2 issues a MODIFY function to change address for E1. Since run unit
1 has also locked the record, run unit 2 also waits.
Retrieve E1 Wait
E1 E1 E1
105
IDMS/R
5. Since each run unit is now waiting for a record that the other run unit locked, a
deadlock has occurred.
..
.. Abend
Deadlock Detected
6. Sensing a deadlock, IDMS/R automatically abends run unit 2 to recover.
Retrieve E1
E1 E1
E1 Modified
Implicit Exclusive Lock
7. The lock set by run unit 2 is now removed, the MODIFY issued by run unit 1 is
allowed to complete, and IDMS/R sets an implicit exclusive lock on the record
until run unit 1 ends.
Eg. 13.1.
In a high volume application such as an airline reservation system, abnormally

terminating a run unit would be an inefficient method of handling a common res-
ervation system problem: contention for the same seat. Explicit locks provide a better
way of handling the same situation.
Explicit record locks:
To set an explicit record lock, code the KEEP clause in the DML statement that is
used to retrieve the record. Following are two examples of CALC retrievals during
which locks are set on the retrieved Employee record.
Shared lock: OBTAIN KEEP CALC EMPLOYEE.
Exclusive lock: OBTAIN KEEP EXCLUSIVE CALC EMPLOYEE.
In either case, the lock remains set until we either end the run unit by executing the
FINISH statement or we execute a COMMIT statement.
We can issue a separate KEEP statement to set an explicit lock on a record after
retrieving it.
106
IDMS/R
Explicit lock example:
Run Unit 1 Run Unit 2
Retrieve E1
E1 E1
1.Run unit 1 retrieves the Employee record.
Issue KEEP EXCLUSIVE

CURRENT statement
E1
E1
Explicit Exclusive Lock
2.Run unit 1 places an explicit exclusive lock on the Employee record just
retrieved.
Attempt to
retrieve E1
E1
3.Run unit 2 attempts to retrieve the record.
Wait
E1
4.Since run unit 1 has already placed an exclusive lock on the E1 record, run unit
2 waits.
Modify E1
E1 E1 Wait
5.Run unit 1 issues a MODIFY to update address information for the E1 record.
107
IDMS/R
End Run Unit E1 Wait
Lock Released
6.Run unit 1 issues a FINISH, and IDMS/R releases the lock on the E1 record.
Record
Retrieved
E1 E1
7.Run unit 2 is now allowed to retrieve the E1 record. Now that the address has
been updated, the user 2 will see the record with the latest address information.
Eg. 13.2.
108
IDMS/R
14. Utilities
14.1. DMLO
DMLO stands for DML-Online.
Please refer to Lab Book Appendix A.
In DMLO, you can access one DB-record at a time.
Steps to invoke DMLO for Employee Database (Training Dept):
 On CCS screen, type ccscv24t <Enter>.

 On ‘Enter next task code’ prompt, type following:
signon IBM-id password

dcuf set dictname patni
dcuf set dbname patni
dmlo
 On the first screen of DMLO:
select mode as R (for retrieval mode)

type subschema-name, schema-name, ver
 On the next screen of DMLO at the bottom:
Type various retrieval DMLs.
E.g.:
Display department <Enter>
This will display record layout of Department.

Enter the value for Dept-Id-0410. Then type following DML:
Obtain calc department <Enter>.
This will display department occurrence for the give id, if exists. Otherwise, it
will display error message as ‘db-rec-not-found’ and the value of Error-Status
field as well.
109
IDMS/R
 At the end, to come out of DMLO, type following:
Finish nosave <Enter>.
 To get back to CCS screen, type following:
Bye (Type ‘bye’ again if required).
If you want to make any updation in the database, then do following:
On the first screen of DMLO, type mode as U (for Update mode)

To come out of DMLO, type Finish save.
14.2. OLQ
OLQ stands for On-Line Query.
Please refer to Lab Book Appendix B.
In OLQ, you can generate a report as per the specifications. There are two types
of OLQ sessions: Online and Batch.
First 3 steps are same as that of DMLO, i.e. upto setting the environment for DB
and dictionary. After that, type OLQ.
On the first screen:

Type ‘menu’ at the top left corner
On the next screen:

Select subschema with any non-blank character
Next screen:
Select from the given record types
Next screen:
Select the required elements of the selected record types as columns of the
report.
Note: - Everywhere selection should be done with nonblank character.
Next:
110
IDMS/R
Give the required attributes i.e. change headers, sort on columns etc.
On continue processing, mark NO as an active option.
Following are some of the toggle commands:
rec - to go to the record type selection screen

ret - to go to the continue processing screen
Esc 3 or PF3 key - to take you back to the 1st screen
PF7 key - to take you to the previous screen
PF8 key - to take you one screen forward
111
IDMS/R
15. Appendix A: Employee Database

The diagram is shown on next page.
112
IDMS/R
113
IDMS/R
114
IDMS/R
115
IDMS/R
116
IDMS/R
117
IDMS/R
118
IDMS/R
119
IDMS/R
120
IDMS/R
121
IDMS/R
122
IDMS/R
123
IDMS/R
124
IDMS/R
125
IDMS/R
126
IDMS/R
127
IDMS/R
128
IDMS/R
129
IDMS/R
130
IDMS/R
131
IDMS/R
//SYSPCH DD DSN=&&DMLOUT,
// UNIT=&UTUNIT,
// DISP=(NEW,PASS),
// SPACE=(TRK,(5,5))
//SYSIPT DD DSN=DA0000T.SUDHIR.COBOL(IDMST1),DISP=SHR
//* +-----------------------------------------------------------------+
//* | COMPILE THE TRANSLATED COBOL PROGRAM |
//* +-----------------------------------------------------------------+
//COB EXEC PGM=IKFCBL00,REGION=&CREG,
// PARM='&CPARM',COND=(5,LT,DML)
//SYSPRINT DD &PRT
//SYSLIB DD DSN=SYS1.COBCOMP,DISP=SHR
//SYSUT1 DD UNIT=&UTUNIT,SPACE=(CYL,(4,1))
//SYSLIN DD DSN=&&OBJ,DISP=(MOD,PASS),UNIT=&UTUNIT,
// SPACE=(TRK,(40,40))
//SYSIN DD DSN=&&DMLOUT,DISP=(OLD,DELETE)
//* +-----------------------------------------------------------------+
//* | LINK EDIT THE COMPILED PROGRAM |
//* +-----------------------------------------------------------------+
//LKED EXEC PGM=IEWL,PARM='&LPARM',
// COND=((5,LT,DML),(5,LT,COB)),REGION=&LREG
//SYSLIN DD DSN=&&OBJ,DISP=(OLD,DELETE)
// DD DDNAME=SYSIN
//SYSLIB DD DSN=SYS1.COBLIB,DISP=SHR
// DD DSN=SYS5.IDMS.&CV..LOADLIB,DISP=SHR
// DD DSN=SYS5.IDMS.&CV..BASELOAD,DISP=SHR
// DD DDNAME=USERLIB
//SYSIN DD DSN=SYSZ.IDMS.CCS.CARDLIB(&MODE.C),DISP=SHR
//USERLIB DD DSN=SYS5.IDMS.&CV..LOADLIB,DISP=SHR
//SYSLMOD DD DSN=DA0000T.SUDHIR.LOADLIB(IDMST1),DISP=OLD
//SYSUT1 DD UNIT=&UTUNIT,SPACE=(1024,(50,20))
//SYSPRINT DD &PRT
// PEND
//STEP1 EXEC IDMSDMLC
//SYSIDMS DD *
DICTNAME=PATNI
DBNAME=PATNI
ECHO=ON
DMCL=IDMSDMCL
JOURNAL=OFF
132
IDMS/R
Run JCL: -
//DA0000TA JOB LA2719,'PRASANNA',NOTIFY=DA0000T,

// CLASS=A,MSGCLASS=X,REGION=0M,TIME=(0,1)
//*
//STEP020 EXEC PGM=IDMST1
//STEPLIB DD DSN=DA0000T.SUDHIR.LOADLIB,DISP=SHR
// DD DSN=SYS5.IDMS.CV24T.BASELOAD,DISP=SHR
// DD DSN=SYS5.IDMS.CV24T.LOADLIB,DISP=SHR
//SYSCTL DD DSN=SYS5.IDMS.CV24T.SYSCTL,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
2222
/*
//SYSOUT DD SYSOUT=*
//SYSIDMS DD *
ECHO=ON
DBNAME=PATNI
JOURNAL=OFF
/*
133
IDMS/R
17. Appendix C: IDMS/R ERROR-STATUS

VALUES
MAJOR CODES
Code Database Function

00 Any DML statement
01 FINISH
02 ERASE
03 FIND/OBTAIN
05 GET
06 KEEP
07 CONNECT
08 MODIFY
09 READY
11 DISCONNECT
12 STORE
14 BIND
15 ACCEPT
16 IF
17 RETURN
18 COMMIT
19 ROLLBACK
20 LRF request
134
IDMS/R
MINOR CODES
00 If major code 00, indicates successful completion; if nonzero, indicates unsuccessful

completion due to problems related to CV
01 Area not readied: OR IF operation determined that set not empty or current record of run
unit not a member of set
02 Db-Key used with a FIND/OBTAIN DBKEY, or direct db-key on a STORE, not within
page range for specified record
04 Occurs-depending-on value negative or exceeds maximum; OR zero is sequence number
for FIND/OBTAIN sequence-vn WITHIN SET/AREA
05 Execution of DML function would violate duplicates-not-allowed restriction
06 Currency not established for object record, set, or area
07 End of a set, area, or index set reached; OR set empty
08 Object record, set, procedure, or LR verb not in subschema; OR object record not
member of object set
09 Area readied for retrieval, but DML issued requires update usage mode
10 Access restriction or subschema USAGE restriction prevents execution of requested
DML; for SPF users, may indicate improper use of an ERASE
11 Record not stored because of insufficient space in area
13 Run-unit currency not established or nullified by a previous ERASE.

14 CONNECT not executed because object record defined as mandatory automatic
member of set
15 DISCONNECT not executed because object record defined as mandatory member of set
16 Record already member of set
18 Record not bound
20 Current record of run unit not the same type as specified record
21 Not all areas being updated were readied in update usage mode; OR not all
records, sets and areas affected are in subschema
22 Named record not currently member of named set
23 Named area not in subschema
25 Currency not established for object set
26 Record or SPF index entry not found; OR no more duplicates exists for object record
28 Run unit attempted to ready a previously readied area
29 DB-Key KEEP deadlock
30 Attempt made to erase owner of nonempty set
31 Retrieval statement’s format conflicts with record’s location mode
32 CALC field value in variable storage not equal to CALC control element value in current
record of record type
33 One or more sets in which the record participates not in subschema
135
IDMS/R
40 WHERE clause in OBTAIN NEXT logical record inconsistent with previous

OBTAIN FIRST or NEXT for same logical record
41 Subschema contains no path to match logical record request’s WHERE clause
42 Error occurred in processing logical record path
43 Bad or inconsistent data in the logical record’s variable storage location, or in request’s
or path’s WEHRE clause
44 Logical record request’s WHERE clause did not supply a key element expected by path
45 Subscript value in logical record request’s WHERE clause invalid
46 Arithmetic program check would occur in evaluation of logical record request’s
WHERE clause
55 Invalid length defined for variable-length record
56 Insufficient memory available for IDMS compression/decompression routines
60 Record type inconsistent with set named in error set field of the IDMS
Communications Block
61 No record found for pointer db-key
63 DBMS could not interpret DML function
64 CALC control element not described properly
65 Database page read not page requested
66 Area specified not available for update
67 Subschema invoked does not match subschema object tables

68 CICS interface (IDMSINTC) was not started
69 Run unit not bound to DBMS
70 Database or journal file would not open properly
71 Page range for area being readied or page requested not in DMCL
72 Insufficient memory available for load or storage allocation
73 New central vision run unit would exceed MAXERUS value specified at CV
generation
74 Dynamic load of module failed
75 Read error
76 Write error
77 Run unit not bound or bound twice
78 Area wait deadlock
79 Run unit requested more db-keys locks than available to system
80 Target node not active or disconnected from DDS configuration
81 Database name specified not known
82 Subschema not allowed under specified database
83 Error was made in use of native VSAM datasets
136
IDMS/R
18. Appendix D: References

 Manual: - IDMS-DB / DC Programmer’s Guide
 IDMS/R A Professional’s Guide to Concepts, Design and Programming
By Larry E. Towner
 IDMS/R Concepts, Design and Programming
By James Martin, Richard Derer, Joe Leben
137

IDMS Mat

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IDMS Mat

Uploaded by

Copyright:

Available Formats

IDMS/R

1.1. IDMS/R and DBMS

A DBMS is a software subsystem that manages a collection of interrelated data

Components of IDMS/R work around a central software subsystem called IDD

1.2. Database Approach

1.2.1. Data Integrity

Reducing / eliminating data redundancy: - There is no duplication of

Recovery and Restart: - A database management system provides powerful tools

Simplified Programming: - In a program that uses conventional files, much of

Reduced Maintenance: - The application programs using conventional files are

These two things increase programmer productivity.

1.3. Different Database Architectures

Relational model supports one-to-many and many-to-many links. But, Network

To illustrate the implementation of the Network model, suppose the Dept-

Consider another example given below about chain pointers.

Address Sub-Id Sub-Name First Last

Address Course-Id Course-Name Next Prior Owner

1.4. IDMS/R: - Network and Relational Facilities, DBMS

Network structured databases can be used to handle high volume transaction

IDMS/R uses a software subsystem called Automatic System Facility (ASF) to

2. Logical Database Structure

2.1. Entity, Logical and Physical Structure

2.2. Attributes, Relationships – Training Database

The database will store information about the following entities.

Faculty: - Information about faculties in Training department

An attribute is a particular piece of information that is associated with an entity. E.g.,

2.3. Entity-Relationship Diagrams

An entity-relationship diagram for Training Department information is given below.

2.4. IDMS Database Records, Record Type, Record Occurrences

Record Types Vs. Record Occurrences: - There is a clear distinction between a

Subject Record Type

Subject Record Occurrences

S003 VSAM IBM

S004 IDMS IBM

2.5. One-To-Many and Many-To-Many Relationships

The junction record type is described in more details in Section 9.2.

2.6. IDMS Set, Set Type, Set Occurrence, Bubble Diagram

Also, please refer to Employee Database in Appendix A.

Set Type Vs. Set Occurrence:

As with record types and record occurrences, there is an important distinction

A specific occurrence of the set Faculty-Course is shown in a diagram given below. It

Following is another example of bubble diagram.

CO701 C1001 CO702 C1002

2.7. Schema, Subschema

Subschema: - In real-world systems, most application programs do not require access

E.g. In a big manufacturing company, there would be a different subschema for

An application program always accesses the database by referring to a subschema. So

3. IDMS/R Batch Program

3.1. Operating Environment

In an IDMS/R application program, there are no file description statements or OPEN

3.2. DML Statements: Executable and Compiler Directive

Some DML statements are compiler-directive statements. Compiler-directive

3.3. Three Steps Compilation: DML Pre-processor, Compilation

DML Processor Errors

3.4. Compiled Listing of Sample IDMS/R Program

Explanation of sample IDMS/R program:

The Identification Division of the IDMS/R program is similar to that of a

In addition to the normal INPUT-OUPUT section, the Environment division contains

The PROTOCOL statement is a compiler-directive statement that specifies the

The remaining DATA division sections are similar to those of a conventional

As in a conventional application program, the Procedure division defines the

BIND statements are required for database access.