IDMS_mat

8/7/2019 IDMS_mat

1/120

IDMS/R

Version 2.0

16-May-2002

1

8/7/2019 IDMS_mat

2/120

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 .............................................................................................................. 61.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 Pointers .................9

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 .......................................................................................132.4. IDMS Database Records, Record Type, Record Occurrences ....................................14

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

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

3.4. Compiled Listing of Sample IDMS/R Program ............................................................22

3.5. Run-Unit ...........................................................................................................................28

3.6. Virtual Storage Layout ....................................................................................................293.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 ..............................................................................................................375.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

8/7/2019 IDMS_mat

3/120

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 ............................................................ 517.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 ................................................................................................................ 648.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 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 .......................................................................................................................94

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

12.6. Rollback ........................................................................................................................101

13. Locking .................................................................................................................................102

13.1. Area Locks ....................................................................................................................102

13.2. Area Usage Modes ........................................................................................................102

3

8/7/2019 IDMS_mat

4/120

IDMS/R

13.3. Record Locks Implicit, Explicit ............................................................................... 104

14. Utilities .................................................................................................................................109

14.1. DMLO ........................................................................................................................... 109

14.2. OLQ ..............................................................................................................................110

15. Appendix A: Employee Database ......................................................................................112

16. Appendix B: Compilation and Run JCL ..........................................................................11417. Appendix C: IDMS/R ERROR-STATUS VALUES ........................................................117

18. Appendix D: References ..................................................................................................... 120

4

8/7/2019 IDMS_mat

5/120

IDMS/R

Day-Wise Schedule

Day 1

Overview

Logical Database StructureIDMS/R Batch Program

Day 2

Physical Database Structure

Record

Set

Day 3

Retrieval: Basic, By Sort-key, Indexed Set, Sweeping Areas

Day 4Currency

Day 5

Types of Set Relationships

Day 6

Set Membership Options

DML Data Update Functions

Day 7

Recovery and RestartLocking

Day 8

Utilities DMLO, OLQ

5

8/7/2019 IDMS_mat

6/120

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 collectionof 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 placethe 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 ofinformation. 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 itsoriginal form, and restarting jobs that were affected by failures.

6

8/7/2019 IDMS_mat

7/120

IDMS/R

1.2.2. Application Development Productivity

Simplified Programming: - In a program that uses conventional files, much ofthe 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 locatethe 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 aretied 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 thedatabase 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 withembedded pointers to form a tree structure / configuration, in which a dependent

record type has one and only one parent. IMS is an example of hierarchicalDBMS.

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

Supplier

Order

Line Item

8/7/2019 IDMS_mat

8/120

Supplier

Order

Line Item

Part

Quotation

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.

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.

8

SupplierOrder Part

Quotation Line-Item

8/7/2019 IDMS_mat

9/120

IDMS/R

Fig. 1.3.

1.3.4. Difference Between RDBMS and Network, Relations, Chain

Pointers

The reason relational systems are called relational is that the term relation isbasically just a mathematical term for a table.

In the relational model, the data and the relationships among data are representedby a collection of tables. The network model differs from the relational model in

that data are represented by collection ofrecords, and relationships among data

are represented by links.

Relational model supports one-to-many and many-to-many links. But, Networkmodel supports only one-to-many links and it does not support many-to-manylinks.

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

8/7/2019 IDMS_mat

10/120

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 forcedto 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 databasemodel, 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 transactionprocessing 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 aversatile tool for meeting both production requirements and the ease-of-use

requirements of end users.

10

8/7/2019 IDMS_mat

11/120

IDMS/R

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 beaccessed 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 eithercase, 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 ofa 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: datadescription 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 requestsfor 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

8/7/2019 IDMS_mat

12/120

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 arerepresenting 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 logicalstructure 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 10faculties in the department. A faculty can teach multiple subjects.

A subject can be taught by multiple faculties.

There are manyparticipants 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 taughtCourse: - Information about courses of diff subjects

Participant: - Information about participants in a course

Performance: - Information about performance of a participant

12

8/7/2019 IDMS_mat

13/120

Faculty Subject

Course

Participant

Performance

IDMS/R

In discussing entities, we can discuss the attributes that an entity has and therelationships 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-manyrelationship. 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-manyrelationship. 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.

