Training IDMS

7/14/2019 Training IDMS

http://slidepdf.com/reader/full/training-idms-563279d4a5bcd 1/258

IDMS

Integrated Database

ManagementSystem



2

Topics Covered

Introduction to DBMS

Logical and Physical Database Structure

Record Characteristics

Set Characteristics

IDD and DDDL

Data Description Language (DDL)

Data Manipulation Language (DML)

Recovery & Restart of Database

Locking Facilities



3

Introduction to DBMS



4

TYPES of DBMS

Inverted List (e.g. Datacom DB)

Hierarchical (e.g. IMS)

Data records are typically connected

with embedded pointers to form a tree

structure. Each node (except root) can

have one and only one parent



5

Continue …..

• Network (e.g. IDMS)

The database forms a mesh structure

Entity-Relationship is implemented

using Record type and Set.

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

Entity-Relationship is implemented in

the normalized form. Data representedin the form of rows and columns (twodimensional table)



6

Logical & PhysicalDatabase Structure



7

A database can be viewed as consisting of

Entities. An entity is an object about which

we are storing data. Every entity has

attributes. e.g. Employee is an entity which

has attributes like, emp-code, emp-name,

emp-address, emp-sex, emp-dept etc. There

exists relationship between different

entities. We can represent the relationship

between our entities using an entity-

relationship (E-R) diagram as below.

LOGICAL DATABASE STRUCTURE



8

SALARY

BONUS

TEAM

PLAYER GAME

E-R Diagram



9

The example discussed here:

Taken from a typical American baseball

league.

A team has many players but at a given

time, a player is attached to only one team.

A team plays many games. Games can befurther identified by Game-Home and

Game-Away.

THE EXAMPLE



10

A player plays many games and same way

a game is played by many players.

A player has many salary records since his

salary (contracts) may have undergone

changes during a season. Similarly, a

player might have many bonuses awarded

to him.

Team, Player, Game, Salary and Bonus

represent Entities.

Continue …..



11

Attributes of Team could be Team-

Name, Team-City, Team-Address etc.

The relationship between entities is

shown by line diagram. We use

cardinality symbols to represent type of

relationship. The crow-foot end of the

line diagram represents Many type andsingle line represents One type of the

relationship.

Continue …..



12

For example, consider relationship

between Team and Player. Team end

has a single line whereas Player end

has a crow-foot. This represents a

One-to-Many relationship. It means a

team has many players. But a player

is attached to only one team.

Note that relationship between Player and Game is Many-to-Many. i.e a

game has many players and a player

plays many games.

Continue …..



13

In IDMS, entities are implemented

using Record types and

relationships are implemented using

Set types.

IDMS does not allow direct

implementation of many-to-many

relationship.

Continue …..



14

JUNCTION RECORD

It is a way of implementing many-to-

many relationship in IDMS. It is a

record type having attributes that are

common (intersection) to both record

types participating in many-to-many

relation.

Thus, many-to-many relation between

player and game can be resolved as

below.



15

NOTE:

Here, referring to our earlier example of

American baseball league, we had many-

to-many relationship between entities

player and game.

PLAYER GAME

POSITION

Continue …..



16

That is to say, a player has played in

many games and conversely, a game

has many players in it. To resolve this

M:M relationship, we introduce a junction entity, Position record.

Position is called Junction record

because it represents junction or intersection between Player and Game

record.

Continue …..



17

A player has many positions assigned to

him for different games. But for a game

he has a fixed position. Main attribute of

the record is “player - position” for a

game. It thus resolves many-to-many

relationship between player and game.

In other words, we can easily move

from a player record occurrence to agame record occurrence using the

position record occurrence.

Continue …..



18

BACHMAN DIAGRAM

Most installations use a line with an arrow

at one end to show each one-to-many

relationship instead of using crow‟s foot

notation. Such a diagram is called

Bachman Diagram. Here, the end of the

relationship without an arrow always

represents “One” side of the relationship

and the end with arrow always represents

“Many” side of the relationship.

Our earlier E-R diagram is represented

using Bachman diagram as:



19

SALARYTEAM

PLAYER GAME

BONUS POSITION

BACHMAN DIAGRAM



20

IDMS database is divided into one or

more areas. An area is defined as the

major named subdivision of addressable

storage in database.

An area is further subdivided into

pages. Page is a smallest unit of data

transfer between main memory and hard

disk.

PHYSICAL DATABASE STRUCTURE

Database Area, Page and File



21

Each page stores control information

and can store up to a maximum 255

database records.

Database areas can be of different pagesizes. e.g AREA-A can be of page

size 2048 bytes where as AREA-B of

same database can be of page size

4096 bytes.

Continue …..



22

Page size for an area is decided based

on the record types that will be

residing within that area.

ALL record occurances of a

particular record type are stored

within the SAME area.

But, an area may store occurances of multiple record types. Hence this

holds true for a database page as well.

Continue …..



23

Record types are assigned to areas by

designer.

Areas are mapped to files.

Many or all areas can be mapped

into one file if all areas have the

same page size.

Each area can be mapped into a

different file.

One area can be mapped into

several files.

Continue …..



24

AREAS and FILES MAPPING

Page Area

Logical Database

Physical Database File

Block



25

Team Area

921 922 … 930

IDMS File 1

Position Area

1021 1022 … 1040

Salary Area

821 822 ... 830

IDMS File 2

Area and File Mapping…..



26

SALARYTEAM

PLAYER GAME

BONUS

POSITION

ADVANTAGES OF MULTIPLE AREAS

SALARY-AREAPOSITION-AREA

TEAM-AREA



27

Continue …..

As shown in the previous slide, our example of baseball database is divided into

three physical areas namely Team-area,

Position-area and Salary-area.

The advantages of dividing a database into

separate physical areas are:

Processing efficiency

Records those are accessed together

during most of the processing can be

grouped together into same area for

efficiency.



28

Continue …..

Security

One can restrict access to certain

record types. e.g. salary-area can be

restricted to only finance department. Database recovery and backup

Database can be initialized,

reorganized and backed up on area-

by-area basis. Backup of most

updated areas can be made more

frequent than other areas.



29

Continue …..

Concurrent updating

A program can request exclusive

use of an area and prevent other programs from accessing it

concurrently.



30

CONCEPT of DB-KEY

Each Record occurrence stored in the

database is assigned an unique numeric

identifier, called Database Key (db-key).

A record‟s db-key consists of a 32-bit fieldthat contains a 23-bit page number and an

8-bit line number. The page number

identifies the page in which the record is

stored and the line number identifieslocation of the record occurrence within

the page.

The format of db-key is as below:



31

8-bits 23-bits 1-bit

(NotUsed)

Line NumberDatabase Page NumberSign Bit



32

RECORD TYPE v/s RECORD

OCCURRENCEIt is important to make distinction

between Record Type and RecordOccurrences.

Record type is like a template. Itdescribes the format of all occurrences of a given record type stored in database.

Record occurrence represents the smallestdirectly addressable unit of data. Itconsists of fixed or variable number of characters that are subdivided into unitscalled Data Elements.



33

Example of Record Type versus Record

Occurrences

Employee Record Type ……….

Emp-code

PIC 9(4)

Emp-name

PIC X(30)

Sex

PIC X

Emp-dept

PIC X(10)

Employee Record Occurrences …..…...

1000 ABC M TECH

1500 XYZ F SALES



34

Database consists of collection of record

occurrences.

The physical records stored in a database

consist of more than the data elements

used by the application program.

IDMS also maintains information about

relationships that exists between records.Relationships are implemented by linking

record occurrences together with pointers.

STRUCTURE of DATABASE RECORDS



35

Pointers contain addresses of related

record occurrences and are stored along

with the data portion of the record

occurrences.A record occurrence in database consists

of two parts.

Data portion and

Prefix portion.

Continue …..



36

Data elements values are stored in data

portion. Pointers to related record

