HEADER
IDMS_record_relation_bubble_diagrams
http://mftuto.blogspot.com/2009/05/idms.html
MA I NF RAME TU TO RI A L S
THIS IS FREE MAINFRAME TUTORIALS. IT CONTAINS BASIC CONCEPTS IN COBOL, JCL, MVS, VSAM, DB2. I WILL KEEP UPDATING AND ADDING MORE CONTENTS AS AND WHEN POSSIBLE.
Friday, May 8, 2009
IDMS
Table of Contents
1. Overview
1.1. IDMS/R and DBMS
1.2. Database Approach
1.2.1. Data Integrity
1.2.2. Application Development Productivity
1.3. Different Database Architectures
1.3.1. Hierarchical
1.3.2. Network
1.3.3. Relational
1.3.4. Difference Between RDBMS and Network, Relations, Chain Pointers
1.4. IDMS/R: - Network and Relational Facilities, DBMS
2. Logical Database Structure
2.1. Entity, Logical and Physical Structure
2.2. Attributes, Relationships – Training Database
2.3. Entity-Relationship Diagrams
2.4. IDMS Database Records, Record Type, Record Occurrences
2.5. One-To-Many and Many-To-Many Relationships
2.6. IDMS Set, Set Type, Set Occurrence, Bubble Diagram
2.7. Schema, Subschema
3. IDMS/R Batch Program
3.1. Operating Environment
3.2. DML Statements: Executable and Compiler Directive
3.3. Three Steps Compilation: DML Pre-processor, Compilation and Linking
3.4. Compiled Listing of Sample IDMS/R Program
3.5. Run-Unit
3.6. Virtual Storage Layout
3.7. DML Execution Steps
4. Physical Database Structure
4.1. Areas
4.2. Pages
4.3. DB-Key
4.4. Multiple Areas
4.5. Files
4.6. Record occurrence – Prefix, Data
5. Record
5.1. Record Name
5.2. Record Identifier
5.3. Storage Mode
5.4. Record Length
5.5. Location Mode
5.6. Duplicates Option
5.7. Area Name
5.8. Bachman Diagram For Record Type
6. Set
6.1. Set Name
6.2. Linkage Options
6.3. Order Options
6.4. Bachman Diagram For Set
7. Retrieval: Basic, By Sort-key, Indexed Set, Sweeping Areas
7.1. Basic Retrieval: CALC, Through Relationship
7.2. CALC Retrieval: Random access
7.3. Error Handling
7.4. Access By Walking Sets i.e. Access Through Set Relationship
7.5. Retrieval By Sort-Key Value
7.6. Generic Key Retrieval
7.7. Indexed Set
7.8. Retrieval Using Indexed Set
7.9. Bachman Diagram: Indexed Set
7.10. Retrieval By Sweeping Areas
8. Currency
8.1. Currency Table
8.2. Currency loss
8.3. Storing and Retrieval By DB-Key Value
8.4. Obtain Vs. Find and Get
8.5. IF EMPTY / MEMBER:
9. Types of Set Relationships
9.1. Hierarchies
9.2. Junction Record: Multiple Set Membership
9.3. Nested Structure – Bill Of Material
10. Set Membership Options
10.1. Disconnect option
10.2. Connect option
10.3. Bachman Diagram and Examples
11. DML Data Update Functions
11.1. Ready
11.2. Store
11.3. Modify
11.4. Erase
11.5. Connect
11.6. Disconnect
12. Recovery and Restart
12.1. IDMS/R Operating Environments
12.2. Journal Files, Checkpoints
12.3. Recovery / Restart
12.4. Commit
12.5. Recovering From Failures
12.6. Rollback
13. Locking
13.1. Area Locks
13.2. Area Usage Modes
13.3. Record Locks – Implicit, Explicit
14. Utilities
14.1. DMLO
14.2. OLQ
Appendix A: Employee Database
Appendix B: Compilation and Run JCL
Appendix C: IDMS/R ERROR-STATUS VALUES
__________________________________________________________
1. Overview
1.1. IDMS/R and DBMS
IDMS/R (Integrated Database Management System/Relational) is a software product on IBM mainframe that offers capabilities for working with well-organized data. IDMS/R is one of a number of software systems that can be classified as a
DBMS (Database Management System).
A DBMS is a software subsystem that manages a collection of interrelated data elements, stored in a database, that can be accessed in a shared manner by a collection of application programs.
Components of IDMS/R work around a central software subsystem called IDD (Integrated Data Dictionary). In IDMS/R environment, all data elements used in application system are defined in the data dictionary.
1.2. Database Approach
There are many advantages to maintaining all an organization data in a central pool or reservoir, so that it can be shared by a number of application programs. We can place the advantages of the database approach into two categories:
Data integrity and Application development productivity.
1.2.1. Data Integrity
Reducing / eliminating data redundancy: - There is no duplication of information. Each piece of information is stored only once in the central pool and application programs access it via the database management system. E.g. information
about employees is stored centrally in Employee table or structure. Multiple copies of same data do not exist in different stages of updating.
Recovery and Restart: - A database management system provides powerful tools for automatically recovering from system failures, restoring the database to its original form, and restarting jobs that were affected by failures.
1.2.2. Application Development Productivity
Simplified Programming: - In a program that uses conventional files, much of the program logic must deal with the way in which files are read and written, and the order in which data is processed. With a DBMS, application programs
make simple requests for data, and the DBMS performs all the necessary steps to locate the required data. This results in application programs that are less complex than those that work with conventional files.
Reduced Maintenance: - The application programs using conventional files are tied tightly to the formats of files they process. If a record format changes, all programs that access the record must also be modified. With a DBMS, since
programs do not access data directly, changes can be made to the structure of the database without requiring that applications programs be modified. Data and programs are independent.
These two things increase programmer productivity.
1.3. Different Database Architectures
1.3.1. Hierarchical
In a hierarchically structured database, data records are typically connected with embedded pointers to form a tree structure / configuration, in which a dependent record type has one and only one parent. IMS is an example of
hierarchical DBMS.
Supplier
l
l
------ Order
l
l
------ Line Item
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.
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
llll
llll
l ------- Order l l
llll
llll
l l-------- Line Item --------l l
ll
ll
l--------------------- Quotation ------------l
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
1.3.4. Difference Between RDBMS and Network, Relations, Chain Pointers
The reason “relational systems” are called “relational” is that the term relation is basically just a mathematical term for a table.
In the relational model, the data and the relationships among data are represented by a collection of tables. The network model differs from the relational model in that data are represented by collection of records, and relationships
among data are represented by links.
Relational model supports one-to-many and many-to-many links. But, Network model supports only one-to-many links and it does not support many-to-many links.
Links are implemented in the Network model by adding pointer fields to records that are associated via a link.
To illustrate the implementation of the Network model, suppose the Dept-Employee relationship is one-to-many from Dept to Employee. An Employee record occurrence can be associated with only one Dept record occurrence. Thus, we
need only one pointer in the Employee record occurrence to represent the Dept-Employee relationship. However, a Dept record occurrence can be associated with many Employee record occurrences. Rather than using multiple pointers
in Dept record, we can use a ring structure or chain pointers to represent all employees in the given department. Chain pointers form a circular list.
Consider another example given below about chain pointers.
In the Training department, many courses are conducted for different subjects. There are two record types, namely Subject and Course, which are linked.
SUBJECT
Address Sub-Id Sub-Name First Last
#0 S001 MVS *0 *6
#1 S002 JCL *1 *7
#2 S003 VSAM *2 *2
#3 S004 IDMS *3 *3
COURSE
Address Course-Id Course-Name Next Prior Owner
*0 C0701 FIT-MVS *4 - #0
*1 C0702 FIT-JCL *5 - #1
*2 C0703 FIT-VSAM - - #2
*3 C0804 FIT-IDMS - - #3
*4 C0901 EXP-MVS *6 *0 #0
*5 C0902 EXP-JCL *7 *1 #1
*6 C1001 FIT-MVS - *4 #0
*7 C1002 FIT-JCL - *5 #1
Consider subject MVS with Sub-Id S001: - “First” pointer points to first MVS course C0701. “Next” pointer of course C0701 points to next MVS course i.e. C0901 and so on.
It is clear from the preceding discussion that the Network model is closely tied to the implementation. Querying is simple in the relational model, while it is significantly more complicated in the network model. The programmer is forced
to think in term of links, and how to traverse them to get at needed information. Data manipulation in the network model is hence said to be navigational.
1.4. IDMS/R: - Network and Relational Facilities, DBMS
IDMS/R was originally designed to be an implementation of the network database model, but the addition of relational capabilities through a software subsystem called the Automatic System Facility (ASF) has given it a dual nature.
Network structured databases can be used to handle high volume transaction processing applications which have demanding performance requirements. Relational databases can be used to accommodate user-generated applications.
Combining both network and relational capabilities in one system provides the installation with a versatile tool for meeting both production requirements and the ease-of-use requirements of end users.
The relational and network capabilities of IDMS/R are supported by a single database management system product. This means that data stored in the form of network structures can be accessed by conventional application programs, but
can also be accessed by the relational facilities for those applications that require a relational view of the network structured data. In turn, data entered through the relational facility can be used to update the production, networkstructured database. In either case, all database access, input/output operations, and space management are performed by the same system components.
The heart of any database product is the software component that manages access to the database. This component is most commonly called the DBMS. IDMS/R consist of a set of software modules that manage the data elements that are
stored in the database and maintains the relationships that exist between them. A major purpose of a DBMS is to isolate application programs from the details concerning how data elements are physically stored. To this end, the data
stored in an IDMS/R database is accessed only by the DBMS and never directly by an application program.
IDMS/R support for a networked structured database is provided via two common languages that designers and programmers use to control access to the database: data description language (DDL) and data manipulation language (DML).
The DDL is used by database designers to describe the logical and physical structure of the database to DBMS software and to application programs. Application programs use DML to specify how the database is accessed. Application
programs make requests for access to the database by executing DML statements; the DBMS intercepts these requests and performs the required accesses to the database to satisfy these requests.
IDMS/R uses a software subsystem called Automatic System Facility (ASF) to provide users with a relational view of the database. ASF is menu oriented and relatively easy to use.
2. Logical Database Structure
2.1. Entity, Logical and Physical Structure
When we are using a powerful DBMS, such as IDMS/R, to manage a central pool of data, we can view the database on a number of different levels. At the highest level is the application environment, where we discuss the nature of the
entities that we are representing in the database. Entities consist of those objects, people, or ideas about which we are storing data.
On a lower level we are concerned with software, where we describe the logical structure of the database that we are using to represent information about entities in the database.
On a still lower level is the hardware, where we describe the physical structure of the database and the way in which logical records are implemented in computer storage.
2.2. Attributes, Relationships – Training Database
We will be using a hypothetical Training Department database that might be used to maintain information about courses conducted and faculties.
Please consider the following scenario for the Training Department.
• The Training Dept conducts courses for various subjects. At any given point of time, multiple courses can be in progress.
• There are 10 faculties in the department. A faculty can teach multiple subjects. A subject can be taught by multiple faculties.
• There are many participants for a course.
• Performance of a participant in a course is measured in terms of attendance, assignments and test marks.
The database will store information about the following entities.
Faculty: - Information about faculties in Training department
Subject: - Information about subjects taught
Course: - Information about courses of diff subjects
Participant: - Information about participants in a course
Performance: - Information about performance of a participant
In discussing entities, we can discuss the attributes that an entity has and the relationships that exist between the entities.
Entity Attributes:
An attribute is a particular piece of information that is associated with an entity. E.g., possible attributes of the Subject entity are Subject-Id, Subject-Name, Subject-Stream, etc.
Entity Relationships:
We can identify a number of relationships between the entities about which we are storing information. E.g. the Faculty and Course entities participate in one-to-many relationship. Each course is conducted by one faculty, but each
faculty conducts many courses. The Course and Participant entities form another one-to-many relationship. Each participant attends one course, and each course has many participants. The Participant and Performance entities also form
one-to-many relationship. The Faculty and Subject entities form a many-with-many relationship. One faculty can teach many subjects, and a subject can be taught by many faculties.
2.3. Entity-Relationship Diagrams
We can represent the relationships between the entities (discussed above) using an entity-relationship diagram.
An entity-relationship diagram for Training Department information is given below.
Faculty Subject
ll
ll
ll
l------------- Course ------------------------l
l
l
l
Participant
l
l
l
Performance
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 side of a relationship and the other end of the arrow indicates the
“one” side of a relationship.
2.4. IDMS Database Records, Record Type, Record Occurrences
Database Records: - In representing the Training Department database using a network-structured IDMS/R database, we begin by defining a separate database record for each entity. Consider the Subject entity and its attributes. We
represent the Subject attributes using a Subject record and we represent each Subject attribute as a data element within the Subject record as shown below. Data elements are sometimes called data items or fields. We name each data
element, define its length and define the type of data that it will contain.
Subject Record
Subject-Id Subject-Name Subject-Stream
PIC X(04) PIC X(10) PIC X(06)
(Subject record type)
Record Types Vs. Record Occurrences: - There is a clear distinction between a record type and a record occurrence. We can think of a record type as a template. It describes the format of all occurrences of a given record type that will
be stored in the database. Each occurrence of the Subject record type consists of a single set of values for the Subject-Id, Subject-Name and Subject-Stream data elements as shown below.
Subject Record Type
Subject-Id Subject-Name Subject-Stream
PIC X(04) PIC X(10) PIC X(06)
Subject Record Occurrences
S002 JCL IBM
S003 VSAM IBM
S004 IDMS IBM
2.5. One-To-Many and Many-To-Many Relationships
IDMS/R supports one-to-many relationship. IDMS/R does not support directly many-to-many relationships. For each many-to-many relationship between two entities, we will almost always identify additional attributes that are not
associated with either of the two entities alone, but are associated with the intersection between the two entity types. This intersection is represented by another record type, called junction record type, which has one-to-many
relationships with the two entity types. The junction record resolves the many-to-many relationship and implements this many-to-many relationship indirectly.
The junction record type is described in more details in Section 9.2.
2.6. IDMS Set, Set Type, Set Occurrence, Bubble Diagram
A one-to-many relationship in an IDMS/R network database is implemented by defining a set. A set consists of two or more record types that participate in one-to-many relationships with one another. The record type on the “one” side of
the relationship is designated the owner of the set; the record type on the “many” side is designated the member record type. Each set must be assigned a unique name.
The names of all the sets for Training Dept database are shown in the diagram below.
Faculty Subject
Faculty-Course l Subject-Course l
ll
ll
l------------------- Course -------------------l
l Course-Participant
l
l
Participant
l Participant-Performance
l
l
Performance
A set that consist of only two record types is generally given a name that is a concatenation of the names of Owner and Member record types separated by hyphen. E.g. Faculty-Course, Course-Participant.
Also, please refer to Employee Database in Appendix A.
Set Type Vs. Set Occurrence:
As with record types and record occurrences, there is an important distinction between a set type and a set occurrence. Like a record type, a set type can be thought of as a template that describes the general nature of the set. A set
occurrence, on the other hand, consists of a specific single occurrence of the owner record type and all occurrences of the member record type that are associated with it.
A specific occurrence of the set Faculty-Course is shown in a diagram given below. It is called a bubble diagram.
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.
Following is another example of bubble diagram.
2.7. Schema, Subschema
Schema: - The definition of all record types and all set types that make up an IDMS/R network database is called a schema. We can represent a schema visually by using a Bachman diagram. Refer to Section 5.8 for more details of
Bachman diagram.
Subschema: - In real-world systems, most application programs do not require access to all record types and all set types that are defined in a schema. One or more subschemas are defined such that each subschema specify the particular
record types, data elements and set types, that each group of application programs needs access to.
E.g. In a big manufacturing company, there would be a different subschema for Inventory Dept, Payroll Dept, Sales Dept, etc. Users in a particular department work only on record types, data elements, set types that are required for
their application or function. Users in Payroll Dept do not work on data of Inventory dept functions. Users in any particular department do not need access to the entire schema, but they work on some portion of the schema.
Subschemas provide a means of simplifying the view of the database for each application program. Subschemas also provide the ability to restrict access to only those record types, data elements and set types that a particular application
program is authorized to access.
An application program always accesses the database by referring to a subschema. So even if a program requires access to all the record types, data elements and set types defined in the schema, there should be a subschema defined
such that includes all the elements defined in the schema.
3. IDMS/R Batch Program
3.1. Operating Environment
A conventional application program generally begins by issuing one or more OPEN statements. OPEN statements prepare files for processing and establish linkages between the application program and the operating system data
management routines. The program then makes requests for file accesses by issuing READ, WRITE statements. These statements result in calls to the operating system data management routines that handle the requests.
In an IDMS/R application program, there are no file description statements or OPEN or CLOSE statements for the database. The reason for this is that the application program does not interface directly with the operating system data
management routines that handle data transfer operations. Instead, the application program issues DML statements that direct IDMS/R to access the database.
3.2. DML Statements: Executable and Compiler Directive
An IDMS/R program uses DML statements for database access. The IDMS/R DML provides a number of statements that enable the programmer to access an IDMS/R database and to perform a number of support functions.
Some DML statements are carried out during the program’s execution.
Some DML statements are compiler-directive statements. Compiler-directive statements control compilation of a program. E.g. a compiler-directive statement is used to identify the subschema that the program should use.
3.3. Three Steps Compilation: DML Pre-processor, Compilation and Linking
Following diagram illustrates the steps required to prepare an application program for execution.
An IDMS/R application program has DML statements embedded in the source code to request database access and other support functions. Before the source program is compiled, the program is first read by a DML processor. The DML
processor validates the DML statements and creates a translated version of the source program 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.
The DML processor must have access to the data dictionary as it processes the source program. The programmer can use COPY or INCLUDE statements to merge in predefined program modules, record descriptions. The DML processor
automatically includes record description entries defined by the subschema the program is using. In addition, the DML processor automatically updates the data dictionary. E.g. the DML processor stores into the data dictionary information
about the types of DML statements that the program executes against database records.
3.4. Compiled Listing of Sample IDMS/R Program
IDENTIFICATION DIVISION.
PROGRAM-ID. IDMSTEST.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. IBM-3090.
OBJECT-COMPUTER. IBM-3090.
*IDMS-CONTROL SECTION.
*PROTOCOL. MODE IS BATCH.
* IDMS-RECORDS MANUAL.
DATA DIVISION.
*SCHEMA SECTION.
* DB EMPSS01 WITHIN EMPSCHM VERSION 100.
WORKING-STORAGE SECTION.
01 WS-DEPT-ID PIC 9(04) VALUE 0.
* COPY IDMS SUBSCHEMA-CONTROL.
01 SUBSCHEMA-CTRL.
03 PROGRAM-NAME PIC X(8)
VALUE SPACES.
03 ERROR-STATUS PIC X(4)
VALUE '1400'.
88 DB-STATUS-OK
VALUE '0000'.
88 ANY-STATUS
VALUE ' ' THRU '9999'.
88 ANY-ERROR-STATUS
VALUE '0001' THRU '9999'.
88 DB-END-OF-SET
VALUE '0307'.
88 DB-REC-NOT-FOUND
VALUE '0326'.
03 DBKEY PIC S9(8) COMP SYNC.
03 RECORD-NAME PIC X(16)
VALUE SPACES.
03 RRECORD-NAME REDEFINES RECORD-NAME.
05 SSC-NODN PIC X(8).
05 SSC-DBN PIC X(8).
03 AREA-NAME PIC X(16)
VALUE SPACES.
03 AREA-RNAME REDEFINES AREA-NAME.
05 SSC-DNO PIC X(8).
05 SSC-DNA PIC X(8).
03 ERROR-SET PIC X(16)
VALUE SPACES.
03 ERROR-RECORD PIC X(16)
VALUE SPACES.
03 ERROR-AREA PIC X(16)
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 '.
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.
* 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).
CALL 'ABORT'.
ISABEX. EXIT.
Explanation of sample IDMS/R program:
Identification Division
The Identification Division of the IDMS/R program is similar to that of a conventional COBOL program.
IDENTIFICATION DIVISION.
PROGRAM-ID. IDMSTEST.
The name of Program-id is generally the same name as the name of the load module that is referenced in the EXEC statement of the run JCL.
Environment Division
This division contains the INPUT-OUPUT section, which contains references to the files used by the program.
In addition to the normal INPUT-OUPUT section, the Environment division contains a new section called the IDMS-CONTROL section:
IDMS-CONTROL SECTION.
PROTOCOL. MODE IS BATCH
IDMS-RECORDS MANUAL.
The PROTOCOL statement is a compiler-directive statement that specifies the manner in which the DML processor will generate CALL statements. In this example, BATCH indicates that the program will run in the batch rather than the
online mode. The IDMS-RECORDS MANUAL clause specify records whose data descriptions (or record layout) will be copied from the data dictionary into the working-storage section by using the statement ‘COPY IDMS RECORD in the Data
Division.
Note: - If we mention ‘MODE IS BATCH DEBUG’, then DEBUG indicates that the DML processor will supply additional code in the resulting source program that will be helpful in program debugging using the debugger.
Data Division
This division begins with a new section called ‘Schema Section’ in addition to File section and Working-Storage section. Schema Section specifies the names of the subschema and the schema used in the program.
DATA DIVISION.
SCHEMA SECTION.
DB EMPSS01 WITHIN EMPSCHM VERSION 100.
The remaining DATA division sections are similar to those of a conventional COBOL program.
The data descriptions that define the IDMS Communications Block (i.e. Subschema-Control) and the Department record have been inserted by the DML processor.
Procedure Division
As in a conventional application program, the Procedure division defines the processing that the program performs. The main difference between the
PROCEDURE division of an IDMS/R application program and that of a conventional COBOL program is the inclusion of DML statements that request IDMS/R services.
BIND statements are required for database access.
The ‘BIND RUN-UNIT’ statement establishes addressability for the IDMS Communications Block and causes IDMS/R to load the subschema identified in the SCHEMA section.
The ‘BIND DEPARTMENT’ statement establishes addressability for the WORKING STORAGE area that will be used to contain Department record occurrences.
The READY statement performs an equivalent function as an OPEN statement for a conventional file.
The ‘READY ORG-DEMO-REGION’ statement indicates that the program will retrieve data only and will not be allowed to execute database modification DML statements for the specified area.
Status Checking:
The statement immediately following the READY statement performs a paragraph named IDMS¬-STATUS.
READY ORG-DEMO-REGION.
PERFORM IDMS STATUS.
The IDMS STATUS routine is brought into the program as a result of a COPY IDMS statement that is coded toward the end of the source listing:
COPY IDMS IDMS STATUS.
The program performs the IDMS STATUS paragraph after each DML statement is executed to determine if the requested operation executed successfully. IDMS/R returns, in the ERROR STATUS field of the IDMS Communications Block, a
status code that describes the results of the requested operation.
If IDMS/R completes a requested DML operation successfully, it returns an error status code zero. If IDMS/R detects an error condition, it returns a
nonzero error status code. The data elements that define the layout of the Communications Block specify a number of status code values. These represent the status code values most often returned by IDMS/R. A status code value of
"0000"is labeled DB STATUS OK, and indicates a successful DML operation. An end of set condition is indicated by “0307”. When a retrieval fails because a record is not found, a value of “0326” is returned.
The IDMS STATUS paragraph performs error status code checking and abnormally terminates the program if a nonzero error status code is found. For the READY statement, anything other than a zero status code is unacceptable.
Database access: - The program accepts the value of Dept-Id and moves that value to Dept-Id field of Department record layout in working storage. The program then issues a DML statement to read the appropriate Department database
record: OBTAIN CALC DEPARTMENT.
If IDMS/R cannot locate a Department record having the requested dept-id, the program displays an error message. If the Department record is found, the program displays department-name.
Finish statement: - The pro¬ gram 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.
A run unit is a unit of work within IDMS/R. Each run unit represents a concurrently executing task that is interacting with an IDMS/R database.
A run unit begins with the BIND RUN-UNIT statement and ends with the FINISH statement. The BIND RUN-UNIT and FINISH statements are analogous to the processing time between OPEN and CLOSE file statements. A program can consist of
any number of run units that are executed serially, but typically contains only one.
Note: - If your program consists of more than one run unit, you must reinitialize the ERROR STATUS field in the IDMS Communication Block to the value 1400, before reissuing the BIND RUN-UNIT and READY statements.
3.6. Virtual Storage Layout
Following diagram shows the layout of virtual storage when an IDMS/R program executes.
IDMS/R is generally contained in its own area of virtual storage, i.e. an address space in an MVS system. The IDMS/R area of virtual storage contains the IDMS/R database management system and the system buffers. The system buffers are
the storage locations that IDMS/R uses in transferring database pages to and from direct access storage. The IDMS/R area also contains the subschema tables for the IDMS/R application programs currently in execution. Subschema tables
are loaded when an application program requests database access.
The area of virtual storage occupied by the IDMS/R application program contains variable storage, the IDMS/R interface module and an executable code. Variable storage contains the data areas to be modified by the program during
execution. In addition to other storage areas used by the program, variable storage contains a control block called the IDMS communication block. IDMS/R stores into the IDMS communication block information about the results of each
request for an IDMS/R service.
3.7. DML Execution Steps
Following are the steps that are involved in the execution of a typical DML statement, in this case for a retrieval.
i. Call the IDMS/R Interface Module: - The CALL statement generated by DML processor passes control to IDMS/R Interface Module and provides it with information that will be needed to perform the requested database access. This
information includes the type of database service desired and record, set, and area names.
ii. Transfer control to IDMS/R: - The IDMS/R interface module transfers control to IDMS/R DBMS, which performs the requested service. Since access to the database is controlled by the subschema tables, the DBMS reads the tables to
determine record, set, and area definitions, currencies, and access restrictions.
iii. Retrieve database record and build subschema record: - The required database record is retrieved, if required, and an image of the requested subschema record is built in variable storage. It is not always necessary for the DBMS to
read the database to satisfy a retrieval request. E.g. the required record may already be in a system buffer due to a previous retrieval. If the desired record is not already in a buffer, the DBMS uses operating system data management
facilities to read the required database page from direct access storage.
iv. Update currencies: - The DBMS updates run-unit, record type, set type and area currencies, as required. This is done by moving the database key and other control data from the system buffers to the subschema tables.
v. Store status information: - The DBMS moves status information to appropriate locations within the IDMS Communication Block. This information describes the results of the requested DML function.
vi. Return to the program: - After updating the Communication block, control is passed first from the DBMS to the IDMS/R Interface Module and then to the application program at the statement following the DML statement just executed.
vii. Test status information: - The application program should contain code to check the results of each requested service. The ERROR-STATUS field of IDMS Communication Block contains the status of DML statement just executed.
4. Physical Database Structure
Here, we discuss how an IDMS/R network-structured database is physically implemented.
4.1. Areas
An IDMS/R database is divided into one or more areas. An area is defined as the major named subdivision of addressable storage in the database. Areas contain occurrences of the records that make up networked-structured databases.
Each area can contain occurrences of one or more record types, but all occurrences of a particular record type must be located in the same area.
4.2. Pages
An area can be further subdivided into pages, which constitute the smallest logical units of database storage. A page is the unit of data that is moved between the database and the system buffers that are used by IDMS/R to hold the
retrieved records. The diagram given below shows the structure of a page from a database area.
A database page contains record occurrences and control information.
Header of a page: 16 Bytes
Page Number Next pointer Prior Pointer SA Unused
4 Bytes 4 Bytes 4 Bytes 2 Bytes 2 Bytes
Footer of a page: 16 Bytes
Line Index 0 Line Space Count Page Update Count Page Number
8 Bytes 2 Bytes 2 Bytes 4 Bytes
Line Index format: 8 Bytes
Record-Id Displacement Record Length Prefix Length
2 Bytes 2 Bytes 2 Bytes 2 Bytes
Each page can be considered as a mini-database since each normally stores several records and contains its own control information. The IDMS/R database page is broken into four distinct sections.
i. The header of a page is 16 bytes long, consisting of the page number (4 bytes), the next pointer (4 bytes), the prior pointer (4 bytes), the space available count (2 bytes) and a 2-byte unused space.
SA (Space Available Count) is the number of bytes of free space on the page. Initial value of this field is (PAGESIZE – 32) bytes.
ii. The page body that contains all of the object data records being stored on the page. The data stored in the page body is always concentrated at the front of the page body. This feature, that continuously optimizes the available space
on the page, reduces unusable space to a minimum.
iii. The line index group contains one or more line index pointers, one for each record stored on the page. The indexes move from the end of the page backward into the page body as more records are placed on the page.
The line index itself is 8 bytes in length, broken into four 2-bytes fields: the record identifier, the displacement of the beginning of the record from the start of the page, the record length and the length of the record prefix (the
pointers).
iv. The page footer consists of 16 bytes, broken into a line index for the header (8 bytes), the line space count (2 bytes), the page update count (2 bytes) and the page number (4 bytes).
Note that the page number occurs as the first and last four bytes of each page. This is added protection against undetected database damage. IDMS/R actually checks both values each time a page is read; an unequal value causes
immediately alarm within DBMS.
Each page has a unique page number. Within a page, each record occurrence has unique line number.
Pages in an area must be sequentially numbered. Gaps in the page numbers can occur between areas. Areas cannot overlap i.e. a page number can belong to one area only.
Valid page numbers:
AREA 1 Pages 1 – 500
AREA 2 Pages 601 – 1000
Invalid page numbers:
AREA 1 Pages 1 – 500
AREA 2 Pages 401 – 700
4.3. DB-Key
Each record occurrence is assigned a unique numeric identifier, called its database key (db-key). Format of db-key is shown below.
A record occurrence’s db-key consists of a 32-bit field that typically contains a 23-bit page number and an 8-bit line number. The page number identifies the page in which the record occurrence is stored and the line number identifies the
location of the record occurrence within that page.
IDMS/R uses database keys to keep track of where in the database record occurrences are physically stored.
Sign Bit (Not used)
/
/____________________________________________
l l Database Page Number l Line Number l
---------------------------------------------0 1 23 24 31
4.4. Multiple Areas
A database could be divided into multiple areas for many reasons.
• Processing efficiency. Programs can open areas individually. If we group record-types into areas appropriately, programs can open only the areas that contain the record types they need. E.g. programs of Payroll function do not need
any record types pertaining to Inventory / Stock data of Parts. So, record-types associated with Payroll data would be in one area. Record-types associated with Inventory data can be in another area.
• Security. If we need to restrict access to certain record types, we can place them together in an area that is protected using IDMS/R security facilities. E.g. access to Payroll-Area is restricted.
• Search efficiency. Efficiency of sequential scan through the database improves if the record type is assigned to a separate area.
• Concurrent updating. A program can request exclusive use of an area and prevent other programs from accessing it concurrently.
• Database recovery and backup. The database can be initialized, restructured and backed up on an area-by-area basis. Areas assigned to highly volatile record types can be given different treatment from areas that are assigned to record
types whose occurrences are changed little.
4.5. Files
Each page corresponds to a physical record that is stored in a file, and all data transfers between the database and the system buffers are accomplished a page at a time.
The ways in which areas can be mapped into files in direct access storage are as follows:
• Many (or all) areas can be mapped into one file if all the areas have the same page size.
• Each area can be mapped into a different file.
• One area can be mapped into many files.
4.6. Record occurrence – Prefix, Data
An IDMS/R database consists physically of a collection of record occurrences. The record occurrence represents the smallest directly addressable unit of data. A record occurrence consists of a fixed or variable number of characters that
are subdivided into units called data elements or fields. These data element values follow the formats that were defined in the schema for this record type. Application programs work on these fields. In an application program, we cannot
address an individual data element without first retrieving the record occurrence in which it is stored.
The physical records stored in the database consist of more than the data elements used by the application program. IDMS/R also maintains information about the relationships that exist between records. These relationships are physically
implemented by linking record occurrences together with pointers. Pointers contain the addresses of related record occurrences and are stored with the data elements that make up each record occurrence.
Following diagram shows the format of a record occurrence, as it is physically stored in the database. A record occurrence in the database is made up of two parts: a data portion and a prefix portion. Data element values are stored in the
data portion. Pointers to related record occurrences are stored in the prefix portion. Application programs generally work only with the data element values that are stored in the data portion. IDMS/R DBMS automatically maintains the
pointers in the prefix portion.
_____________________________________________________________________________________
:Prefix : Data :
:___________________________________________:_______________________________________:
:Pointer 1 : Pointer 2 : Pointer 3 : ………. : Data :Data : Data : ……..:
: : : : : Element 1:Element 2 : Element 3: :
-------------------------------------------------------------------------------------
5. Record
Here, we discuss the characteristics that apply to record types.
5.1. Record Name
Each record must be assigned a 1- to 16-character name that identifies the record type. It should be a unique name. The name must begin with an alphabetic character. The application program must reference the record’s name in
requesting that some DML function be performed on one or more occurrences of a record type.
5.2. Record Identifier
The record identifier is a number (in the range 100 through 9999) that serves as an internal identifier for the record type. Each record type must be assigned a unique record identifier within the installation. A database administrator
assigns record identifiers for each record type that the installation creates. Application programs do not refer to records using their record identifiers.
5.3. Storage Mode
The storage mode indicates whether occurrences of this record type are fixed or variable in length and whether they are stored in compressed format. Codes used to represent a record’s storage mode are as follows:
• F (fixed length)
• V (variable length)
• C (compressed)
The compressed storage mode can be used in conjunction with the fixed-length or variable-length storage mode. E.g. a storage mode of FC indicates that record occurrences are fixed length and compressed. When data compression is
used, an IDMS/R module automatically compresses and decompresses the data. Application programs are not aware that compression and decompression is taking place.
5.4. Record Length
The record length, expressed in bytes, is the actual data length for a fixed-length record or the maximum data length for a variable-length record.
5.5. Location Mode
The location mode defines the way a record is stored in its database area and tells the application programmer the way in which occurrences of this record type must be accessed. The three possible location modes are:
• CALC
• VIA
• DIRECT
CALC Location Mode
With the CALC location mode, a particular field (data element) within the record itself must be declared as the CALC-key. When the application program requests that record occurrences be stored into the database, IDMS/R uses the
CALC-key value to calculate the page into which the record should be placed. IDMS/R uses a randomizing routine to distribute records evenly over its area. To retrieve a record later, the application program supplies IDMS/R with a CALCkey value, and IDMS/R uses the randomizing routine to locate the proper page and directly retrieve the record occurrence that has the supplied CALC-key value.
E.g., Department record type with CALC location mode and Dept-Id-0410 field as CALC-key. When we add each new Department record occurrence to the database, IDMS/R uses the Dept-Id-0410 value contained in the record we are
adding to calculate the specific page within the database to store the record. It then stores the record occurrence on that page. To retrieve the record for a particular department later, the application program moves the Dept-Id-0410
value for the desired department into a designated application program storage area and executes a DML retrieval function. IDMS/R then uses the randomizing routine to locate the page on which the desired record is stored, searches
through the page for the desired Department record occurrence, and builds an image of the required subschema record in an application program storage area.
The use of the CALC location mode results in record occurrences being distributed relatively evenly over the pages in the area, thus minimizing overflow conditions and leaving space for adding new records. Secondly, it allows us to
retrieve records directly by supplying a CALC-key value. A desired record is typically retrieved with a single access rather than requiring IDMS/R to search through the database for it.
VIA Location Mode
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.
Employee
:
: Emp-Expertise
:
V
Expertise
Area 1
_______________________________________
: _________ _________ _________ :
: :Employee : :Employee : :Expertise: :
: --------- --------- --------- :
: _________ _________ _________ :
: :Expertise: :Expertise: :Expertise: :
: --------- --------- --------- :
: _________ _________ _________ :
: :Expertise: :Expertise: :Expertise: :
: --------- --------- --------- :
: _________ _________ :
: :Expertise: :Expertise: :
: --------- --------- --------- :
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.
Employee
: Emp: Expertise
:
v
Expertise
Area 1 Area 2
______________ ___________________________________________
: : : __________ __________ :
: __________ : : :Expertise : :Expertise : :
: :Employee : : : ---------- ---------- :
: ---------- : : __________ __________ __________ :
: : : :Expertise : :Expertise : :Expertise : :
: __________ : : ---------- ---------- ---------- :
: :Employee : : : __________ __________ __________ :
: ---------- : : :Expertise : :Expertise : :Expertise : :
: : : ---------- ---------- ---------- :
: : : __________ :
: : : :Expertise : :
: : : ---------- :
::::
:--------------: :-------------------------------------------:
When the VIA location mode is assigned to a record type, no CALC-key can be defined for that record type. This means that CALC retrievals cannot be requested for record types that are assigned VIA location mode. In many cases, the
owner record type of a set type is assigned the CALC location mode, and the member record type is assigned the VIA location mode. This allows an owner record type to be retrieved directly, after which all the owner’s member record
occurrences can then be quickly located.
DIRECT Location Mode
When storing records into the database using the DIRECT location mode, the application program explicitly specifies the page number into which the record occurrence should be stored. Then when retrieving a record occurrence, the
program must specify the db-key value of the desired record occurrence. Since it is often difficult for the program to determine the db-key value of the record it wants, this location mode is less often used than CALC or VIA.
5.6. Duplicates Option
The duplicates option is specified only for records that are stored using the CALC location mode. This option specifies whether records having duplicate CALC-keys are allowed, and if duplicates are allowed, where records having duplicate
CALC-key values are to be placed in the area. Codes used to represent the duplicates options are as follows:
• DN (Duplicates Not Allowed). With this option, a record occurrence with a duplicate CALC-key value will not be accepted. IDMS/R will signal an error if the program attempts to store a record that has the same CALC-key value as an
existing record in the database.
• DF (Duplicates First). With this option, a record occurrence with a duplicate CALC-key value will be accepted. IDMS/R will store the record before any record in the database that has a matching CALC-key value. When a CALC retrieval is
made using that CALC-key value, the new record will be retrieved first.
• DL (Duplicates Last). With this option, a record occurrence with a duplicate CALC-key value will be accepted. IDMS/R will store the record after any record in the database that has a matching CALC-key value. When a CALC retrieval is
made using that CALC-key value, the new record will be retrieved last.
5.7. Area Name
The area name is the name of the area into which all record occurrences of the record type are to be stored.
5.8. Bachman Diagram For Record Type
Please refer to Employee Database mentioned in Appendix A. It is called a Bachman diagram. A rectangle box is used to describe characteristics of a record. Following diagram shows how characteristics of a record are mentioned in the
rectangle box.
The information for Department record type is as follows.
• Department – The record name.
• 410 – The unique record identifier assigned to the record type.
• F – The storage mode, indicating fixed-length records.
• 56 – The record length.
• CALC – The location mode, indicating records are stored in the database area using the CALC location mode.
• Dept-Id-0410 – The data element (field) name designated as the CALC-key. For a record that is defined with the VIA location mode, this space is used to specify the name of the set that is used in locating and storing record occurrences.
• DN – The duplicates option, indicating duplicates not allowed.
• Org-Demo-Region – The name of the area in which the Department records are stored.
6. Set
Set relationships are defined according to the following rules:
• Any record type can be a member of any number of sets.
• Any record type can be the owner of any number of sets.
• Any record type can be a member of one set and the owner of another.
• A record need not be part of any set.
Set characteristics:
Set characteristics are assigned to each set when defining the database to IDMS/R. These characteristics are:
• Set name
• Linkage options
• Membership options
• Order options
6.1. Set Name
The unique name must be assigned to each set type in the database. The set’s name must be referenced whenever an application program accesses records using that set relationship. Generally, a set name is formed by concatenation of
names of the owner and the member record types separated by a hyphen. E.g. in the Employee database, the set Dept-Employee implements the one-to-many relationship between the Department record and the Employee record.
6.2. Linkage Options
The linkage option indicates the types of pointers that are used to implement the set. Pointers control flexibility in accessing records within a set. Codes used to represent the linkage options are as follows:
• N (NEXT pointers). With this linkage option, the pointers in the set identify the NEXT record occurrence. Following figure shows the use of NEXT pointers in implementing a set occurrence. This option allows access to member records
only in the forward direction. To access a particular member record occurrence, we must typically begin with owner record and then walk through all the member records until we access the one we want. When only NEXT pointers are
used to 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
• 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
• 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.
• 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
Ex.: Consider the following set.
Department
Dept-Employee
Emp-Expertise
Pointers in Employee record occurrence:
Prior in Emp-Expertise set
Next in Emp-Expertise set
Owner in Dept-Employee set
Prior in Dept-Employee set
Next in Dept-Employee set
6.3. Order Options
The Order option specifies the logical order in which member record occurrences are placed within a set occurrence. The logical order of member record occurrences is independent of the physical placement of the records themselves.
The order options are as follows:
• FIRST. Each new member record occurrence is placed immediately after the owner record (in the next direction). While retrieving, this option achieves a member order of LIFO.
Before Insertion
After Insertion
E15 is inserted
• LAST. Each new member record occurrence is placed immediately before the owner record (in the prior direction). While retrieving, this option achieves a member order of FIFO. PRIOR pointers are required (NP or NPO linkage option)
to satisfy the LAST order option.
Before Insertion
After Insertion: E15 is inserted
• NEXT. Each new member record occurrence 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
After Insertion: E15 is inserted
• PRIOR. Each new member record occurrence is placed immediately before the member record occurrence that was last accessed (in the prior direction) within the set occurrence i.e. prior to the current of set. Prior pointers are
required in order to specify the PRIOR order option.
Before Insertion: current of set is E2
After Insertion: E15 is inserted
• SORTED. With this option, a new member record occurrence is placed in ascending or descending sequence, based on the value of a designated sort-control data element, or sort key, contained in each record occurrence. When a record
is placed into a set, the DBMS examines the sort key in each member record occurrence to determine the logical position of the new member record occurrence in the set occurrence.
A sorted set order is defined by the keywords ASC (ascending) or DES (descending), followed by the data element name of the sort key.
Consider Dept-Employee set. Order option is sorted, ASC, and sort-key is EMP-LAST-NAME-0415.
Before insertion:
Insert “Kamat”.
After insertion:
Duplicates Option: - A duplicates option indicates the action to be taken by the DBMS when a duplicate sort-key value occurs. Codes used to represent the duplicates option for sorted sets are as follows:
• DF (Duplicates First). With the DF duplicates option, a record with a duplicate sort-key value is stored immediately before the existing duplicate record in the set. The first duplicate record encountered in the next direction is always
the most recently stored duplicate record.
After insertion. Patil(2) inserted.
• DL (Duplicates Last). With the DL duplicates option, a record with a duplicate sort-key value is stored immediately after the existing duplicate record in the set. The last duplicate record encountered in the next direction is always the
most recently stored duplicate record.
Ex.: After insertion. Patil(2) inserted.
• DN (Duplicates Not Allowed). With the DN duplicates option, a record with a duplicate sort-key value cannot be stored in the set. When a program attempts to store a record with a duplicate sort-key value, the DBMS returns an error
code.
Ex.: Try to insert Patil(2). It is rejected. IDMS/R returns an error code.
6.4. Bachman Diagram For Set
Please refer to Employee Database Bachman diagram in Appendix A. Please check up Dept-Employee set. All the set characteristics for Dept-Employee set are shown along side the arrow, which represents the set. The set characteristics
shown are as follows:
Dept-Employee – The set name.
NPO – The linkage options. The set has Next, Prior, and Owner pointers.
OA – Membership options.
ASC (Emp-Last-Name-0415 Emp-First-Name-0415): - The Order option for the set is ‘Sorted’ in ascending sequence. Sort-key is Emp-Last-Name-0415 Emp-First-Name-0415.
DL – The duplicates option of the sorted set.
7. Retrieval: Basic, By Sort-key, Indexed Set, Sweeping Areas
7.1. Basic Retrieval: CALC, Through Relationship
Here, we discuss how to code the specific DML statements that are used to retrieve information from an IDMS/R database. There are various ways to access the data. Two of those methods are given below.
• By performing a CALC retrieval. It is a random access.
• By walking sets i.e. access through set relationship.
The DML statement used for these retrievals is OBTAIN. The “OBTAIN” statement causes IDMS/R to locate the appropriate record occurrence in the database and moves data element values into application program’s variable storage i.e.
working-storage section. It makes the data available to the program.
7.2. CALC Retrieval: Random access
The syntax is as follows.
OBTAIN CALC .
Ex.: Retrieve a Department record occurrence, given Dept-Id (CALC-key).
MOVE 2000 TO DEPT-ID-0410.
OBTAIN CALC DEPARTMENT.
MOVE WS-DEPT-ID TO DEPT-ID-0410.
OBTAIN CALC DEPARTMENT.
In the above example, it retrieves a particular Department record occurrence.
Coding steps are as follows.
• Move / assign value to the CALC key-field
• Issue “OBTAIN” DML statement
To perform a CALC retrieval, the record type we are retrieving must have a CALC-key defined for it, and we must know the CALC-key value of the record occurrence we are retrieving. We cannot perform a CALC retrieval for EXPERTISE
records.
IDMS/R uses the CALC-key value we supply to locate the appropriate page in the database, retrieves the desired Department record occurrence and constructs a subschema record in the program’s variable storage i.e. working-storage
section.
7.3. Error Handling
The application program must check up status of any DML statement immediately after its execution. ERROR-STATUS field of IDMS Communication Block contains status information of the DML statement just executed. The ERROR-STATUS
field consists of 4 bytes. First two bytes (major code) identify the function performed. The last two bytes (minor code) describe the status of that function. A value of “0000” indicates that the DML statement was successful. Any non-zero
value indicates failure. There are some 88-level condition names associated with ERROR-STATUS field in IDMS Communication Block as given below.
ERROR-STATUS
Field Values Condition Name Explanation
“0000” DB-STATUS-OK Successful
“0307” DB-END-OF-SET End of set, area or index
“0326” DB-REC-NOT-FOUND No record found for given key
“0001” To “9999” ANY-ERROR-STATUS Any error, Any non-zero value
Example given above is reproduced below.
MOVE 2000 TO DEPT-ID-0410.
OBTAIN CALC DEPARTMENT.
If Department record occurrence with Dept-Id 2000 does not exist, it can be checked with following IF conditions.
IF ERROR-STATUS = ‘0326’
DISPLAY ……
03 – Major code – For “OBTAIN” DML function
26 – Minor code – Function status: - No record found
Or, we can use condition name as follows.
IF DB-REC-NOT-FOUND
DISPLAY ……..
Standard approach for error handling in the program:
Ex.: Coding for error handling.
MOVE 2000 TO DEPT-ID-0410.
OBTAIN CALC DEPARTMENT.
IF DB-STATUS-OK
DISPLAY DEPT-NAME-0410
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘GIVEN DEPT-ID NOT FOUND’
ELSE
PERFORM IDMS-STATUS.
7.4. Access By Walking Sets i.e. Access Through Set Relationship
There are two types of retrievals through set relationship.
• Retrieving members from owner
• Retrieving owner from members
Retrieving members from owner:
In many application situations, it is necessary to retrieve a particular owner record occurrence and then to retrieve one or more of that owner’s member record occurrences. We choose the set occurrence that we wish to access by
executing a retrieval statement (either an OBTAIN or a GET) for a particular occurrence of the set’s owner record type; a CALC-type retrieval is often useful for this purpose. Once we have established the set’s owner record occurrence as
current of its record type and also current of its set type, then to retrieve member record occurrences from the set occurrence, following syntax is used.
OBTAIN First within
Last
Next
Prior
Nth
Ex.: First
OBTAIN FIRST EMPLOYEE WITHIN DEPT-EMPLOYEE
IDMS/R retrieves the first Employee record in the Dept-Employee set, which then becomes current of the Dept-Employee set. The original Department record remains current of its record type.
Ex.: Last
OBTAIN LAST EMPLOYEE WITHIN DEPT-EMPLOYEE
If a set is defined with prior pointers, we can retrieve the last member record occurrence of a set as mentioned above.
Ex.: Next
OBTAIN NEXT EMPLOYEE WITHIN DEPT-EMPLOYEE
To retrieve each of an owner record’s members in sequence is very useful. This is called as walking the set or navigating the set. The retrieval statement, given above, can be repeatedly executed to retrieve all of an owner record’s
members until it reaches end-of-set.
Department D1
Employee E1 Employee E3
Employee E2
The particular record occurrence that this statement retrieves depends on which record occurrence in the set is established as current of the Dept-Employee set; it always retrieves the record that follows the record occurrence that is
current of the Dept-Employee set in the next direction.
IDMS/R sets an end-of-set condition code that the program must test to avoid walking the set a second time.
Example: Display all employees’ names for a given department.
MOVE ‘N’ TO WS-END-SET.
MOVE WS-DEPT-ID TO DEPT-ID-0410.
OBTAIN CALC DEPARTMENT.
IF DB-STATUS-OK
PERFORM RETRIEVE-REC UNTIL WS-END-SET = ‘Y’
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘GIVEN DEPT-ID NOT FOUND’
ELSE
PERFORM IDMS-STATUS.
………
………
RETRIEVE-REC.
OBTAIN NEXT EMPLOYEE WITHIN DEPT-EMPLOYEE.
IF DB-STATUS-OK
DISPLAY EMP-NAME-0415
ELSE
IF DB-END-OF-SET
MOVE ‘Y’ TO WS-END-SET
ELSE
PERFORM IDMS-STATUS.
Note: - If the 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.
Ex.: Prior
OBTAIN PRIOR EMPLOYEE WITHIN DEPT-EMPLOYEE
If a set has been defined as having PRIOR pointers, we can walk the set in the prior direction by repeatedly executing a statement of the above-mentioned type.
OBTAIN PRIOR works in the same manner as OBTAIN NEXT, except in the reverse direction. OBTAIN PRIOR statements cannot be issued for a member record type if the member’s set does not include PRIOR pointers.
Ex.: Nth
We can retrieve a particular member of a set by a number that specifies the relative sequence in the set of the desired member.
OBTAIN 3 EMPLOYEE WITHIN DEPT-EMPLOYEE
Or, we can use a variable (of PIC S9(5) COMP) in place of sequence number.
01 SEQ-FIELD PIC S9(5) COMP.
MOVE SEQUENCE-NUMBER TO SEQ-FIELD.
OBTAIN SEQ-FIELD EMPLOYEE WITHIN DEPT-EMPLOYEE
Retrieving owner from members:
We can use the following DML statement to retrieve the owner of a set occurrence:
OBTAIN OWNER WITHIN
OBTAIN OWNER WITHIN DEPT-EMPLOYEE
If currency is established anywhere in the set occurrence (as shown in above bubble diagram), OBTAIN OWNER will cause IDMS/R to retrieve the Department record occurrence for D1.
An OBTAIN OWNER retrieval can be issued whether or not the set is defined as having OWNER pointers. If owner pointers do not exist, IDMS/R walks the set, if necessary, to locate the owner record. If the set is defined as having OWNER
pointers, IDMS/R can get directly to the owner from any member in the set occurrence.
Example: Display department name for a given employee-id.
MOVE WS-EMP-ID TO EMP-ID-0415.
OBTAIN CALC EMPLOYEE.
IF DB-STATUS-OK
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.
Assignment 1: - Refer to Lab Book. Source code given.
Assignment 2: - Refer to Lab Book. Similar to 1.
Those participants, who finished these assignments, can continue to Assignment 3. The logic and programming would be on similar lines.
7.5. Retrieval By Sort-Key Value
If we are retrieving member records and the set type is with order option of SORTED, we can base retrievals on sort-key values.
E.g. Dept-Employee set is with order option of SORTED in ascending sequence and the sort-key is EMP-LAST-NAME-0415. Please check up above diagram of the set occurrence for Department record occurrence D1. We want to access
Employee record occurrence “Patil” in the set occurrence of D1. With this sorted set, we can retrieve a particular member of a set occurrence based on a sort-key value, as in the example give below.
MOVE ‘PATIL’ TO EMP-LAST-NAME-0415.
OBTAIN EMPLOYEE WITHIN DEPT-EMPLOYEE USING
EMP-LAST-NAME-0415.
In this example, we move a last name value to the data element in the Employee record description that defines the sort key and issues an OBTAIN statement that references the sort-key data element. Note that although the retrieval
appears similar to a CALC retrieval, the search for a record is limited to the current set occurrence. IDMS/R does not search other set occurrences for a member having the specified sort-key value.
In the previous example, IDMS/R begins searching member records from the first member record occurrence in the set occurrence, regardless of which record occurrence is current of set type.
The general syntax is as follows:
OBTAIN WITHIN USING .
The expected outcomes / return-codes are DB-STATUS-OK,
DB-REC-NOT-FOUND.
Ex.:
MOVE ‘PATIL’ TO EMP-LAST-NAME-0415.
OBTAIN EMPLOYEE WITHIN DEPT-EMPLOYEE USING
EMP-LAST-NAME-0415.
IF DB-STATUS-OK
DISPLAY EMP-ID-0415 EMP-NAME-0415 EMP-ADDRESS-0415
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘GIVEN EMPLOYEE NOT FOUND’
ELSE
PERFORM IDMS-STATUS.
7.6. Generic Key Retrieval
To perform a generic-key retrieval in a sorted set, we supply IDMS/R with a partial key value. E.g. in Dept-Employee sorted set as mentioned above, we want to retrieve all the Employee record occurrences whose last name value begin
with the letter ‘S’. Following is the partial code for this type of retrieval.
01 WS-LAST-NAME.
05 WS-FIRST-CHAR PIC X.
05 FILLER PIC X(14).
……..
……..
MOVE LOW-VALUES TO WS-LAST-NAME.
MOVE WS-INPUT-CHAR TO WS-FIRST-CHAR.
MOVE WS-LAST-NAME TO EMP-LAST-NAME-0415.
OBTAIN EMPLOYEE WITHIN DEPT-EMPLOYEE
USING EMP-LAST-NAME-0415.
IF DB-STATUS-OK
DISPLAY EMP-ID-0415 EMP-NAME-0415
Process all remaining Employee occurrences for which
last name starts with ‘S’
ELSE
IF DB-REC-NOT-FOUND
Obtain next employee occurrence within the set
If db-status-ok
If last-name starts with ‘S”
Display emp-id, emp-name
Process all remaining Employee occurrences
for which last name starts with ‘S’
else
display message ‘Not found’
else
display message ‘Not found’
ELSE
PERFORM IDMS-STATUS.
Please notice that the data element in which we store the generic key must be padded to the right with low values.
7.7. Indexed Set
A special type of set is provided by IDMS/R that allows retrieval of records using an index. In a conventional set, member records are chained together by pointers. In an index set, database key values are stored in a specified order in one
or more index records. E.g. Employee record has an index built on last-name and first-name fields, apart from CALC key. Skill record has an index built on skill-name apart from CALC key. We can have more than one indexes built on
different fields, so that we can retrieve record occurrences based on any index that we need.
With an index, retrieval of members can sometimes be more efficient because the index can be traversed more quickly than the set of chained member records. Indexed sets are used mainly to add flexibility to data retrieval.
To implement an index, IDMS/R builds an index file that contains the database key values of member record occurrences. These db-key values are maintained in the sequence specified for the index. i.e. IDMS/R uses an array of database
pointers to quickly access member records. DBMS locates the data by searching the index rather than the actual member record.
The use of indexes can simplify processing in the following situations:
• Random retrieval by key value. Also a partial or generic key value can be used.
• Sorted retrieval by key value.
• Multiple-key access. Sometimes we need to access records based on more than one key.
7.8. Retrieval Using Indexed Set
By using index sets, we can perform three types of retrieval that are difficult or impossible without the use of an index:
• Sequential retrieval in symbolic-key sequence
• Generic-key retrieval
• Random retrieval based on the value of a symbolic key other than a CALC-key.
Each entry in the index contains a symbolic-key (or index-key) data element value and the db-key value of its corresponding record occurrence.
Random Retrieval
To use the index to find the first record having a particular index-key (a field on which the index is built) value, we can do a random retrieval in a similar manner to the method we used for retrieving a member record having a particular
sort-key value.
The syntax and the logic are similar to the sorted set. Please refer to Sec. 8.1.
We name the desired record type, specify the name of the index set and supply a data element value for the indexed data element:
OBTAIN SKILL WITHIN SKILL-NAME-NDX
USING SKILL-NAME-0455.
Expected return-codes are DB-STATUS-OK, DB-REC-NOT-FOUND.
Sequential Retrieval
Consider the index set EMP-NAME-NDX built on last-name field of Employee record. There may be many Employee records all having the same last-name value. Once the program locates the first one through random retrieval, it could
issue a series of sequential retrievals to locate additional records having that same name:
OBTAIN NEXT EMPLOYEE WITHIN EMP-NAME-NDX.
Expected return codes are DB-STATUS-OK, DB-END-OF-SET.
The program has to test the last-name field after each sequential retrieval to determine when it has reached the last record with the specified last-name data element value.
Generic-Key Retrieval
The syntax and logic is exactly similar to Sorted set. Please refer to Sec. 8.2.
7.9. Bachman Diagram: Indexed Set
The set characteristics of an Indexed set are similar to the set with order option as Sorted. The index set characteristics are shown along side the arrow representing the indexed set in the Bachman diagram.
Please refer to Employee database in Appendix A. There are indexes built on Skill record, Employee record and Job record.
Assignment 3: - Refer to Lab Book.
Assignment 4: - Refer to Lab Book.
7.10. Retrieval By Sweeping Areas
In performing an area sweep, IDMS/R scans through all the records in an area in physical sequence. The order in which records are retrieved will generally have little relationship to the logical sequence of records. Area sweeps are useful
when we want to retrieve all the records in an area without regard to the order in which we get them. E.g. when we are simply gathering statistics about the database.
Performing an area sweep in the forward direction:
OBTAIN FIRST WITHIN .
IDMS/R will simply retrieve the record occurrence of the given record-type having the lowest database-key value in the area. In the following statement, IDMS/R uses currency within the area to determine which record occurrence of the
given record-type to retrieve. It uses area currency to retrieve the record occurrence having the next highest database-key value.
OBTAIN NEXT WITHIN .
Performing an area sweep in the reverse direction:
OBTAIN LAST WITHIN .
….
….
OBTAIN PRIOR WITHIN .
Pointers are not used in performing an area sweep, so prior pointers are not necessary for executing OBTAIN PRIOR WITHIN AREA statements.
In the above mentioned OBTAIN syntax, record-name can be omitted.
We can also used the following syntax:
OBTAIN Nth WITHIN .
We can use a sequence number or a variable (of PIC S9(5) COMP) in place of a sequence number as given below.
01 SEQ-FIELD PIC S9(5) COMP.
MOVE SEQUENCE-NUMBER TO SEQ-FIELD.
OBTAIN SEQ-FIELD EMPLOYEE WITHIN EMP-DEMO-REGION.
Expected return-codes are DB-STATUS-OK, DB-END-OF-SET.
Example: Retrieve all Course record occurrences.
OBTAIN FIRST COURSE WITHIN COURSE-AREA.
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.
8. Currency
To help keep track of where we are in the database, IDMS/R maintains pointers to a number of different record occurrences as each run unit executes. We use the term currency to refer to these pointers.
To enable a program to position itself and move about in the database, IDMS/R maintains a Currency Table for each run unit.
The currency is the db-key of the most recently accessed record occurrence.
IDMS/R maintains four types of currency (Currency Table) for each run unit:
• Record Currency (Current of record type). The db-key of the most recent record occurrence of each record type accessed by the program. IDMS/R maintains a separate currency for each record type defined in the subschema.
• Set Currency (Current of set type). The db-key of the most recent record occurrence of each set type accessed by the program. IDMS/R maintains a separate currency for each set type defined in the subschema.
• Area Currency (Current of area). The db-key of the most recent record occurrence of each area accessed by the program. IDMS/R maintains a separate currency for each area to which the program has access.
• Run Unit Currency (Current of run unit). The db-key of the most recent record occurrence accessed by the program.
8.1. Currency Table
Currency table is the table of four different types of currencies as explained above. IDMS/R maintains a currency table for each run unit.
Record Currencies Set Currencies Area Currencies Run Unit Currency
• BIND RUN-UNIT statement sets all the currencies to NULL.
• Successful DML statement changes the currencies involved. The other currencies remain null until some future database access sets them.
• Using the currencies and the NPO pointers stored in record occurrences, IDMS/R DBMS accesses records in the database.
• FINISH statement nullifies all the currencies.
Subject in Trg-Area
Sub-Course
Course in Course-Area
CURRENCIES
Subject Course Sub-Course Set Trg-Area Course-Area Run-Unit
Bind Run-unit - - - - - Move ‘MVS’ To Sub-Id
OBTAIN CALC SUBJECT MVS - MVS MVS - MVS
CURRENCIES
Subject Course Sub-Course Set Trg-Area Course-Area Run-Unit
Bind Run-unit - - - - - Move ‘MVS’ To Sub-Id
OBTAIN CALC SUBJECT MVS - MVS MVS - MVS
Obtain next course within
Sub-course MVS C07 C07 MVS C07 C07
Obtain last course within
Sub-course MVS C10 C10 MVS
C10 C10
Obtain next course within
Sub-course MVS C10 MVS MVS C10 MVS
Obtain course within sub-course using ‘C08’ MVS C10 MVS
(NPO) MVS C10 MVS
8.2. Currency loss
Following example uses retrieval by area sweeping.
Example: Display last Course of all Subjects.
….
….
Obtain first subject within course-area.
Perform next-subject-para until ws-course-area-end = ‘y’.
….
…..
Next-subject-para.
If db-status-ok
Perform disp-course-para
Obtain next subject within course-area
Else
If db-end-of-set
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.
COURSE-AREA: Record occurrences are as follows.
Page-1 Page-2 Page-3 Page-4
S1 C21 C31 C32
C11 C13 S4 C42
S2 C14 C22 S5
C12 S3 C41 C43
(Draw sub-course. Same area assumption. Bubble diagram).
The program displays courses C14 and C32. But it did not display courses C22 and C43, which it was supposed to do.
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.
Course-Area Currency:
S1
C14
S3
C32
S5
The DML ‘Obtain first subject within course-area’ retrieves S1. Area currency is S1. Then the DML ‘Obtain last course within sub-course’ is executed and it retrieves C14. Now, area currency changes to C14. Then DML ‘Obtain next subject
within course-area’ is executed and it retrieves S3. Area currency becomes S3. We miss S2 here. Scan for next subject should have started from S1 onwards, but it started from C14 onwards. This is currency loss. Same thing happened with
S4 also.
Solution:
The record occurrences of both records, Subject and Course, are in the same area Course-Area. So, any retrieval of Subject or Course record occurrence changes the area Course-Area currency.
In the above program, we need to store / maintain the area currency. Find out the part of code where currency loss takes place. The paragraph ‘Disp-course-para’ is the place where currency loss happens. So before the execution of the
statement ‘Perform disp-course-para’, we need to store the area currency. After the execution of the statement ‘Perform disp-course-para’, we need to reestablish the area currency from the stored value.
8.3. Storing and Retrieval By DB-Key Value
We can save the db-key / currency value in a working-storage field for later use. The syntax is as follows.
ACCEPT FROM CURRENCY
Or
MOVE DBKEY TO ws-db-key-v.
The field ws-db-key-v should be defined in working-storage as follows.
01 ws-db-key-v PIC S9(8) COMP SYNC.
To reestablish the currency to stored value, use following statement.
FIND / OBTAIN DB-KEY IS ws-db-key-v.
The record-name is optional.
Ex.: The above-mentioned program is modified to take care of area currency loss. Only affected code is given below.
Next-subject-para.
If db-status-ok
Accept ws-db-key-v from course-area currency
Perform disp-course-para
Obtain subject db-key is ws-db-key-v
Perform idms-status
Obtain next subject within course-area
Else
…..
Reestablishing Run-Unit Currency:
To reestablish the current record occurrence of record type, set type, or area as the current record occurrence of run unit, use the following statement:
FIND / OBTAIN CURRENT WITHIN
WITHIN
After this statement, issue PERFORM IDMS-STATUS.
8.4. Obtain Vs. Find and Get
An OBTAIN statement performs the same function as a FIND followed by a GET. The find function causes IDMS/R to locate the appropriate record in the database and place it in the system buffers. We can latter follow a successful FIND
with a GET. GET causes IDMS/R to move the appropriate data element values from the system buffers into our program’s variable storage – working-storage section.
We may not follow a FIND with a GET. In some cases, we only wish to locate a record, but do not need actually to retrieve it. E.g. we may need only to verify that a particular record occurrence exists, or we may need to establish a
starting point for some subsequent retrieval sequence.
The syntax of FIND is similar to OBTAIN.
MOVE 2000 TO DEPT-ID-0410.
FIND CALC DEPARTMENT.
GET DEPARTMENT.
MOVE ‘SUDHIR’ TO FACULTY-ID.
FIND CALC FACULTY.
GET FACULTY.
8.5. IF EMPTY / MEMBER:
By using IF statement, you can determine
• If the set is empty
• If the record occurrence is member of the specified set occurrence.
Using the IF EMPTY statement:
IF IS [NOT] EMPTY
Imperative statement
After you have retrieved a owner record occurrence in a set, you can issue the IF EMPTY statement to determine if the set has any member record occurrences. This allows you to control processing based on whether the set is empty.
IF DEPT-EMPLOYEE IS EMPTY
MOVE NO-EMP-MSG TO WS-MSG
ELSE
PERFORM 1000-DEPT-EMP THRU 1000-EXIT
UNTIL DB-END-OF-SET.
………
………
1000-DEPT-EMP.
OBTAIN NEXT EMPLOYEE WITHIN DEPT-EMPLOYEE.
…….
To determine if a set is empty, perform the following steps:
i. Establish currency for the set.
ii. Issue the IF EMPTY statement.
iii. Perform further processing as specified.
Using the IF MEMBER statement:
IF [NOT] MEMBER
Imperative statement
You can issue the IF member statement to ensure that a record occurrence currently participates as a member of a specified set occurrence.
To determine if a record participates as a member in a set, perform the following steps:
i. Establish run unit currency for the specified member record.
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.
Please consider the following data.
Employees E1 and E2 are attached to Dept D1. Employee E5 is not attached to any Department.
If we do not use IF MEMBER:
CURRENCIES
Department Employee Dept-Employee Set Run-Unit
Bind Run-unit - - - Move E1 To Emp-Id-0415
Obtain calc Employee - E1 E1 E1
Obtain owner within Dept-Employee D1 E1 D1 D1
Move E2 To Emp-Id-0415
Obtain calc Employee D1 E2 E2 E2
Move E5 To Emp-Id-0415
Obtain calc Employee D1 E5 E2 E5
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.
This is solved by using IF MEMBER statement as follows.
CURRENCIES
Department Employee Dept-Employee Set Run-Unit
Bind Run-unit - - - Move E1 To Emp-Id-0415
Obtain calc Employee - E1 E1 E1
Obtain owner within Dept-Employee D1 E1 D1 D1
Move E2 To Emp-Id-0415
Obtain calc Employee D1 E2 E2 E2
Move E5 To Emp-Id-0415
Obtain calc Employee D1 E5 E2 E5
IF Dept-Employee MEMBER
Obtain owner within Dept- Employee
Else
Display ‘No Owner’ D1 E5 E2 E5
The program will display error message ‘No Owner’.
9. Types of Set Relationships
9.1. Hierarchies
Two-Level Hierarchies:
A single set implements a two-level hierarchy. The owner record type is on the first level, and member record types are on the second level. A one-to-many relationship exists between the owner record type and its member record types.
Dept-Employee
Multilevel Hierarchies:
A member record of one set can also be the owner of another set. This results in a multilevel hierarchy.
Dept-Employee
Emp-Expertise
Multiple Member Sets:
There are more than one member record types in a set type. While walking a set, we can access all member record types.
Coverage-Claims
Note: - If the clause is omitted from the OBTAIN syntax, then in case of a multimember set, member record occurrences of any record type will be retrieved.
Multiple Set Ownership:
This form of hierarchy uses one record type as the owner record in more than one set. The common owner record provides the means of movement between the two different member record types in different sets.
Emp-Emposition Emp-Expertise
Multiple Sets:
It is quite possible for two record types to participate in multiple one-to-many relationships with one another.
For example, in the diagram below about Customer and Invoice record types, it is useful to separate overdue invoices from other invoices. This is implemented by defining two different one-to-many relationships between the Customer
record type and the Invoice record type, with each being implemented by a different set type.
Cust-Invice Cust-Overdue-Invoice
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
9.2. Junction Record: Multiple Set Membership
IDMS/R does not support many-to-many relationship directly. For each many-to-many relationship that we identify among a set of entities in real world applications, we will almost always identify additional attributes that are not
associated with either of the two entities alone, but are associated with the intersection between the two entity types.
E.g. there is a many-to-many relationship between Supplier and Parts record types. A supplier supplies many parts and a part is supplied by many suppliers. An additional record type Quantity is provided, in which information about
quantity supplied can be stored. Supplier and Parts have a one-to-many relationship with Quantity. The record type Quantity is called the junction record, because it represents a junction or intersection between the Supplier and the
Parts record types. The junction record Quantity is the member record in the multiple sets Supplier-Qty and Parts-Qty. The junction record resolves the many-to-many relationship and implements it indirectly.
Supplier-Qty Parts-Qty
S1 P1
S2 P2
Q: S1P1 P3
Q: S1P2
Q: S1P3
Q: S2P1
Q: S2P2
Q: S2P3
Supplier-Qty Parts-Qty
9.3. Nested Structure – Bill Of Material
Nested structures arise when modeling bill-of-materials structures in the manufacturing environment. In some applications, there exists a many-to-many relationship among different occurrences of the same record type. Occurrences of a
record type are related to other occurrences of the same record type.
For example, consider a typical bill-of-material case of main-parts and sub-parts. A main-part consists of many sub-parts and a sub-part belongs to (or takes part in construction of) many main-parts. But, a main-part and a sub-part are
basically Parts. So, there exists a many-to-many relationship among Parts record occurrences. The owner record and the member record both are the same record type. It can be shown as follows.
Parts-Are
Parts-For
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-Are Parts-For
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
Consider another example of bill-of-materials structure.
To learn a particular subject, the knowledge of some other subjects is a pre-requisite. E.g. to learn IDMS, knowledge of Cobol, JCL, MVS is a pre-requisite. To learn DB2, knowledge of Cobol, DBMS, JCL, MVS is pre-requisite. Given a
particular subject, say Cobol, it is a pre-requisite for IDMS, DB2, JCL. So, there exists a many-to-many relationship among Subject record occurrences. The owner record and the member record both are the same record type. It can be
shown as follows.
Prereq-Are
Prereq-For
We resolve this by creating a junction record Skill-Level. To learn IDMS, prerequisite are knowledge of Cobol with skill-level of 3, JCL with skill-level of 2, MVS with skill-level of 1. To learn DB2, prerequisite are knowledge of Cobol with
skill-level of 2, JCL with skill-level of 2, MVS with skill-level of 1, DBMS with skill-level of 3. Cobol is a pre-requisite for IDMS (Cobol level 3), DB2 (Cobol level 2), JCL (Cobol level 1).
Prereq-Are Prereq-For
The Skill-Level junction record is related to the Subject record using two sets. The set Prereq-Are allows us to find out the subjects that are prerequisites of a given subject, and the set Prereq-For helps to find the subjects for which the
given subject is a prerequisite.
Exercise: - Draw the diagram of Subject, Skill-Level record occurrences with Prereq-Are and Prereq-For set occurrences (similar to Parts, Quantity shown above).
Coding for retrieval logic:
Please consider record types Parts and Quantity with two sets Parts-Are and Part-For as explained above.
The owner record type is same for both the sets. The member record type is also the same for both the sets. So, retrieval of any of the two record types, Parts or Quantity, changes the set currencies of both the sets. If we want to walk
along (navigate) a particular set occurrence sequentially, then any retrieval through another set during the processing will change the set currency of the set occurrence we are walking along. This is a problem of set currency loss. So, we
need to store the set currency for the set occurrence we want to walk along and reestablish it later.
Ex.: List out all sub-parts of part-number P1.
MOVE P1 TO PART-NUMBER.
OBTAIN CALC PARTS.
IF DB-STATUS-OK
PERFORM 1000-WALK THRU 1000-EXIT
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.
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
Parts Quantity Parts-Are Set Parts-For Set ….-Area Run-Unit
Bind Run-unit - - - - - Move P1 To Part-number
Obtain calc Parts P1 - P1 P1 P1 P1
Obtain next Quantity within Parts-Are P1 Q11 Q11 Q11 Q11 Q11
Obtain owner within Part-For P11 Q11 P11 P11 P11 P11
Obtain next Quantity within Parts-Are P11 Q11 P11 P11 P11 P11
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 PARTSFOR’ 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.
CURRENCIES
Parts Quantity Parts-Are Set Parts-For Set ….-Area Run-Unit
Bind Run-unit - - - - - Move P1 To Part-number
Obtain calc Parts P1 - P1 P1 P1 P1
Obtain next Quantity within Parts-Are P1 Q11 Q11 Q11 Q11 Q11
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-Are P11 Q12 Q12 Q12 Q12 Q12
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-Are P12 Q13 Q13 Q13 Q13 Q13
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-Are P1 Q13 P1 P1 P1 P1
Exercise:
Write DML statement: • List all sub-parts for P8
• List all parts which consists of P5
• List all sub-parts and main parts for P2, P11
• List all parts that are not main parts
• List all parts that are only main parts
• List all parts that are main part as well as sub-part
Assignment 5: - Please refer to Lab Book.
10. Set Membership Options
The membership option indicates the way a member record occurrence is connected to and disconnected from a set occurrence is connected to and disconnected from a set occurrence. It is defined in two parts. The first part is a
disconnect option, which indicates the way a record is disconnected from a set. The second part is a connect option, which indicates the way a record is connected to a set.
10.1. Disconnect option
The disconnect option specifies whether a member record can later be disconnected from a set once its membership has been established. Codes used to represent the disconnect options are as follows:
• M (mandatory). With this option, the membership of a record occurrence in a set is permanent once it is established. A record occurrence cannot be disconnected from a set unless that record is erased from the database, as shown in
figure below.
Please check up the set Emp-Emposition with this option in Appendix A.
To disconnect Empo3 from the Emp-Emposition set, we must erase the Empo3 record from the database. Erasing Empo3 record also causes the record to be disconnected from the set.
Erase Empo3:
• O (optional). 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 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.
Disconnect E3:
With the optional disconnect option, a record occurrence can be disconnected from a set without erasing it. It can then be later connected to some other set.
10.2. Connect option
The second part of the membership option indicates the type of connect option defined for this set. A connect option specifies whether or not a member record is automatically connected to a set occurrence when it is added to the
database. Codes used to represent the connect options are as follows:
• A (automatic). With this option, a new member record is automatically connected to a set occurrence when it is added to the database. With the automatic connect option, the program needs to indicate in which set the new member is
to belong at the time that it adds a new record occurrence.
• M (manual). With this option, a new member record is not automatically connected to a set occurrence when it is added to the database. The application program must execute an explicit connect function after it adds a new record
occurrence to connect the member record to a set occurrence.
10.3. Bachman Diagram and Examples
Please refer to Bachman diagram of Employee database in Appendix A. The set membership options are mentioned along with all the other set characteristics. The set characteristics are shown by the side of the arrow representing the
set.
E.g. the set Dept-Employee set has membership options as ‘OA’. The set Emp-Expertise has membership options as ‘MA’. The first character represents the disconnect option and the second character represents the connect option.
Examples:
MA: Mandatory / Automatic
Cust-Inv
Mandatory: - Invoice occurrence cannot exist without Customer occurrence.
Automatic: - Customer must be known when invoice is created.
MM: Mandatory / Manual
Cust-Late-Paid
Mandatory: - Once the invoice is late-paid, it must remain late-paid.
Manual: - Invoice when created may not be late-paid.
OA: Optional / Automatic
Cust-Unpaid-Inv
Optional: - Once the invoice is paid, it does participate in this set occurrence.
Automatic: - All invoices are unpaid when created.
OM: Optional / Manual
Cust-Unpaid-And-Overdue-Inv
Optional: - Once the invoice is paid, it is not unpaid.
Manual: - Invoice is not overdue when it is created.
Events Set Relation
Today’s date: 05-April-2002
Invoice created Does not participate in the set occurrence
Due date: 15-April-2002
On 16-April-2002
Not paid Now participating in the set occurrence
On 18-April-2002
Paid Now does not participate in the set
Occurrence
11. DML Data Update Functions
11.1. Ready
The Ready statement performs an equivalent function as an OPEN statement for a conventional file. It makes the required area of the database available to the program. The syntax is as follows:
SHARED
READY USAGE-MODE IS PROTECTED RETRIEVAL
ALL EXCLUSIVE UPDATE
This statement begins a run-unit.
The ‘Usage-Mode Is Retrieval’ clause indicates that the program will retrieve data only and will not be allowed to execute any database modification DML statement for the specified area.
The ‘Usage-Mode Is Update’ clause informs IDMS/R that the program intends to update records from the specified area.
A READY statement for update can also specify additional usage mode options that control the way in which database areas can be concurrently ac¬cessed by two or more run units. Usage mode options for updating are dis¬cussed in the
Section 13.2 on ‘Area Usage Modes’.
11.2. Store
The STORE statement is used to add a new record occurrence to the database. Adding a new record to the database is a simple three step process:
1. Construct the new record occurrence in the record's area in working-storage section.
2. Establish currency within appropriate occurrences of the set types in which the new record participates as an automatic member. We can use FIND for this purpose, since we do not need the records to be moved to the program’s
working-storage section.
3. Execute the store function, specifying the name of the record type we are adding.
The syntax for the store function is simple; the only required parameter is
the name of the record type. The following STORE statement adds a new occur¬rence of the Employee record type:
STORE EMPLOYEE.
The syntax is as follows: STORE
However, IDM S/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 writ¬ten.
• Whether the new record should be made a member of any sets and, if so, to which set occurrences it should be connected.
• Where in the set occurrences the new record should be inserted.
IDMS/R uses record currencies and the attributes assigned to records and sets to obtain this information.
Determining Where to Write the New Record:
IDMS/R finds an appropriate location for a new record by examining the loca¬tion 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 da¬tabase key value in the IDMS Communications Block. IDMS/R uses this value in finding a place for the record.
Connecting the Record to Sets
IDM S/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 cur¬rency 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.
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 SkillLevel-0425.
To summarize, the STORE statement performs the following functions:
• Acquires space and a database key for a new record occurrence.
• Transfers data element values from working-storage to the database.
• Connects the new record occurrence to all sets in which it participates as an automatic member.
Example:
Add a new occurrence in Expertise record.
Expertise record is an automatic member in Emp-Expertise and a manual member in Skill-Expertise.
…..
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.
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
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 stor¬age.
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 state¬ment:
1. We must execute a READY statement with one of the UPDATE usage mode options for the area that contains the record we are modifying.
2. We must issue an OBTAIN for the record we are updating before we execute the MODIFY statement.
The syntax is as follows: MODIFY
Example:
Modify address and phone-number for a given employee.
MOVE WS-EMP-ID TO EMP-ID-0415.
OBTAIN CALC EMPLOYEE.
IF DB-STATUS-OK
MOVE WS-ADDRESS TO EMP-ADDRESS-0415
MOVE WS-PHONE TO EMP-PHONE-0415
MODIFY EMPLOYEE
PERFORM IDMS-STATUS
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘EMPLOYEE NOT FOUND’
ELSE
PERFORM IDMS-STATUS.
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, how¬ever, the ERASE often affects not only the record that is the object of the ERASE
statement but also, in some cases, members of sets owned by that record.
The options with Erase statement are as follows:
PERMANENT
ERASE SELECTIVE MEMBERS
ALL
The ERASE statement with no member option is straightforward. We be¬gin by retrieving the record we want to erase, making it current of run unit. We then issue an ERASE, naming the record type. IDMS/R first disconnects the record
from any sets in which it participates as a member, then removes the record occurrence from the database. If the record we are erasing is he owner of any sets, the record will be erased only if those sets are empty. If we try to erase an
owner record of a nonempty set, IDMS/R returns an error status code value.
Example:
Delete Employee record occurrence for a given employee-id.
MOVE WS-EMP-ID TO EMP-ID-0415.
OBTAIN CALC EMPLOYEE.
IF DB-STATUS-OK
ERASE EMPLOYEE
PERFORM IDMS-STATUS
ELSE
IF DB-REC-NOT-FOUND
DISPLAY ‘EMPLOYEE NOT FOUND’
ELSE
PERFORM IDMS-STATUS.
Notice that, in this case, we did not specify a member option in the ERASE. This means that the Employee record occurrence will only be erased if it is the owner of an empty set occurrence. We must use one of the other three ERASE
options if we want to erase an owner of one or more nonempty sets.
The ERASE ALL Option
Using ERASE ALL first causes the object record to be removed from the data¬base. Then all its members, both mandatory and optional, will be removed, whether or not they are members in other set occurrences. If we execute an ERASE
ALL for an Employee record, IDMS/R also removes all its member records, along with all their members.
The ERASE PERMANENT Option
With the other two ERASE options, the members that are automatically erased depend on whether the members participate in other sets and what the set dis¬connect options are.
When we use ERASE PERMANENT, IDMS/R erases the record that is the object of the ERASE. It also erases all mandatory members all sets owned by the object record. It does not erase optional members; it disconnects them instead. If an
erased member is the owner of any sets, it is treated as if an ERASE PERMANENT were issued for it. Its mandatory members will be erased, and its optional members disconnected. This process continues until all members have been
processed.
The ERASE SELECTIVE Option
An ERASE SELECTIVE always erases the record that is the object of the ERASE, and it always erases mandatory members in all sets owned by the object record. It also erases optional members if they do not participate in any other sets. If
the erased member is the owner of any sets, it is treated as if an ERASE SELECTIVE were issued for it. Its mandatory members will be erased, and its optional members will be erased if they do not participate in any other sets.
Remark: - Run unit and area currencies remain unchanged. It nullifies current pointers for:
- All record types involved in Erase
- All sets in which the erased record participates
11.5. Connect
It is used to establish a record occurrence as a member in a set occurrence.
CONNECT TO .
The CONNECT function can be used in conjunction with STORE for records that must be manually connected to sets. CONNECT connects the record that is current of run unit to the named set.
The CONNECT statement names both a record type and a set type. The CONNECT function causes the record that is current of the named record type to be connected to the set occurrence that is current of the named set type.
Membership option must not be MA (mandatory automatic). All areas affected must be readied in UPDATE usage mode.
Example:
Assumption: The Coverage record is a manual member of the Emp-Coverage set.
…..
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.
Remark: - On successful Connect, the set currency will become current of record occurrence just connected.
11.6. Disconnect
It is used to disconnect a record occurrence from a set occurrence of which it is a member.
DISCONNECT FROM .
The DISCONNECT statement removes the record occurrence that is current of run unit from the named set.
The DISCONNECT statement cancels the membership of a record occurrence in a set occurrence in which it currently participates as a member. The record that is the object of a DISCONNECT function must be defined as an optional
member of that set. Otherwise, IDMS/R returns an error status code. All areas affected must be readied in UPDATE usage mode.
The DISCONNECT and CONNECT functions are also often used together to move a record occurrence from one set occurrence to another.
Example:
Transfer a given employee to another given department.
…..
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.
DML Statement Execution Steps:
Please refer to Section 3.7 for the steps that are involved in the execution of a DML statement.
Assignment 6: - Please refer to Lab Book.
Assignment 7: - Please refer to Lab Book.
Assignment 8: - Please refer to Lab Book.
12. Recovery and Restart
IDMS/R provides the facilities for recovering from problem situations and for restarting after failures occur. These facilities include procedures that IDMS/R automatically invokes when certain types of failures occur and also services that
application programs use to handle restart and recovery.
12.1. IDMS/R Operating Environments
It is possible to run an IDMS/R application program in two operating environments: local mode or central version. All online applications that use IDMS/DC or some other telecommunications monitor to control access to remote terminals
must run under central version. An application program that operates in batch mode can be run either under the control of central version or in local mode. The mode in which a particular application program is run is generally chosen by
the DBA group and is not of concern to the application developer. However, the mode in which the applica¬tion executes determines the restart and recovery facilities that are available to it.
Central Version
In most situations, the preferred method of running an IDMS/R application is under the control of IDMS/R central version. With central version, a single copy of the IDMS/R DBMS controls the operation of a particular set of IDMS/R
application program run units. With central version, a single DMCL module (which maps logical database areas into physical files in DASD) de¬fines all database areas that will be accessed by all the run units that will execute under a
particular IDMS/R central version. Multiple copies of IDMS/R central version can execute in the same computing system with each copy normally ac¬cessing a different set of database areas; no two central versions are allowed to update
the same database area. All the run units that will execute under the con¬trol of a particular central version are chosen so that they all access the same group of database areas. Central version implements facilities for recovering from
system failures and for automatically restarting aborted run units.
Local Mode
A batch program that operates in local mode has its own copy of the IDMS/R DBMS loaded into its address space. A local mode run unit operates independently of any other IDMS/R run units that may be operating in the system at the same
time. In general, an application runs faster when run in local mode, but IDMS/R provides no automatic restart and recovery facilities for local mode applications. Batch retrieval programs are good candidates for running in local mode,
since they do not ordinarily require automatic restart and recovery facilities.
12.2. Journal Files, Checkpoints
IDMS/R maintains a set of journal files that can be used to recover from failures and to restart aborted run units. An IDMS/R application can choose to write the journal files to direct access data sets, to tape tiles, or to ignore completely
the journaling facility. IDMS/R provides automatic restart and recovery facilities only for run units that operate under the control of central version, and then only when the run unit writes the journal files to direct access data sets.
Applications, either central ver¬sion or local mode, that write tape journal files can use the journal files to restart manually an aborted run unit. Applications that bypass the journaling facilities are responsible for their own restart
processing.
When a run unit begins by issuing the BIND RUN UNIT statement, IDMS/R writes a begin checkpoint record on a journal file. A checkpoint record contains information about the current status of the run unit. As a run unit exe¬cutes, it may
update records in the database. As IDMS/R processes each update request, it writes to the journal tile 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 im¬ages of all updated records, and an end checkpoint.
Journal File
Begin Checkpoint
Start of run unit Before image After image … … End Checkpoint
(FINISH)
of updated record ………
12.3. Recovery / Restart
There are many types of situations that may require recovery and restart processing. A program may cause an error that causes the run unit to be abnormally terminated. IDMS/R may also encounter situations that require it to terminate
abnormally one or more run units. For example, IDMS/R may terminate a run unit after a wait time limit has been exceeded to prevent deadlocks from occurring. If a run unit is abnormally terminated after it has updated one or more
database records, IDMS/R works backward in the journal file until it reaches the begin checkpoint record and uses the information in the before record images to reverse the effect of the database updates already made by aborted run
unit. The run unit can then be restarted from the beginning.
Journal File
Begin Checkpoint:
Start of RU Before image
15 After image
17 Checkpoint:
Abnormal termination
Journal File
Begin Checkpoint:
Start of RU Before image
15 After image
17 Checkpoint:
Abnormal termination
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 oper¬ate 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 re¬covery 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 cre¬ate intermediate checkpoints, the run unit periodically issues a COMMIT
state¬ment to make permanent all database updates that the run unit has already made: COMMIT.
Another form of the COMMIT statement is: COMMIT ALL.
The COMMIT statement causes IDMS/R to release all locks except for those that are placed on current records; COMMIT ALL releases all record locks.
Both forms of the COMMIT statement cause IDVIS/R to write a commit checkpoint on the journal file. If the run unit is later abnormally terminated after it has issued a COMMIT statement, IDMS/R again works backward in the jour¬nal file
and uses the information in the before record images to reverse the effect of changes that the run unit made. This time, however, IDMS/R stops at the commit checkpoint rather than proceeding all the way back to the begin check¬point
that was written when the run unit began. Now, when the run unit is re¬started, it can be restarted from the point at which it wrote the most recent com¬mit checkpoint.
Many different techniques can be used for determining how often a COMMIT statement should be executed. One simple technique is simply to count the number of updates the run unit processes. Every one hundred updates or so, the run
unit might issue a COMMIT statement, causing IDMS/R to write an inter¬mediate checkpoint to the journal file.
Journal File
Begin Checkpoint:
Start of RU Before image
15 After image
17 Checkpoint: Commit Checkpoint:
Abnormal termination
Journal File
Begin Checkpoint:
Start of RU Before image
15 After image
17 Checkpoint: Commit Checkpoint:
Abnormal termination
12.5. Recovering From Failures
If the run unit is operating under the control of central version and is writing the journal files to direct access data sets, IDMS/R handles all the processing that is necessary to roll back database changes and to restart run units that it
aborts. No special application programming is necessary to invoke the automatic recovery and restart facilities in the central version environment with journal files written to direct access data sets.
In the local mode environment and in the central version environment with tapes journal files, IDMS/R provides utility programs to handle manual restarting of aborted applications.
Suppose a batch application is reading transactions from a sequential transaction file and processing database updates based on the data read from the transaction file. The application issues a COMMIT statement to write a commit
checkpoint every few hundred updates. Suppose the application now fails. A utility program can be run that backs out the changes that the pro¬gram made up to the previous commit checkpoint that the aborted run unit wrote to the
journal file. To restart the run unit, the run unit must contain application logic that will reposition the transaction file at the appropriate point so the run unit will reapply the changes that were backed out. It may also need to
reestab¬lish the appropriate positions within the database to resume processing at the ap¬propriate point in the database.
12.6. Rollback
In some cases, a program may itself determine during program processing that it needs to back out the changes that it has made to the database since it wrote the most recent checkpoint record. In the central version environment with
journal files written to direct access data sets, the program can request that IDMS/R do this automatically by simply abnormally terminating the run unit.
If we would like to back out the changes but not abend the run unit, we can issue a ROLLBACK statement. There are two formats of ROLLBACK statement as given below.
ROLLBACK.
This form of the ROLLBACK statement causes IDMS/R to write a checkpoint record to the journal file, nullify all currencies, automatically restore the data¬base using the before images from the journal, and terminate the run unit. After
issuing this form of ROLLBACK, to access the database again, we must re¬issue the BIND/READY sequence.
ROLLBACK CONTINUE.
If we issue this statement, IDMSIR restores the database but does not terminate the run unit. We may now access the database immediately without reissuing the BIND/READY sequence.
13. Locking
IDMSIR provides locking facilities for controlling access to areas and to indi¬vidual records when two or more run units require access to the same database areas. IDMS/R provides three levels of locks: Area locks, Area usage modes, and
record locks.
13.1. Area Locks
IDMS/R uses area locks to prevent areas from being updated by more than one IDMS/R central version or by more than one application running in local mode. This lock works at operating environment level, i.e. at central version level and
local mode application level.
If an area lock is already set on an area that is required by a local mode application, that local mode application abends; otherwise the local mode application locks those areas, and no other local mode application or IDMS/R central
version will be given access to those areas. An area lock is re¬leased by FINISH statement of the local mode application.
If an area lock is already set on an area that is required by an IDMS/R central version, the execution of that central version continues with no access to those areas for the run units of the CV. The area is said to be varied offline to that
central version. Run units that attempt to access an area that is varied offline are abnormally terminated. If all required areas are available, then CV locks those and are available to all run units of that CV. No other local mode
application or CV will be given access to locked areas. An area that is locked by a particular CV is released only when the central version is shut down or when the area is varied offline.
13.2. Area Usage Modes
All the run units that operate under the control of a particular IDMS/R central version can access the same set of database areas. In the central version en¬vironment, IDMS/R provides area usage mode options to control the concurrent
access of database areas by different run units. The area usage mode option is specified with READY statement. Please refer to Section 12.1 for READY statement.
SHARED
READY USAGE-MODE IS PROTECTED RETRIEVAL
ALL EXCLUSIVE UPDATE
There are six usage modes as follows.
• Usage mode is RETRIEVAL. With the RETRIEVAL or SHARED RETRIEVAL usage modes, we are requesting retrieval access to the area, and we are specifying that other run units of our CV will also be allowed to retrieve or update records in
the same area.
• Usage mode is PROTECTED RETRIEVAL. With the PROTECTED RE¬TRIEVAL usage mode, we are requesting retrieval access to the area, and we are specifying that no other run unit should update the records in the same area for the
duration of our run unit. However, other run units of our CV can retrieve the records in the area as long as they did not specify a usage mode of EXCLUSIVE for the same area. If another run unit is already updating the records in the area,
our run unit will wait until that run unit finishes.
• Usage mode is EXCLUSIVE RETRIEVAL. With the EXCLUSIVE RE¬TRIEVAL usage mode, we are requesting retrieval access, and we are specify¬ing that no other run unit be allowed to retrieve or update records in the area while our run unit
executes. If other run units are already accessing the area, our run unit will wait until all other run units finish with the area. This usage mode is not often used.
• Usage mode is UPDATE. With the UPDATE usage mode option, also called shared update mode, we are requesting update access to the area, and we are specifying that other run units also be allowed to retrieve or update records in the
area as long as they do not specify the PROTECTED or EXCLUSIVE op¬tions in their READY statements.
• Usage mode is PROTECTED UPDATE. With the PROTECTED UPDATE usage mode option, we are requesting update access to the area, and we are specifying that no other run unit should be able to update records while our run unit
executes. Other run units may also be allowed to retrieve records in the same area or areas as long as they do not specify the PROTECTED or EXCLU¬SIVE usage mode options. If another run unit is already updating the records in the area,
or if other run units are accessing the area with the PROTECTED RETRIEVAL or EXCLUSIVE RETRIEVAL usage mode, our run unit will wait until all other run units finish with the area.
• Usage mode is EXCLUSIVE UPDATE. With the EXCLUSIVE UPDATE us¬age mode option, we are requesting update access to the area, and we are spec¬ifying that no other run unit should either retrieve or update records in the area while
our run unit executes. This essentially gives the run unit exclusive use of the area.
13.3. Record Locks – Implicit, Explicit
Preventing other run units from accessing the same areas can cause system wide performance problems. When we use usage mode options that allow more than one run unit to access the same area while updating is taking place, IDMS/R
sets implicit record locks to prevent the same record from being concurrently updated by two or more run units. Implicit record locks are only maintained for run units operating under central version. Central version always maintains
record locks for run units executing in shared update mode. Record locks are never maintained for run units operating in local mode. In local mode, concurrent updates are prevented by setting locks on entire areas.
Implicit record locks:
There are two types of implicit record locks: implicit shared 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 guaran¬tees 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 ex¬clusive locks remain in effect until the run unit ends or until the run unit exe¬cutes a COMMIT statement.
Implicit lock example:
Two users are trying to update the same Employee record occurrence.
Run Unit 1 Run Unit 2
Implicit shared lock
1. Run unit 1 retrieves the Employee record for E1. IDMS/R places an implicit shared lock on the E1 record.
Implicit shared lock
2. Run unit 2 retrieves the Employee record for E1. Since a shared lock does not prevent other run units from accessing a record, IDMS/R gives the record to run unit 2. IDMS/R places another shared record lock on the E1 record on behalf
of run unit 2.
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 al¬lowed to update the record. Run unit 1 waits.
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.
5. Since each run unit is now waiting for a record that the other run unit locked, a dead¬lock has occurred.
..
..
Deadlock Detected
6. Sensing a deadlock, IDMS/R automatically abends run unit 2 to recover.
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.
In a high volume application such as an airline reservation system, abnormally terminating a run unit would be an inefficient method of handling a common res¬ervation system problem: contention for the same seat. Explicit locks provide
a better way of handling the same situation.
Explicit record locks:
To set an ex¬plicit record lock, code the KEEP clause in the DML statement that is used to retrieve the record. Following are two examples of CALC retrievals during which locks are set on the retrieved Employee record.
Shared lock: OBTAIN KEEP CALC EMPLOYEE.
Exclusive lock: OBTAIN KEEP EXCLUSIVE CALC EMPLOYEE.
In either case, the lock remains set until we either end the run unit by executing the FINISH statement or we execute a COMMIT statement.
We can issue a separate KEEP statement to set an explicit lock on a record after retrieving it.
Explicit lock example:
Run Unit 1 Run Unit 2
1.Run unit 1 retrieves the Employee record.
Explicit Exclusive Lock
2.Run unit 1 places an explicit exclusive lock on the Employee record just retrieved.
3.Run unit 2 attempts to retrieve the record.
4.Since run unit 1 has already placed an exclusive lock on the E1 record, run unit 2 waits.
5. Run unit 1 issues a MODIFY to update address information for the E1 record.
Lock Released
6. Run unit 1 issues a FINISH, and IDMS/R releases the lock on the E1 record.
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 in¬formation.
14. Utilities
14.1. DMLO
DMLO stands for DML-Online.
Please refer to Lab Book Appendix A.
In DMLO, you can access one DB-record at a time.
Steps to invoke DMLO for Employee Database (Training Dept):
• On CCS screen, type ccscv24t .
• On ‘Enter next task code’ prompt, type following:
signon IBM-id password
dcuf set dictname[company name]
dcuf set dbname [company name]
dmlo
• On the first screen of DMLO:
select mode as R (for retrieval mode)
type subschema-name, schema-name, ver
• On the next screen of DMLO at the bottom:
Type various retrieval DMLs.
E.g.:
Display department
This will display record layout of Department.
Enter the value for Dept-Id-0410. Then type following DML:
Obtain calc department .
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.
• At the end, to come out of DMLO, type following:
Finish nosave .
• To get back to CCS screen, type following:
Bye (Type ‘bye’ again if required).
If you want to make any updation in the database, then do following:
On the first screen of DMLO, type mode as U (for Update mode)
To come out of DMLO, type Finish save.
14.2. OLQ
OLQ stands for On-Line Query.
Please refer to Lab Book Appendix B.
In OLQ, you can generate a report as per the specifications. There are two types of OLQ sessions: Online and Batch.
First 3 steps are same as that of DMLO, i.e. upto setting the environment for DB and dictionary. After that, type OLQ.
On the first screen:
Type ‘menu’ at the top left corner
On the next screen:
Select subschema with any non-blank character
Next screen:
Select from the given record types
Next screen:
Select the required elements of the selected record types as columns of the report.
Note: - Everywhere selection should be done with nonblank character.
Next:
Give the required attributes i.e. change headers, sort on columns etc.
On continue processing, mark NO as an active option.
Following are some of the toggle commands:
rec - to go to the record type selection screen
ret - to go to the continue processing screen
Esc 3 or PF3 key - to take you back to the 1st screen
PF7 key - to take you to the previous screen
PF8 key - to take you one screen forward
Appendix A: Employee Database
The diagram is shown on next page.
Appendix B: Compilation and Run JCL
Compilation JCL: //DA0000TY JOB LA2719,'TEST2',NOTIFY=DA0000T,TIME=(0,5)
//IDMSDMLC PROC CREG=512K, COBOL COMPILER REGION SIZE
// CV=CV24T, LAST 3 CHARACTERS OF CV NAME
//* DREG=4M, IDMSDMLC REGION SIZE
//* LINKLIB='NO "LINKLIB" PARM', LINK EDITOR OUTPUT LIB
// LREG=512K, LINKAGE EDITOR REGION SIZE
// MODE=BATCH, PROGRAM EXECUTION MODE
//* PROGNAM='NO "PROGNAM" PARM', LOAD MODULE NAME
// PRT='SYSOUT=*', SYSOUT DESTINATION
// UTUNIT=SYSALLDA, UTILITY DATASET UNIT NAME
// CPARM='LOAD,SUPMAP,APOST,"SIZE=4096K,BUF=116K"',
// LPARM='LIST,XREF,LET,MAP'
//* +-----------------------------------------------------------------+
//* | EXECUTE IDMSDMLC IN EITHER CV OR LOCAL MODE |
//* +-----------------------------------------------------------------+
//DML EXEC PGM=IDMSDMLC
//STEPLIB DD DSN=SYS5.IDMS.&CV..LOADLIB,DISP=SHR
// DD DSN=SYS5.IDMS.&CV..BASELOAD,DISP=SHR
// DD DSN=SYSZ.IDMS.CCS.LOADLIB,DISP=SHR
//SYSIDMS DD DUMMY
//SYSCTL DD DSN=SYS5.IDMS.&CV..SYSCTL,DISP=SHR
//SYSLST DD SYSOUT=*
//SYS001 DD UNIT=&UTUNIT,SPACE=(TRK,(10,10))
//SYS002 DD UNIT=&UTUNIT,SPACE=(TRK,(10,10))
//SYS003 DD UNIT=&UTUNIT,SPACE=(TRK,(10,10))
//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=[company name]
DBNAME=[DBname]
ECHO=ON
DMCL=IDMSDMCL
JOURNAL=OFF
Run JCL: //DA0000TA JOB LA2719,'PRASANNA',NOTIFY=DA0000T,
// CLASS=A,MSGCLASS=X,REGION=0M,TIME=(0,1)
//*
//STEP020 EXEC PGM=IDMST1
//STEPLIB DD DSN=DA0000T.SUDHIR.LOADLIB,DISP=SHR
// DD DSN=SYS5.IDMS.CV24T.BASELOAD,DISP=SHR
// DD DSN=SYS5.IDMS.CV24T.LOADLIB,DISP=SHR
//SYSCTL DD DSN=SYS5.IDMS.CV24T.SYSCTL,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
2222
/*
//SYSOUT DD SYSOUT=*
//SYSIDMS DD *
ECHO=ON
DBNAME=[DBname]
JOURNAL=OFF
/*
Appendix C: IDMS/R ERROR-STATUS VALUES
MAJOR CODES
Code Database Function
00 Any DML statement
01 FINISH
02 ERASE
03 FIND/OBTAIN
05 GET
06 KEEP
07 CONNECT
08 MODIFY
09 READY
11 DISCONNECT
12 STORE
14 BIND
15 ACCEPT
16 IF
17 RETURN
18 COMMIT
19 ROLLBACK
20 LRF request
MINOR CODES
00 If major code 00, indicates successful completion; if nonzero, indicates unsuccessful completion due to problems related to CV
01 Area not readied: OR IF operation determined that set not empty or current record of run unit not a member of set
02 Db-Key used with a FIND/OBTAIN DBKEY, or direct db-key on a STORE, not within page range for specified record
04 Occurs-depending-on value negative or exceeds maximum; OR zero is sequence number for FIND/OBTAIN sequence-vn WITHIN SET/AREA
05 Execution of DML function would violate duplicates-not-allowed restriction
06 Currency not established for object record, set, or area
07 End of a set, area, or index set reached; OR set empty
08 Object record, set, procedure, or LR verb not in subschema; OR object record not member of object set
09 Area readied for retrieval, but DML issued requires update usage mode
10 Access restriction or subschema USAGE restriction prevents execution of requested DML; for SPF users, may indicate improper use of an ERASE
11 Record not stored because of insufficient space in area
13 Run-unit currency not established or nullified by a previous ERASE.
14 CONNECT not executed because object record defined as mandatory automatic member of set
15 DISCONNECT not executed because object record defined as mandatory member of set
16 Record already member of set
18 Record not bound
20 Current record of run unit not the same type as specified record
21 Not all areas being updated were readied in update usage mode; OR not all records, sets and areas affected are in subschema
22 Named record not currently member of named set
23 Named area not in subschema
25 Currency not established for object set
26 Record or SPF index entry not found; OR no more duplicates exists for object record
28 Run unit attempted to ready a previously readied area
29 DB-Key KEEP deadlock
30 Attempt made to erase owner of nonempty set
31 Retrieval statement’s format conflicts with record’s location mode
32 CALC field value in variable storage not equal to CALC control element value in current record of record type
33 One or more sets in which the record participates not in subschema
40 WHERE clause in OBTAIN NEXT logical record inconsistent with previous OBTAIN FIRST or NEXT for same logical record
41 Subschema contains no path to match logical record request’s WHERE clause
42 Error occurred in processing logical record path
43 Bad or inconsistent data in the logical record’s variable storage location, or in request’s or path’s WEHRE clause
44 Logical record request’s WHERE clause did not supply a key element expected by path
45 Subscript value in logical record request’s WHERE clause invalid
46 Arithmetic program check would occur in evaluation of logical record request’s WHERE clause
55 Invalid length defined for variable-length record
56 Insufficient memory available for IDMS compression/decompression routines
60 Record type inconsistent with set named in error set field of the IDMS Communications Block
61 No record found for pointer db-key
63 DBMS could not interpret DML function
64 CALC control element not described properly
65 Database page read not page requested
66 Area specified not available for update
67 Subschema invoked does not match subschema object tables
68 CICS interface (IDMSINTC) was not started
69 Run unit not bound to DBMS
70 Database or journal file would not open properly
71 Page range for area being readied or page requested not in DMCL
72 Insufficient memory available for load or storage allocation
73 New central vision run unit would exceed MAXERUS value specified at CV generation
74 Dynamic load of module failed
75 Read error
76 Write error
77 Run unit not bound or bound twice
78 Area wait deadlock
79 Run unit requested more db-keys locks than available to system
80 Target node not active or disconnected from DDS configuration
81 Database name specified not known
82 Subschema not allowed under specified database
83 Error was made in use of native VSAM datasets
POSTED BY GAYATRI GADRE AT 9:24 AM
1 COMMENT:
Joeri Alenis said...
Is it maybe possible to download this document with all the pictures included?
SEPTEMBER 24, 2009 AT 3:20 AM
Post a Comment
LINKS TO THIS POST
Create a Link
Newer Post Home
Subscribe to: Post Comments (Atom)
https://www.theblogchatter.com/download/off-beats-by-gayatri/
Search jobs in UK
Visit http://www.careersandjobsuk.com/?c=bspz
Visit my other blogs
For exhaustive list of diseases, their causes, symptoms and cure - Visit Aditya Ray of Hope
Blog Archive

► 2010 (23)
o
o
► March (7)
► February (16)

▼ 2009 (13)
o ▼ May (13)
 1. INTRODUCTION TO VSAM
 2. VSAM Catalogs











3. Inside VSAM Datasets
4. IDCAMS COMMANDS
5. LISTCAT
6. Creating Alternate Indexes
7. Reorganizing VSAM datasets
8. VERIFY , PRINT, DELETE, ALTER Command
9. Generation DataSets
10. COBOL VSAM Considerations
VSAM Index
MVS (Multiple Virtual Storage)
IDMS
Visitors count
<div class statcounter=><a href="http://www.statcounter.com/blogger/" class="statcounter" title="blogspot hit counter"><img class blogspot hit counter statcounter=" alt=" src="http://c.statcounter.com/4915057/0/59e64ccf/0/"/></img
class></a></div class>
Translate this page
Albanian | Arabic | Bulgarian | Catalan | Chinese | Croatian | Czech | Danish | Dutch | Estonian | Filipino | Finnish | French | Galician | German | Greek | Hebrew | Hindi | Hungarian | Indonesian | Italian |
Japanese | Korean | Latvian | Lithuanian | Maltese | Norwegian | Polish | Portuguese | Romanian | Russian | Serbian | Slovak | Slovenian | Spanish | Swedish | Thai | Turkish | Ukrainian | Vietnamese | (Get this
widget)
Add this to favourites
Followers
Copyright Notice
© GAYATRI GADRE. 2010. ANY UNAUTHORISED AND ILLEGAL USAGE WI LL BE PROSECUTED.
FOOTER