Fig. 2.1.

Each entity is represented by a square-cornered box. We use arrow symbols forconnecting the boxes to represent relationships. The arrow head points to the many

13

8/7/2019 IDMS_mat

14/120

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 Subjectentity and its attributes. We represent theSubjectattributes using a Subjectrecord and we represent each Subjectattribute as a

data element within the Subjectrecord as shown below. Data elements are sometimes

called data items or fields. We name each data element, define its length and definethe type of data that it will contain.

Subject Record

Subject-IdPIC X(04)

Subject-NamePIC X(10)

Subject-StreamPIC 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 thedatabase. 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-IdPIC X(04)

Subject-NamePIC X(10)

Subject-StreamPIC 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, wewill almost always identify additional attributes that are not associated with either of

14

8/7/2019 IDMS_mat

15/120

Faculty Subject

Course

Participant

Performance

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 junctionrecord 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 bydefining 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 ownerof the set; the record type on the many side isdesignated the memberrecord 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-Course Subject-Course

Course-Participant

Participant-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 thoughtof as a template that describes the general nature of the set. A set occurrence, on the

15

8/7/2019 IDMS_mat

16/120

Faculty

Sudhir

Course

C0702 Course

C0804

CourseC0703

Faculty

Raju

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.

Fig. 2.3.

There exists one occurrence of the Faculty-Course set for each occurrence of the setsowner record type.

A set consists of an ownerrecord type and one or more memberrecord 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 lastmember 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, inwhich 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.

16

8/7/2019 IDMS_mat

17/120

IDMS/R

Fig. 2.4.

Following is another example of bubble diagram.

Fig. 2.5.

17

MVS

CO701

CO901

C1001

JCL

CO702

CO902

C1002

MVS

CO701

CO901

C1001

CO702

JCL

C1002

CO902

KishoreShilpa

8/7/2019 IDMS_mat

18/120

IDMS/R

Fig. 2.6.

18

Classroom Exercise

Faculty Subject

Course

Participant

Sub : JCL ; IDMS

Courses : C001 ; C003 --- JCL

C005;C006;C009 --- IDMS

Faculties :

SHEKHAR SHILPA

C001;C005 C003;C006;C009

Participants :

P1;P3 ---C001 ; P2;P4;P5 ---C003

P6;P7 ---C005 ; NIL ---C006

P8;P9;P10 ---C009

Draw a bubble diagram for following

8/7/2019 IDMS_mat

19/120

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 aschema. We can represent a schema visually byusing 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 accessto all record types and all set types that are defined in a schema. One or moresubschemas 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 workonly 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 theywork 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 onlythose 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 theelements defined in the schema.

19

8/7/2019 IDMS_mat

20/120

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 applicationprogram does not interface directly with the operating system data managementroutines 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 programs 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 forexecution.

An IDMS/R application program has DML statements embedded in the source codeto 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

8/7/2019 IDMS_mat

21/120

Source

StatementsDML

Processor

Data

Dictionary

COBOLSource

ErrorListing

COBOLCompiler

Object

Module

ErrorListing

LinkageEditor

LoadModule

Error

Listing

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

IDMS/R DML statements have been changed to comments.

DML requests that involve the transfer of control to IDMS/R have generatedappropriate CALL statements.

After the translated source program has been compiled, the resulting object module isprocessed 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 incalls to the IDMS Interface module.

DML Processor Errors

Compilation Errors

Linking ErrorsFig. 3.1.

21

8/7/2019 IDMS_mat

22/120

IDMS/R

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

predefined program modules, record descriptions. The DML processor automaticallyincludes 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 DMLstatements 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)

22

8/7/2019 IDMS_mat

23/120

IDMS/R

VALUE SPACES.

03 ERROR-AREA PIC X(16)

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

23

8/7/2019 IDMS_mat

24/120

IDMS/R

03 EMP-EXPERTISE PIC X(16)

VALUE 'EMP-EXPERTISE '.

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

PERFORM IDMS-STATUS.

* BIND DEPARTMENT.


IDBMSCOM (48)

SR410

DEPARTMENT.

24

8/7/2019 IDMS_mat

25/120

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.


25

8/7/2019 IDMS_mat

26/120

IDMS/R

IDBMSCOM (67).

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 in the DataDivision.