occurrences are stored in prefix portion.

Application programs deal only with data portion of the record occurrence.

Whereas, IDMS system maintains the

pointers in the prefix portion.

Continue …..

PREFIX Portion DATA Portion

Pointer

1

Pointer

2

Pointer

3…..

Data

element 1

Data

element 2...



37

Schema is the logical definition of a

database. A schema is a complete

database description (all records types &

record elements, set types, files and

areas).

There is ONE and ONLY ONE schema

for a given database.

SCHEMA and SUBSCHEMA



38

A subschema defines a subset of the

schema. One or more subschemas can

be associated with a schema. A load

module is created for each subschema.At runtime, a program can access only

one subschema. A program can not

access IDMS database by referring to

the schema.

A subschema is similar to a view in a

relational database.

Continue …..



39

Even if a program requires access to

ALL record types, data elements and

ALL set types defined in the schema,

the designer must still define a

subschema that includes all the

entities defined in the schema.

A subschema can restrict access to a

program. For example, it may give

only read-only access to an area, or it

may not allow deletion of some record

types.

Continue …..



40

Record Characteristics



41

The characteristics that apply to recordtypes are:

Record Name

Record Identifier

Storage Mode

Record Length

Location Mode

Duplicates Option

Area Name



42

RECORD NAME

Each record type must be assigned a 1

to 16 character name that identifies the

record type. The name must begin with

an alphabetic character. The

application program must reference the

record‟s name in DML (Data

Manipulation Language).



43

It is a number that serves as in internal

identifier for the record type. It is in the

range 100 through 9999. Each recordtype must be assigned an unique record

identifier within the installation. DBAs

assign this number to each record type.Application programs do not refer to

record type using this number.

RECORD IDENTIFIER



44

STORAGE MODE

It indicates whether record occurances

of the record type are fixed or variable

length and whether they are stored in

compressed format.

Allowable codes are:

F (fixed length)

V (variable length)

C (compressed)



45

NOTE:

Compressed mode can be used along

with fixed or variable length storage

modes. For example, one can mention

storage mode as „FC‟ or „VC‟. DBMS

takes care of compression anddecompression of data.

Continue …..



46

RECORD LENGTH

It is expressed in BYTES. It is the

actual data length for fixed-length

record or the maximum data length

for variable-length record.



47

LOCATION MODE

It defines the way record occurances

are stored in the database.

Allowable location modes are:

CALC

VIA

DIRECT



48

In CALC mode, a particular data

element within the record is declared as

the CALC-key. At the time of storing

the record in the database, IDMS

system uses value of the data element

to calculate the page number for storing

a record. Records stored with a CALC

mode can be retrieved from disk in a

single access.

CALC Mode



49

IDMS system uses randomizing routine

to distribute records evenly over its area,

minimizing overflow conditions and

leaving space for adding new records. For retrieving the record (stored with

CALC location mode), appropriate value

for the data element is moved to thestorage area in the application program

and then DML retrieval function is

executed.

Continue …..



50

VIA Mode

Records stored with VIA location mode

are stored near another database record.

This mode is generally used for storing

member records on the same page

containing owner record or on a page

near their owner record.

This mode tends to reduce disk accesses

needed to retrieve all the records of a set

occurrence.



51

Continue …..

CALC retrieval is not possible in

case of records stored with VIA

location mode. Generally the owner

record is assigned CALC location

mode for easy access of member

records.



52

DIRECT Mode

In DIRECT location mode, application

program explicitly specifies the page

into which the record should be stored.

To retrieve this record, programmer

must specify its database address, i.e

db-key of the record.

This mode is less often used than

CALC and VIA mode.



53

DUPLICATES OPTION

It is specified only for record types that

are stored using CALC location mode. It

specifies whether records with duplicate

CALC-key values are allowed and if so,

how would they be stored in the

database.

Possible codes are as on next slides:



54

Continue …..

DN (Duplicates Not Allowed)

Record occurances with

duplicate CALC-key value will

not be accepted. IDMS will

give an error if application

program tries to store a recordwith duplicate CALC-key.



55

DF (Duplicates First)

IDMS will store the record with

duplicate CALC-key value Before

any record in the database that has

matching CALC-key value. When

CALC retrieval is made usingCALC-key value, newly stored

record will be retrieved first.

Continue …..



56

DL (Duplicates Last)

IDMS will store the record with

duplicate CALC-key value After

any record in the database that has

matching CALC-key value. When

CALC retrieval is made usingCALC-key value, newly stored

record will be retrieved last.

Continue …..



57

AREA NAME

It is the name of the area into which all

record occurances of the record type are

to be stored. e.g. CUST-AREA,

SALARY-AREA, SALES-AREA etc.



58

Data Structure Diagram (DSD) for

Documenting Record Characteristics

Record name

Record-id Storagemode

Record length

Location mode

Calc key or VIA set name Duplicates option

Area name



59

Example : DSD for Employee Record

Type

EMPLOYEE

1000 F 150 CALC

EMP-CODE DN

HR-AREA



60

Set Characteristics



61

A Set Occurrence consists of oneoccurrence of owner record type and any

number of member record occurrences.

WHAT IS A SET ?

A Set consists of an OWNER record

type and one or more MEMBER record

types.

SET OCCURRENCE ?



62

A set occurrence that consists only of anowner record occurrence and no

member record occurrences is called

Empty Set occurrence.

Walking a Set

Records in each set occurrence are

physically linked together by pointers.

Accessing members by following the

pointers from one record occurrence tothe next is called Walking the Set.

Empty Set Occurrence



63

• Any record type can be member in one

or more sets.

• Any record type can be owner of one or

more sets.• Any record type can be member in one

set and owner in another set.

• An owner record can own the same

member record in more than one set.

• A record cannot be both owner and

member in the same set.

RULES & FEATURES FOR SET

RELATIONSHIP



64

Office

Employee

Department

Office-EmployeeDept-Employee

Any record type can be member in one or more sets



65

Any record type can be owner of one or more sets

Order

Cust-Order

Customer

Parts

Cust-Parts



66

Any record type can be member in one set and

owner in another set

Order

Cust-Order

Customer

Items

Ord-Items



67

An owner record can own the same member

record in more than one set

Class

Teacher

Teach-Class Examiner-Class



68

DBA typically assigns characteristics toeach set when defining the IDMSdatabase in the schema DDL.

The characteristics are:

Set Name

Linkage Options

Membership Options Order Option

Duplicates Option

Set Characteristics



69

SET NAME

A unique name must be given to each set

type in the database. The name can be

maximum of 16 characters. The set namemust be referenced whenever an application

program accesses records using that set

relationship. Usually it will be owner record

name followed by member record name e.g.

CUST-ORDER.



70

LINKAGE OPTIONS

It indicates the types of pointers that

are used to implement the set.

Pointers provide flexibility inaccessing records in a set occurrence.

Pointers are stored in the prefix part

of the database record occurrences.

Available options are:



71

Continue …..

N (NEXT pointer)

Each record in the set contains a

pointer to the next record

occurrence. This option allows toaccess member records only in the

forward direction. Next pointer is

mandatory for all sets. All other

pointers are optional.



72

Continue …..

NP (NEXT and PRIOR pointer)

With this, in addition to Next

pointer, each record contains

pointer to prior record occurrence

in the set. This allows us to access

member records in both forward

and backward direction.



73

Continue …..

NO (NEXT and OWNER pointer)

With this, in addition to Next

pointer, each record contains pointer

to owner record occurrence in the

set. This allows us to access the

owner record directly from any

member record occurrence.



74

NPO (NEXT, PRIOR and

OWNER pointer)

Each record in the set contains all

three pointers. This option allows

to access member records in both

forward and backward direction

and also allows to access the owner record directly from any member

record occurrence.

Continue …..



75

Xansa Mumbai DATAP N

EMP-A DATAP N

EMP-B DATAP N

EMP-C DATAP N

