Version 2.0
16-May-2002
1
IDMS/R
Table of Contents
1. Overview.....................................................................................................................6
1.1. IDMS/R and DBMS...........................................................................................6
1.2. Database Approach...........................................................................................6
1.2.1. Data Integrity.............................................................................................6
1.2.2. Application Development Productivity....................................................7
1.3. Different Database Architectures.....................................................................7
1.3.1. Hierarchical................................................................................................7
1.3.2. Network......................................................................................................7
1.3.3. Relational....................................................................................................8
1.3.4. Difference Between RDBMS and Network, Relations, Chain Pointers9
1.4. IDMS/R: - Network and Relational Facilities, DBMS.................................10
2. Logical Database Structure....................................................................................12
2.1. Entity, Logical and Physical Structure..........................................................12
2.2. Attributes, Relationships – Training Database.............................................12
2.3. Entity-Relationship Diagrams........................................................................13
2.4. IDMS Database Records, Record Type, Record Occurrences....................14
2.5. One-To-Many and Many-To-Many Relationships.......................................15
2.6. IDMS Set, Set Type, Set Occurrence, Bubble Diagram...............................15
2.7. Schema, Subschema.........................................................................................19
3. IDMS/R Batch Program..........................................................................................20
3.1. Operating Environment..................................................................................20
3.2. DML Statements: Executable and Compiler Directive................................20
3.3. Three Steps Compilation: DML Pre-processor, Compilation and Linking20
3.4. Compiled Listing of Sample IDMS/R Program............................................22
3.5. Run-Unit...........................................................................................................28
3.6. Virtual Storage Layout....................................................................................29
3.7. DML Execution Steps......................................................................................30
4. Physical Database Structure...................................................................................32
4.1. Areas.................................................................................................................32
4.2. Pages..................................................................................................................32
4.3. DB-Key..............................................................................................................34
4.4. Multiple Areas..................................................................................................34
4.5. Files...................................................................................................................35
4.6. Record occurrence – Prefix, Data..................................................................35
5. Record.......................................................................................................................37
5.1. Record Name....................................................................................................37
5.2. Record Identifier..............................................................................................37
5.3. Storage Mode...................................................................................................37
5.4. Record Length..................................................................................................38
5.5. Location Mode.................................................................................................38
5.6. Duplicates Option............................................................................................40
5.7. Area Name........................................................................................................41
5.8. Bachman Diagram For Record Type.............................................................41
6. Set..............................................................................................................................43
2
IDMS/R
6.1. Set Name...........................................................................................................43
6.2. Linkage Options...............................................................................................43
6.3. Order Options..................................................................................................46
6.4. Bachman Diagram For Set.............................................................................50
7. Retrieval: Basic, By Sort-key, Indexed Set, Sweeping Areas..............................51
7.1. Basic Retrieval: CALC, Through Relationship............................................51
7.2. CALC Retrieval: Random access...................................................................51
7.3. Error Handling................................................................................................52
7.4. Access By Walking Sets i.e. Access Through Set Relationship....................53
7.5. Retrieval By Sort-Key Value..........................................................................58
7.6. Generic Key Retrieval.....................................................................................59
7.7. Indexed Set.......................................................................................................59
7.8. Retrieval Using Indexed Set............................................................................60
7.9. Bachman Diagram: Indexed Set.....................................................................61
7.10. Retrieval By Sweeping Areas......................................................................62
8. Currency...................................................................................................................64
8.1. Currency Table................................................................................................64
8.2. Currency Loss..................................................................................................66
8.3. Storing and Retrieval By DB-Key Value.......................................................68
8.4. Obtain Vs. Find and Get.................................................................................69
8.5. IF <set-name> EMPTY / MEMBER:............................................................71
9. Types of Set Relationships......................................................................................74
9.1. Hierarchies.......................................................................................................74
9.2. Junction Record: Multiple Set Membership.................................................76
9.3. Nested Structure – Bill Of Material...............................................................77
10. Set Membership Options.....................................................................................84
10.1. Disconnect option.........................................................................................84
10.2. Connect option.............................................................................................85
10.3. Bachman Diagram and Examples..............................................................86
11. DML Data Update Functions.............................................................................88
11.1. Ready............................................................................................................88
11.2. Store..............................................................................................................88
11.3. Modify...........................................................................................................91
11.4. Erase..............................................................................................................92
11.5. Connect.........................................................................................................94
11.6. Disconnect.....................................................................................................95
12. Recovery and Restart..........................................................................................97
12.1. IDMS/R Operating Environments.............................................................97
12.2. Journal Files, Checkpoints..........................................................................98
12.3. Recovery / Restart........................................................................................98
12.4. Commit.........................................................................................................99
12.5. Recovering From Failures........................................................................101
12.6. Rollback......................................................................................................101
13. Locking...............................................................................................................103
13.1. Area Locks..................................................................................................103
13.2. Area Usage Modes.....................................................................................103
3
IDMS/R
13.3. Record Locks – Implicit, Explicit.............................................................105
14. Utilities................................................................................................................110
14.1. DMLO.........................................................................................................110
14.2. OLQ............................................................................................................111
15. Appendix A: Employee Database.....................................................................113
16. Appendix B: Compilation and Run JCL.........................................................115
17. Appendix C: IDMS/R ERROR-STATUS VALUES......................................118
18. Appendix D: References......................................................................................121
4
IDMS/R
Day-Wise Schedule
Day 1
Overview
Logical Database Structure
IDMS/R Batch Program
Day 2
Physical Database Structure
Record
Set
Day 3
Retrieval: Basic, By Sort-key, Indexed Set, Sweeping Areas
Day 4
Currency
Day 5
Types of Set Relationships
Day 6
Set Membership Options
DML Data Update Functions
Day 7
Recovery and Restart
Locking
Day 8
Utilities – DMLO, OLQ
5
IDMS/R
1. Overview
6
IDMS/R
1.2.2. Application Development Productivity
1.3.1. Hierarchical
In a hierarchically structured database, data records are typically connected with
embedded pointers to form a tree structure / configuration, in which a dependent
record type has one and only one parent. IMS is an example of hierarchical
DBMS.
Supplier
Order
Line Item
Fig. 1.1.
1.3.2. Network
A network-structured database typically uses embedded pointers to create a mesh
structure / configuration, in which a dependent record type can have more than
one parent. IDMS/R is an example of network DBMS.
7
IDMS/R
The term network in this context has nothing to do with a communications
network! It refers rather to the kinds of data structures and operators (e.g. for
retrieval) supported by the system.
Supplier Part
Order
Line Item
Quotation
Fig. 1.2.
Dependent records Line-Item and Quotation have more than one parent.
1.3.3. Relational
In a relational DBMS, data is represented in the form of tables in which all
associations are expressed using values in the stored data and no embedded
pointers are required to represent relationships between records.
Supplier
Order Part
Quotation Line-Item
Fig. 1.3.
8
IDMS/R
1.3.4. Difference Between RDBMS and Network, Relations, Chain
Pointers
The reason “relational systems” are called “relational” is that the term relation is
basically just a mathematical term for a table.
In the relational model, the data and the relationships among data are represented
by a collection of tables. The network model differs from the relational model in
that data are represented by collection of records, and relationships among data
are represented by links.
Links are implemented in the Network model by adding pointer fields to records
that are associated via a link.
In the Training department, many courses are conducted for different subjects.
There are two record types, namely Subject and Course, which are linked.
SUBJECT
#0 S001 MVS *0 *6
#1 S002 JCL *1 *7
#2 S003 VSAM *2 *2
#3 S004 IDMS *3 *3
9
IDMS/R
COURSE
*0 C0701 FIT-MVS *4 - #0
*1 C0702 FIT-JCL *5 - #1
*2 C0703 FIT-VSAM - - #2
*3 C0804 FIT-IDMS - - #3
*4 C0901 EXP-MVS *6 *0 #0
*5 C0902 EXP-JCL *7 *1 #1
*6 C1001 FIT-MVS - *4 #0
*7 C1002 FIT-JCL - *5 #1
Consider subject MVS with Sub-Id S001: - “First” pointer points to first MVS
course C0701. “Next” pointer of course C0701 points to next MVS course i.e.
C0901 and so on.
It is clear from the preceding discussion that the Network model is closely tied to
the implementation. Querying is simple in the relational model, while it is
significantly more complicated in the network model. The programmer is forced
to think in term of links, and how to traverse them to get at needed information.
Data manipulation in the network model is hence said to be navigational.
The relational and network capabilities of IDMS/R are supported by a single database
management system product. This means that data stored in the form of network
structures can be accessed by conventional application programs, but can also be
accessed by the relational facilities for those applications that require a relational
view of the network structured data. In turn, data entered through the relational
facility can be used to update the production, network-structured database. In either
10
IDMS/R
case, all database access, input/output operations, and space management are
performed by the same system components.
The heart of any database product is the software component that manages access to
the database. This component is most commonly called the DBMS. IDMS/R consist
of a set of software modules that manage the data elements that are stored in the
database and maintains the relationships that exist between them. A major purpose of
a DBMS is to isolate application programs from the details concerning how data
elements are physically stored. To this end, the data stored in an IDMS/R database is
accessed only by the DBMS and never directly by an application program.
IDMS/R support for a networked structured database is provided via two common
languages that designers and programmers use to control access to the database: data
description language (DDL) and data manipulation language (DML). The DDL is
used by database designers to describe the logical and physical structure of the
database to DBMS software and to application programs. Application programs use
DML to specify how the database is accessed. Application programs make requests
for access to the database by executing DML statements; the DBMS intercepts these
requests and performs the required accesses to the database to satisfy these requests.
11
IDMS/R
On a lower level we are concerned with software, where we describe the logical
structure of the database that we are using to represent information about entities in
the database.
On a still lower level is the hardware, where we describe the physical structure of the
database and the way in which logical records are implemented in computer storage.
The Training Dept conducts courses for various subjects. At any given point
of time, multiple courses can be in progress.
There are 10 faculties in the department. A faculty can teach multiple subjects.
A subject can be taught by multiple faculties.
There are many participants for a course.
Performance of a participant in a course is measured in terms of attendance,
assignments and test marks.
12
IDMS/R
In discussing entities, we can discuss the attributes that an entity has and the
relationships that exist between the entities.
Entity Attributes:
Entity Relationships:
We can identify a number of relationships between the entities about which we are
storing information. E.g. the Faculty and Course entities participate in one-to-many
relationship. Each course is conducted by one faculty, but each faculty conducts
many courses. The Course and Participant entities form another one-to-many
relationship. Each participant attends one course, and each course has many
participants. The Participant and Performance entities also form one-to-many
relationship. The Faculty and Subject entities form a many-with-many relationship.
One faculty can teach many subjects, and a subject can be taught by many faculties.
Faculty Subject
Course
Participant
Performance
Fig. 2.1.
Each entity is represented by a square-cornered box. We use arrow symbols for
connecting the boxes to represent relationships. The “arrow head” points to the many
13
IDMS/R
side of a relationship and the other end of the arrow indicates the “one” side of a
relationship.
Subject Record
Subject-Id Subject-Name Subject-Stream
PIC X(04) PIC X(10) PIC X(06)
(Subject record type)
14
IDMS/R
the two entities alone, but are associated with the intersection between the two entity
types. This intersection is represented by another record type, called junction record
type, which has one-to-many relationships with the two entity types. The junction
record resolves the many-to-many relationship and implements this many-to-many
relationship indirectly.
Faculty Subject
Faculty-Course Subject-Course
Course
Course-Participant
Participant
Participant-Performance
Performance
Fig. 2.2.
A set that consist of only two record types is generally given a name that is a
concatenation of the names of Owner and Member record types separated by hyphen.
E.g. Faculty-Course, Course-Participant.
15
IDMS/R
other hand, consists of a specific single occurrence of the owner record type and all
occurrences of the member record type that are associated with it.
Faculty
Sudhir
Course
C0702 Course
C0804
Course
C0703
Fig. 2.3.
There exists one occurrence of the Faculty-Course set for each occurrence of the set’s
owner record type.
A set consists of an owner record type and one or more member record types. A set
occurrence consists of one occurrence of the owner record type and any number of
member record occurrences. Records in each occurrence of the set are physically
linked together by pointers. Above figure shows an example of a set occurrence.
Notice that the set occurrence begins with an owner record occurrence. The owner
record occurrence points to the first occurrence of the member record type, that
occurrence points to the next member record occurrence, and so on until the last
member record occurrence is encountered. The last member record occurrence then
points back to its owner. Accessing members by following the pointers from one
record occurrence to the next is called walking the set. A set occurrence can also
consists only of an owner record occurrence and no member record occurrences, in
which case the set occurrence is said to be empty. In the following figure, the Faculty
record for Raju is the owner record of an empty set.
Faculty
Raju
16
IDMS/R
Fig. 2.4.
MVS JCL
CO901 CO902
JCL
MVS
CO702 C1002
C1001
CO701 CO902
Shilpa CO901
Kishore
Fig. 2.5.
17
IDMS/R
Fig. 2.6.
18
IDMS/R
Subschemas provide a means of simplifying the view of the database for each
application program. Subschemas also provide the ability to restrict access to only
those record types, data elements and set types that a particular application program is
authorized to access.
19
IDMS/R
Some DML statements are carried out during the program’s execution.
An IDMS/R application program has DML statements embedded in the source code
to request database access and other support functions. Before the source program is
compiled, the program is first read by a DML processor. The DML processor
validates the DML statements and creates a translated version of the source program
20
IDMS/R
in which DML statements have been replaced by appropriate calls to IDMS/R. Output
from the DML processor is a new source program, which serves as the input to the
compiler. In addition, the DML processor can optionally generate a source statement
listing containing error diagnostics. The source program that the DML processor
generates differs from the input IDMS/R source file in the following way:
Database record descriptions have been copied into the program from the data
dictionary.
IDMS/R DML statements have been changed to comments.
DML requests that involve the transfer of control to IDMS/R have generated
appropriate CALL statements.
After the translated source program has been compiled, the resulting object module is
processed by the linkage editor to create an executable load module. The linkage
editor also includes a copy of a routine called the IDMS Interface Module in the
finished load module. Requests that the program makes for IDMS/R services result in
calls to the IDMS Interface module.
Source
DML Data
Statements Dictionary
Processor
Error
COBOL
Listing
Source
COBOL
Compiler
Error
Object
Listing
Module
Compilation Errors
Linkage
Editor
Error
Load
Listing
Module
Linking Errors
Fig. 3.1.
The DML processor must have access to the data dictionary as it processes the source
program. The programmer can use COPY or INCLUDE statements to merge in
21
IDMS/R
predefined program modules, record descriptions. The DML processor automatically
includes record description entries defined by the subschema the program is using. In
addition, the DML processor automatically updates the data dictionary. E.g. the DML
processor stores into the data dictionary information about the types of DML
statements that the program executes against database records.
22
IDMS/R
VALUE SPACES.
03 IDBMSCOM-AREA PIC X(100)
VALUE LOW-VALUE.
03 IDBMSCOM REDEFINES IDBMSCOM-AREA
PIC X
OCCURS 100.
03 RIDBMSCOM REDEFINES IDBMSCOM-AREA.
05 DB-SUB-ADDR PIC X(4).
05 FILLER PIC X(96).
03 DIRECT-DBKEY PIC S9(8) COMP SYNC.
03 DIRECT-DBK REDEFINES DIRECT-DBKEY
PIC S9(8) COMP SYNC.
03 DATABASE-STATUS.
05 DBSTATMENT-CODE PIC X(2).
05 DBSTATUS-CODE PIC X(5).
03 FILLER PIC X.
03 RECORD-OCCUR PIC S9(8) COMP SYNC.
03 DML-SEQUENCE PIC S9(8) COMP SYNC.
01 SUBSCHEMA-SSNAME PIC X(8)
VALUE 'EMPSS01 '.
01 SUBSCHEMA-RECNAMES.
03 SR460 PIC X(16)
VALUE 'STRUCTURE '.
03 SR455 PIC X(16)
VALUE 'SKILL '.
03 SR450 PIC X(16)
VALUE 'OFFICE '.
03 SR445 PIC X(16)
VALUE 'NON-HOSP-CLAIM '.
03 SR440 PIC X(16)
VALUE 'JOB '.
03 SR435 PIC X(16)
VALUE 'INSURANCE-PLAN '.
03 SR430 PIC X(16)
VALUE 'HOSPITAL-CLAIM '.
03 SR425 PIC X(16)
VALUE 'EXPERTISE '.
03 SR420 PIC X(16)
VALUE 'EMPOSITION '.
03 SR415 PIC X(16)
VALUE 'EMPLOYEE '.
03 SR410 PIC X(16)
VALUE 'DEPARTMENT '.
03 SR405 PIC X(16)
VALUE 'DENTAL-CLAIM '.
03 SR400 PIC X(16)
VALUE 'COVERAGE '.
01 SUBSCHEMA-SETNAMES.
03 COVERAGE-CLAIMS PIC X(16)
VALUE 'COVERAGE-CLAIMS '.
03 DEPT-EMPLOYEE PIC X(16)
VALUE 'DEPT-EMPLOYEE '.
03 EMP-COVERAGE PIC X(16)
VALUE 'EMP-COVERAGE '.
03 EMP-EXPERTISE PIC X(16)
VALUE 'EMP-EXPERTISE '.
23
IDMS/R
03 EMP-NAME-NDX PIC X(16)
VALUE 'EMP-NAME-NDX '.
03 EMP-EMPOSITION PIC X(16)
VALUE 'EMP-EMPOSITION '.
03 JOB-EMPOSITION PIC X(16)
VALUE 'JOB-EMPOSITION '.
03 JOB-TITLE-NDX PIC X(16)
VALUE 'JOB-TITLE-NDX '.
03 MANAGES PIC X(16)
VALUE 'MANAGES '.
03 OFFICE-EMPLOYEE PIC X(16)
VALUE 'OFFICE-EMPLOYEE '.
03 REPORTS-TO PIC X(16)
VALUE 'REPORTS-TO '.
03 SKILL-EXPERTISE PIC X(16)
VALUE 'SKILL-EXPERTISE '.
03 SKILL-NAME-NDX PIC X(16)
VALUE 'SKILL-NAME-NDX '.
03 CALC PIC X(16)
VALUE 'CALC '.
01 SUBSCHEMA-AREANAMES.
03 EMP-DEMO-REGION PIC X(16)
VALUE 'EMP-DEMO-REGION '.
03 INS-DEMO-REGION PIC X(16)
VALUE 'INS-DEMO-REGION '.
03 ORG-DEMO-REGION PIC X(16)
VALUE 'ORG-DEMO-REGION '.
* COPY IDMS RECORD DEPARTMENT.
01 DEPARTMENT.
02 DEPT-ID-0410 PIC 9(4).
02 DEPT-NAME-0410 PIC X(45).
02 DEPT-HEAD-ID-0410 PIC 9(4).
02 FILLER PIC XXX.
PROCEDURE DIVISION.
0000-MAIN.
PERFORM 1000-INIT THRU 1000-EXIT.
PERFORM 2000-PROCESS THRU 2000-EXIT.
PERFORM 8000-WRAP-OFF THRU 8000-EXIT.
STOP RUN.
0000-EXIT.
EXIT.
1000-INIT.
* BIND RUN-UNIT.
CALL 'IDMS' USING SUBSCHEMA-CTRL
IDBMSCOM (59)
SUBSCHEMA-CTRL
SUBSCHEMA-SSNAME.
PERFORM IDMS-STATUS.
* BIND DEPARTMENT.
CALL 'IDMS' USING SUBSCHEMA-CTRL
IDBMSCOM (48)
SR410
DEPARTMENT.
PERFORM IDMS-STATUS.
24
IDMS/R
* READY ORG-DEMO-REGION.
CALL 'IDMS' USING SUBSCHEMA-CTRL
IDBMSCOM (37)
ORG-DEMO-REGION.
PERFORM IDMS-STATUS.
ACCEPT WS-DEPT-ID.
1000-EXIT.
EXIT.
2000-PROCESS.
MOVE WS-DEPT-ID TO DEPT-ID-0410.
* OBTAIN CALC DEPARTMENT.
CALL 'IDMS' USING SUBSCHEMA-CTRL
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
PERFORM IDMS-STATUS.
2000-EXIT.
EXIT.
8000-WRAP-OFF.
* FINISH.
CALL 'IDMS' USING SUBSCHEMA-CTRL
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.
CALL 'IDMS' USING SUBSCHEMA-CTRL
IDBMSCOM (67).
25
IDMS/R
CALL 'ABORT'.
ISABEX. EXIT.
Eg. 3.1.
Identification Division
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.
IDMS-CONTROL SECTION.
PROTOCOL. MODE IS BATCH
IDMS-RECORDS MANUAL.
Note: - If we mention ‘MODE IS BATCH DEBUG’, then DEBUG indicates that the
DML processor will supply additional code in the resulting source program that will
be helpful in program debugging using the debugger.
Data Division
26
IDMS/R
This division begins with a new section called ‘Schema Section’ in addition to File
section and Working-Storage section. Schema Section specifies the names of the
subschema and the schema used in the program.
DATA DIVISION.
SCHEMA SECTION.
DB EMPSS01 WITHIN EMPSCHM VERSION 100.
The 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
Status Checking:
READY ORG-DEMO-REGION.
PERFORM IDMS-STATUS.
27
IDMS/R
The IDMS-STATUS routine is brought into the program as a result of a COPY IDMS
statement that is coded toward the end of the source listing:
The program performs the IDMS-STATUS paragraph after each DML statement is
executed to determine if the requested operation executed successfully. IDMS/R
returns, in the ERROR-STATUS field of the IDMS Communications Block, a status
code that describes the results of the requested operation.
Database access: - The program accepts the value of Dept-Id and moves that value to
Dept-Id field of Department record layout in working storage. The program then
issues a DML statement to read the appropriate Department database record:
OBTAIN CALC DEPARTMENT.
If IDMS/R cannot locate a Department record having the requested dept-id, the
program displays an error message. If the Department record is found, the program
displays department-name.
Finish statement: - The program ends the run unit by executing a FINISH statement.
The FINISH statement releases the database areas from the program's control.
Finally, the program ends by executing a STOP RUN statement.
3.5. Run-Unit
A run unit is the portion of the program’s processing during which it has access to
one or more database areas and can request IDMS/R services. The program may
perform some processing before it begins an IDMS/R run unit and it may perform
processing after the run unit is completed. Also the program may begin and end more
than one run unit in the same program execution.
28
IDMS/R
A run unit is a unit of work within IDMS/R. Each run unit represents a concurrently
executing task that is interacting with an IDMS/R database.
A run unit begins with the BIND RUN-UNIT statement and ends with the FINISH
statement. The BIND RUN-UNIT and FINISH statements are analogous to the
processing time between OPEN and CLOSE file statements. A program can consist
of any number of run units that are executed serially, but typically contains only one.
Note: - If your program consists of more than one run unit, you must reinitialize the
ERROR STATUS field in the IDMS Communication Block to the value 1400, before
reissuing the BIND RUN-UNIT and READY statements.
IDMS/R is generally contained in its own area of virtual storage, i.e. an address space
in an MVS system. The IDMS/R area of virtual storage contains the IDMS/R
database management system and the system buffers. The system buffers are the
storage locations that IDMS/R uses in transferring database pages to and from direct
access storage. The IDMS/R area also contains the subschema tables for the IDMS/R
application programs currently in execution. Subschema tables are loaded when an
application program requests database access.
The area of virtual storage occupied by the IDMS/R application program contains
variable storage, the IDMS/R interface module and an executable code. Variable
storage contains the data areas to be modified by the program during execution. In
addition to other storage areas used by the program, variable storage contains a
control block called the IDMS communication block. IDMS/R stores into the IDMS
communication block information about the results of each request for an IDMS/R
service. Operating System
Operating System
IDMS/R
Address Space
IDMS/R
Address Space
ii. Transfer control to IDMS/R: - The IDMS/R interface module transfers control
to IDMS/R DBMS, which performs the requested service. Since access to the
database is controlled by the subschema tables, the DBMS reads the tables to
determine record, set, and area definitions, currencies, and access restrictions.
iii. Retrieve database record and build subschema record: - The required
database record is retrieved, if required, and an image of the requested
subschema record is built in variable storage. It is not always necessary for the
DBMS to read the database to satisfy a retrieval request. E.g. the required
record may already be in a system buffer due to a previous retrieval. If the
desired record is not already in a buffer, the DBMS uses operating system data
management facilities to read the required database page from direct access
storage.
iv. Update currencies: - The DBMS updates run-unit, record type, set type and
area currencies, as required. This is done by moving the database key and other
control data from the system buffers to the subschema tables.
30
IDMS/R
vi. Return to the program: - After updating the Communication block, control is
passed first from the DBMS to the IDMS/R Interface Module and then to the
application program at the statement following the DML statement just
executed.
vii. Test status information: - The application program should contain code to
check the results of each requested service. The ERROR-STATUS field of
IDMS Communication Block contains the status of DML statement just
executed.
31
IDMS/R
4.1. Areas
An IDMS/R database is divided into one or more areas. An area is defined as the
major named subdivision of addressable storage in the database. Areas contain
occurrences of the records that make up networked-structured databases. Each area
can contain occurrences of one or more record types, but all occurrences of a
particular record type must be located in the same area.
4.2. Pages
An area can be further subdivided into pages, which constitute the smallest logical
units of database storage. A page is the unit of data that is moved between the
database and the system buffers that are used by IDMS/R to hold the retrieved
records. The diagram given below shows the structure of a page from a database area.
Header
Record Occurrences
Record Occurrences
Free Space
Fig. 4.1.
Each page can be considered as a mini-database since each normally stores several
records and contains its own control information. The IDMS/R database page is
broken into four distinct sections.
i. The header of a page is 16 bytes long, consisting of the page number (4 bytes),
the next pointer (4 bytes), the prior pointer (4 bytes), the space available count
(2 bytes) and a 2-byte unused space.
SA (Space Available Count) is the number of bytes of free space on the page.
Initial value of this field is (PAGESIZE – 32) bytes.
ii. The page body that contains all of the object data records being stored on the
page. The data stored in the page body is always concentrated at the front of the
page body. This feature, that continuously optimizes the available space on the
page, reduces unusable space to a minimum.
iii. The line index group contains one or more line index pointers, one for each
record stored on the page. The indexes move from the end of the page backward
into the page body as more records are placed on the page.
The line index itself is 8 bytes in length, broken into four 2-bytes fields: the
record identifier, the displacement of the beginning of the record from the start
of the page, the record length and the length of the record prefix (the pointers).
iv. The page footer consists of 16 bytes, broken into a line index for the header (8
bytes), the line space count (2 bytes), the page update count (2 bytes) and the
page number (4 bytes).
Note that the page number occurs as the first and last four bytes of each page. This is
added protection against undetected database damage. IDMS/R actually checks both
values each time a page is read; an unequal value causes immediately alarm within
DBMS.
33
IDMS/R
Each page has a unique page number. Within a page, each record occurrence has
unique line number.
Pages in an area must be sequentially numbered. Gaps in the page numbers can occur
between areas. Areas cannot overlap i.e. a page number can belong to one area only.
4.3. DB-Key
Each record occurrence is assigned a unique numeric identifier, called its database
key (db-key). Format of db-key is shown below.
A record occurrence’s db-key consists of a 32-bit field that typically contains a 23-bit
page number and an 8-bit line number. The page number identifies the page in which
the record occurrence is stored and the line number identifies the location of the
record occurrence within that page.
IDMS/R uses database keys to keep track of where in the database record occurrences
are physically stored.
34
IDMS/R
Security. If we need to restrict access to certain record types, we can place them
together in an area that is protected using IDMS/R security facilities. E.g. access
to Payroll-Area is restricted.
Database recovery and backup. The database can be initialized, restructured and
backed up on an area-by-area basis. Areas assigned to highly volatile record types
can be given different treatment from areas that are assigned to record types
whose occurrences are changed little.
4.5. Files
Each page corresponds to a physical record that is stored in a file, and all data
transfers between the database and the system buffers are accomplished a page at a
time.
The ways in which areas can be mapped into files in direct access storage are as
follows:
Many (or all) areas can be mapped into one file if all the areas have the same page
size.
Each area can be mapped into a different file.
One area can be mapped into many files.
The physical records stored in the database consist of more than the data elements
used by the application program. IDMS/R also maintains information about the
relationships that exist between records. These relationships are physically
implemented by linking record occurrences together with pointers. Pointers contain
35
IDMS/R
the addresses of related record occurrences and are stored with the data elements that
make up each record occurrence.
Prefix Data
Pointer 1 Pointer 2 Pointer 3 ………. Data Data Data ……..
Element 1 Element 2 Element 3
36
IDMS/R
5. Record
Here, we discuss the characteristics that apply to record types.
F (fixed length)
V (variable length)
C (compressed)
The compressed storage mode can be used in conjunction with the fixed-length or
variable-length storage mode. E.g. a storage mode of FC indicates that record
occurrences are fixed length and compressed. When data compression is used, an
IDMS/R module automatically compresses and decompresses the data. Application
programs are not aware that compression and decompression is taking place.
37
IDMS/R
The record length, expressed in bytes, is the actual data length for a fixed-length
record or the maximum data length for a variable-length record.
With the CALC location mode, a particular field (data element) within the record
itself must be declared as the CALC-key. When the application program requests that
record occurrences be stored into the database, IDMS/R uses the CALC-key value to
calculate the page into which the record should be placed. IDMS/R uses a
randomizing routine to distribute records evenly over its area. To retrieve a record
later, the application program supplies IDMS/R with a CALC-key value, and
IDMS/R uses the randomizing routine to locate the proper page and directly retrieve
the record occurrence that has the supplied CALC-key value.
E.g., Department record type with CALC location mode and Dept-Id-0410 field as
CALC-key. When we add each new Department record occurrence to the database,
IDMS/R uses the Dept-Id-0410 value contained in the record we are adding to
calculate the specific page within the database to store the record. It then stores the
record occurrence on that page. To retrieve the record for a particular department
later, the application program moves the Dept-Id-0410 value for the desired
department into a designated application program storage area and executes a DML
retrieval function. IDMS/R then uses the randomizing routine to locate the page on
which the desired record is stored, searches through the page for the desired
Department record occurrence, and builds an image of the required subschema record
in an application program storage area.
The use of the CALC location mode results in record occurrences being distributed
relatively evenly over the pages in the area, thus minimizing overflow conditions and
leaving space for adding new records. Secondly, it allows us to retrieve records
directly by supplying a CALC-key value. A desired record is typically retrieved with
a single access rather than requiring IDMS/R to search through the database for it.
38
IDMS/R
With the VIA location mode, each member record in a set is stored on or near the
page that contains the member record’s owner. The use of the VIA location mode
tends to group together in close physical proximity records that are likely to be
accessed together and minimizes the number of disk accesses needed to retrieve all
the records that belong to a given set occurrence.
Following diagram shows records stored using the VIA location mode. Each new
Expertise record occurrence is stored as close as possible to its owner Employee
record occurrence. When an occurrence of the Employee record is retrieved, some or
all of its member record occurrences will tend to be on the same page. Since IDMS/R
transfers data into its buffers one page at a time, only a single physical I/O operation
is needed, in many cases, to retrieve an owner record and all of its members.
Area 1
Fig. 5.1.
If the owner and member record types are assigned to different areas, or to different
page ranges in the same area, record occurrences are distributed within their
associated page range in the same relative position as their owner occurrences is in its
associated page range. Or, in other words – When occurrences of a VIA member
record type are stored in a different area from occurrences of the owner record type,
IDMS/R clusters together the VIA member records of each owner and stores each
cluster at a point that is proportionally as far from the beginning of the area as the
owner record is from the beginning of its area. Following diagram shows records
stored using the VIA location mode when owner and member record types are
assigned to different areas.
Area 1 Area 2
Employee Expertise Expertise
Employee
Expertise
IDMS/R
Expertise
Fig. 5.2.
When the VIA location mode is assigned to a record type, no CALC-key can be
defined for that record type. This means that CALC retrievals cannot be requested for
record types that are assigned VIA location mode. In many cases, the owner record
type of a set type is assigned the CALC location mode, and the member record type is
assigned the VIA location mode. This allows an owner record type to be retrieved
directly, after which all the owner’s member record occurrences can then be quickly
located.
When storing records into the database using the DIRECT location mode, the
application program explicitly specifies the page number into which the record
occurrence should be stored. Then when retrieving a record occurrence, the program
must specify the db-key value of the desired record occurrence. Since it is often
difficult for the program to determine the db-key value of the record it wants, this
location mode is less often used than CALC or VIA.
40
IDMS/R
DL (Duplicates Last). With this option, a record occurrence with a duplicate
CALC-key value will be accepted. IDMS/R will store the record after any record
in the database that has a matching CALC-key value. When a CALC retrieval is
made using that CALC-key value, the new record will be retrieved last.
Record Name
CALC-key or Duplicates
VIA Set Name Option
Area Name
Fig. 5.3.
DEPARTMENT
410 F 56 CALC
DEPT-ID-0410 DN
ORG-DEMO-REGION
Fig. 5.4.
41
IDMS/R
42
IDMS/R
6. Set
Set relationships are defined according to the following rules:
Set characteristics:
Set characteristics are assigned to each set when defining the database to IDMS/R. These
characteristics are:
Set name
Linkage options
Membership options
Order options
N (NEXT pointers). With this linkage option, the pointers in the set identify the
NEXT record occurrence. Following figure shows the use of NEXT pointers in
implementing a set occurrence. This option allows access to member records only
in the forward direction. To access a particular member record occurrence, we
must typically begin with owner record and then walk through all the member
records until we access the one we want. When only NEXT pointers are used to
43
IDMS/R
implement a set, space is required in the prefix of each record for only one
pointer. NEXT pointers must be specified for all sets; all other types of pointers
are optional.
Prefix Data
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. Owner record
occurrences contain only Next pointer. Owner pointers provide direct access from
any member record occurrence to its owner record occurrence.
44
IDMS/R
NPO (NEXT, PRIOR and OWNER pointers). With this linkage option, the set
includes all three pointer options as shown in the following figure. This linkage
option allows access to member records in a set occurrence in both the next and
prior directions and direct access from a member record to the owner record.
Prefix Data
Fig. 6.3.
Department
Dept-Employee
Employee
Emp-Expertise
Expertise
Fig. 6.4.
45
IDMS/R
Fig. 6.5.
FIRST. Each new member record occurrence is placed immediately after the
owner record (in the next direction). While retrieving, this option achieves a
member order of LIFO.
Before Insertion
D1
After Insertion
E1 E3
E15 is inserted
E2
D1
Fig. 6.6. E1 E3
5
LAST. Each new memberE1 record occurrence is placed immediately before the
owner record (in the prior direction).E2While retrieving, this option achieves a
46
IDMS/R
member order of FIFO. PRIOR pointers are required (NP or NPO linkage option)
to satisfy the LAST order option.
Before Insertion
D1
E2
D1
E1 E1
Fig. 6.7. 5
E2
NEXT. Each new member record occurrence E3 is placed immediately after the
member record occurrence that was last accessed (in the next direction) within the
set occurrence i.e. next to the current of set.
Before Insertion
Current of set: - E2
D1
After Insertion: E15 is inserted
E1 E3
E2
D1
E1 E3
Fig. 6.8.
E2
E1
5
47
IDMS/R
PRIOR. Each new member record occurrence is placed immediately before the
member record occurrence that was last accessed (in the prior direction) within
the set occurrence i.e. prior to the current of set. Prior pointers are required in
order to specify the PRIOR order option.
D1
After Insertion: E15 is inserted
E1 E3
E2
D1
Fig. 6.9. E1 E3
D1
Jos Verm
hi a
Kam
at Pati
l
48
IDMS/R
Before insertion:
Fig. 6.10.
Fig. 6.11. D1
Jos Verm
DL (Duplicates Last). hi With the DL duplicates a option, a record with a
duplicate sort-key value is stored immediately after the existing duplicate
Patil(2)
record in the set. The last duplicate record encountered in the next direction is
Patil(1)
always the most recently stored duplicate record.
49
IDMS/R
Ex.: After insertion. Patil(2) inserted.
D1
Fig. 6.12
Jos Verm
hi a
DN (Duplicates Not Allowed). With the DN duplicates option, a record with
a duplicate sort-key value cannot be stored in the set. When a program
Patil(1)
attempts to store a record with a duplicate sort-key value, the DBMS returns
Patil(2)
an error code.
D1
Fig. 6.13.
Josh Verm
6.4. i
Bachman Diagram For Set aE3
Patil(1)
Please refer to Employee Database Bachman diagram in Appendix A. Please check
up Dept-Employee set. All the set characteristics for Dept-Employee set are shown
along side the arrow, which represents the set. The set characteristics shown are as
follows:
50
IDMS/R
The DML statement used for these retrievals is OBTAIN. The “OBTAIN” statement
causes IDMS/R to locate the appropriate record occurrence in the database and moves
data element values into application program’s variable storage i.e. working-storage
section. It makes the data available to the program.
51
IDMS/R
To perform a CALC retrieval, the record type we are retrieving must have a CALC-
key defined for it, and we must know the CALC-key value of the record occurrence
we are retrieving. We cannot perform a CALC retrieval for EXPERTISE records.
IDMS/R uses the CALC-key value we supply to locate the appropriate page in the
database, retrieves the desired Department record occurrence and constructs a
subschema record in the program’s variable storage i.e. working-storage section.
If Department record occurrence with Dept-Id 2000 does not exist, it can be checked
with following IF conditions.
IF ERROR-STATUS = ‘0326’
DISPLAY ……
IF DB-REC-NOT-FOUND
DISPLAY ……..
52
IDMS/R
Standard approach for error handling in the program:
DML statement
Expected
Status
IDMS-STATUS
Take Appropriate
Actions
End
Continue
Processing
Fig. 7.1.
Eg. 7.1.
53
IDMS/R
In many application situations, it is necessary to retrieve a particular owner record
occurrence and then to retrieve one or more of that owner’s member record
occurrences. We choose the set occurrence that we wish to access by executing a
retrieval statement (either an OBTAIN or a GET) for a particular occurrence of the
set’s owner record type; a CALC-type retrieval is often useful for this purpose. Once
we have established the set’s owner record occurrence as current of its record type
and also current of its set type, then to retrieve member record occurrences from the
set occurrence, following syntax is used.
Ex.: First
IDMS/R retrieves the first Employee record in the Dept-Employee set, which then
becomes current of the Dept-Employee set. The original Department record remains
current of its record type.
Ex.: Last
If a set is defined with prior pointers, we can retrieve the last member record
occurrence of a set as mentioned above.
Ex.: Next
D1
E1 E3
Department D1
E2
54
IDMS/R
Employee E1 Employee E3
Employee E2
Fig. 7.2.
The particular record occurrence that this statement retrieves depends on which
record occurrence in the set is established as current of the Dept-Employee set; it
always retrieves the record that follows the record occurrence that is current of the
Dept-Employee set in the next direction.
IDMS/R sets an end-of-set condition code that the program must test to avoid
walking the set a second time.
Note: - If the <Record-Name> clause is omitted from the above mentioned OBTAIN
syntax, then in case of a multimember set, member record occurrences of any record
type will be retrieved.
Including a qualifying a record name is useful when walking sets that have more than
one member record type.
55
IDMS/R
Ex.: Prior
If a set has been defined as having PRIOR pointers, we can walk the set in the prior
direction by repeatedly executing a statement of the above-mentioned type.
OBTAIN PRIOR works in the same manner as OBTAIN NEXT, except in the reverse
direction. OBTAIN PRIOR statements cannot be issued for a member record type if
the member’s set does not include PRIOR pointers.
Ex.: Nth
We can retrieve a particular member of a set by a number that specifies the relative
sequence in the set of the desired member.
Or, we can use a variable (of PIC S9(5) COMP) in place of sequence number.
We can use the following DML statement to retrieve the owner of a set occurrence:
If currency is established anywhere in the set occurrence (as shown in above bubble
diagram), OBTAIN OWNER will cause IDMS/R to retrieve the Department record
occurrence for D1.
An OBTAIN OWNER retrieval can be issued whether or not the set is defined as
having OWNER pointers. If owner pointers do not exist, IDMS/R walks the set, if
necessary, to locate the owner record. If the set is defined as having OWNER
pointers, IDMS/R can get directly to the owner from any member in the set
occurrence.
56
IDMS/R
OBTAIN OWNER WITHIN DEPT-EMPLOYEE
IF DB-STATUS-OK
DISPLAY DEPT-NAME-0410
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘DEPARTMENT NOT FOUND’
ELSE
PERFORM IDMS-STATUS
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘GIVEN EMPLOYEE NOT FOUND’
ELSE
PERFORM IDMS-STATUS.
Eg. 7.3.
Those participants, who finished these assignments, can continue to Assignment 3. The logic and
programming would be on similar lines.
57
IDMS/R
E.g. Dept-Employee set is with order option of SORTED in ascending sequence and
the sort-key is EMP-LAST-NAME-0415. Please check up above diagram of the set
occurrence for Department record occurrence D1. We want to access Employee
record occurrence “Patil” in the set occurrence of D1. With this sorted set, we can
retrieve a particular member of a set occurrence based on a sort-key value, as in the
example give below.
In this example, we move a last name value to the data element in the Employee
record description that defines the sort key and issues an OBTAIN statement that
references the sort-key data element. Note that although the retrieval appears similar
to a CALC retrieval, the search for a record is limited to the current set occurrence.
IDMS/R does not search other set occurrences for a member having the specified
sort-key value.
In the previous example, IDMS/R begins searching member records from the first
member record occurrence in the set occurrence, regardless of which record
occurrence is current of set type.
58
IDMS/R
7.6. Generic Key Retrieval
To perform a generic-key retrieval in a sorted set, we supply IDMS/R with a partial
key value. E.g. in Dept-Employee sorted set as mentioned above, we want to retrieve
all the Employee record occurrences whose last name value begin with the letter ‘S’.
Following is the partial code for this type of retrieval.
01 WS-LAST-NAME.
05 WS-FIRST-CHAR PIC X.
05 FILLER PIC X(14).
……..
……..
MOVE LOW-VALUES TO WS-LAST-NAME.
MOVE WS-INPUT-CHAR TO WS-FIRST-CHAR.
MOVE WS-LAST-NAME TO EMP-LAST-NAME-0415.
Eg. 7.5.
Please notice that the data element in which we store the generic key must be padded
to the right with low values.
59
IDMS/R
records. E.g. Employee record has an index built on last-name and first-name fields,
apart from CALC key. Skill record has an index built on skill-name apart from CALC
key. We can have more than one indexes built on different fields, so that we can
retrieve record occurrences based on any index that we need.
With an index, retrieval of members can sometimes be more efficient because the
index can be traversed more quickly than the set of chained member records. Indexed
sets are used mainly to add flexibility to data retrieval.
To implement an index, IDMS/R builds an index file that contains the database key
values of member record occurrences. These db-key values are maintained in the
sequence specified for the index. i.e. IDMS/R uses an array of database pointers to
quickly access member records. DBMS locates the data by searching the index rather
than the actual member record.
Random retrieval by key value. Also a partial or generic key value can be used.
Sorted retrieval by key value.
Multiple-key access. Sometimes we need to access records based on more than
one key.
Each entry in the index contains a symbolic-key (or index-key) data element value
and the db-key value of its corresponding record occurrence.
Random Retrieval
To use the index to find the first record having a particular index-key (a field on
which the index is built) value, we can do a random retrieval in a similar manner to
the method we used for retrieving a member record having a particular sort-key value.
The syntax and the logic are similar to the sorted set. Please refer to Sec. 8.1.
We name the desired record type, specify the name of the index set and supply a data
element value for the indexed data element:
60
IDMS/R
Sequential Retrieval
The program has to test the last-name field after each sequential retrieval to determine
when it has reached the last record with the specified last-name data element value.
Generic-Key Retrieval
The syntax and logic is exactly similar to Sorted set. Please refer to Sec. 8.2.
Please refer to Employee database in Appendix A. There are indexes built on Skill
record, Employee record and Job record.
61
IDMS/R
In performing an area sweep, IDMS/R scans through all the records in an area in
physical sequence. The order in which records are retrieved will generally have little
relationship to the logical sequence of records. Area sweeps are useful when we want
to retrieve all the records in an area without regard to the order in which we get them.
E.g. when we are simply gathering statistics about the database.
IDMS/R will simply retrieve the record occurrence of the given record-type having
the lowest database-key value in the area. In the following statement, IDMS/R uses
currency within the area to determine which record occurrence of the given record-
type to retrieve. It uses area currency to retrieve the record occurrence having the next
highest database-key value.
Pointers are not used in performing an area sweep, so prior pointers are not necessary
for executing OBTAIN PRIOR WITHIN AREA statements.
We can use a sequence number or a variable (of PIC S9(5) COMP) in place of a
sequence number as given below.
62
IDMS/R
PERFORM 2000-RETRIEVE-REC
UNTIL WS-END-OF-COURSE-AREA = ‘Y’.
….
….
2000-RETRIEVE-REC.
IF DB-STATUS-OK
DISPLAY COURSE-ID
OBTAIN NEXT COURSE WITHIN COURSE-AREA
ELSE
IF DB-END-OF-SET
MOVE ‘Y’ TO WS-END-OF-COURSE-AREA
ELSE
PERFORM IDMS-STATUS.
Eg. 7.6.
63
IDMS/R
8. Currency
To help keep track of where we are in the database, IDMS/R maintains pointers to a number
of different record occurrences as each run unit executes. We use the term currency to refer
to these pointers.
To enable a program to position itself and move about in the database, IDMS/R maintains a
Currency Table for each run unit.
The currency is the db-key of the most recently accessed record occurrence.
IDMS/R maintains four types of currency (Currency Table) for each run unit:
Record Currency (Current of record type). The db-key of the most recent record
occurrence of each record type accessed by the program. IDMS/R maintains a separate
currency for each record type defined in the subschema.
Set Currency (Current of set type). The db-key of the most recent record occurrence of
each set type accessed by the program. IDMS/R maintains a separate currency for each
set type defined in the subschema.
Area Currency (Current of area). The db-key of the most recent record occurrence of
each area accessed by the program. IDMS/R maintains a separate currency for each area
to which the program has access.
Run Unit Currency (Current of run unit). The db-key of the most recent record
occurrence accessed by the program.
64
IDMS/R
Using the currencies and the NPO pointers stored in record occurrences, IDMS/R
DBMS accesses records in the database.
FINISH statement nullifies all the currencies.
Sub-Course
Course Course in Course-Area
MVS
C0 C10
7
C09
Fig. 8.1.
CURRENCIES
Course
Sub-Course Set
Course-Area
Subject
Trg-Area
Run-Unit
Bind Run-unit - - - - - -
Move ‘MVS’ To Sub-Id
MVS - MVS MVS - MVS
OBTAIN CALC SUBJECT
65
IDMS/R
CURRENCIES
Course
Sub-Course Set
Course-Area
Subject
Trg-Area
Run-Unit
Bind Run-unit - - - - - -
Move ‘MVS’ To Sub-Id
MVS - MVS MVS - MVS
OBTAIN CALC SUBJECT
Obtain next course within
MVS C07 C07 MVS C07 C07
Sub-course
Obtain last course within MVS
MVS C10 C10 C10 C10 DB-END-
Sub-course OF-SET
Obtain next course within
MVS C10 MVS MVS C10 MVS
Sub-course
Obtain course within sub-course MVS
MVS C10 MVS C10 MVS
using ‘C08’ (NPO)
DB-REC-NOT-
FOUND
….
….
Obtain first subject within course-area.
Perform next-subject-para until ws-course-area-end = ‘y’.
….
…..
Next-subject-para.
If db-status-ok
Perform disp-course-para
Obtain next subject within course-area
Else
If db-end-of-set
66
IDMS/R
Move ‘y’ to ws-course-area-end
Else
Perform idms-status.
Disp-course-para.
Obtain last course within sub-course.
If db-status-ok
Display course-id
Else
If db-end-of-set
Display ‘No Course’
Else
Perform idms-status.
Eg. 8.1.
Sub-Course
Subject S1
Fig. 8.2.
C1 C1
1 4
Assumption: Both Record types, Subject and Course, are in Course-Area.
Course
The program displays courses C14C1 and C32. ButC1
it did not display courses C22 and
C43, which it was supposed to do. 2 3
This happened because of currency loss. Retrievals by sweeping areas work based on
area currency. Due to loss of Course-area currency, the Subjects S2 and S4 could not
be obtained by the area-sweeping logic. So, the courses C22 and C43 did not get
displayed.
67
IDMS/R
Course-Area Currency:
S1
C14
S3
C32
S5
The DML ‘Obtain first subject within course-area’ retrieves S1. Area currency is S1.
Then the DML ‘Obtain last course within sub-course’ is executed and it retrieves
C14. Now, area currency changes to C14. Then DML ‘Obtain next subject within
course-area’ is executed and it retrieves S3. Area currency becomes S3. We miss S2
here. Scan for next subject should have started from S1 onwards, but it started from
C14 onwards. This is currency loss. Same thing happened with S4 also.
Solution:
The record occurrences of both records, Subject and Course, are in the same area
Course-Area. So, any retrieval of Subject or Course record occurrence changes the
area Course-Area currency.
In the above program, we need to store / maintain the area currency. Find out the part
of code where currency loss takes place. The paragraph ‘Disp-course-para’ is the
place where currency loss happens. So before the execution of the statement ‘Perform
disp-course-para’, we need to store the area currency. After the execution of the
statement ‘Perform disp-course-para’, we need to reestablish the area currency from
the stored value.
<record-name>
ACCEPT <ws-db-key-v> FROM <set-name> CURRENCY
<area-name>
Or
68
IDMS/R
The field ws-db-key-v should be defined in working-storage as follows.
Ex.: The above-mentioned program is modified to take care of area currency loss.
Only affected code is given below.
Next-subject-para.
If db-status-ok
Accept ws-db-key-v from course-area currency
Perform disp-course-para
Obtain subject db-key is ws-db-key-v
Perform idms-status
Obtain next subject within course-area
Else
…..
Eg. 8.2.
To reestablish the current record occurrence of record type, set type, or area as the
current record occurrence of run unit, use the following statement:
<record-name>
FIND / OBTAIN CURRENT WITHIN <set-name>
WITHIN <area-name>
69
IDMS/R
We may not follow a FIND with a GET. In some cases, we only wish to locate a
record, but do not need actually to retrieve it. E.g. we may need only to verify that a
particular record occurrence exists, or we may need to establish a starting point for
some subsequent retrieval sequence.
70
IDMS/R
After you have retrieved a owner record occurrence in a set, you can issue the IF
EMPTY statement to determine if the set has any member record occurrences. This
allows you to control processing based on whether the set is empty.
IF DEPT-EMPLOYEE IS EMPTY
MOVE NO-EMP-MSG TO WS-MSG
ELSE
PERFORM 1000-DEPT-EMP THRU 1000-EXIT
UNTIL DB-END-OF-SET.
………
………
1000-DEPT-EMP.
OBTAIN NEXT EMPLOYEE WITHIN DEPT-EMPLOYEE.
…….
Eg. 8.3.
You can issue the IF member statement to ensure that a record occurrence currently
participates as a member of a specified set occurrence.
71
IDMS/R
ii. Issue the IF MEMBER statement.
iii. Perform further processing, as specified.
1000-DEPT-EMP.
OBTAIN NEXT EMPLOYEE WITHIN DEPT-EMPLOYEE.
IF DB-STATUS-OK
NEXT SENTENCE
ELSE
IF DB-END-OF-SET
GO TO 1000-EXIT
ELSE
PERFORM IDMS-STATUS.
IF OFFICE-EMPLOYEE MEMBER
OBTAIN OWNER WITHIN OFFICE-EMPLOYEE
PERFORM IDMS-STATUS
DISPLAY OFFICE-ADDRESS-0450
ELSE
MOVE NO-OFF-MSG TO WS-MSG.
……….
……….
1000-EXIT.
EXIT.
Eg. 8.4.
D1
Fig. 8.3. E5
Employees E1 and
E1 E2 are attached
E2to Dept D1. Employee E5 is not attached to any
Department.
72
IDMS/R
CURRENCIES
Dept-Employee Set
Run-Unit
Department
Employee
Bind Run-unit - - - -
Move E1 To Emp-Id-0415
- E1 E1 E1
Obtain calc Employee
Obtain owner within Dept-Employee D1 E1 D1 D1
Move E2 To Emp-Id-0415
D1 E2 E2 E2
Obtain calc Employee
Move E5 To Emp-Id-0415
D1 E5 E2 E5
Obtain calc Employee
Obtain owner within Dept-Employee D1 E5 D1 D1
This is a wrong result. Employee E5 is not attached to any Department, but the
program concludes that it is attached to Dept D1.
CURRENCIES
Dept-Employee Set
Run-Unit
Department
Employee
Bind Run-unit - - - -
Move E1 To Emp-Id-0415
- E1 E1 E1
Obtain calc Employee
Obtain owner within Dept-Employee D1 E1 D1 D1
Move E2 To Emp-Id-0415
D1 E2 E2 E2
Obtain calc Employee
Move E5 To Emp-Id-0415
D1 E5 E2 E5
Obtain calc Employee
IF Dept-Employee MEMBER
Obtain owner within Dept- Employee
D1 E5 E2 E5
Else
Display ‘No Owner’
73
IDMS/R
9.1. Hierarchies
Two-Level Hierarchies:
A single set implements a two-level hierarchy. The owner record type is on the first
level, and member record types are on the second level. A one-to-many relationship
exists between the owner record type and its member record types.
Department
Dept-Employee
Employee
Fig. 9.1.
Multilevel Hierarchies:
A member record of one set can also be the owner of another set. This results in a
multilevel hierarchy.
Department
Dept-Employee
Employee
Emp-Expertise
Expertise
Fig. 9.2.
There are more than one member record types in a set type. While walking a set, we
can access all member record types.
74
IDMS/R
Coverage
Coverage-Claims
Fig. 9.3.
Note: - If the <Record-Name> clause is omitted from the OBTAIN syntax, then in
case of a multimember set, member record occurrences of any record type will be
retrieved.
This form of hierarchy uses one record type as the owner record in more than one set.
The common owner record provides the means of movement between the two
different member record types in different sets.
Employee
Emp-Emposition Emp-Expertise
Emposition Expertise
Fig. 9.4.
Multiple Sets:
Customer
Cust-Invice Cust-Overdue-Invoice
Invoice
Fig. 9.5.
75
IDMS/R
The same two record types, Customer and Invoice, now participate in two different
sets. However, a given Invoice record occurrence will be a member of only one of the
two possible set types. For each Customer record occurrence, there are two different
groups of Invoice record occurrences associated with it.
Cust-Invoice
Cust-Overdue-Invoice
C1
I3 I2
Fig. 9.6 I1
I5
E.g. there is a many-to-many relationship between Supplier and Parts record types. A
supplier supplies many parts and a part is supplied by many suppliers. An additional
record type Quantity is provided, in which information about quantity supplied can be
stored. Supplier and Parts have a one-to-many relationship with Quantity. The record
type Quantity is called the junction record, because it represents a junction or
intersection between the Supplier and the Parts record types. The junction record
Quantity is the member record in the multiple sets Supplier-Qty and Parts-Qty. The
junction record resolves the many-to-many relationship and implements it indirectly.
Supplier Parts
Supplier-Qty Parts-Qty
Quantity
Fig. 9.7
S1 P1
76
IDMS/R
S2 P2
Q: S1P1 P3
Q: S1P2
Q: S1P3
Q: S2P1
Q: S2P2
Q: S2P3
Supplier-Qty Parts-Qty
Fig. 9.8.
Parts-Are Parts
Parts-For
Fig. 9.9.
In a set relationship in IDMS/R, a record type cannot be both an owner and a member
of the same set. The technique of junction record can be used to resolve this situation.
A possible intersection data is the quantities required of the Parts. A main-part
consists of many different sub-parts in certain quantity. Different quantities of a sub-
part are used in construction of many different main-parts. We can create a junction
record called Quantity.
Parts
77
Quantity
IDMS/R
Parts-Are Parts-For
Fig. 9.10.
The Quantity junction record is related to the Parts record using two sets. The set
Parts-Are allows us to find out sub-parts of a given part, and Parts-For helps to find
the main-parts where the given part is used as a sub-part.
P1
P2
P11
P21
P81
P82
Q: P1P81
Q: P1P82
Q: P1P11
Q: P2P81
Q: P2P82
Q:P2P21
Parts-Are Parts-For
Fig. 9.11.
Subject
Prereq-Are
78
IDMS/R
Prereq-For
Fig. 9.12.
Subject
Prereq-Are Prereq-For
Skill-Level
Fig. 9.13.
The Skill-Level junction record is related to the Subject record using two sets. The set
Prereq-Are allows us to find out the subjects that are prerequisites of a given subject,
and the set Prereq-For helps to find the subjects for which the given subject is a
prerequisite.
Exercise: - Draw the diagram of Subject, Skill-Level record occurrences with Prereq-
Are and Prereq-For set occurrences (similar to Parts, Quantity shown above).
Please consider record types Parts and Quantity with two sets Parts-Are and Part-For
as explained above.
The owner record type is same for both the sets. The member record type is also the
same for both the sets. So, retrieval of any of the two record types, Parts or Quantity,
changes the set currencies of both the sets. If we want to walk along (navigate) a
particular set occurrence sequentially, then any retrieval through another set during
the processing will change the set currency of the set occurrence we are walking
along. This is a problem of set currency loss. So, we need to store the set currency for
the set occurrence we want to walk along and reestablish it later.
MOVE P1 TO PART-NUMBER.
OBTAIN CALC PARTS.
IF DB-STATUS-OK
PERFORM 1000-WALK THRU 1000-EXIT
79
IDMS/R
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘PART NOT FOUND’
ELSE
PERFORM IDMS-STATUS.
….
….
1000-WALK.
IF PARTS-ARE IS EMPTY
DISPLAY ‘NO SUB-PARTS’
GO TO 1000-EXIT.
PERFORM 2000-PROCESS THRU 2000-EXIT
UNTIL WS-END-SET = ‘Y’.
1000-EXIT.
EXIT.
2000-PROCESS.
OBTAIN NEXT QUANTITY WITHIN PARTS-ARE.
IF DB-STATUS-OK
PERFORM 3000-DISPLAY THRU 3000-EXIT
FIND CURRENT QUANTITY
PERFORM IDMS-STATUS
ELSE
IF DB-END-OF-SET
MOVE ‘Y’ TO WS-END-SET
ELSE
PERFORM IDMS-STATUS.
2000-EXIT.
EXIT.
3000-DISPLAY.
IF PARTS-FOR MEMBER
OBTAIN OWNER WITHIN PARTS-FOR
IF DB-STATUS-OK
DISPLAY PART-NUMBER ‘ ‘ PART-NAME
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘OWNER NOT FOUND’
ELSE
PERFORM IDMS-STATUS
ELSE
DISPLAY ‘OWNER NOT AVAILABLE’.
3000-EXIT.
EXIT.
Eg. 9.1.
What will happen if we do not store the Parts-Are set currency i.e. if we do not write
the statements ACCEPT WS-DB-KEY ….. and OBTAIN QUANTITY DB-KEY
…..?
Consider the following data: Part P1 has three sub-parts as P11, P12, and P13. Parts
P11, P12, and P13 do not have any sub-parts i.e. those are stand-alone parts.
CURRENCIES
80
IDMS/R
Parts-For Set
Parts
Parts-Are Set
….-Area
Run-Unit
Quantity
Bind Run-unit - - - - - -
Move P1 To Part-number
P1 - P1 P1 P1 P1
Obtain calc Parts
Obtain next Quantity within Parts-
P1 Q11 Q11 Q11 Q11 Q11
Are
Obtain owner within Part-For P11 Q11 P11 P11 P11 P11
Obtain next Quantity within Parts-
P11 Q11 P11 P11 P11 P11
Are
DB-END-
OF-SET
First the program retrieves part P1. Parts-Are set currency is P1. Then DML
‘OBTAIN NEXT QUANTITY WITHIN PARTS-ARE’ retrieves Quantity
occurrence, say Q11. Parts-Are set currency is Q11. Then DML ‘OBTAIN OWNER
WITHIN PARTS-FOR’ is executed and retrieves P11. Parts-Are (and Parts-For) set
currency is P11. Then DML ‘OBTAIN NEXT QUANTITY WITHIN PARTS-ARE’
is executed and it encounters DB-END-OF-SET, since P11 Parts-Are set occurrence
is empty as per given data. Then program ends. So, the program does not display
parts P12 and P13.
To avoid such set currency loss and thereby wrong results, we have to store the set
currency and reestablish it later as shown in the program.
81
IDMS/R
CURRENCIES
Parts-For Set
Parts
Parts-Are Set
….-Area
Run-Unit
Quantity
Bind Run-unit - - - - - -
Move P1 To Part-number
P1 - P1 P1 P1 P1
Obtain calc Parts
Obtain next Quantity within Parts-
P1 Q11 Q11 Q11 Q11 Q11
Are
Obtain owner within Part-For P11 Q11 P11 P11 P11 P11
Find current Quantity P11 Q11 Q11 Q11 Q11 Q11
Obtain next Quantity within Parts-
P11 Q12 Q12 Q12 Q12 Q12
Are
Obtain owner within Part-For P12 Q12 P12 P12 P12 P12
Find current Quantity P12 Q12 Q12 Q12 Q12 Q12
Obtain next Quantity within Parts-
P12 Q13 Q13 Q13 Q13 Q13
Are
Obtain owner within Part-For P13 Q13 P13 P13 P13 P13
Find current Quantity P13 Q13 Q13 Q13 Q13 Q13
Obtain next Quantity within Parts-
P1 Q13 P1 P1 P1 P1
Are
DB-END-
OF-SET
82
IDMS/R
Exercise:
P1 P2
P8
P4(q2) P7(q1)
P7(q11)
MAIN -PART SUB-PART QUANTITY
P1 P5 3
P1 P11 6
P1 P4 2
P2 P7 11
P8 P5 7
P8 P2 9
P11 P4 2
P11 P7 1
Fig. 9.14.
83
IDMS/R
To disconnect Empo3 from the Emp-Emposition set, we must erase the Empo3 record
from the database. Erasing Empo3 record also causes the record to be disconnected
from the set.
E1
Empo Empo
Erase Empo3:
1 3
Empo
2
E1
Fig. 10.1.
Empo
O (optional).1 With this option, a record occurrence can be disconnected from a set,
as shown in the figure below. The record occurrence remains in the database and may
Empo
2
84
IDMS/R
be accessible in other way. For example, in Dept-Employee set, after disconnecting
one Employee record occurrence from one Department set occurrence, we might then
connect it to some other Department set occurrence, as when we are transferring a
employee from one department to another. To transfer employee E3 from D1
department to D2 department, we disconnect E3 from the set occurrence whose
owner record is D1 and connect it to the set occurrence whose owner record is D2.
D1
Disconnect E3:
E E
1 3
E
2
D1
Fig. 10.2. E
E 3
1
With the optional disconnect option, a record occurrence can be disconnected from a
set without erasing it. It can then beE later connected to some other set.
2
M (manual). With this option, a new member record is not automatically connected
to a set occurrence when it is added to the database. The application program must
execute an explicit connect function after it adds a new record occurrence to connect
the member record to a set occurrence.
85
IDMS/R
10.3. Bachman Diagram and Examples
Please refer to Bachman diagram of Employee database in Appendix A. The set
membership options are mentioned along with all the other set characteristics. The set
characteristics are shown by the side of the arrow representing the set.
E.g. the set Dept-Employee set has membership options as ‘OA’. The set Emp-
Expertise has membership options as ‘MA’. The first character represents the
disconnect option and the second character represents the connect option.
Examples:
Customer
Cust-Inv
Invoice
Fig. 10.3.
Customer
Cust-Late-Paid
Invoice
Fig. 10.4.
Customer
86
Invoice
IDMS/R
Cust-Unpaid-Inv
Fig. 10.5.
Optional: - Once the invoice is paid, it does not participate in this set occurrence.
Automatic: - All invoices are unpaid when created.
Customer
Cust-Unpaid-And-Overdue-Inv
Invoice
Fig. 10.6.
On 16-April-2002
Not paid Now participating in the set occurrence
On 18-April-2002
Paid Now does not participate in the set
Occurrence
87
IDMS/R
11.1. Ready
The Ready statement performs an equivalent function as an OPEN statement for a
conventional file. It makes the required area of the database available to the
program. The syntax is as follows:
SHARED
READY <area-name> USAGE-MODE IS PROTECTED RETRIEVAL
ALL EXCLUSIVE UPDATE
The ‘Usage-Mode Is Retrieval’ clause indicates that the program will retrieve data
only and will not be allowed to execute any database modification DML
statement for the specified area.
The ‘Usage-Mode Is Update’ clause informs IDMS/R that the program intends to
update records from the specified area.
A READY statement for update can also specify additional usage mode options
that control the way in which database areas can be concurrently accessed by two
or more run units. Usage mode options for updating are discussed in the Section
13.2 on ‘Area Usage Modes’.
11.2. Store
The STORE statement is used to add a new record occurrence to the database.
Adding a new record to the database is a simple three-step process:
2. Establish currency within appropriate occurrences of the set types in which the
new record participates as an automatic member. We can use FIND for this
purpose, since we do not need the records to be moved to the program’s working-
storage section.
88
IDMS/R
3. Execute the store function, specifying the name of the record type we are
adding.
The syntax for the store function is simple; the only required parameter is
the name of the record type. The following STORE statement adds a new occur-
rence of the Employee record type:
STORE EMPLOYEE.
However, IDMS/R must know more than the information we supply in the
STORE statement to add the new record occurrence correctly, including the
following:
The location in the database in which the new record occurrence should be
written.
Whether the new record should be made a member of any sets and, if so, to
which set occurrences it should be connected.
IDMS/R uses record currencies and the attributes assigned to records and sets to
obtain this information.
IDMS/R finds an appropriate location for a new record by examining the location
mode defined for the record type being added. If the location mode is CALC,
IDMS/R converts the CALC-key value to a database-key value and then stores the
new record as close as possible to the calculated page. If the location mode is
VIA, IDMS/R finds an optimum location for the new record based on the location
of the owner record occurrence in the VIA set type. If the location mode is
DIRECT, the program must have previously stored an appropriate database-key
value in the IDMS Communications Block. IDMS/R uses this value in finding a
place for the record.
IDMS/R next determines the set occurrences in which the new record should be a
member and where in each set to insert the record. As shown in Employee
Database, the Expertise record participates in two set types. It is an automatic
member of the Emp-Expertise set and a manual member of the Skill-Expertise set.
Before issuing a STORE, the program must establish currency within all the sets
in which the new record is an automatic member. Before storing an Expertise
record, we can establish currency within the Emp-Expertise set by accessing the
appropriate Employee record.
89
IDMS/R
IDMS/R connects the new record to an occurrence of each set for which it is an
automatic member; it does not automatically connect it to any sets in which it is a
manual member. For sets in which the record is a manual member, the program
can locate the appropriate set occurrences and issue CONNECT statements for the
record once the record has been stored. We will discuss the CONNECT statement
later.
Before connecting records to sets, IDMS/R examines the order option for the set.
Since the Emp-Expertise set is ordered DEC SORTED, each new Expertise record
occurrence is placed in the set in descending sorted order of sort-key Skill-Level-
0425.
Example:
…..
MOVE WS-EMP-ID TO EMP-ID-0415.
FIND CALC EMPLOYEE.
IF DB-STATUS-OK
MOVE WS-SKILL-LEVEL TO SKILL-LEVEL-0425
MOVE WS-EXP-DATE TO EXPERTISE-DATE-0425
STORE EXPERTISE
PERFORM IDMS-STATUS
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘EMPLOYEE NOT FOUND’
ELSE
PERFORM IDMS-STATUS.
Eg. 11.1.
The new Expertise record will be automatically connected to the current oc-
currence of the Emp-Expertise set. The new Expertise record will not be auto-
matically connected to an occurrence of the Skill-Expertise set. We will have to
90
IDMS/R
later use a CONNECT statement to connect the Expertise record to an appropriate
occurrence of the Skill-Expertise set.
Remark: - Run unit, area, record-type and all sets in which its Connect option is
Automatic and sets in which it is an owner is affected.
11.3. Modify
Once we have readied one or more areas with one of the UPDATE usage mode
options, we can use the MODIFY statement to replace the data element values in
a record occurrence with new data element values. In modifying a record
occurrence we generally perform the following steps:
1. Execute an OBTAIN for the desired record. This establishes run-unit currency
on the record we are going to change and also places a copy of the record in
variable storage.
2. Make changes to the record by storing new data element values in working-
storage.
3. Execute the MODIFY function, naming the record type that we are modifying.
IDMS/R then replaces the data element values in the database with the new data
element values in working-storage.
There are two requirements for successful execution of the MODIFY statement:
1. We must execute a READY statement with one of the UPDATE usage mode
options for the area that contains the record we are modifying.
2. We must issue an OBTAIN for the record we are updating before we execute
the MODIFY statement.
Example:
91
IDMS/R
IF DB-REC-NOT-FOUND
DISPLAY ‘EMPLOYEE NOT FOUND’
ELSE
PERFORM IDMS-STATUS.
Eg. 11.2.
Remark: - After successful execution, object record becomes current of the run
unit, all sets in which it participates, its record type and area currencies are
affected.
11.4. Erase
This is used to delete a record occurrence from database.
The Modify and Store functions are fairly straight-forward; they each operate on a
single record occurrence. When we use the erase function, however, the ERASE
often affects not only the record that is the object of the ERASE statement but
also, in some cases, members of sets owned by that record.
PERMANENT
ERASE <rec-name> SELECTIVE MEMBERS
ALL
Example:
ERASE EMPLOYEE
PERFORM IDMS-STATUS
ELSE
IF DB-REC-NOT-FOUND
92
IDMS/R
DISPLAY ‘EMPLOYEE NOT FOUND’
ELSE
PERFORM IDMS-STATUS.
Eg. 11.3.
Notice that, in this case, we did not specify a member option in the ERASE. This
means that the Employee record occurrence will only be erased if it is the owner
of an empty set occurrence. We must use one of the other three ERASE options if
we want to erase an owner of one or more nonempty sets.
Using ERASE ALL first causes the object record to be removed from the data-
base. Then all its members, both mandatory and optional, will be removed,
whether or not they are members in other set occurrences. If we execute an
ERASE ALL for an Employee record, IDMS/R also removes all its member
records, along with all their members.
With the other two ERASE options, the members that are automatically erased
depend on whether the members participate in other sets and what the set dis-
connect options are.
When we use ERASE PERMANENT, IDMS/R erases the record that is the object
of the ERASE. It also erases all mandatory members all sets owned by the object
record. It does not erase optional members; it disconnects them instead. If an
erased member is the owner of any sets, it is treated as if an ERASE
PERMANENT were issued for it. Its mandatory members will be erased, and its
optional members disconnected. This process continues until all members have
been processed.
An ERASE SELECTIVE always erases the record that is the object of the
ERASE, and it always erases mandatory members in all sets owned by the object
record. It also erases optional members if they do not participate in any other sets.
If the erased member is the owner of any sets, it is treated as if an ERASE
SELECTIVE were issued for it. Its mandatory members will be erased, and its
optional members will be erased if they do not participate in any other sets.
Remark: - Run unit and area currencies remain unchanged. It nullifies current
pointers for:
- All record types involved in Erase
- All sets in which the erased record participates
93
IDMS/R
11.5. Connect
It is used to establish a record occurrence as a member in a set occurrence.
The CONNECT function can be used in conjunction with STORE for records that
must be manually connected to sets. CONNECT connects the record that is
current of run unit to the named set.
The CONNECT statement names both a record type and a set type. The
CONNECT function causes the record that is current of the named record type to
be connected to the set occurrence that is current of the named set type.
Membership option must not be MA (mandatory automatic). All areas affected
must be readied in UPDATE usage mode.
Example:
…..
MOVE WS-EMP-ID TO EMP-ID-0415.
OBTAIN CALC EMPLOYEE.
IF DB-STATUS-OK
MOVE WS-SELN-DATE TO SELECTION-DATE-0400
MOVE WS-TERM-DATE TO TERMINATION-DATE-0400
MOVE WS-TYPE TO TYPE-0400
MOVE WS-PLAN-CODE TO INS-PLAN-CODE-0400
STORE COVERAGE
PERFORM IDMS-STATUS
CONNECT COVERAGE TO EMP-COVERAGE
PERFORM IDMS-STATUS
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘EMP-ID NOT FOUND’
ELSE
PERFORM IDMS-STATUS.
Eg. 11.4.
Remark: - On successful Connect, the set currency will become current of record
occurrence just connected.
11.6. Disconnect
94
IDMS/R
It is used to disconnect a record occurrence from a set occurrence of which it is a
member.
The DISCONNECT and CONNECT functions are also often used together to
move a record occurrence from one set occurrence to another.
Example:
…..
MOVE WS-EMP-ID TO EMP-ID-0415.
OBTAIN CALC EMPLOYEE.
IF DB-STATUS-OK
PERFORM 2000-TRANSFER
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘EMP-ID NOT FOUND’
ELSE
PERFORM IDMS-STATUS.
….
…..
2000-TRANSFER.
DISCONNECT EMPLOYEE FROM DEPT-EMPLOYEE.
PERFORM IDMS-STATUS.
MOVE WS-DEPT-ID TO DEPT-ID-0410.
OBTAIN CALC DEPARTMENT.
IF DB-STATUS-OK
PERFORM 3000-CONNECT.
……
……
3000-CONNECT.
CONNECT EMPLOYEE TO DEPT-EMPLOYEE.
PERFORM IDMS-STATUS.
Eg. 11.5.
95
IDMS/R
Please refer to Section 3.7 for the steps that are involved in the execution of a DML
statement.
96
IDMS/R
Central Version
Local Mode
A batch program that operates in local mode has its own copy of the IDMS/R
DBMS loaded into its address space. A local mode run unit operates
independently of any other IDMS/R run units that may be operating in the system
at the same time. In general, an application runs faster when run in local mode,
but IDMS/R provides no automatic restart and recovery facilities for local mode
97
IDMS/R
applications. Batch retrieval programs are good candidates for running in local
mode, since they do not ordinarily require automatic restart and recovery
facilities.
When a run unit begins by issuing the BIND RUN-UNIT statement, IDMS/R
writes a begin checkpoint record on a journal file. A checkpoint record contains
information about the current status of the run unit. As a run unit executes, it may
update records in the database. As IDMS/R processes each update request, it
writes to the journal file a before image and an after image of the updated record.
When the application ends the run unit by executing a FINISH statement,
IDMS/R writes out an end checkpoint record. At the conclusion of the run unit,
the journal file contains begin checkpoint, before and after images of all updated
records, and an end checkpoint.
Journal File
Begin Checkpoint Before After … … End Checkpoint
image image (FINISH)
Start of run unit of updated record ………
98
IDMS/R
reverse the effect of the database updates already made by aborted run unit. The
run unit can then be restarted from the beginning.
15
Journal File 17
Begin Before After Checkpoint:
Checkpoint: image image Abnormal
Start of RU 15 17 termination
17
Journal File 15
Begin Before After Checkpoint:
Checkpoint: image image Abnormal
Start of RU 15 17 termination
Fig. 12.1.
12.4. Commit
All run units that terminate normally create at least two checkpoint records on the
journal file, a begin checkpoint when the READY statement is executed and an
end checkpoint when the FINISH statement is executed. The before and after
record images that are recorded between these two checkpoints constitute a record
of all the updating the run unit performed. The processing that a unit performs
between checkpoints is called a recovery unit. In the simplest case, the entire run
unit constitutes a single recovery unit. Many online applications operate in this
manner. A separate run unit may be started to process each incoming transaction.
In such a case, no more than a few database updates are processed during the
execution of each run unit, and each run unit constitutes a single recovery unit.
In some situations, a single online run unit may process many transactions and
perform many database updates. Batch applications are even more likely to make
a great many updates during the execution of a single run unit. In such situations,
it is often necessary to divide a run unit into multiple recovery units to reduce the
time that it takes to recover from a run unit failure. To create intermediate
checkpoints, the run unit periodically issues a COMMIT statement to make
permanent all database updates that the run unit has already made: COMMIT.
99
IDMS/R
The COMMIT statement causes IDMS/R to release all locks except for those that
are placed on current records; COMMIT ALL releases all record locks.
Many different techniques can be used for determining how often a COMMIT
statement should be executed. One simple technique is simply to count the
number of updates the run unit processes. Every one hundred updates or so, the
run unit might issue a COMMIT statement, causing IDMS/R to write an inter-
mediate checkpoint to the journal file.
15
Journal File 17
Begin Before After Checkpoint: Checkpoint:
Checkpoint: image image Commit Abnormal
Start of RU 15 17 termination
17
Journal File
Begin Before After Checkpoint: Checkpoint:
Checkpoint: image image Commit Abnormal
Start of RU 15 17 termination
Fig. 12.2.
100
IDMS/R
In the local mode environment and in the central version environment with tapes
journal files, IDMS/R provides utility programs to handle manual restarting of
aborted applications.
12.6. Rollback
In some cases, a program may itself determine during program processing that it
needs to back out the changes that it has made to the database since it wrote the
most recent checkpoint record. In the central version environment with journal
files written to direct access data sets, the program can request that IDMS/R do
this automatically by simply abnormally terminating the run unit.
If we would like to back out the changes but not abend the run unit, we can issue
a ROLLBACK statement. There are two formats of ROLLBACK statement as
given below.
ROLLBACK.
ROLLBACK CONTINUE.
If we issue this statement, IDMSIR restores the database but does not terminate
the run unit. We may now access the database immediately without reissuing the
BIND/READY sequence.
101
IDMS/R
13. Locking
IDMSIR provides locking facilities for controlling access to areas and to individual records
when two or more run units require access to the same database areas. IDMS/R provides
three levels of locks: Area locks, Area usage modes, and record locks.
If an area lock is already set on an area that is required by a local mode application,
that local mode application abends; otherwise the local mode application locks those
areas, and no other local mode application or IDMS/R central version will be given
access to those areas. An area lock is released by FINISH statement of the local mode
application.
If an area lock is already set on an area that is required by an IDMS/R central version,
the execution of that central version continues with no access to those areas for the
run units of the CV. The area is said to be varied offline to that central version. Run
units that attempt to access an area that is varied offline are abnormally terminated. If
all required areas are available, then CV locks those and are available to all run units
of that CV. No other local mode application or CV will be given access to locked
areas. An area that is locked by a particular CV is released only when the central
version is shut down or when the area is varied offline.
102
IDMS/R
SHARED
READY <area-name> USAGE-MODE IS PROTECTED RETRIEVAL
ALL EXCLUSIVE UPDATE
Usage mode is UPDATE. With the UPDATE usage mode option, also called
shared update mode, we are requesting update access to the area, and we are
specifying that other run units also be allowed to retrieve or update records in the
area as long as they do not specify the PROTECTED or EXCLUSIVE options in
their READY statements.
103
IDMS/R
area while our run unit executes. This essentially gives the run unit exclusive
use of the area.
There are two types of implicit record locks: implicitshared record locks and implicit
exclusive record locks.
An implicit shared record lock is used to guarantee that only one run unit at a time
will be allowed to update a specific record occurrence; any number of run units will
be allowed to retrieve a record protected by a shared record lock. An implicit
exclusive record lock is used to guarantee that no other run unit can either update or
retrieve the record while the exclusive lock is in effect.
Implicit locks are placed on records as they are made current of run unit, record type,
set type, and area. An implicit shared lock is placed on a record when it is retrieved,
and an implicit exclusive lock is placed on a record when it is accessed via update
DML functions. In this way, IDMS/R guarantees that only one run unit at a time will
be allowed to access a record that is being updated, but that any number of run units
will be allowed to retrieve a given record.
Implicit shared locks remain in effect until currency changes; implicit exclusive locks
remain in effect until the run unit ends or until the run unit executes a COMMIT
statement.
Two users are trying to update the same Employee record occurrence.
104
IDMS/R
Retrieve E1
E1 E1
Retrieve E1
E1 E1 E1
Modify E1
E1 E1
3. Run unit 1 issues a MODIFY function to change address for E1. Since run unit
2 has placed a shared lock on the record, run unit 1 is not allowed to update the
record. Run unit 1 waits.
Wait Modify E1
E1 E1 E1
4. Run unit 2 issues a MODIFY function to change address for E1. Since run unit
1 has also locked the record, run unit 2 also waits.
Retrieve E1 Wait
E1 E1 E1
105
IDMS/R
5. Since each run unit is now waiting for a record that the other run unit locked, a
deadlock has occurred.
..
.. Abend
Deadlock Detected
Retrieve E1
E1 E1
E1 Modified
Implicit Exclusive Lock
7. The lock set by run unit 2 is now removed, the MODIFY issued by run unit 1 is
allowed to complete, and IDMS/R sets an implicit exclusive lock on the record
until run unit 1 ends.
Eg. 13.1.
To set an explicit record lock, code the KEEP clause in the DML statement that is
used to retrieve the record. Following are two examples of CALC retrievals during
which locks are set on the retrieved Employee record.
In either case, the lock remains set until we either end the run unit by executing the
FINISH statement or we execute a COMMIT statement.
We can issue a separate KEEP statement to set an explicit lock on a record after
retrieving it.
106
IDMS/R
Explicit lock example:
Retrieve E1
E1 E1
Attempt to
retrieve E1
E1
Wait
E1
4.Since run unit 1 has already placed an exclusive lock on the E1 record, run unit
2 waits.
Modify E1
E1 E1 Wait
5.Run unit 1 issues a MODIFY to update address information for the E1 record.
107
IDMS/R
Lock Released
6.Run unit 1 issues a FINISH, and IDMS/R releases the lock on the E1 record.
Record
Retrieved
E1 E1
7.Run unit 2 is now allowed to retrieve the E1 record. Now that the address has
been updated, the user 2 will see the record with the latest address information.
Eg. 13.2.
108
IDMS/R
14. Utilities
14.1. DMLO
DMLO stands for DML-Online.
E.g.:
This will display department occurrence for the give id, if exists. Otherwise, it
will display error message as ‘db-rec-not-found’ and the value of Error-Status
field as well.
109
IDMS/R
14.2. OLQ
OLQ stands for On-Line Query.
In OLQ, you can generate a report as per the specifications. There are two types
of OLQ sessions: Online and Batch.
First 3 steps are same as that of DMLO, i.e. upto setting the environment for DB
and dictionary. After that, type OLQ.
Next screen:
Select from the given record types
Next screen:
Select the required elements of the selected record types as columns of the
report.
Note: - Everywhere selection should be done with nonblank character.
Next:
110
IDMS/R
Give the required attributes i.e. change headers, sort on columns etc.
On continue processing, mark NO as an active option.
111
IDMS/R
112
IDMS/R
113
IDMS/R
114
IDMS/R
115
IDMS/R
116
IDMS/R
117
IDMS/R
118
IDMS/R
119
IDMS/R
120
IDMS/R
121
IDMS/R
122
IDMS/R
123
IDMS/R
124
IDMS/R
125
IDMS/R
126
IDMS/R
127
IDMS/R
128
IDMS/R
129
IDMS/R
130
IDMS/R
131
IDMS/R
//SYSPCH DD DSN=&&DMLOUT,
// UNIT=&UTUNIT,
// DISP=(NEW,PASS),
// SPACE=(TRK,(5,5))
//SYSIPT DD DSN=DA0000T.SUDHIR.COBOL(IDMST1),DISP=SHR
//* +-----------------------------------------------------------------+
//* | COMPILE THE TRANSLATED COBOL PROGRAM |
//* +-----------------------------------------------------------------+
//COB EXEC PGM=IKFCBL00,REGION=&CREG,
// PARM='&CPARM',COND=(5,LT,DML)
//SYSPRINT DD &PRT
//SYSLIB DD DSN=SYS1.COBCOMP,DISP=SHR
//SYSUT1 DD UNIT=&UTUNIT,SPACE=(CYL,(4,1))
//SYSUT2 DD UNIT=&UTUNIT,SPACE=(CYL,(4,1))
//SYSUT3 DD UNIT=&UTUNIT,SPACE=(CYL,(4,1))
//SYSUT4 DD UNIT=&UTUNIT,SPACE=(CYL,(4,1))
//SYSLIN DD DSN=&&OBJ,DISP=(MOD,PASS),UNIT=&UTUNIT,
// SPACE=(TRK,(40,40))
//SYSIN DD DSN=&&DMLOUT,DISP=(OLD,DELETE)
//* +-----------------------------------------------------------------+
//* | LINK EDIT THE COMPILED PROGRAM |
//* +-----------------------------------------------------------------+
//LKED EXEC PGM=IEWL,PARM='&LPARM',
// COND=((5,LT,DML),(5,LT,COB)),REGION=&LREG
//SYSLIN DD DSN=&&OBJ,DISP=(OLD,DELETE)
// DD DDNAME=SYSIN
//SYSLIB DD DSN=SYS1.COBLIB,DISP=SHR
// DD DSN=SYS5.IDMS.&CV..LOADLIB,DISP=SHR
// DD DSN=SYS5.IDMS.&CV..BASELOAD,DISP=SHR
// DD DDNAME=USERLIB
//SYSIN DD DSN=SYSZ.IDMS.CCS.CARDLIB(&MODE.C),DISP=SHR
//USERLIB DD DSN=SYS5.IDMS.&CV..LOADLIB,DISP=SHR
//SYSLMOD DD DSN=DA0000T.SUDHIR.LOADLIB(IDMST1),DISP=OLD
//SYSUT1 DD UNIT=&UTUNIT,SPACE=(1024,(50,20))
//SYSPRINT DD &PRT
// PEND
//STEP1 EXEC IDMSDMLC
//SYSIDMS DD *
DICTNAME=PATNI
DBNAME=PATNI
ECHO=ON
DMCL=IDMSDMCL
JOURNAL=OFF
132
IDMS/R
Run JCL: -
133
IDMS/R
134
IDMS/R
MINOR CODES
135
IDMS/R
136
IDMS/R
137