Note: - If we mention MODE IS BATCH DEBUG, then DEBUG indicates that theDML processor will supply additional code in the resulting source program that will

be helpful in program debugging using the debugger.

Data Division

26

8/7/2019 IDMS_mat

27/120

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 theprocessing that the program performs. The main difference between the

PROCEDURE division of an IDMS/R application program and that of a conventionalCOBOL 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 theSCHEMA section.

The BIND DEPARTMENT statement establishes addressability for theWORKING-STORAGE area that will be used to contain Department recordoccurrences.

The READY statement performs an equivalent function as an OPEN statement for aconventional file.

The READY ORG-DEMO-REGION statement indicates that the program willretrieve 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.PERFORM IDMS-STATUS.

27

8/7/2019 IDMS_mat

28/120

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 isexecuted 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 theCommunications 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-setcondition 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, theprogram 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 programs 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 performprocessing after the run unit is completed. Also the program may begin and end more

than one run unit in the same program execution.

28

8/7/2019 IDMS_mat

29/120

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 consistof 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 theERROR 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 directaccess 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. Variablestorage 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/Rservice.

Application Program

29

Operating System

Variable IDMS CommunicationStorage Block

IDMS/R

Executable Code InterfaceModule

Subschema IDMS/R IDMS/R

Tables Systems DBMS

Buffers

Operating System

8/7/2019 IDMS_mat

30/120

IDMS/R

Address Space

IDMS/RAddress 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 itwith 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 todetermine record, set, and area definitions, currencies, and access restrictions.

iii. Retrieve database record and build subschema record: - The requireddatabase 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 thedesired 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 othercontrol data from the system buffers to the subschema tables.

30

8/7/2019 IDMS_mat

31/120

IDMS/R

v. Store status information: - The DBMS moves status information to

appropriate locations within the IDMS Communication Block. This informationdescribes the results of the requested DML function.

vi. Return to the program: - After updating the Communication block, control ispassed 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 justexecuted.

31

8/7/2019 IDMS_mat

32/120

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

Fig. 4.1.

A database page contains record occurrences and control information.

Header of a page: 16 Bytes

32

Header

Record Occurrences

Record Occurrences

Free Space

Line Index 3 Line Index 4 Line Index 5 Line Index 6

Line Index2 Line Index 1 Footer

8/7/2019 IDMS_mat

33/120

IDMS/R

Footer of a page: 16 Bytes

Line Index format: 8 Bytes

Each page can be considered as a mini-database since each normally stores severalrecords 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 thepage, reduces unusable space to a minimum.

iii. The line index group contains one or more line index pointers, one for eachrecord 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 startof 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 (8bytes), 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

Page Number Next pointer Prior Pointer SA Unused

4 Bytes 4 Bytes 4 Bytes 2 Bytes 2 Bytes

Line Index 0 Line Space Count Page Update Count Page Number

8 Bytes 2 Bytes 2 Bytes 4 Bytes

Record-Id Displacement Record Length Prefix Length2 Bytes 2 Bytes 2 Bytes 2 Bytes

8/7/2019 IDMS_mat

34/120

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 500AREA 2 Pages 601 1000

Invalid page numbers:

AREA 1 Pages 1 500

AREA 2 Pages 401 700

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 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 whichthe 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 occurrencesare 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 grouprecord-types into areas appropriately, programs can open only the areas thatcontain 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

8/7/2019 IDMS_mat

35/120

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 highlyvolatile 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 subdividedinto units called data elements orfields. These data element values follow the formats

that were defined in the schema for this record type. Application programs work onthese 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 therelationships that exist between records. These relationships are physically

implemented by linking record occurrences together with pointers. Pointers contain

35

8/7/2019 IDMS_mat

36/120

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 DataPointer 1 Pointer 2 Pointer 3 . Data

Element 1

Data

Element 2

Data

Element 3

..

36

8/7/2019 IDMS_mat

37/120

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 recordtype. It should be a unique name. The name must begin with an alphabetic character.

The application program must reference the records 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 uniquerecord 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 torepresent a records 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, anIDMS/R module automatically compresses and decompresses the data. Applicationprograms are not aware that compression and decompression is taking place.

37

8/7/2019 IDMS_mat

38/120

IDMS/R

5.4. Record Length