Record Occurrences with Next, Prior & Owner Pointers

Office

Employee

Office-Employee

O

O

O



76

The Membership options specify how a

member record may be connected to or

disconnected from a set occurrence.

The option is defined in two parts.

MEMBERSHIP OPTIONS

First part is a Disconnect Option,

indicating the way a record is

disconnected from a set.

Second part is the Connect Option,

indicating how a record is connected to

a set.



77

It specifies whether a member record can

be later disconnected from a set once its

membership has been established.

Possible values are:

M (Mandatory)

The record cannot be disconnected

from a set unless that record isdeleted (erased) from the database

using the ERASE command.

Disconnect Option



78

O (Optional)

A record occurrence can be

disconnected from a set. The

record remains in the database. Itcan be connected to some other

set occurrence. It is optional to

use ERASE for such records.

Continue …..



79

It specifies whether or not a member

record is automatically connected to a set

occurrence when it is added to the

database.Possible values are:

A (Automatic)

Automatic means when a member

record is inserted in database, IDMSwill automatically connect it to all its

owner records (provided currencies

have been established for owners).

Connect Option



80

M (Manual)

Manual option specifies that after

inserting a record, programmer

must explicitly connect it to its

owner record by issuing

CONNECT statement.

Continue …..



81

MA - Mandatory Automatic

MM - Mandatory Manual

OA - Optional Automatic

OM - Optional Manual

Combinations for Membership Options



82

The order option specifies logical order

in which member record occurrences are

placed within a set occurrence. Options

available are: FIRST

Each new member record

occurrence is placed immediately

after the owner record (in the next

direction). This option achieves a

member record in LIFO.

ORDER OPTION



83

LAST Each new member record occurrence

is placed immediately before the

owner record (in the prior direction).

This option achieves a member recordin FIFO. Prior pointer is a must to

specify this option.

NEXT

Each new member record occurrence

is placed immediately after the

member record occurrence that was

last accessed (in the next direction).

Continue …..



84

PRIOR

Each new member record occurrence

is placed immediately before themember record occurrence that was

last accessed within the set (in the

prior direction). Prior pointer is a

must to specify this option.

Continue …..



85

SORTEDEach new member record occurrence

is placed in ascending or descending

sequence, based on the value of

designated sort-control data element(sort-key) in each record occurrence.

When the record is placed into a set,

DBMS examines the sort-key value

in each member to find the logical position of new member record in

the set.

Continue …..



86

This option is useful only in case whereset is defined with order option as Sorted.It indicates the action to be taken when aduplicate sort-key value occurs.

DN (Duplicates Not Allowed)

Record occurances with duplicatesort-key value will not be stored in

the set. IDMS returns an error codeif program tries to store such arecord.

DUPLICATES OPTION



87

DF (Duplicates First)

Record with duplicate sort-key

value is stored Before any

existing record in the set that has

matching sort-key value. Most

recently stored duplicate record

will be retrieved first.

Continue …..



88

DL (Duplicates Last)

The record occurrence with

duplicate sort-key value is stored

After existing record in the set that

has matching sort-key value. Most

recently stored duplicate recordwill be retrieved last.

Continue …..



89

IDMS allows retrieval of records using

an index.

In conventional sets, member records

are chained together by pointers. In anindexed set, DB-key values of member

record occurrences are stored in a

specified order in one or more index

records. Adds flexibility to data retrieval and

retrieval is made faster in some cases.

INDEXED SETS



90

Indexed sets are useful in cases where:

Records need to be accessed using

alternate-key (apart from CALC

key).

Walking very long sets and when

only key values of a member

record is required.

Member records need to beretrieved randomly using partial

key value.

Continue …..



91

Indexed sets can be implemented

using two database record types or

a single record type and a system

defined record type.

Continue …..



92

Player

Position

Player-Position-Index

(Position-Name)

Continue .....

User-definedOwner Record



93

Employee

System-defined owner record

(Employee-Name)

Continue .....

SR7



94

Index between Player and Position

records allows to access position

records using Position-name values.

System owned index on employee

implements alternate index on

employee-name.

Continue …..

SALARY

TEAM-PLAYER

NPO

TEAM-GAME

NPO



95

SALARY

PLAYER

BONUS

TEAM

POSITION

GAME

SALARY-AREA

SALARY-AREA

TEAM-AREA

TEAM-AREA

TEAM-AREA

POSITION-AREA

DN

DN

DN

VIA

VIA VIA

CALC CALC

CALC40

70

25 50

80

701000

1100

1200

2000

25003000

F

F

F

F

F

F

PLAYER-BONUSGAME-POSITION

PLAYER-NAME

PLAYER-SALARY

GAME-PLAY-DATE

TEAM-NAME

PLAYER-SALARY

NPO

OA

NEXT

OM

LAST

PLAYER-BONUS

NPO

OA

NEXT

PLAYER-POSITION

NPO

OA

NEXT

GAME-POSITION

NPO

MA

NEXT

NPO

MM

NEXT



96

IDD & Data Dictionary

Definition Language(DDDL)

INTEGRATED DATA DICTIONARY (IDD)



97

IDD stores meta-data about all the data items

in the database (The data values are not storedin IDD).

Stores information about users, application programs, files, record, data element, module(date routine, error handling routine) andapplication systems.

IDD is integrated with every software

component provided in IDMS like ADSO,OLQ and Report Generator. Each software

component accesses IDD to get information

about data items and programs.

INTEGRATED DATA DICTIONARY (IDD)



98

The data dictionary definition language

(DDDL) is used to create, update or delete

entity occurrences in IDD.

DDDL provides five verbs to manipulate

entities:

ADD to add a new entity.

MODIFY to change entity description.

DATA DICTIONARY DEFINITION

LANGUAGE (DDDL)



99

DELETE to remove an entity.

DISPLAY to display an entity

description.

PUNCH to copy entityinformation from IDD to a file.

Continue …..



100

ADD ELEMENT CITY-NAME

ELEMENT DESCRIPTION „TEAM CITY‟

PICTURE X(20)

USAGE DISPLAY.

DISPLAY PROGRAM STATSEDIT.

DELETE PROGRAM NAME IS STATSEDIT.

Examples of DDDL



101

MODIFY ELEMENT CITY-NAME

PICTURE X(25).

MODIFY PROGRAM NAME IS STATSEDIT

VERSION IS 1LANGUAGE IS COBOL

ESTIMATED LINES 5000.

SIGNOFF. ( to exit from IDD )

Continue …..



102

Data Description

Language (DDL)



103

Data Description Language (DDL) is

used to define:

SCHEMAS

DBA describes the logicalstructure of the database by coding

set of schema DDL statements.

There is a single schema for a

given database.



104

DEVICE-MEDIA CONTROL

LANGUAGE (DMCL) MODULES

Many aspects of the database‟s physical structure, such as disk

device assignments and page sizes

are described in DMCL module

definition.



105

SUBSCHEMAS

The views that individual

applications programs have of the

database are defined in

subschemas and described with set

of subschema DDL statements.

Any number of subschemas can bedefined for a given database.



106

The logical structure of a database is

defined in a set of schema DDL statements.

Schema DDL statements define the

following: Schema name

Database file names

Database areas Data elements and records

Sets

SCHEMA DDL STATEMENTS



107

The schema DDL is processed by the

schema compiler. The schema

compiler reads the schema DDL

statements and stores a description of

the schema in the data dictionary.

The data dictionary is the central

repository of information that IDMSmaintains about the databases under its

control.

Process



108

Schema

DDL

Statements

Schema

Compiler

DataDictionary

The schema compiler can also copy from

the data dictionary descriptions of records

that have been previously defined and

stored in the data dictionary.

Continue …..



109

ADD SCHEMA NAME IS DDSCHEMA VERSION 1

ADD FILE NAME IS CUST-FILE

ASSIGN TO CUST.

