Introduction

TITLE

IDMS/
R

Overview
IDMS is a network database.
A network data model is regarded as an extension of hierarchical model. The
principle difference between the two is that in a hierarchic model, a child is
associated with only one type of parent record, whereas in a network model it can
be associated with many types.
A network database consists of records, which actually hold information as a set of
links between records, which form relationships.

Overview
IDMS (Integrated Data Management System) was developed by Cullinet Software
Inc. It was enhanced and is currently supported by Computer Associates (CA).
Initially IDMS was developed to run on IBM mainframes, however of late, versions
for other environments have also been developed.
IDMS centralizes the data used by an organization but does not prevent data from
being arranged in different ways to suit different applications. All data records are
treated as members of one cohesive storage facility, i.e. the database.
The database contains a single definition for each data record. Records are
connected in different logical groups called Sets, expressing various arrangements
between records as required by applications

Page

Database is subdivided into number of pages.

Smallest unit of data transfer between auxiliary and main memory
Page size is typically 2k or 4k bytes
Record occurrences are stored in pages
Each page has a unique page number
Each record within the page has a unique line number

Areas

Pages in the database are grouped into areas

Pages in an area are sequentially numbered
Gaps in page numbers can occur between areas
A page can belong to one and only one area
All pages of an area are of the same size

Record type

A Record type is the structural component that conveys the format in which records are stored.
Record type is a generic group of similar record occurrences that would exist in the database.

Record Occurrence

A Record occurrence is the actual content of data that is stored; it can be thought as the substance of information stored in
the database.
Record occurrence is the basic addressable unit of data under IDMS database.
Record occurrences are always related to a specific Record type, and reside in pages.
Each record occurrence can be fixed or variable in length.
A record occurrence is further subdivided into fields or data elements based on its structure.

DBKEY
Database key or DBKEY is a unique identifier for each record occurrence
within the database. DBKEY comprises of two components Page number and
Line number within a page.

DBKEY of a record occurrence does not change as long as the occurrence

exists in the database.

Each record occurrence has two components: Prefix and Data:

The Prefix consists of pointers such as those pointing to the NEXT, PRIOR
and OWNER record. Each pointer is in form of a DBKEY. The pointer refers to
physical location of another record occurrence that is related to the one
containing the pointer.

The Data is the set of bytes that represents the record value; it may have
some internal structure that is defined by the application developer

Location Mode

The assignment of record to a particular page in its area is determined by the location mode.
CALC

record stored on or near a page calculated by IDMS

retrieval of record based on symbolic key value
IDMS converts symbolic key into record address
Can have duplicates clause as DF/DL/DN
OBTAIN CALC <Record-Type-Name>.
Move 0657 to dept-key
Obtain CALC dept

Location Mode

VIA

cluster member records with their respective owners

minimize disk accesses needed to retrieve members
groups records that are likely to be retrieved at the same time
DIRECT

Records are retrieved using DB-Key

DB-Key
Each record occurrence is assigned a unique numeric identifier, called its database key (dbkey). Format of db-key is shown below.
A record occurrences 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)

0 1 Database Page Number

23 24 Line Number

31

Sets
A Set expresses relationships or association between two record types, where one is the super
ordinate and other is the sub ordinate.

The super ordinate record type is called the OWNER record and the subordinate record type is called
the MEMBER record.

A set associates one owner record occurrence with one or more member record occurrences; it
establishes a one-to-many relationship.
A Set Type defines the structural components of a set, or the attributes of a set.

A Set Occurrence comprises of an owner record occurrence along with its associated member record
occurrences.

There exists one set occurrence for each owner record occurrence.

In case of a NULL set, an owner record may be the only one in the set occurrence if it does not have
any associated member records.

Sets Type

SetName

unique name of the set

SetLinkage

type of pointers used in member records

NEXT: each member record points to the next in the set
PRIOR: each member record points to the previous in the set
OWNER: each member record points to its owner

Sets Type

Set Order