The record length, expressed in bytes, is the actual data length for a fixed-lengthrecord 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 theapplication 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 recorditself 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 arandomizing 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 retrievethe record occurrence that has the supplied CALC-key value.

E.g., Department record type with CALC location mode and Dept-Id-0410 field asCALC-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 departmentlater, 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 onwhich 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 recordsdirectly 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.

38

8/7/2019 IDMS_mat

39/120

IDMS/R

VIA Location Mode

With the VIA location mode, each member record in a set is stored on or near thepage that contains the member records 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 allthe records that belong to a given set occurrence.

Following diagram shows records stored using the VIA location mode. Each newExpertise 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 operationis needed, in many cases, to retrieve an owner record and all of its members.

Area 1

Emp-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 memberrecord 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 recordsstored using the VIA location mode when owner and member record types are

assigned to different areas.

Area 1 Area 2

39

Employee

Expertise

Expertise

Expertise

Employee

Expertise

Expertise

Expertise

Expertise

Expertise

Expertise

Employee

Expertise

Employee

Expertise

Expertise

Expertise

Expertise

Expertise

Expertise

Expertise

Expertise

Expertise

Expertise

Employee

Employee

8/7/2019 IDMS_mat

40/120

IDMS/R

Emp-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 isassigned the VIA location mode. This allows an owner record type to be retrieved

directly, after which all the owners member record occurrences can then be quicklylocated.

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 programmust 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-keysare 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 aduplicate CALC-key value will notbe accepted. IDMS/R will signal an error ifthe 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 duplicateCALC-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

40

8/7/2019 IDMS_mat

41/120

IDMS/R

retrieval is made using that CALC-key value, the new record will be retrievedfirst.

DL (Duplicates Last). With this option, a record occurrence with a duplicate

CALC-key value will be accepted. IDMS/R will store the record afterany record

in the database that has a matching CALC-key value. When a CALC retrieval ismade 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 aBachman

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.

Fig. 5.3.

The information for Department record type is as follows.

41

Record Name

Record Id Storage Record Location

Mode Length Mode

CALC-key or DuplicatesVIA Set Name Option

Area Name

DEPARTMENT

410 F 56 CALC

DEPT-ID-0410 DN

ORG-DEMO-REGION

8/7/2019 IDMS_mat

42/120

IDMS/R

Fig. 5.4.

Department The record name.

410 The unique record identifier assigned to the record type.

F The storage mode, indicatingfixed-length records.

56 The record length.

CALC The location mode, indicating records are stored in the database areausing 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 tospecify 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

8/7/2019 IDMS_mat

43/120

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. Thesecharacteristics 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 sets name

must be referenced whenever an application program accesses records using that setrelationship. 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 theDepartment 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 recordsonly 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

8/7/2019 IDMS_mat

44/120

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

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

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. Ownerrecord occurrences contain only Next pointer. Owner pointers provide direct

access from any member record occurrence to its owner record occurrence.

44

N Dept. 1000 Rec. occurrence

N Emp-Id 0001 Sudhir

N Emp-Id 0002 Pai

N Emp-Id 0003 Anil

N P Dept. 1000 Rec. occurrence

N P Emp-Id 0001 Sudhir

N P Emp-Id 0002 Pai

N P Emp-Id 0003 Anil

8/7/2019 IDMS_mat

45/120

IDMS/R

NPO (NEXT, PRIOR and OWNER pointers). With this linkage option, theset 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

Fig. 6.3.

Ex.: Consider the following set.

Department

Dept-Employee

Emp-Expertise

Fig. 6.4.

Pointers in Employee record occurrence:

45

N P Dept. 1000 Rec. occurrence

N P OEmp-Id 0001 Sudhir

N P OEmp-Id 0002 Pai

N P OEmp-Id 0003 Anil

Employee

Expertise

8/7/2019 IDMS_mat

46/120

D1

E1

E2

E3

D1E15

E1E2

E3

IDMS/R

Prior in Emp-Expertise set

Next in Emp-Expertise setOwner 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 areplaced within a set occurrence. The logical order of member record occurrences isindependent 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

After InsertionE15 is inserted

Fig. 6.6.

LAST. Each new member record occurrence is placed immediately before theowner record (in the prior direction). While retrieving, this option achieves a

46

N P O N P Emp-Id 0001 Sudhir