ADD FILE NAME IS ORDER-FILEASSIGN TO ORDER.

ADD AREA NAME IS CUST-AREA

PAGE RANGE IS 505000 FOR 100

WITHIN FILE CUST-FILE.ADD AREA NAME IS ORDER-AREA

PAGE RANGE IS 809000 FOR 100

WITHIN FILE ORDER-FILE.

Example Of Schema DDL



110

ADD RECORD NAME IS CUST-REC RECORD ID IS 3000

LOCATION MODE IS CALC USING (CUST-NO)

DUPLICATES ARE NOT ALLOWED

WITHIN AREA CUST-AREA.

02 CUST-NO PICTURE IS 9(6) USAGE IS DISPLAY.

02 CUST-NAME PICTURE IS X(40) USAGE IS DISPLAY.

ADD RECORD NAME IS ORDER-REC RECORD ID IS 3100

LOCATION MODE IS CALC USING (ORDER-NO)

DUPLICATES ARE NOT ALLOWED

WITHIN AREA ORDER-AREA.02 ORDER-NO PICTURE IS 9(7) USAGE IS DISPLAY.

02 ORDER-STATUS PICTURE IS X(1) USAGE IS DISPLAY.

02 ORDER-REQ-DT PICTURE IS 9(8) USAGE IS DISPLAY.

Continue …..



111

ADD SET NAME IS CUST-ORDER

ORDER IS NEXT

MODE IS CHAIN LINKED TO PRIOR

OWNER IS CUST-REC

MEMBER IS ORDER-REC LINKED TO OWNER

MANDATORY AUTOMATIC.

Continue …..



112

It completes the mapping of logical areas

into physical files.

It also identifies and describes the journal

files that are used by IDMS for recordingchanges made to the database. Journal

files are used to implement IDMS backup

and recovery facilities.

DMCL DDL STATEMENTS



113

DMCL DDL statements define the

following:

DMCL module name

Schema name associated with this

DMCL module

Sizes of the I/O buffers

Information about database areas Information about journal files used

for backup and recovery

Continue …..



114

The DMCL definition is processed bythe DMCL compiler. The DMCL

compiler reads the DMCL source

statements and stores a description of the

DMCL module in the data dictionary. As the DMCL compiler processes

DMCL source, it must have access to the

corresponding schema definition in the

data dictionary. For this reason, schemamust be compiled before its associated

DMCL module.

Process



115

The DMCL compiler also generates aset of assembler language source

statements. These are in turn processed

by assembler and the linkage editor to

form an executable DMCL load

module. The linkage editor places the

load module into a load module library.

The DMCL load module is used byIDMS at run-time when an application

program accesses the database files

described by the DMCL module.

Continue …..



116

DMCL

Compiler

Assembler

Linkage

Editor

DMCL

Source

Statements

Data

Dictionary

Load

Library

Continue …..



117

DMCL DDL statements contain followingfour sections:

Device-Media Description section

This sections gives name to the DMCL

statements. It further provides other

documentary details about the DMCL

module.

Buffer section

It assigns page size and defines buffers

that IDMS will use to handle database

accesses.

Continue …..

C ti



118

Area section

Information about each area is copied

from the schema into this section of the

DMCL. The section assigns each area

to buffers that were defined in the buffer section.

Journal section

The section describes disk files to beused for journaling. Journal files are

used to keep track of database activity.

Continue …..



119

DEVICE-MEDIA DESCRIPTION.DEVICE-MEDIA NAME IS DMCLBASE OF

SCHEMA NAME SCHBASE VERSION 1.

DATE. DD/MM/YY.

INSTALLATION. XANSA MUMBAI

INDIA.BUFFER SECTION.

BUFFER NAME IS XXBUFF

PAGE CONTAINS 4096 CHARACTERS

BUFFER CONTAINS 5 PAGES.

JOURNAL BUFFER NAME IS JJBUFF

PAGE CONTAINS 3188 CHARACTERS

BUFFER CONTAINS 3 PAGES.

Example Of DMCL DDL



120

AREA SECTION.

COPY SALARY-AREA AREA

BUFFER IS XXBUFF

JOURNAL SECTION.

JOURNAL BUFFER IS JJBUFF.FILE CONTAINS 3000 BLOCKS.

FILE NAME IS XANJRNL1

ASSIGN TO SYSJRNL1.

FILE NAME IS XANJRNL2

ASSIGN TO SYSJRNL2.

Continue …..



121

Subschema DDL statements specify the

following:

Subschema, Schema and DMCL

module name Areas accessible in this

subschema

Records and data elements

accessible and

Sets included in the subschema

SUBSCHEMA DDL STATEMENTS



122

The subschema compiler reads

subschema source statements and

stores a description of the subschema

in the data dictionary.

The compiler also stores an executable

load module in an area of the data

dictionary, known as Load Area.

IDMS uses this load module whenever

an application program using this

subschema is under execution.

Process



123

Like DMCL compiler, subschemacompiler must have access to the

corresponding schema definition in the

data dictionary. Thus, schema must

have been compiled before any of itsassociated subschemas can be

compiled.

After compiling subschema, data

dictionary has all the requiredinformation about the logical and

physical structures of the database.

Continue …..



124

Data

Dictionary

Subschema

DDL

Subschema

Compiler

Load Area

Continue …..



125

ADD SUBSCHEMA NAME SUBSCHA OF SCHEMA NAME SCHDBA VERSION 1

DMCL NAME SUBADMCL OF SCHEMA NAMESCHDBA VERSION 1

COMMENTS „LIMITED VIEW OF SCHDBA‟

ADD AREA NAME IS CUST-AREA.ADD AREA NAME IS ORDER-AREA.ADD RECORD NAME CUST-REC

ELEMENTS ARE CUST-ID CUST-NAME.ADD RECORD NAME ORDER-REC

ELEMENTS ARE ALL.ADD SET NAME ORDER-ACTION.ADD SET NAME CUST-ORDER.GENERATE.

Example Of Subschema DDL



126

Data Manipulation

Language(DML)



127

In an IDMS application program, there

are no file description statements or Open

and Close statements found in a typical

batch Cobol file processing application

system.

To access data stored in the database,

DML verbs are used.

Two new terms Run Unit and Currency

are important to understand.



128

The BIND RUN-UNIT statement is

used to specify the start of a run unit.

A run unit ends when program

completes all database processing and

issues a FINISH statement.

CONCEPT of RUN UNIT

The run unit is that portion of program‟s

processing during which it has access to

one or more database areas and services.



129

The program may perform some

processing before it begins a run

unit.

The program may perform some

processing even after it finishes a run

unit.

A program may begin and end more

than one run unit.

Continue …..



130

IDMS internally stores pointers to

the most recently accessed records.

It uses these pointers to access

subsequent records. These pointers

are referred to as CURRENCY.

At the beginning of a program, all

currencies are null.

CONCEPT of CURRENCY



131

Currency is established by DMLverbs FIND, OBTAIN, STORE,

CONNECT, DISCONNECT and

ERASE.

There are four currencies maintained

for a database:

current of run unit

current of record type

current of set

current of area

Continue …..



132

Current of Run Unit is a recordwhich was most recently accessed.

Current of Record type is the most

recently retrieved or inserted record

of that record type.

Current of Set is the most recentlyretrieved or stored record of thatset. Record may be a member or owner of that set.

Continue …..



133

Current of Area is the most recentlyretrieved or stored record of that area.

When a record is erased, currency of its

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

Continue …..

IDMS APPLICATION PROGRAM PREPARATION



134

DML

Processor

Compiler

Linkage

Editor

Source

Statements Data

Dictionary

Load

Library

IDMS APPLICATION PROGRAM PREPARATION



135

The previous slide shows how an IDMS

application program written in Cobol hostlanguage is compiled and made ready for

execution.

Application program with embedded DMLstatements is first read by DML processor.

It validates DML statements and creates

translated version of the source program