specifies where a new record is to be placed during insertion

FIRST: new record placed first in the set
LAST: new record placed last in the set
NEXT: new record placed next to the current record
PRIOR: new record placed previous to the current record
SORTED: new record placed based sort key value

Sets Membership option

Removal Options

These are also known as Disconnect or Erase options

Removal options are MANDATORY or OPTIONAL
MANDATORY: member is disconnected only when erased
OPTIONAL: member can be disconnected and can remain in the database

Sets Membership option

STORAGE OPTION

These are also known as Connect options

Storage options are MANUAL or AUTOMATIC
AUTOMATIC: member automatically connected when created
MANUAL: member not connected when created

Sets membership option

MA - Mandatory Automatic

this is default
members automatically connected while insertion
members disconnected while deletion
MM - Mandatory Manual

owner not identified at the time of insertion of member

hence member created but left isolated
member connected when owner is identified

OA - Optional Automatic

members automatically connected while creation

need to disconnect and keep isolated from owner
to be possibly connected to some other owner

OM - Optional Manual

owner not identified at the time of insertion

members connected when owner is identified
members need to be disconnected and left isolated from owner
to be connected to other owner

Duplicates Option For CALC

The duplicates option is specified only for CALC location mode.
DN (Duplicates Not Allowed). 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). 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, the new record will be
retrieved first.
DL (Duplicates Last). 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, the new record will be retrieved last.

Duplicates Option DF (Duplicates First)

D1
Joshi
Patil(2)

Verm
a

After insertion. Patil(2) inserted.

Patil(1)

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.

Duplicates Option DL (Duplicates Last)

D1
Joshi
Patil(1)

Verm
a

After insertion. Patil(2) inserted.

Patil(2)

With the DL duplicates option, a record with a duplicate sort-key value is stored
immediately after the existing duplicate record in the set. The last duplicate record
encountered in the next direction is always the most recently stored duplicate record.

Duplicates Option DN (Duplicates Not Allowed)

D1
Try to insert Patil(2).

Joshi

Verma

It is rejected.
IDMS/R returns an error code.

Patil(1)
With the DN duplicates option, a record with a duplicate sort-key value cannot
be stored in the set. When a program attempts to store a record with a duplicate
sort-key value, the DBMS returns an error code.

Error Handling

ERRORSTATUS
Field Values
0000

Condition
Name

Explanation

DB-STATUS-OK

Successful

0307

DB-END-OF-SET

End of set, area or

index

0326

DB-REC-NOTFOUND

No record found for

given key

0001 To
9999

ANY-ERRORSTATUS

Any error, Any nonzero value

Copyright 2008 Accenture All Rights Reserved.

ERROR-STATUS field of IDMS Communication Block contains status 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.

Example: Error Handling

MOVE 2000 TO DEPT-ID-0410.

OBTAIN CALC DEPARTMENT.
IF DB-STATUS-OK
DISPLAY DEPT-NAME-0410
ELSE
IF DB-REC-NOT-FOUND
DISPLAY GIVEN DEPT-ID NOT FOUND
ELSE
PERFORM IDMS-STATUS.

Area Name and Bachman

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

Obtain Vs. Find and Get

An OBTAIN statement is equivalent to 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.
GET causes IDMS/R to move the appropriate data element values from the system buffers into
our programs working-storage section.
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.
MOVE 2000 TO DEPT-ID-0410.
FIND CALC DEPARTMENT.
GET DEPARTMENT.
MOVE SUDHIR TO FACULTY-ID.
FIND CALC FACULTY.
GET FACULTY.

Access By Walking Sets: Access

Through Set Relationship
Retrieving members from owner
Retrieving owner from members
Retrieving members from owner:
Access the sets owner record occurrence, then to retrieve member record occurrences from
the set occurrence, following syntax is used.
OBTAIN

First
Last
Next
Prior
Nth

<Record-Name>

within

<Set-Name>

Example: Access Thru Owner