8/7/2019 IDMS_mat

47/120

D1

E1

E2

E3

D1

E1

E2E3

E1

5

D1

E1

E2

E3

D1

E1

E2 E1

5

E3

IDMS/R

member order of FIFO. PRIOR pointers are required (NP or NPO linkage option)

to satisfy the LAST order option.

Before Insertion

After Insertion: E15 is inserted

Fig. 6.7.

NEXT. Each new member record occurrence is placed immediately after the

member record occurrence that was last accessed(in the next direction) within theset occurrence i.e. next to the current of set.

Before InsertionCurrent of set: - E2


Fig. 6.8.

47

8/7/2019 IDMS_mat

48/120

D1

E1

E2

E3

D1

E1

E15 E2

E3

D1

Josh

i

Patil

Verm

aE3

D1Jos

hi

Kam

at Pati

l

Verm

a

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


Fig. 6.9.

SORTED. With this option, a new member record occurrence is placed in

ascendingordescending sequence, based on the value of a designated sort-control

data element, orsort key, contained in each record occurrence. When a record is

placed into a set, the DBMS examines the sort key in each member recordoccurrence 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.

Consider Dept-Employee set. Order option is sorted, ASC, and sort-key is EMP-

LAST-NAME-0415.

48

8/7/2019 IDMS_mat

49/120

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

DL (Duplicates Last). With the DL duplicates option, a record with aduplicate 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.

49

D1Jos

hi

Patil(2)Patil(1)

Verm

a

8/7/2019 IDMS_mat

50/120

IDMS/R

Ex.: After insertion. Patil(2) inserted.

Fig. 6.12

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

attempts to store a record with a duplicate sort-key value, the DBMS returns

an error code.

Ex.: Try to insert Patil(2). It is rejected. IDMS/R returns an error code.

Fig. 6.13.

6.4. Bachman Diagram For Set

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

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

D1

Joshi

Patil(1)Patil(2)

Verma

D1

Joshi

Patil(1)

VermaE3

8/7/2019 IDMS_mat

51/120

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 retrieveinformation 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 statementcauses IDMS/R to locate the appropriate record occurrence in the database and moves

data element values into application programs 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 .

Ex.: Retrieve a Department record occurrence, given Dept-Id (CALC-key).

MOVE 2000 TO DEPT-ID-0410.OBTAIN CALC DEPARTMENT.

MOVE WS-DEPT-ID TO DEPT-ID-0410.OBTAIN CALC DEPARTMENT.

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

8/7/2019 IDMS_mat

52/120

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 asubschema record in the programs variable storage i.e. working-storage section.

7.3. Error Handling

The application program must check up status of any DML statement immediatelyafter 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. Thelast 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 indicatesfailure. There are some 88-level condition names associated with ERROR-STATUSfield in IDMS Communication Block as given below.

ERROR-STATUSField Values

Condition Name Explanation

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.

MOVE 2000 TO DEPT-ID-0410.OBTAIN CALC DEPARTMENT.

If Department record occurrence with Dept-Id 2000 does not exist, it can be checked

with following IF conditions.

IF ERROR-STATUS = 0326DISPLAY

03 Major code For OBTAIN DML function26 Minor code Function status: - No record found

Or, we can use condition name as follows.

IF DB-REC-NOT-FOUNDDISPLAY ..

52

8/7/2019 IDMS_mat

53/120

IDMS/R

Standard approach for error handling in the program:

Fig. 7.1.

Ex.: Coding for error handling.

MOVE 2000 TO DEPT-ID-0410.OBTAIN CALC DEPARTMENT.IF DB-STATUS-OK

DISPLAY DEPT-NAME-0410

ELSEIF DB-REC-NOT-FOUNDDISPLAY GIVEN DEPT-ID NOT FOUND

ELSEPERFORM IDMS-STATUS.

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

DML statement

Expected

Status

Take Appropriate

Actions

ContinueProcessing

IDMS-STATUS

End

8/7/2019 IDMS_mat

54/120

D1

E1

E2

E3

IDMS/R

In many application situations, it is necessary to retrieve a particular owner record

occurrence

Date post:	08-Apr-2018
Category:	Documents
Upload:	shadab-khan
View:	219 times
Download:	1 times

IDMS_mat

Documents