where in DML statements are replaced by

appropriate calls to IDMS.

Continue …..



136

DML processors are available for a

number of commonly used programming

languages. DML processor may also

generate a listing of errors. DML

processor interacts with data dictionaryfor copying descriptions of various

database elements like schema,

subschema, record types etc.

Output from the DML processor acts as

input to the host programming language

compiler like a Cobol compiler.

Continue …..



137

After the translated source program is

compiled by host language compiler, the

resulting object module is processed by

Linkage editor to create an executable

load module.

The Linkage editor also includes copy of

a routine called IDMS Interface Module

in final load module. IDMS service

requests from the program are converted

in to calls to IDMS Interface Module.



138

Following are typical changes one

notices in a n IDMS Cobol application

program.

IDENTIFICATION DIVISION

remains exactly the same as before.

ENVIRONMENT DIVISION hasIDMS-CONTROL section.

Continue …..

C ti



139

DATA DIVISION begins withSCHEMA SECTION which gives

the subschema used by the

program.

PROCEDURE DIVISION has

DML verbs for data retrieval and

data updation.

Continue …..



140

.….

ENVIRONMENT DIVISION.

IDMS-CONTROL SECTION.

PROTOCOL.

MODE IS BATCH DEBUG.

IDMS-RECORDS WITHIN WORKING-STORAGE SECTION.

CONFIGURATION SECTION.

…..

INPUT-OUTPUT SECTION.

FILE CONTROL.

…..

IDMS-CONTROL SECTION

C i



141

The PROTOCOL statement is a

compiler-directive statement that

specifies the manner in which DML

processor will generate CALLstatements.

Application program must specify one

of the following modes to access

database:

Continue …..

C i



142

BATCH (a batch program with

database processing)

IDMS-DC (a non-batch program i.e.

an online program called by a dialog

process)

DC-BATCH (a batch program with

access to DC queues)

Continue …..

Continue …..



143

„DEBUG‟ instructs DML processor to

produce additional code in the resulting

source code which is helpful during

program debugging.

The IDMS-RECORDS clause specifies

that the data definitions for records and

data elements will be copied automatically

from the data dictionary and placed at the

end of working storage section.

DATA DIVISION



144

.…. DATA DIVISION.

SCHEMA SECTION.

DB SUBEMP WITHIN SCHEMP.

FILE SECTION.

…..

WORKING-STORAGE SECTION.

…..

DATA DIVISION

Continue



145

As explained earlier, DATA DIVISION begins with SCHEMA SECTION which

gives the subschema used by the

program.

As shown in previous slide, SUBEMP is

the name of the subschema which will be

used by the program.

Further, the SCHEMP is the schema from

which SUBEMP subschema is derived.

Continue …..

BIND STATEMENT



146

BIND RUN UNIT.

BIND EMPLOYEE.

BIND MANAGER.

BIND PROJECT.

BIND SALARY.

BIND STATEMENT

Above example displays the typical

code that might be found in the

Procedure Division of an IDMS

Cobol program.

C ti



147

Continue …..

The first statement BIND RUN-UNIT

establishes addressability for the IDMS

communications block and causes

IDMS to load the subschema identified

in the Schema section. Next four BIND

statements establish addressability for

the working-storage areas that will be

used to contain record occurrences.

Continue …..



148

Generally, following one statement is

found in the source code.

COPY IDMS SUBSCHEMA-BINDS.

When the source is pre-compiled, theabove single statement is replaced by

previous set of five Bind statements.

BIND statement identifies the record

types that the program will access.

COPY STATEMENT



149

COPY IDMS SUBSCHEMA-BINDS.

COPY IDMS IDMS-STATUS.

COPY STATEMENT

Copy statement is a compiler directivestatement.

In first example above, the copy

statement generates appropriate Bindstatements at the time of pre-compile.

Continue



150

Continue …..

As in second example, the copy

statement copies module called

IDMS-STATUS from data

dictionary into the source code

when it is pre-compiled. This

particular module (routine) checks

result of DML statement.

This helps in reducing coding effort.

READY STATEMENT



151

READY EMPLOYEE-AREA USAGE IS RETRIEVAL.

READY SALARY-AREA USAGE EXCLUSIVE UPDATE.

READY USAGE IS RETRIEVAL.

READY STATEMENT

Ready statement can be thought as an

equivalent to Open statement for a

conventional file. It gives the program

access to all or named areas defined inthe subschema and begins a run-unit.

Continue …..



152

The usage-mode clause in the Readystatement indicates whether the program

will only retrieve data or update it as

well.

If no areas are mentioned in the Ready

statement, then all areas mentioned in

the subschema will be made available to

the program by default in the mode

specified in the Ready statement.

FINISH STATEMENT



153

FINISH.

FINISH STATEMENT

Finish statement is used to end a run

unit by releasing database resources and

terminating database processing.

Non-database processing of the program

may continue after the Finish statement, but database can not be accessed (unless

a fresh run unit is started).

FIND STATEMENT



154

MOVE INPUT-EMP-CODE TO EMPLOYEE-CODE.

FIND CALC EMPLOYEE.

FIND STATEMENT

Find statement is used to locate a record

occurrence in the database. The record

occurrence is placed in the system

buffers but the data element values are

still not available in the variable storage

of the program.

Continue



155

Continue …..

There are situations when we do not need

actual values of a record occurrence like:

We may need to verify that a particular

record occurrence exists

We need to establish currencies for

some subsequent record retrieval

In the example, the required employeeinformation is moved to the CALC-key

data element of Employee.

Continue



156

Continue …..

Next, Find statement will locate the recordoccurrence with matching employee-code.

If the Find is successful, currencies are set

appropriately but the individual data

element values for the located record are not

yet made available to the program.

In case, data element values are required

then Find can be followed by Get statement.

GET STATEMENT



157


FIND CALC EMPLOYEE.

GET.

GET STATEMENT

Get statement is used to make available to

the program a record occurrence that was

previously located by the Find statement.

Get statement can qualify the record type

or it can be unqualified as in this case.

Continue …..



158

To continue with our earlier Find example,we have followed it with unqualified Get.

This will transfer record occurrence values

to the variable storage.

If Get is qualified then IDMS will verify

whether the previously located record is

Employee record or not. If it does not

match then IDMS will return error code.

OBTAIN STATEMENT



159

The Obtain statement is equivalent of a

Find followed by a Get.

It is most widely used statement for

data retrieval in IDMS.

There are many syntax variations

available for Obtain statement, based

on location mode of records and modeof retrieval.

OBTAIN STATEMENT

Continue



160

CALC-key Retrieval

To perform Calc-key retrieval, the record

must have location mode specified as

CALC and we must know the Calc-key

value for the record to be retrieved.

Continue …..

MOVE INPUT-EMP-CODE TO EMPLOYEE-CODE.OBTAIN CALC EMPLOYEE.

Continue …..



161

As shown in previous example, we movethe Calc-key value for the record to be

retrieved to the data element of Employee

record type that is defined as Calc-key(Employee-Code) and issue Obtain

statement to get the record contents.

IDMS uses the Calc-key value supplied tocalculate the target page for the data

retrieval.

Continue …..



162

Duplicate CALC-key Retrieval

Sometimes the record type is defined

with duplicate allowed option. We can

try and find out if duplicate record exists

for a given Calc-key value.

Continue …..

MOVE INPUT-EMP-NAME TO EMPLOYEE-NAME.OBTAIN CALC EMPLOYEE.

OBTAIN DUPLICATE EMPLOYEE.

Continue



163

As shown in previous example, we

obtain the first record with matching

Calc-key value in normal way.

The second Obtain statement tries to

obtain duplicate record with same

Calc-key value. If it exists then IDMS

fetches the record, else an error code is

returned.

Continue …..

Continue



164

Member Record Retrieval

Many times, we need to retrieve owner

record for a set occurrence and then

proceed to retrieve one or more of its