Example: Display all employees names for a given department.

MOVE N TO WS-END-SET.
MOVE WS-DEPT-ID TO DEPT-ID-0410.
OBTAIN CALC DEPARTMENT.
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
PERFORM IDMS-STATUS.

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
PERFORM IDMS-STATUS.

Retrieving Owner From Members

OBTAIN OWNER WITHIN <Set-Name>
Example:

Move 0001 to EMP-CODE.

Obtain calc EMP.
...
Obtain owner within DEPT-EMP.

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.
OBTAIN <record-name> WITHIN <set-name> USING <sort-key>.
Expected return-codes are DB-STATUS-OK, DB-REC-NOT-FOUND.
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.
IDMS/R begins searching member records from the first member record occurrence in the set
occurrence.

Indexed Set
To implement an index, IDMS/R builds an index file that contains the database key values of
member record occurrences.
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.
E.g. Employee record has an index built on last-name and first-name fields, apart from CALC
key.
The use of indexes can simplify processing in the following situations:
Random retrieval by key value. 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.

Retrieval Using Indexed Set

Each entry in the index contains an index-key data element value and the db-key value of its
corresponding record occurrence.
Random Retrieval
OBTAIN SKILL WITHIN SKILL-NAME-NDX
USING SKILL-NAME-0455.
Expected return-codes are DB-STATUS-OK, DB-REC-NOT-FOUND.
Sequential Retrieval
OBTAIN NEXT EMPLOYEE WITHIN EMP-NAME-NDX.
Expected return codes are DB-STATUS-OK, DB-END-OF-SET.
Generic-Key Retrieval
Same as Sorted Set.

Retrieval By Sweeping Areas

IDMS/R scans through all the records in an area in physical sequence.
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.
OBTAIN

First
Last
Next
Prior
Nth

<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.
Expected return-codes are DB-STATUS-OK, DB-END-OF-SET.

Retrieval By Sweeping Areas

Example: Retrieve all Course record occurrences.

OBTAIN FIRST COURSE WITHIN COURSE-AREA.
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
PERFORM IDMS-STATUS.

Storing and Retrieval By DB-Key Value

<record-name>
ACCEPT <ws-db-key-v> FROM <set-name>
CURRENCY
<area-name>
MOVE DBKEY TO ws-db-key-v.
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.

Currencies

Currencies are maintained in form of DBKEYS of most recently accessed records by application programs. The
currencies enable application programs to position itself and move about record occurrences within the
database.
Types of Currencies:1)Run Unit 2)Record Type 3)Set 4)Area

Currencies
RUNUNIT

most recently accessed record by the program

RECORDTYPE

most recent record occurrence accessed for each record type

SET

most recent record occurrence accessed in each set,

either the owner or the member
AREA

most recent record occurrence accessed in each area accessed by the program

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.
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.

Currency Loss

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
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.

Re-establishing Currency

Ex.: To solve the area currency loss.

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
..
Reestablishing Run-Unit Currency:
<record-name>
FIND / OBTAIN CURRENT WITHIN
<set-name>
WITHIN
<area-name>
After this statement, issue PERFORM IDMS-STATUS.

IF EMPTY statement

Syntax: If <set name> member

If not <set name> member
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.

Example:

Move 0001 to EMP-CODE.

Obtain calc EMP.
...
If DEPT-EMP member
To determine if a set is empty, perform the following steps:
Establish currency for the set.
Issue the IF EMPTY statement.
Perform further processing as specified.

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:
Establish run unit currency for the specified member record.
Issue the IF MEMBER statement.
Perform further processing, as specified.

DML Data Update Functions

READY
It is an equivalent to an OPEN statement for a conventional file.
It makes the required area of the database available to the program.
SHARED
READY <area-name> USAGE-MODE IS PROTECTED RETRIEVAL
ALL
EXCLUSIVE UPDATE
This statement begins a run-unit.
Usage-Mode Is Retrieval: The program will retrieve data only and will not modify data for the specified area.
Usage-Mode Is Update: It informs IDMS/R that the program intends to update records from the specified area.
Additional usage mode options that control the way in which database areas can be concurrently accessed by two
or more run units.