member records.

Following are some of the examples of

such typical member retrieval criteria.

Continue …..

Continue



165

Continue …..

OBTAIN FIRST EMPLOYEE WITHIN DEPT-EMP.

OBTAIN LAST EMPLOYEE WITHIN DEPT-EMP.

OBTAIN NEXT EMPLOYEE WITHIN DEPT-EMP.

OBTAIN PRIOR EMPLOYEE WITHIN DEPT-EMP.

OBTAIN OWNER WITH DEPT-EMP.

OBTAIN 5 WITHIN DEPT-EMP.

Continue



166

By first retrieving the owner record, we

establish the currency for the subsequent

member retrievals. Owner becomes

current of run unit, record type and set

type. Now to access members within the

set becomes relatively simple task.

“Obtain First” gets the first member

record within the set.

Continue …..

Continue



167

“Obtain Last” gets the last member

record within the set. For this, the set

must have been defined with prior

linkage option.

Next option is known as Walking the Set.

“Obtain Next” gets each member in

sequence. This statement is executed in a

loop generally till end-of-set is reached.

Continue …..

Continue



168

“Obtain Prior” gets the prior member

record within the set. For this, the set

must have been defined with prior

linkage option. This works in same

manner as Next option, except that it

is in the reverse direction.

Continue …..

Continue



169

We can obtain owner of the set by

“Obtain Owner” statement.

If set is defined with Owner linkage

pointer then owner is obtained directly.

In case such pointer is absent, IDMS

walks through the entire set and

obtains the set owner.

Continue …..

Continue



170

We can obtain specific member record

within the set by its relative position with

respect to owner in the „next‟ direction.

“Obtain 5” will fetch the fifth member

record in the set.

Continue …..

Continue …..



171

Current Record Retrieval

Many times, we need to retrieve records

based directly on various currency.

Continue …..

OBTAIN CURRENT EMPLOYEE.

OBTAIN CURRENT WITHIN DEPT-EMP.

OBTAIN CURRENT WITHIN EMPLOYEE-AREA.

Continue …..



172

In first case, IDMS obtains the record

that is current of the Employee record

type.

In second case, current of the Dept-Emp

set type is fetched. Depending on

currency established, either Dept record

or an employee record is obtained.

Continue …..

Continue …..



173

In last case, current of employee-area

is obtained. e.g. if employee-area

contains employee, project, salary

record types then depending on

currency, the statement will fetch

record occurrence of any one of theserecord types.

Continue …..

Continue …..



174

Area Sweep Retrieval

Sometimes, we need to retrieve records by

doing an area sweep. IDMS scans through

the area in physical sequence. Area sweep

is used when we need to access all records

within an area, irrespective of the record

types and/or their sequence.

Co ue …..

Continue …..



175

OBTAIN FIRST WITHIN EMPLOYEE-AREA.

OBTAIN NEXT WITHIN EMPLOYEE-AREA.

OBTAIN LAST WITHIN EMPLOYEE-AREA.

In first case, the record having lowest

db-key value within the employee-area

will be fetched. In second case, record

having next highest db-key value will beobtained. The sweep in reverse direction

as in last case can also be made.

Continue …..



176

OBTAIN FIRST EMPLOYEE WITHIN

EMPLOYEE-AREA.

OBTAIN LAST EMPLOYEE WITHIN

EMPLOYEE-AREA.

As shown above, the record type can

also be qualified during the area sweep.

Only record type mentioned in the

statement (employee) are obtainedduring the sweep. Occurrences of other

record types are ignored.

Continue …..



177

Sort-Key Retrieval

We can retrieve records based on sort-

key values, provided the set is defined as

Sorted order option.

In our earlier example of American

baseball league database, suppose that

set Player-Position is defined as Sorted.

Continue …..



178

The sort-key data element is Position-name of Position record.

Then we can retrieve Position record

directly based on sort-key value as below.….

OBTAIN CALC PLAYER-REC.

MOVE INPUT-POSITION-NAME TO POSITION-NAME.

OBTAIN POSITION-REC WITHIN PLAYER-POSITION

USING POSITION-NAME.

Continue …..



179

In the example, a position-name value is

moved to sort-key data element and then

Obtain statement is issued using reference

to the sort-key element.

The retrieval appears similar to CALC, but

in this case the search is made only within

the current set occurrence and not within

entire record type.

Continue …..



180

DB-Key Value Retrieval

If we know the dB-key value of a record

then we can directly obtain the record.

This is useful in cases where we know

that a particular record would be

processed again later on during the

execution of the program.

Continue …..



181

When a record is successfully retrieved

or located, its dB-key value is available

in the IDMS Communication Block. We

can store this value in a variable storage

area for later use. Later on, we can use

the stored dB-key value to retrieve therecord and process it.

Continue …..



182

…..

MOVE INPUT-PLAYER-NAME TO PLAYER-NAME.

OBTAIN CALC PLAYER-REC.

…..

MOVE DBKEY TO SAVE-DBKEY.…..

OBTAIN DB-KEY IS SAVE-DBKEY.

Continue …..



183

Note that the dB-key of a record may

undergo change whenever a database is

reorganized. Hence it is not always

advisable to save dB-key values for a

long time with an intention of using

them later on.

Continue …..



184

Index Set Retrieval

Using index sets, following types of

retrieval is made possible which is

otherwise very difficult.

Generic key retrieval.

Random and sequential retrieval based

on a key other than Calc-key.

Continue …..



185

Suppose in our baseball example, Player

record has a system indexed set IX-

PLAYER-NAME on Player-Name

element, then we can retrieve a player

record by supplying a partial key to

IDMS. Such retrieval is not possible

unless we have index set. In Calc, we

have to supply complete key value.

Continue …..



186

01 WS-PLAYER-NAME.05 FIRST-INITIAL PIC X.

05 FILLER PIC X(29).

…..

MOVE LOW-VALUES TO WS-PLAYER-NAME.

MOVE WS-INITIAL-LETTER TO FIRST-INITIAL.

MOVE WS-PLAYER-NAME TO PLAYER-NAME.

OBTAIN PLAYER-REC WITHIN IX-PLAYER-NAME

USING PLAYER-NAME.

…..

OBTAIN NEXT PLAYER-REC WITHIN IX-PLAYER-NAME.

Continue …..



187

Say we want to retrieve all players

starting with „C‟.

We move „C‟ to ws-initial-letter and rest

is filled with low values. This is called

Partial key value.

Then the program will obtain first player

starting with name „C‟.

Continue …..



188

First obtain statement is random retrieval

using index set. Whereas the second

obtain statement is the example of the

sequential retrieval using index set.

Program has to check name field after

every retrieval to determine if it hasreached the last record with specific name.

MODIFY STATEMENT



189

The Modify statement is used to

change data element values in an

existing record occurrence.

Important considerations for a record

to be successfully modified are:

Ready the concerned area(s)

with one of the update options.

Continue …..



190

Making the record to be modifiedas current of run unit. This is done

by retrieving the record before

modifying it, by issuing Obtain.

Continue …..



191


OBTAIN CALC EMPLOYEE.

IF DB-STATUS-OK

MOVE NEW-EMP-ADDRESS

TO EMPLOYEE-ADDRESS

MODIFY EMPLOYEEPERFORM IDMS-STATUS.

Above example shows how an existing

Employee record is modified.

STORE STATEMENT



192

The Store statement is used to add

new record occurrence to the database.

Adding a new record involves:

Constructing new record

occurrence in the record‟s area in

variable storage.

Continue …..



193

Establish currency with correct set

occurrences in which the new

record participates as automatic

member. FIND is used to setcurrencies.

Issue Store statement specifying

the name of the record type we areadding.

Continue …..



194

Syntax for Store is :

STORE EMPLOYEE.

While adding a new record, following

information is analyzed.

Continue …..



195

Location where new record is added.

If location mode is CALC, then based

on Calc-key value, storage page is