STORE

STORE <rec-name>
It is used to add a new record occurrence to the database. Adding a new record occurrence to the database is a simple
threestep process:
Construct the new record occurrence in the working-storage section.
Establish currency of the set types in which the new record participates as an automatic member. We can use FIND for this
purpose.
Execute the STORE function specifying the record type name.
Example:

Move 0001 to DEPT-CODE.

Move Finance to DEPT-NAME.
Move 120 to DEPT-COUNT.
Store DEPT.

Notes:
Creates record in the database
Connects stored record to owner in Automatic sets
Owner records of those sets need to be made current
Set currency needs to be established
Calc key and sort field should be populated

MODIFY

Syntax: Modify <record name>

Example:

Move 0001 to DEPT-CODE.

Obtain calc DEPT.
...
...
Find current DEPT.
Move 20 to DEPT-COUNT
Modify DEPT

Notes:
Record should be accessed by Obtain before Modify
Record should be populated before Modify
Record should be current of run-unit before Modify
Calc key should not be modified
Modification of record in sorted set may be expensive

ERASE

This is used to delete a record occurrence from database.

PERMANENT
ERASE <rec-name>
SELECTIVE
ALL

MEMBERS

Retrieve the record we want to erase, making it current of run unit.

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.

ERASE

The ERASE ALL Option

It first causes the object record to be removed from the database.
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
IDMS/R erases the record that is the object of the ERASE.
It erases all mandatory members in 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.

ERASE

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 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

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.
Membership option must not be MA (mandatory automatic).
All areas affected must be readied in UPDATE usage mode.

DISCONNECT

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.
.

How to Access DB-KEY for record occurrences

Syntax:
Accept <database key> from <record name> currency

Accept <database key> from <set name> currency

Accept <database key> from <area name> currency
Accept <database key> from <set name>
[next/prior/owner] currency
Example:

Move 0001 to EMP-CODE.

Obtain calc EMP.
Accept WS-EMP-DBKEY from EMP currency.

Notes:
Accesses database key for a record
Storage format for database key is S9(8) COMP.

BIND STATEMENTS

BIND RUN-UNIT
identifies IDMS communication block of program to DBMS
identifies subschema to be loaded for run-unit
enables program to sign on to database
Bind <record name>
establishes addressability of record structure with DBMS
tells DBMS the address of record in variable storage

READY STATEMENTS

Ready <area name> Usage Mode

SHARED/PROTECTED/EXCLUSIVE
RETRIEVAL/UPDATE

requests access to database areas, and in turn records

specifies modes of access of areas

RETRIEVAL: read only operations

UPDATE:
read and create/modify/delete

SHARED: other run units can concurrently access

PROTECTED:
other run units cannot ready in UPDATE
EXCLUSIVE: other run units cannot ready in ANY

FINISH STATEMENTS

terminates run-unit
releases all resources associated with run-unit
writes checkpoint to journal

COMMIT STATEMENTS

Commit requests IDMS to write checkpoint, makes changes to database permanent for the
unit of work. Commit has two variations, i.e Commit and Commit All

Commit

releases all locks except implicit shared locks

writes a checkpoint
does not affect currencies

Commit All

releases all locks

writes a checkpoint
nullifies currencies

ROLLBACK STATEMENTS

Rollback
Rollback requests IDMS recovery of unit of work, undoes the changes to database.
Rollback has two variations, i.e. Rollback and Rollback Continue

Rollback
request recovery of unit of work
terminates run unit

Rollback Continue

requests recovery of unit of work does not terminate run unit IDMS returns a 4 character
error code after executing every DML statement. When DML statements are embedded in
COBOL programs, IDMS returns error code in a variable called ERROR-STATUS, error code
0000 indicates that the DML statement has executed successfully.