calculated. For VIA, optimum

location is found based on the

location of owner record. If its

DIRECT, then program specifies the

page number through db-key.

Continue …..



196

Where in the set occurrences the new

record should be inserted.

Before issuing Store, set order option

is also examined. Depending on

order option like first, last, next etc,

the new record is inserted in

appropriate position within the set.

ERASE STATEMENT



197

The Erase statement is used to delete

a record occurrence from the

database.

Erase statement often affects not only

the record that is being deleted but, in

some cases, also members of sets

owned by that record.

Continue …..



198

There are four options available for the

Erase statement.

ERASE

ERASE ALL MEMBERS

ERASE PERMANENT MEMBERS

ERASE SELECTIVE MEMBERS

Continue …..



199

ERASE

We first begin by retrieving the record

we want to delete and thus the record is

made current of run unit. Then Erase isissued naming the record type.

The record is first disconnected from all

sets in which it participates as amember.

Continue …..



200

Then the record occurrence is

removed (erased) from the database.

If the record is the owner of any sets,

then the record will be erased ONLY

IF those sets are empty. If we try to

erase an owner record of a non-empty

set, IDMS returns an error status code.

Continue …..



201


OBTAIN CALC EMPLOYEE.

IF DB-STATUS-OK

ERASE EMPLOYEE

PERFORM IDMS-STATUS.

Above example shows how an existing

Employee record is erased from the

database with unqualified Erase statement.

Continue …..



202

ERASE ALL MEMBERS

First the record occurrence is removed

from the database.

Then all its members, both mandatory

and optional, are also removed from

the database.

Continue …..



203

ERASE PERMANENT MEMBERSFirst the record occurrence is erased from

the database.

Then all mandatory members in all sets

owned by the record are also removed.

Optional members are NOT removed but

they are disconnected from their respective

set occurrences.

Continue …..



204

Lastly, if the erased member is theowner of any sets then it is treated as if

an Erase Permanent is issued for it. Its

mandatory members are removed andoptional members are disconnected.

This process continues until all

members have been processed.

Continue …..



205

ERASE SELECTIVE MEMBERSFirst the record occurrence is erased from

the database.

Then all mandatory members in all sets

owned by the record are also removed.

Optional members are removed, provided

they do not participate in any other sets.

Continue …..



206

Lastly, if the erased member is theowner of any sets then it is treated as

if an Erase Selective is issued for it.

Its mandatory members are removed

and optional members are removed if

they do not participate in any other

sets.

CONNECT STATEMENT



207

Connect statement is used to link a record

occurrence into a set.

Here, we name both the record type and

the set type.

The statement causes the current of

record type to be connected to the set

occurrence that is current of set type.

CONNECT EMPLOYEE TO DEPT-EMP.

Continue …..



208

In case of set defined with Automatic

member option, the member record gets

connected automatically at the time of

addition to the database.

With set defined with Manual member

option, Connect statement is used to

manually set up link with a set

occurrence.

DISCONNECT STATEMENT



209

Disconnect statement cancels the membershipof a record in a set occurrence in which it

currently participates as a member.

The record that is being disconnected, must bedefined as an Optional member of that set. If

not then IDMS returns an error code.

DISCONNECT EMPLOYEE FROM DEPT-EMP.

QUEUE RECORDS

We write temporary data to a queue



210

We write temporary data to a queue

record in data dictionary and make this

data available to other IDMS COBOL

programs (DC-BATCH Mode).

Queue records are relatively

permanent records in that they are not

deleted when the system is shutdown

or when the system crashes. They are

deleted either explicitly by

programmer or after the retention

period specified for the queue is over.

Continue …..

As the data remains permanent it is



211

As the data remains permanent, it is

global in a sense. Thus, queues are

used to pass data information from

one application to another.

Specifically this feature is verywidely used in online applications

using ADSO.

QUEUE MANAGEMENT COMMANDS

Commands to write a record to a queue



212

Commands to write a record to a queue,

retrieve a queue record and delete a

queue record are:

PUT QUEUE ID queue-id GET QUEUE ID queue-id

DELETE QUEUE ID queue-id

Continue …..

PUT QUEUE ID queue-id



213

Q q

This command is used to store a

queue record in the data dictionary in

the queue identified by the queue-id.

An added parameter of Last or Firstcan be mentioned to instruct whether

the new queue record will be placed

at the beginning or end of the queue.Default is Last.

Continue …..

GET QUEUE ID queue-id



214

Q q

This command is used to transfer the

contents of a queue record to a

specified location in the variable

storage. Added parameter is Delete or Keep. Delete will remove the record

from the queue after retrieval. Keep

will retain the record in the queue.Default is Delete.

Continue …..

DELETE QUEUE ID queue-id



215

q

This command is used to delete one

or all queue records in a specified

queue. Added parameter is Current or

All. Current will delete only thecurrent record of the queue. All will

delete all queue records, including the

header record.Default is Current.

MAJOR CODES OF ERROR-STATUS



216

01 : FINISH02 : ERASE

03 : FIND/OBTAIN

05 : GET

06 : KEEP

07 : CONNECT

08 : MODIFY

09 : READY

Continue …..



217

11 : DISCONNECT12 : STORE

14 : BIND

18 : COMMIT

19 : ROLLBACK



218

Recovery and Restart

of Database



219

IDMS provides facilities for recoveringfrom problem situations and for restarting

after failures occur.

Journal files are used for the recovery

and restart facilities.

These facilities are dependant on the two

operating environments in which an

IDMS run unit executes.

IDMS OPERATING ENVIRONMENTS



220

IDMS application program can be run intwo operating environments: Local Mode

and Central Version.

All online applications that use IDMS/DC

or some other telecommunication facilities

must run under central version.

An application program that operates in

batch mode can be run either under the

control of central version or in local mode.

In central version a single copy of the

Central Version



221

In central version, a single copy of the

IDMS DBMS controls the operation of a

particular set of IDMS application

program run units.

No two central version are allowed to

update the same database area. All run

units that execute under the control of a

particular central version are chosen suchthat they all access the same group of

database areas.

Continue …..



222

Multiple copies of IDMS central versioncan execute in same region with each

copy accessing different set of database

areas.

Central version implements facilities for

recovering from system failures.

It is the preferred method of running anIDMS application.

A batch program that operates in local mode

Local Mode



223

has its own copy of IDMS DBMS loadedinto its partition, region or address space.

IDMS provides no automatic restart and

recovery facilities for applications runningin local mode.

Batch retrieval programs are good

candidates for running in local mode.

An application runs faster in local mode.

JOURNAL FILES



224

IDMS maintains set of journal files that

are used to recover from failures and to

restart aborted run units.

IDMS provides automatic restart and

recovery facilities for applications

running under central version AND for

run units those use journal files.

Journal files can be put on disk or tapes.

CHECKPOINTING



225

When a run unit begins by issuing BINDrun-unit statement, IDMS system writes

Begin checkpoint record on the journal

file. This contains information about

current status of the run-unit.

As run-unit executes, it may update

records in database. As each update

request is processed, IDMS writesBefore Image and After Image of the

updated record to the journal file.

Continue …..

When applications ends the run-unit by



226

pp y

issuing FINISH statement, IDMS writes

End checkpoint record on to the journal file.

Thus, at the end of execution of a run-unit

the journal files contains: Begin checkpoint

Before and After images of all

updated records and End checkpoint

RECOVERY and RESTART

Following are typical scenarios when run



227

g yp

unit is terminated abnormally.

Program error may cause the run unit

to terminate abnormally.

IDMS system may encounter

situations that require it to terminate

one or more run units abnormally. e.g.

Wait time limit has been exceeded toavoid deadlock.

Continue …..

In situations like these, when a run unit is



228

terminated abnormally after it has updated

one or more database records; IDMS works

backwards in the journal file until it

reaches the Begin checkpoint record anduses the information in the Before images

to reverse effect of database updates

already made by the aborted run unit. The

run unit can then be restarted from the

beginning.

RECOVERY UNIT



229

All run units that terminate normally,create at least two checkpoint records

on the journal file: BEGIN

CHECKPOINT when Ready/Bind

statement is executed and ENDCHECKPOINT when FINISH

statement is executed. Before and After

images that are recorded between these

two checkpoints constitute a record of

all updating the run unit performed.

Continue …..



230

The processing that a run unit performs between checkpoints is called Recovery

Unit.

In the simplest form, the entire run unitconstitutes a single recovery unit.

INTERMEDIATE CHECKPOINTS



231

In real life scenario (for onlineapplications), a separate run unit is started

for each incoming transaction. Very few

database updates are made during each run

unit. Each run unit is a single recoveryunit.

At times, it is required to divide the run

unit into many smaller run units to reduce

the time for recovery in case of run unit

failure.

Continue …..



232

This leads us to the concept of Intermediate checkpoints.

To create intermediate checkpoints, run

unit periodically issues a COMMITstatement to make permanent all

database updates that has already been

made.

THE COMMIT VERB



233

Commit verb is used to write Intermediate

checkpoints on the journal file.

There are two forms of Commit verb:

COMMIT and

COMMIT ALL

Continue …..

In COMMIT, IDMS releases all locks



234

except those placed on current records.

In COMMIT ALL, IDMS releases all

locks including those on current records.

In case of abnormal termination of run

unit, IDMS works backwards in the

journal file and reads till the most recent

COMMIT checkpoint is encountered.

Continue …..



235

Now the journal file is not read till

Begin checkpoint. The run unit can now

be restarted from the point at which it

wrote the most recent Commitcheckpoint.

A simple thumb rule of 500 or 1000

database updates is used to issue aCommit statement.

THE ROLLBACK VERB

Sometimes an application program may



236

itself decide to back out all the updates itmade to the database since it wrote the last

intermediate (commit) checkpoint.

To back out the changes, we can issue aROLLBACK statement.

It has two forms:

ROLLBACK and

ROLLBACK CONTINUE

ROLLBACK



237

It writes a checkpoint record to the journal file, nullifies all currencies,

automatically restore the database

using the before images from the

journal and terminate the run unit.

After issuing the unqualified Rollback,

to access the database again, we must

reissue the Bind.

ROLLBACK CONTINUE



238

This form causes IDMS to restore the

database but does not terminate the run

unit.

One can access the database immediately

without reissuing the Bind.



239

Locking Facilities

Locking facilities are provided for



240

controlling access to areas and to individualrecords when two or more run units require

access to the same database areas.

IDMS provides three levels of lockingfacilities.

Area Locks

Area Usage Modes Record Locks

AREA LOCKS



241

Area locks are used to prevent areasfrom being updated by more than one

IDMS central version or by more than

one application running in local mode.

If an area is locked that is required by a

local mode application, that local mode

application ABENDS.

Continue …..

If required area is NOT locked, area



242

lock is set by the local mode

application and no other local mode

application is given access to that area.

An area locked by a local mode

application is released when that

application executes its FINISH

statement (end of run-unit).

Continue …..

If required area is locked that is



243

required by an IDMS central version,execution of that central version

continues, but no run-unit executing

under the control of that central version

will be given access to the already

locked area. The area is said to be

Varied Offline to that central version.

Run-units that attempt to access an area

that is varied offline are abnormally

terminated.

Continue …..

If required areas are NOT locked, then

those areas are locked by the central



244

version. Run-units executing under the

control of that central version can

access those areas. No other central

version will be given access to locked

areas.

An area that is locked by a central

version is released only when the

central version is shut down.

AREA USAGE MODES



245

Area usage modes control how

database areas under the control of a

central version can be accessed.

The six possible usage modes for a

database area are as follows:

Continue …..

(Sh d) R i l



246

(Shared) Retrieval Protected Retrieval

Exclusive Retrieval

(Shared) Update

Protected Update

Exclusive Update

The „Shared‟ word is optional.

Retrieval or Shared Retrieval



247

We are requesting only retrieval access

to the area. All other run units under

the same central version will beallowed to RETRIEVE or UPDATE

records in the same area, provided they

do no specify usage mode Exclusive.

Protected Retrieval

We are requesting retrieval access to the area

d i l ifi h h i



248

and it also specifies that no other run unit

should update records in the same area for the

duration of our run unit. All other run units

under the same central version will be allowedto retrieve records in the same area provided

they did not specify usage mode Exclusive.

If another run unit is already updating records

in the area, our run unit will wait till that run

unit finishes.

Exclusive Retrieval



249

We are requesting retrieval access to the area

and it also specifies that no other run unit

should retrieve or update records in the same

area till our run unit finishes execution. If

another run unit is already accessing the

area, our run unit will wait till that run unit

finishes.

This mode is not often used.

Update or Shared Update



250

We are requesting updating access to the

area. All other run units under the same

central version will be allowed to retrieve

or update records in the same area as long

as they do not specify Protected or

Exclusive usage mode options in Ready

statements.

Protected Update

We are requesting update access to the area and

if i th t th it h ld t b bl



251

specifying that other run units should not be able

to update records in the same area till our run unit

finishes. All other run units will be allowed to

retrieve records in the same area as long as they

do not specify Protected or Exclusive as usage

modes.

If another run unit is already accessing the area,

our run unit will wait till that run unit finishes.

Exclusive Update



252

We are requesting update access to the area

and further specifying that no other run unit

should either retrieve or update records in the

same area while our run unit is executing.

This option gives our run unit exclusive use

of the area.

p

d a t e

e

r i e v a l

U

p d a t e

Re

t r i e v a l

U

p d a t e

Re

t r i e v a l

Run Unit 2



253

S h a r e d U p

S h a r e d R e t

P r o t e c t e d U

P r o t e c t e d R e

E x c l u s i v e U

E x c l u s i v e R e

Shared Update Y Y N N N N

Shared Retrieval Y Y Y Y N N

Protected Update N Y N N N N

Protected Retrieval N Y N Y N N

Exclusive Update N N N N N N

Exclusive Retrieval N N N N N N

R u n U n i t 1

IMPLICIT RECORD LOCKS

It i i t i d l f it



254

It is maintained only for run-unitsoperating under Central Version.

When we use usage mode options that

allow more than one run-unit to access

the same area while updating is taking place, IDMS sets Implicit record locks

to prevent same record from being

updated simultaneously by two or more

run-units.

Continue …..

Record locks are generally maintained

f h d d t t d d t d



255

for shared and protected update modeand shared retrieval mode.

Implicit locks can be either Shared or Exclusive.

Implicit Shared lock guarantees thatonly one run-unit is allowed to update arecord while others can retrieve thesame record.

Implicit Exclusive lock ensures that noother run-unit can either update or retrieve the record.

Implicit shared locks is placed on a

record hen it is retrie ed and

Continue …..



256

record when it is retrieved and

Implicit Exclusive lock is placed on a

record when it is accessed through a

DML update verb.

Shared Lock remains in effect till

currency changes.

Exclusive Lock remains in effect till

run-unit ends (Finish) or until

Commit is issued.

Explicit locking is the most efficient way of

l i d l k I b b di h

EXPLICIT RECORD LOCKS



257

placing record locks. It can be set by coding the

KEEP statement or by the KEEP clause of the

FIND/OBTAIN statement.

Explicit lock remain is effect until Finish isexecuted or Commit is issued.

e.g. Obtain Keep Calc Employee.

Obtain Keep Exclusive Calc Employee.First is explicit shared lock and second is

explicit exclusive lock.

Another way of setting explicit locks is to code

t K t t t ft d i

Continue …..



separate Keep statement after a record is

retrieved.

e.g.

Keep exclusive current.

Keep current within Dept-Employee.

Training IDMS

Documents

Transcript of Training IDMS