IMS/DB

Table of contents

Data Language 1 :_________________________________________________________3 IMS Software Environment :________________________________________________3

IMS TERMINOLOGY__________________________________________________________4
Segment Type And Segment Occurrences : __________________________________________________5 Relationships between Segment Types : _____________________________________________________5 Data Base Record :______________________________________________________________________6 Designing of Data Base :_________________________________________________________________6

IMS ACCESS METHODS :______________________________________________________9

HSAM :_______________________________________________________________________________9 HISAM :______________________________________________________________________________9 HIDAM :______________________________________________________________________________9

PCB & PSB :_________________________________________________________________11

FIELD-LEVEL SENSITIVITY :__________________________________________________________12

DL/I PROGRAMMING :_______________________________________________________13

LINKAGE SECTION.__________________________________________________________________13 PROCEDURE DIVISION.______________________________________________________________13 IMS CALL - PARAMETER LIST :________________________________________________________13 Multiple qualification SSAs :____________________________________________________________16

COMMAND CODES:__________________________________________________________18
Using command codes :_________________________________________________________________18 C command code :_____________________________________________________________________19 D command code :_____________________________________________________________________19 F and L command codes :________________________________________________________________19 N command code :_____________________________________________________________________19 P command code :______________________________________________________________________19 Q command code :_____________________________________________________________________19 U and V command codes :_______________________________________________________________20

DL/I FUNCTION CODES:______________________________________________________20 RETRIEVAL OF INFORMATION:______________________________________________21

A GU call without SSAs :_______________________________________________________________21 A GU call with unqualified SSAs :________________________________________________________21 A GU call with qualified SSAs :__________________________________________________________22 Combination of qualified and unqualified SSAs :_____________________________________________22 Missing hierarchical levels :______________________________________________________________22 GN call without SSAs :_________________________________________________________________24 A GN call with unqualified SSAs :________________________________________________________25 A GN call with qualified SSAs :__________________________________________________________25 GNP call without SSA :_________________________________________________________________26 GNP call with SSAs :___________________________________________________________________26 GN and GNP calls with command codes :___________________________________________________27 Status Code Check after GU call:__________________________________________________________29 Status Code Check after GN call:__________________________________________________________29 Segments with non-unique key or no key :___________________________________________________31 Status Code Check :____________________________________________________________________31 General Rules to be followed for DLET and REPL Calls :______________________________________32 Status Code Check :____________________________________________________________________33 Status Code Check :____________________________________________________________________34

MULTIPLE POSITIONING :___________________________________________________34

Advantages of Multiple Positioning :_______________________________________________________38

MULTIPLE PCBs :______________________________________________________38

FAST PATH DATA BASES: ____________________________________________________40
MAIN STORAGE DATABASE :_________________________________________________________40 Terminal Related MSDB:________________________________________________________________40 Non-Terminal-Related MSDB:___________________________________________________________41 DATA ENTRY DATABASE:____________________________________________________________41

SECONDARY INDEXING :____________________________________________________42

PSBGEN requirements for Secondary Indexing:______________________________________________42 CUSTOMER DBD: ____________________________________________________________________50 INVENTORY DBD:___________________________________________________________________50 INVENTORY DBD:___________________________________________________________________53 Logical Child:_________________________________________________________________________56 Logical Parent:________________________________________________________________________56 Physical Parent :_______________________________________________________________________56

IMS - DB
IMS stands for Information Management System. It is a data management system software. There are two systems, IMS/VS (Information Management System/Virtual Storage) and DL/I VSE (Data Language /1 - Virtual Storage Extended). Both these products are available from IBM. IMS/VS program product contains a teleprocessing monitor, generally called IMS-DC (Information Management System - Data Communication) as well as database interface, generally called DL/I (Data Language/1). DL/I can interface with IMS/DC and CICS/VS.

Data Language 1 :
It is IBMs name for the collection of software modules that provide access to the data stored in a DL/I data base. It is IBMs name for the interface language that programmers use in accessing the data base in an application program. The objectives of database management systems are Data Redundancy, Data Integrity, Data Independence, Data Sharing, Data Security, Data Recovery.

IMS Software Environment :

IMS software environment can be divided into five categories. Application Programs use standard CALL statements and parameter lists to communicate with IMS. Application programs can be written in COBOL, PL/I or Assembler Language. IMS database is in hierarchical structure. IMS databases are normally stored in direct access storage, but under certain circumstances, sequential data sets can be used. Application programs make calls to IMS to request data. IMS performs the actual manipulation of data in the data base. IMS consists of a set of program modules that intercepts all requests that programs make for accessing the data base. IMS uses DL/I to provide a set of programming standards for interfacing with DL/I modules. The person who sets up IMS databases uses two IMS control blocks in describing the data base structure and identifying how the data base can be accessed. These two control blocks are called Data Base Description (DBD) and Program Specification Block(PSB). IMS - DC consists of a set of program modules that allow an application program to communicate with remote terminals through a standard interface language using CALL statements and parameter lists. The way in which the program communicates with remote terminals is similar to the way the program accesses the data base.

IMS TERMINOLOGY
Data base is a group of data elements organized to meet the requirements of one or more applications. Data elements are organized in a hierarchical structure. All IMS data bases are made up of one or more hierarchies or inverted tree structures. Some data elements are dependent on others. The hierarchical data base tree structure is shown in the figure below for customer data base.

CUSTOMER DATABASE

C3 C2 CUSTOMERC1

S3 S2 SHIP TO - S1

S4

B2 BUYER - B1 RECEIVABLE - R1

R2

P2 PAYMENT P1 ADJUSTMENT - A1

A2 LINE ITEM L1

L2

A DL/I data base record consists of clusters of data fields, which are called SEGMENTS. A segment represents the smallest unit of information that DL/I transfers to and from the program in an I/O operation. Each segment consists of one or more data fields. A single segment type or multiple segment types can be defined at each level of the data base. The single segment at top of hierarchy - the one from which all the other segments eventually derive is called ROOT segment. Only one root per data base record. In the customer data base example, there are four levels and there are multiple segments at some levels. DL/I allows to implement structures that are more complex in nature, with 15 levels and 255 different segment types in a data base.

Segment Type And Segment Occurrences :

Segment type is simply a category of data. Segment occurrence is one specific segment of a particular type containing user data. Within a database, there is only one of each segment type - its part of the databases definition-but there can be an unlimited number of occurrences of each segment type. In customer data base example there are seven segment types and each is represented by one of the boxes. There are three occurrences of the customer segment type in the above example (C1, C2, C3) which means that three customers information is stored in the data base.

Relationships between Segment Types :

The terms Parent and Child are used to describe the relation ships between segment types. Any segment type having one or more segment types directly below it is called a Parent. Any segment type having a segment type directly above it is called a Child. For example in the Customer data base Receivable segment type (R1) is a parent, and Payment (P1, P2), Adjustment (A1, A2), Line Item (L1, L2) Segment types are its Children. However the Receivable segment type is also a child of Ship-to Segment (S1). All segments in a data base record other than the root segment are called Dependent Segments. For example Line-Item segment is dependent on Receivable segment. A particular Payment segment occurrence cannot exist unless there is a Receivable segment occurrence above it in the data base. But it is valid to have a Receivable segment occurrence (R2) that does not have any of the Payment, Adjustment, Line-item segment occurrences below it. All occurrences of a particular segment type under a single parent segment occurrence are called twins. For example a particular Receivable (R1) has 2 occurrences of adjustment segment type (A1, A2), which are called twins. However, receivable A2, A3 are not twins, because they have different segment occurrences as parents. Set of all twins dependent on a particular parent can be called as Twin Chain. In the Customer data base P1, P2, A1, A2, L1, L2 can be called as Twin Chain, as because all the segment occurrences have the parent same as R1.

Data Base Record :

A data base record consists of a single occurrence of the root segment plus all its dependent segment occurrences. In standard file processing, a record is the unit of data that programs operate upon. Under DL/I, that unit is the segment. A single data base record typically has many segment occurrences. To retrieve a data base record all the segments (Root and dependent) and segment occurrences will be retrieved in a specific sequence which is called as Hierarchical Path. The path is an imaginary line that starts at the root segment, passes through all segment types at intermediate levels in the hierarchy. The path followed is Top - down and Left to Right. The hierarchical path and data base record can be very well understood with the following example. In the Customer data base there are three data base records. They are : 1. C1-S1-B1-B2-R1-P1-P2-A1-A2-L1-L2-R2-R3-A3-S2. 2. C2-S3. 3. C3-S4.

Designing of Data Base :

When Data Base Administrator (DBA) designs a data base, a number of factors must be considered. The factors to be considered are : 1. 2. 3. 4. 5. 6. 7. 8. What are the names of the segments that can be accessed? What are the formats of the various fields within those segments? What are the hierarchical relationships among the segments? What kind of processing can be performed on the segments? What are the hierarchical relationships that best fit the needs of the Which physical access methods provide the best level of efficiency and How often should the data base be reorganized? What kinds of data security should be built into the system?

applications that will access the data base? storage economy for the data base?

A Key or Sequence field is a field within a segment selected to identify which occurrence the segment is, i.e., maintains segments in ascending sequence. Only a single field within each segment can be designated as a key or sequence field. However, segments are generally not required to have a key or sequence field. Sequence fields can be designated as unique or nonunique. To search for a segment based on the contents of some field, but the segments should not be sequenced on that field, the field can be designated as a Search Field. Once segments have been defined, the hierarchical structure decided upon, and key & search fields chosen, the Data Base Administrator communicates this information to IMS. To do this a control block is created in a IMS library, called Data Base Description. It describes the physical nature of a data base. A process called DBD generation (DBDGEN) is used to create DBD. The DBA creates a DBD by coding a series of DBDGEN control statements.

IMS MACLIB

DBDGEN Process

DBDGEN Statements

Assembler

Object Module

Linkage Editor

DBDLIB

The DBDGEN process is as shown in the above diagram. DBDGEN control statements are shown below for the Customer data base. PRINT DBD DATASET SEGM FIELD FIELD FIELD FIELD FIELD FIELD FIELD SEGM FIELD FIELD FIELD FIELD FIELD FIELD FIELD SEGM FIELD FIELD FIELD SEGM FIELD FIELD FIELD FIELD FIELD FIELD FIELD FIELD SEGM NOGEN NAME=CUSTDBD,ACCESS=HIDAM DD1=CUST,DEVICE=3350 NAME=CUSTOMER,PARENT=0,BYTES=128 NAME=(CUSTNUM,SEQ,U),BYTES=6,START=1,TYPE=C NAME=CUSTNAME,BYTES=31,START=7,TYPE=C NAME=CSTADD1,BYTES=31,START=38,TYPE=C NAME=CSTADD2,BYTES=31,START=69,TYPE=C NAME=CUSTCITY,BYTES=18,START=100,TYPE=C NAME=CSTSTATE,BYTES=2,START=118,TYPE=C NAME=CUSTZIP,BYTES=9,START=120,TYPE=C NAME=SHIPTO,PARENT=CUSTOMER,BYTES=124 NAME=(SHPTOSEQ,SEQ,U),BYTES=2,START=1,TYPE=C NAME=SHIPNAME,BYTES=31,START=3,TYPE=C NAME=SHIPADD1,BYTES=31,START=34,TYPE=C NAME=SHIPADD2,BYTES=31,START=65,TYPE=C NAME=SHIPCITY,BYTES=18,START=96,TYPE=C NAME=SHPSTATE,BYTES=2,START=114,TYPE=C NAME=SHIPZIP,BYTES=9,START=116,TYPE=C NAME=BUYER,PARENT=SHIPTO,BYTES=72 NAME=BUYRNAME,BYTES=31,START=1,TYPE=C NAME=BUYTITLE,BYTES=31,START=32,TYPE=C NAME=BUYTELPH,BYTES=10,START=63,TYPE=C NAME=RECVABLE,PARENT=SHIPTO,BYTES=57 NAME=(RSINVNUM,SEQ,U),BYTES=6,START=1,TYPE=C NAME=RSINDATE,BYTES=6,START=7,TYPE=C NAME=RSPONUM,BYTES=25,START=13,TYPE=C NAME=RSPRDTOT,BYTES=4,START=38,TYPE=P NAME=RCASHDIS,BYTES=4,START=42,TYPE=P NAME=RSSLSTAX,BYTES=4,START=46,TYPE=P NAME=RFREIGHT,BYTES=4,START=50,TYPE=P NAME=RSBALDUE,BYTES=4,START=54,TYPE=P NAME=PAYMENT,PARENT=RECVABLE,BYTES=51

FIELD FIELD FIELD FIELD SEGM FIELD FIELD FIELD FIELD SEGM FIELD FIELD FIELD FIELD

NAME=(PSCHKNUM,SEQ,U),BYTES=16,START=1,TYPE=C NAME=PSBNKNUM,BYTES=25,START=17,TYPE=C NAME=PAYDATE,BYTES=6,START=42,TYPE=C NAME=RSPAYAMT,BYTES=4,START=48,TYPE=P NAME=ADJSTMNT,PARENT=RECVABLE,BYTES=17 NAME=(ASREFNUM,SEQ,U),BYTES=6,START=1,TYPE=C NAME=AADJDATE,BYTES=6,START=7,TYPE=C NAME=AADJTYPE,BYTES=1,START=13,TYPE=C NAME=ASADJAMT,BYTES=4,START=14,TYPE=P NAME=LINEITEM,PARENT=RECVABLE,BYTES=16 NAME=(ITKEYVEN,SEQ,U),BYTES=3,START=1,TYPE=C NAME=ITKEYNUM,BYTES=5,START=4,TYPE=C NAME=LIUNTPRC,BYTES=4,START=9,TYPE=P NAME=LIQUANTY,BYTES=4,START=13,TYPE=P

DBDGEN
FINISH END DBDGEN control statements consist of assembler language macro statements. The macros are supplied by IBM in a library named some thing like IMSVS.MACLIB. DBDGEN control statements are normally coded by the DBA and submitted to the system with JCL that invokes a cataloged procedure usually called DBDGEN. The DBDGEN process causes the DBDGEN control statements to be processed by the assembler producing an object module. The object module is then passed to the linkage editor which in turn stores a load module in another library. (IMS.DBDLIB) This load module is the DBD which can be loaded into the storage. In FIELD statements, NAME operands contain from one to three positional subparameters. The first parameter gives a name to the key or search field. If it is the only subparameter coded, the field is a Search Field. If the characters SEQ are coded in the second position, the field is a Key or Sequence Field. Only one of these is allowed per SEGM statement. If a U is coded in third position, the field is a unique sequence field. Various FIELD macro TYPE parameter codes available are : C - Character, P - Packed Decimal, Z - Zoned Decimal, X - Hexadecimal, H - Halfword Binary, F - Full word Binary

IMS ACCESS METHODS :

There are several IMS access methods available, that retrieve and manipulate the segments stored in a data base. These access methods are as follows. 1. 2. 3. 4. The Hierarchical The Hierarchical The Hierarchical The Hierarchical Sequential Access Method (HSAM). Indexed Sequential Access Method (HISAM). Direct Access Method (HDAM). Indexed Direct Access Method (HIDAM).

HSAM :
The adjective that best describes HSAM is tapelike. The hierarchical sequence is represented entirely by physical contiguity. In other words, segments are arranged physically in hierarchical sequence. No provision is made for directly accessing a particular root segment. All segments, including root segments, are stored in hierarchical sequence, and random retrieval of a root segment is performed by scanning through all the segments upto that root. An HSAM database is created by means of a series of Insert operations. Note that the segments to be loaded must be presented in hierarchical sequence. Once created the data base may be used only for Input. HSAM segments cannot be deleted or replaced and new segment occurrences cannot be inserted into an existing data base. To update the data base, an application must process the old HSAM data base as input and create a new version of the HSAM data base using Insert Calls in the load mode.

HISAM :
It can be characterized, a little inaccurately, by saying that it provides indexed access to the root segments, sequential access to the subordinate segments. The main difference between HSAM and HISAM is in the way the root segments are accessed. With HISAM, a VSAM or ISAM index is used to locate root segments. The index is nondense, so that in general there will be many roots for each index entry. Access to dependent segments is sequential, in as much as to access the Nth dependent of a particular root, it is necessary to traverse all the (N-1) dependents that precede it. HISAM tends to be inefficient when the data base is subject to a lot of additions and deletions. In general, HISAM is a good access method to use when random access is required to root segments and when data base records are fairly small, or when access to dependent segments is always sequential. An HISAM data base uses either a combination of ISAM (Indexed Sequential Access Method) and OSAM (Overflow Sequential Access Method) or VSAM (Virtual Storage Access Method) as its supporting access method. When the database is initially loaded (remember that loading must be done in hierarchical sequence), each root segment presented causes a new ISAM stored record to be created; the root segment is placed at the front of this record, and as many dependent segments as will fit are placed after the root. If the ISAM record is filled before all dependents of the current root have been loaded, then a new OSAM record is created and the next dependent is placed at the front of that; also the relative address of the OSAM record is placed in the next dependent pointer position in the ISAM record. Subsequent dependents follow this one in the OSAM record. If the OSAM record is in turn filled, another is created and so on. Thus each physical database record occurrence is represented as a chain containing one ISAM record together with zero or more OSAM record. Deletion of a segment in HISAM is accomplished by setting a flag in the segment prefix. Dependents of the deleted segment are automatically considered as deleted. The ISAM and OSAM data sets are replaced by a VSAM key-sequenced and a VSAM entry-sequenced data set respectively. All root segments reside in the key-sequenced data set, even insertions. When a new root is inserted, it is placed in its proper position in this data set and the VSAM index is updated if necessary.

HDAM :
HDAM provides direct access (by sequence field value) to the root segments, via a hashing and chaining technique, together with pointer access to the subordinate segments. In its simplest form, an HDAM database consists of a single OSAM data set or a single VSAM entry-sequenced data set, divided up into fixed-length stored records. HDAM differs from the other structures in that initial loading of the database need not be performed in sequence. More accurately, root segments may be presented for loading in any order; however all dependents of a given root must be presented in strict hierarchical sequence before the next root is loaded. When a root segment is presented for loading, the value of its sequence field is passed to a DBAsupplied hashing routine, which hashes the value and generates the address of a record within the root segment addressable area. Inserting a new segment does not cause any existing segments to be moved in HDAM. This is made possible by the pointers which allow the space allocation routines to place an inserted segment at any convenient position while still maintaining both the hierarchical sequence and the ability to access the two structures. In HISAM deletions are indicated merely by setting a flag in the segment prefix. In HDAM, however, the space occupied by the deleted segment is made available for reuse, so that a subsequent insertion may cause the segment to be physically overwritten.

HIDAM :
HIDAM provides indexed access to the root segments, pointer access to the subordinate segments. As in HISAM, the indexing is on the root segment sequence field. A HIDAM data base actually consists of two databases; a data database, which contains the actual data, and an associated INDEX database, which provides the index.

The data database consists in its simplest form of a single OSAM data set or a single VSAM entry-sequenced data set, divided up into fixed length stored records. The initial loading of the database must be performed in hierarchical sequence. As each segment is presented, it is placed in the data set at the next available position in sequence as if this were an HSAM database. In addition, of course, the appropriate pointer values are placed in relevant prefixes. Subsequent deletions are handled exactly as in HDAM; that is space is freed and may be used for segments added later. The subsequent insertion of a root segment will cause the new root to be placed as near as possible to the root that precedes it in hierarchical sequence. Subsequent insertion on a dependent segment will cause the new segment to be placed as near as possible to its immediate predecessor in hierarchical sequence. (As in HDAM, segments never move once they have been stored.

10

PCB & PSB :

Generally the user does not operate directly at the physical data base level but rather on an External View of the data. A particular users external view consists of a collection of Logical databases where each logical data base is a subset of corresponding physical database. Each logical database is defined, together with its mapping to the corresponding physical database, by means of Program Communication Block (PCB). The set of all PCBs for one user, corresponding to the external schema plus the associated mapping definition, is called a Program Specification Block (PSB). Although each application program can have its own PSB, it is not uncommon for application programs that have similar database processing requirements to share a PSB. The data base administrator codes a job stream to assemble and link the macro instructions that specify an application programs view of one or more data base. The resulting load module is stored in a partitioned data set. (IMS.PSBLIB) PRINT PCB SENSEG SENSEG SENSEG SENSEG PSBGEN END NOGEN TYPE=DB,DBDNAME=CUSTDBD,KEYLEN=30,PROCOPT=L NAME=CUSTOMER NAME=SHIPTO,PARENT=CUSTOMER NAME=RECVABLE,PARENT=SHIPTO NAME=PAYMENT,PARENT=RECVABLE PSBNAME=CUSTPSB,LANG=COBOL

The first statement in PSBGEN is PCB statement. It begins the coding for one program communication block. It specifies the type of PCB defined, in this case a data base PCB. The PCB statement also gives the name of the DBD that defines the segments named in the PCB. A PSB can only identify segments that have already been defined in the DBD. The PROCOPT operand is optional. A PROCOPT parameter specifies Processing Options that define the type of processing that can be performed on a segment. In the above example L indicates that the program can perform only load operations. Other possible values are retrieve (G), insert (I), replace , and delete (D); any or all of G, I, R, D may be specified in any order. If PROCOPT is specified in both the PCB statement and in SENSEG statement, the SENSEG entry overrides the PCB entry. However, there is only one entry, L which may be specified only in the PCB statement and which cannot be overridden. Also, there is one entry, K (Key Sensitivity), which may be specified only in the SENSEG statement. Key sensitivity is used when the designer of the PCB is forced by the hierarchical structure of the underlying physical database to include a segment that the user of the PCB does not really require (or perhaps is not allowed to access). Following the PCB statement is a series of SENSEG statements. SENSEG statements identify the segments in the CUSTOMER database that this application is sensitive to. The first operand in each SENSEG statement is the NAME operand. The name coded here must be the same as the name coded in the NAME operand in SEGM statement in a DBD that defines the database. In the above PSB example, the program is sensitive to all the fields defined in each of the segments named in SENSEG statements. The data retrieved will appear in the application program I/O area just as it is stored in the data base.

11

FIELD-LEVEL SENSITIVITY :
Within the sensitive segments, some specific fields can be identified as sensitive fields. When the program accesses that segment, only the sensitive fields are retrieved. This is called the Field level sensitivity. Example shown below shows a PCB that specifies field-level sensitivity for three fields in RECVABLE segment. NOGEN TYPE=DB,DBDNAME=CUSTDBD NAME=CUSTOMER,PARENT=0,PROCOPT=K NAME=SHIPTO,PARENT=CUSTOMER,PROCOPT=K NAME=RECVABLE,PARENT=SHIPTO,PROCOPT=K SENFLD NAME=RSINVNUM,START=1 SENFLD NAME=RSPONUM,START=7 SENFLD NAME=RFREIGHT,START=32 SENFLD NAME=RSINDATE,START=36 SENSEG NAME=PAYMENT,PARENT=RECVABLE PSBGEN PSBNAME=CUSTPSB,LANG=COBOL END The SENFLD statements following the SENSEG statement, names the specific fields from the RECVABLE segment that should be passed to the application program. The START parameters in each SENFLD statement specify where in the I/O are each field should be placed. SENFLD statements can be used to create a view of a particular segment that is quite different from the way the segments data is actually stored in the database. This is often useful where a segments physical format must be changed and where existing application programs must continue to be used. The field-level sensitivity feature provides an example of how IMS allows programs to be independent of the physical format of the data it accesses. One restriction with field-level sensitivity is that the fields specified in SENFLD statements are limited to those fields that are identified in DBD FIELD statements. PRINT PCB SENSEG SENSEG SENSEG

12

DL/I PROGRAMMING :
To enable a program to communicate correctly with IMS, certain programming conventions needs to be followed. An application program is treated as a subroutine of IMS, and standard subroutine linkages and parameters lists, hook IMS to application programs. A proper linkage between the program and PCBs passed by IMS needs to be established.

LINKAGE SECTION.
01 PCB1-MASK. 03 DATA-BASE-NAME PIC X(8). 03 CURRENT-SEGMENT-LEVEL PIC XX. 03 STATUS-CODE PIC XX. 88 SUCCESSFUL VALUE . 88 OPEN-ERROR VALUE AI. 88 NEW-LEVEL-UPWARDS VALUE GA. 88 END-OF-DATA-SET VALUE GB. 88 SEGMENT-NOT-FOUND VALUE GE. 88 NEW-SEGMENT-TYPE VALUE GK. 88 DUPLICATE-SEGMENT VALUE II LB. 88 END-OF-MESSAGES VALUE QC. 88 END-OFMSG-SEGMENTS VALUE QD. 03 DLI-PROCESSING-OPTION PIC X(04). 88 GET-FUNCTION VALUE G. 88 INSERT-FUNCTION VALUE I. 88 REPLACE-FUNCTION VALUE R. 88 DELETE-FUNCTION VALUE D. 88 ALL-THE-ABOVE VALUE GIRD. 88 LOAD-SEG-IN-ASC-SEQ-HIDAM VALUE LS. 03 RESERVED-FOR-DLI PIC S9(09) COMP. 03 SEGMENT-NAME-FEEDBACK PIC X(08). 03 LENGTH-OF-CONCAT-KEY PIC S9(09) COMP. 03 NUMBER-OF-SENSITIVE-SEG PIC S9(09) COMP. 03 KEY-FEEDBACK. 05 ................ 05 ............... ..........

PROCEDURE DIVISION.
ENTRY DLITCBL USING PCB1-MASK. ...... ......

GOBACK.
In the above example the PCB is defined in Linkage section which sets the linkage between the program and PSB. The ENTRY statement assigns a standard IMS name to the entry point of the program. The entry point of a COBOL IMS program must be DLITCBL. The USING clause lists the names of the PCB masks coded in the Linkage Section. ENTRY statement also gives the program access to the PCB through the USING clause. The data names in Linkage Section describe the data areas in the PCB. These data names make up a data structure called the PCB mask. The PCB mask is defined in the Linkage Section because the PCB itself resides in storage owned by IMS. It does not reside in any of the application programs data areas. Although the order in which the PCB masks are coded in Linkage Section does not matter, they need to be listed on the ENTRY statement in the same sequence as they appear in the programs PSBGEN. The ENTRY statement provides a mechanism for DL/I to transfer control to the program. When the program ends, it must pass control back to DL/I so that DL/I can deallocate its resources and close the data base data sets. To do that GOBACK statement is required. If the program is ended with a STOP RUN statement, control returns directly to the operating system; DL/I never has a chance to perform its termination functions.

IMS CALL - PARAMETER LIST :

The CALL statement parameter list and the data items identified in the parameter list make up the DL/I interface language. The first parameter is the number of parameters followed in the CALL statement. Note that this parameter is optional. The Second parameter names a four-byte Function Code that describes the type of service requested. For example to retrieve a segment the value to be coded is GU or GN. The third parameter identifies the

13

PCB mask referenced in the call. The PCB mask parameter is included in the call parameter list as well as in the entry coding, because many IMS programs use more than one PCB. The PCB mask parameter is required even if the program accesses only one PCB. The fourth parameter gives the address of the data area into which IMS places the retrieved segment. Some programs retrieve segments of various types using the same retrieval call, in which case an I/O area must be large enough to contain the data retrieved. CALL CBLTDLI USING PARAMETER-COUNT DLI-FUNCTION PCB-MASK SEGMENT-IO-AREA [SEGMENT-SEARCH-ARGUMENTS]

In the above example the 1stst parameter is optional, 2ndnd, 3rdrd and 4thth parameters are required with all retrieval calls. The fifth parameter can be optionally specified from one to fifteen SSAs to further describe a retrieval.

14

SEGMENT SEARCH ARGUMENT (SSA):

An SSA identifies the segment occurrence one wants to access. An SSA is an area of storage that contains data which identifies the segment to which a DL/I call applies. SSAs are coded in the working storage section of the programs. There are TWO types of SSAs Unqualified SSA Fully qualified SSA

Unqualified SSA :
An unqualified SSA simply names the segment type. The basic format of an unqualified SSA is as follows :

| 1 | 9

. 8 |
SPACE

SEGMENT NAME

An unqualified SSA is of 9 bytes long. First 8 bytes is for the segment name and the 9 thth byte should always be a space and this position indicates DL/I what type of an SSA it is i.e. an unqualified SSA or an qualified SSA. If the SSA is only 8 bytes then DL/I gives error. One way of coding an unqualified SSA in the working-storage is as follows : 01 UNQUALIFIED-SSA. 05 UNQL-SSA-SEGMENT-NAME 05 FILLER PIC X(8). PIC X VALUE SPACES.

Qualified SSA :
A fully qualified SSA not only names the segment type, but also specifies the segment occurrence of it. A qualified SSA includes the field value for DL/I to search for a segment occurrence. In other words a qualified SSA specifies a particular segment occurrence based on a condition that a field within a segment must meet. The basic format of an qualified SSA is as follows :

| 1 | | 9 | | 10| | 18|19| | 20| |N+1|

. 8 | . 17| )

SEGMENT NAME

(
FIELD NAME

. |N | FIELD

RELATIONAL OPERATOR VALUE

15

Though, the length of a qualified SSA is not fixed, like unqualified SSAs, the format should be followed. The first eight bytes must be the segment name. The ninth byte must be ( i.e. a left parenthesis. This doesnt mean that the 9 thth position should always be a left parenthesis. The exception will be dealt at the time of explaining command codes. Then followed by a 8 byte field name that has been defined in the DBD from positions 10 to 17. If the field size is less than 8 bytes than the right most bytes must be padded with blanks. The 18thth and 19thth positions are used to specify the relation operator. Followed, is the value of the field for which DL/I should search for. The relational operators that are allowed are as follows. Equal to Not equal to Greater than Greater than or equal to Less than Less than or equal to LT LE EQ NE GT GE < <= or =< = ^= > >= or =>

One way of coding a qualified SSA in the program working storage is as follows 01 CUSTOMER-SSA. 05 FILLER 05 FILLER 05 CUSTNUM-VALUE 05 FILLER PIC X(9) PIC X(10) PIC X(6). PIC X VALUE CUSTOMER (. VALUE CUSTNUM =. VALUE (.

Though the SSA can be generalized, it is always advisable to code separate SSAs for each of the segment that needs to be accessed/processed.

Multiple qualification SSAs :

SSAs can be used with multiple qualifications i.e. SSAs can be coded in such a way that a segment can be processed based on the contents of two or more fields within that segment. To do so, boolean operators are used to connect the qualifiers. There are three boolean operators that can be used in an SSA. They are : AND OR and Independent # & or * + or |

AND

16

You are aware of AND and OR operators. The third one, namely Independent AND will be explained while dealing with Secondary indexing. For now we will ignore it. For e.g., to retrieve VENDOR segments whose vendor codes fall within range 1000 thru 2000, i.e. retrieve all vendor segments where INVENCOD >= 1000 AND INVENCOD <= 2000, the SSA can be coded as follows :

01 CUSTOMER-SSA.
05 05 05 05 05 05 05 FILLER FILLER CUSTNUM-LOW FILLER CUSTNUM-HIGH FILLER FILLER PIC PIC PIC PIC PIC PIC PIC X(9) VALUE CUSTOMER(. X(10) VALUE CUSTNUM>=. X(6). X VALUE &. X(10) VALUE CUSTNUM=<. X(6). X VALUE ).

In the above example, CUSTNUM-LOW and CUSTNUM-HIGH values are supplied in the program. In the above example, two qualifiers (conditions) are connected by an AND operator which makes it a set. Such sets are called qualification sets. In other words, a qualification set is that, where two qualifiers are separated with an & operator. There can be more than one qualification set in an SSA and they are separated by OR operator. An OR operator or the end of an SSA, marks the end of a set. An AND operator connects individual qualifications within a set. Thus, multiple qualification SSAs are to be coded in terms of qualification sets. This puts a restriction on the way a multiple qualification SSA is coded. An SSA cannot have a condition like A * (B + C), since it does not follow qualification set concept of DL/I. To achieve this condition, it must be coded as ((A * B) + (A * C)). This makes the condition to have two qualification sets. This doesnt mean that there cannot be more than one AND operator within a qualification set. Thus, a qualification set as A*B*C is allowed. It should be noted here that DL/I evaluates from left to right when more than two qualifiers are used.

17

COMMAND CODES:
By using a command code along with an SSA, one can modify the way a DL/I call is handled and extend the functions of DL/I calls. This also saves the programming and processing time. There are TEN command codes and these can be used in combination to perform various functions. Though the same can be achieved by using multiple DL/I calls with simple qualified SSAs, it is always better to use SSAs with Command Codes. Remember that Dl/I calls are very expensive. Following are the command codes that can be used : Command C D F L N P Q U V Null command code Meaning Concatenated key Path call First occurrence Last occurrence Path call ignore Set parentage Enqueue segment Maintain position at this level Maintain parentage at this level and all superior levels

Using command codes :

The command codes can be used by coding an * (asterisk) in the 9thth position of the SSA, followed by the command codes starting in position 10. The moment DL/I encounters *, it assumes that command codes follow. And treats all the following characters as command codes until it encounters a space (in case of unqualified SSAs) or a left parenthesis (in case of qualified SSAs). Though more than one command code can be used, it is unusual to use more than one. In case of unqualified SSAs after the command codes, there should be one space specified. This identifies, if the SSA is qualified or unqualified. The general format of an SSA with command codes is as follows :

| 1 | | 9 | | 10| 11| | 12| | 13| |21|22| |23| |N+1|

| 8 |

. SEGMENT NAME

*
COMMAND CODES

|20 | ) |N |

(
FIELD NAME RELATIONAL OPERATOR FIELD VALUE

18

In the format shown above two positions , viz., 10thth and 11thth, specify command codes. Care should be taken while coding qualified SSAs that none of these positions should be left blank. Otherwise DL/I will ignore whatever is coded after the blank position and treats the SSA as an unqualified SSA.

C command code :
The C command code is used to retrieve a segment, if the keys of all the previous level segments are known. For e.g., if the key values of CUSTOMER, SHIPTO and RECVABLE segments are known, then they can be concatenated in the order of the level, to issue the DL/I call. If the key value of any of the intermediate segment is not known then the C command code cannot be used.

D command code :
Normally, when a DL/I call is issued then, only the lowest level segment contents are retrieved and put in the I/O area. By using D command code even the contents of those segments which are at the higher level are also moved to the I/O area.

F and L command codes :

The F and L command codes are used in unqualified SSAs for locating the first and last twin occurrence of a segment type.

N command code :
When a DL/I call is issued with D command code and later try to replace the segment then, all the segments in the hierarchy are replaced. To avoid the replacement of segments which are up in the hierarchy, N command code is used. Thus, by using N command code the replacement of a segment can be suppressed.

P command code :
Generally, when a DL/I call is issued to retrieve a segment, the parentage is established at the lowest level segment that is retrieved. By using P command code, this can be overridden and parentage can be established at a higher level segment in the hierarchy.

Q command code :
The Q command code is used only when multiple applications concurrently access the same data base. It directs IMS to enqueue a segment occurrence to prevent other users from retrieving it using Get-Hold Calls. When the Q command code is set at the root segment level, no other users are allowed to gain access to any segment in that data base record. When it is set at a segment lower in hierarchy, no users are able to retrieve the segment using a Get-Hold call for that segment occurrence, but they can retrieve it using no-Hold calls. This command code is of much use when a program is written in an interactive environment.

19

U and V command codes :

The U and V command codes provide similar functions. When an unqualified SSA with U command code is specified, DL/I restricts the search for the requested segment to the dependents of the segment with U command code. When a V command code is used at any hierarchical level, its effect is same as if U command codes are specified at that level and all levels above it in the hierarchy.

DL/I FUNCTION CODES:

The DL/I function codes may broadly be classified into 3 types. They are : RETRIEVAL CODES GU GET UNIQUE GN GET NEXT GNP GET NEXT WITHIN PARENT UPDATION CODES ISRT INSERT DLET DELETE REPL REPLACE GET-HOLD CODES GHU GET-HOLD UNIQUE GHN GET-HOLD NEXT GHNP GET-HOLD NEXT WITHIN PARENT

20

RETRIEVAL OF INFORMATION:
Retrieval of information from an IMS database can be done in two ways. RANDOM RETRIEVAL GU & GHU FUNCTION CODES ARE USED SEQUENTIAL RETRIEVAL GN, GNP, GHN AND GHNP FUNCTION CODES ARE USED

RANDOM RETRIEVAL : ( GU CALL )

Random processing using DL/I is similar to random processing with standard files. GU function code is used for random processing. The GU call establishes the parentage at lowest level segment in the hierarchy.

A GU call without SSAs :

When a GU call is issued without an SSA, then DL/I assumes an unqualified SSA for the root segment and therefore, retrieves the first occurrence of the root segment. In the CUSTOMER database, the first occurrence of the CUSTOMER segment i.e. the C1 segment, is retrieved.

A GU call with unqualified SSAs :

An unqualified SSA with the GU function code indicates to DL/I that we are interested in the first occurrence of that segment type in the database.

a)

Suppose, a GU call is issued on the CUSTOMER segment with an unqualified SSA as shown below. Lets see what happens
GU CUSTOMER .

Note that a blank is left over after the segment name CUSTOMER. When such a call is issued, DL/I retrieves the first occurrence of the CUSTOMER segment type in the CUSTOMER database i.e the C1 segment is retrieved.

b)

Now, lets see what happens when a DL/I call as the following one is issued,
GU CUSTOMER SHIP-TO RECVABLE

DL/I retrieves the first occurrence of the RECVABLE segment i.e. the R1 segment, under the first occurrence of the SHIPTO segment i.e. the S1 segment, under the first occurrence of the CUSTOMER segment i.e. the C1 segment.

21

A GU call with qualified SSAs :

When we know exactly which segment occurrence is to be retrieved, i.e. the key is known, then fully qualified SSAs can be used.

a)

Suppose, the customer whose number is DV0001 is to be retrieved, then the GU call is issued as follows :
GU CUSTOMER(CUSTNUM =DV0001)

b) Similarly, to retrieve the SHIPTO segment where the shipto sequence num is 01 for the customer DV0001, a GU call can be issued as follows :
GU CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

Combination of qualified and unqualified SSAs :

Qualified and unqualified SSAs can be combined, in any way, while issuing a GU call. The way DL/I handles such calls depend on the level at which unqualified SSAs are coded. Lets see what would be the effect of the following GU calls : a) GU CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

RECVABLE
In this case, the first RECVABLE segment i.e. segment R1, under the SHIPTO segment whose sequence no is 01 which is under customer DV0001, is retrieved. b) GU CUSTOMER SHIPTO RECVABLE(RSINVNUM=123456)

In this case, DL/I scans CUSTOMER and SHIPTO segments from the begining of the database, and finally reaches the RECVABLE segment, if any present, whose invoice num is 123456 for those CUSTOMER and SHIPTO segment values. From this it is evident that such GU calls are very expensive.

Missing hierarchical levels :

It is possible to make retrieval calls without supplying SSAs for each level in the hierarchy above the segment, like the one given below : GU RECVABLE(RSINVNUM=123456) If such call is issued, then DL/I assumes unqualified SSAs for each of the segment up in the hierarchy above. Thus, above call is equivalent to : GU CUSTOMER SHIPTO RECVABLE(RSINVNUM=123456)

22

GU call with command codes : Using C command code : GU CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

The C command code is used when the full key of a segment is known. Instead of specifying CUSTOMER and SHIPTO key values seperately, as shown above, both key value can be concatenated and can be given in GU call with C command code as shown below. GU SHIPTO *C(DV000101) Note that the all the key values are concatenated together. For this, the SSA may be coded in the working-storage section of the program like this:

01 CON-SHIPTO-SSA.
05 05 05 05 FILLER PIC X(9) value SHIPTO *C(. CUSTOMER-KEY-VAL PIC X(6). SHIPTO-KEY-VAL PIC X(2). FILLER PIC X VALUE ).

Using D command code : Generally the details of last segment are retrieved into the I/O area. Using D command code, the details of the parent segments can also be retrieved into the I/O area. The example shown below retrieves both the segment details into the I/O area. GU CUSTOMER*D(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

Note here that the D command code is not specified for SHIPTO segment, since anyway DL/I retrieves the SHIPTO segment. Since, more than one command code can be specified for an SSA, a GU call along with C command code can also can be issued as follows : GU SHIPTO *CD(DV000101) This call also has the same effect as the previous call. F and L command codes : A GU call with F or L command codes with a fully qualified SSA is meaningless. But, they can be used to retrieve the first or last occurrences of a segment as follows : GU CUSTOMER (CUSTNUM =DV0001) SHIPTO *L

By issuing a GU call as the one above, the last segment occurrence of SHIPTO segment under the CUSTOMER segment whose customer num is DV0001 is retrieved. Similarly, F command code can be used to retrieve the first occurrence of a segment.

23

Using P command code : Since, the GU call establishes the parentage at the lowest level segment in the hierarchy, to set the parentage at any other segment up in the hierarchy, a P command code is used. For example : CUSTOMER*P(CUSTNUM =DV0001) SHIPTO In the above case, the parentage is established at the CUSTOMER segment. GU

SEQUENTIAL RETRIEVAL : ( GN and GNP CALLs ) :

The GN and GNP function codes are used for sequential processing. The differrence between these function codes are as follows : GN call establishes the parentage at the lowest level segment. Where as the GNP call doesnt establish the parentage. The GN call retrieves the next segment occurrence in the database.( In this case the segment type may change.) Where as the GNP call retrieves only the segment occurrence that are under the parent segment. Before issuing a GNP call, a GU or GN call must be issued to establish the parentage. There is no such restriction for issue of GN call.

GN call without SSAs :

When a GN call is issued without an SSA, then DL/I retrieves the next segment occurrence in the database from the current position. Thus, if the call is the first call issued then, DL/I retrieves the first CUSTOMER segment occurrence, which is the root segment, in the database. (i.e. the C1 segment which is the first segment occurrence.) Subsequent GN calls retrive the other segment occurrences in the database. Thus, DL/I retrieves the segments C1, S1, B1, B2, S2, C2 etc., in that order until end of the database.

24

a)

Step1 : Step2 :

GU SHIPTO GN

In Step1 the first SHIPTO segment i.e. S1 segment, is retrieved. The GN call in Step2 retrieves the B1 BUYER segment, which is the next segment occurrence after the S1 segment. The next GN call will retrieve the B2 Buyer segment and the next GN call retrieves the the R1 RECVABLE segment, and so on.

A GN call with unqualified SSAs :

When an unqualified GN call is issued, DL/I would retrieve the first occurrecne of that segment type in the database, if the call is the first one issued in the program. Thus, the following GN call would retrieve the first SHIPTO segment occurrence i.e. S1 segment. GN SHIPTO If the above GN call is issued repeatedly, then all the SHIPTO segment occurrences in the database are retrieved one after the other from the current position, i.e. the segments S1, S2, S3 and S4.

A GN call with qualified SSAs :

A GN call with qualified SSA has the same effect as that of a GU call with qualified SSA. The following two calls retrieve the same segment. GU GN CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01) CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01) and

Both the calls retreive the same SHIPTO segment.The difference between the GU and GN calls with qualified SSAs is that GN call is used to perform skip-sequential-processing. When skip-sequential processing is performed, DL/I selects segment occurrences in hierarchical sequence. i.e. in the key sequence. For the GN call shown below, DL/I retrieves the the SHIPTO segment which has sequence num as 02. GN CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=02)

Now, for one more GN call issued, which is shown below, DL/I gives a GE error status indicating that the required SHIPTO segment doesnt exist, though it is very much existing. This is because, the key value specified in the second call is not in the key sequence. It can be said that, if a GN call is issued with a key value lower than the one specified in the previous call, DL/I cannot retrieve the segment. Remember that IMS stores the segments in the increasing key value sequence. When using GU call, IMS backs up in the database, if necessary, to locate the segment. GN CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

25

Combining qualified and unqualified SSAs : GN CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

RECVABLE
For the above GN call, IMS retrieves the first RECVABLE segment occurrence under the SHIPTO segment whose sequence num is 01.

GNP call without SSA :

a) Step1 : GU CUSTOMER(CUSTNUM =DV0001) Step2 : GNP

The GU call establishes the parentage. The subsequent GNP call retrieves the segment which is the child segment of CUSTOMER. If Step2 is repeated, all the segments under CUSTOMER (DV0001) are retrieved sequentially. Thus, the segments S1, B1, B2, R1, P1, P2, A1, A2, L1, L2, R2, R3, A3 and S2 are retrieved sequentially.

GNP call with SSAs :

a) A GNP call with SSA retrieves only the segments of a specific type under the segment at which the parentage is established. Consider the following steps : Step1 : GU CUSTOMER(CUSTNUM =DV0001) Step2 : GNP SHIPTO DL/I retrieves only the SHIPTO segments under the CUSTOMER segment having num DV0001. b) Step1 : GU CUSTOMER(CUSTNUM =DV0001) Step2 : GNP SHIPTO (SHPTOSEQ=01) RECVABLE(RSINDATE=010194)

In the above example Parentage is set at CUSTOMER segment. Generally GNP call retrieves the next available segment of that parent. Since qualified SSA is given for the GNP call, it retrieves the specific segment under that parent.

26

GN and GNP calls with command codes :

D command code : To, retrieve the CUSTOMER segment also along with SHIPTO segment, the D command code is used as follows : GN CUSTOMER*D(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

Similarly, CUSTOMER and SHIPTO segments can be retrieved along with RECVABLE segment, as follows : GN CUSTOMER*D(CUSTNUM =DV0001) SHIPTO *D(SHPTOSEQ=01)

RECVABLE
N command code : The N command code has no effect if used with a GN call. DL/I simply ignores it. Thus, a GN call as follows behaves as if only a D command code is used : GN CUSTOMER*DN(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

F and L command codes : The F and L command code retrieve the first or last segment occurrence. Consider the following two calls. One is a GN call and the other is a GNP call. GN CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

RECVABLE*L
and GNP CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

RECVABLE*L
In both the above calls the last RECVABLE segment occurrence, i.e., R3, is retrieved. The only difference is that In case of the GN call the parentage is established at the R3 segment and when the GNP call is issued the parentage is not set at R3 instead parentage remains at the same location where it was earlier. P command code : All the SHIPTO segment occurrences under CUSTOMER DV0001 can be retrieved by issuing a GU call for CUSTOMER and then a series of GNP calls for SHIPTO segment, as follows : Step1 : Step2 : GU GNP CUSTOMER(CUSTNUM =DV0001) SHIPTO

No doubt that the above steps retrieves all the SHIPTO segments. Since, any DL/I call is expensive, if at least one call can be avoided it is better to avoid. The P command code can be used for this purpose as follows :

27

Step1 : Step2 :

GU CUSTOMER*P(CUSTNUM =DV0001) SHIPTO GNP SHIPTO

Thus, one DL/I call is avoided. The P command code is used at CUSTOMER segment as that is the place where the parentage needs to be established. U and V command codes : The U and V command codes provide control over moving forward in the database when issuing GN or GNP calls. They can be used to prevent a GN or GNP call from leaving the current position. Suppose if all the RECVABLE segments for each SHIPTO segment under CUSTOMER DV0001 are to be retrieved. The following is one possible call sequence. Step1 : GU CUSTOMER(CUSTNUM =DV0001) Step2 : GNP SHIPTO Step3 : GNP RECVABLE (Step2 and Step3 are to be repeated until end of database) The above sequence wouldnt work. When the GNP call in Step2 is issued first time then the S1 segment occurrence is retrieved. Now when GNP calls are issued repeatedly for RECVABLE segment, the segments R1, R2, R3 and R4 segments are retrieved. Note that R4 doesnt belong to S1 but it belongs to S2. As per the requirement, S1 and its depends and then S2 and its dependents and so on are to be retrieved in sequence. Thus, by issuing the above sequence of calls, segments cannot be retrieved as required. To achieve this a qualified GNP call for SHIPTO segment, in Step3, can be issued as follows : Step1 : Step2 : Step3 : GU CUSTOMER(CUSTNUM =DV0001) GNP SHIPTO GNP SHIPTO (SHPTOSEQ= RECVABLE

The key value of SHIPTO segment is moved into the SSA for SHIPTO of the GNP call, after Step2, which is available in the PCB. A better way is to use U command code in the third step, as follows : Step1 : Step2 : Step3 : GU CUSTOMER(CUSTNUM =DV0001) GNP SHIPTO GNP SHIPTO *U RECVABLE

Using U command code in the SHIPTO SSA has the same effect as a qualified SSA for that particular segment occurrence.

28

If the ADJSTMNT segments are also to be retrieved along for each RECVABLE segment, then one more GNP call may be issued as follows : Step1 : Step2 : Step3 : Step4 : GU CUSTOMER(CUSTNUM =DV0001) GNP SHIPTO GNP SHIPTO *U RECVABLE GNP SHIPTO *U RECVABLE*U ADJSTMNT

In Step4 U command code is used for SHIPTO and RECVABLE segments. Instead of specifying U command code at all the levels the V command code can be used only once with RECVABLE segment as follows : Step1 : Step2 : Step3 : Step4 : GU CUSTOMER(CUSTNUM =DV0001) GNP SHIPTO GNP SHIPTO *U RECVABLE GNP RECVABLE*V ADJSTMNT

Status Code Check after GU call:

Following each retrieval call, the status of the call whether successful or not needs to be checked. There is a two-position field in the PCB called status code field. It keeps track of what happened as a result of the call. When GU call is used to retrieve segments to an existing database, the status codes for the following codes needs to be checked. Blank indicates that the retrieval call is successful. Return Status GE indicates that the segment could not be found. (Blank), GE.

Status Code Check after GN call:

When GN call is used to retrieve segments to an existing database, the status codes for the following codes needs to be checked. GA, GK, GB. (Blank), GE,

Blank indicates that the retrieval call is successful. Return Status GE indicates that the segment could not be found. In scanning though the database sequentially, a program normally test for the GB status code to find out when the end of the data base has been reached. If the program issues another call after the GB status code has been returned, IMS goes back to the beginning of the database. When a program issues unqualified Get-Next calls, it can test for the GA and GK status codes to help determine which segment type has been retrieved. When a call retrieves a segment at a higher level, IMS returns a status code of GA. If the call retrieves a segment of a differrent type, but at the same level, IMS returns a status code of GK.

29

DATABASE UPDATIONS:
Following function codes are used for database updations : ISRT DLET REPL Inserting a segment Deleting a segment Replacing a segment

Inserting a segment : (ISRT call)

The ISRT call is used to add a segment occurrence to a database. It can be used either for loading a new database or for inserting a segment into an existing database. There should be at least one SSA, an unqualified SSA, for the segment type that needs to be inserted. But, unless the call is fully qualified, DL/I uses the current position in determining where to insert a segment. Suppose, if a RECVABLE segment is to be inserted under the SHIPTO segment whose sequence num. is 01 which is under the CUSTOMER with num. DV0001, the ISRT call may be issued as follows : Step1 : Step2 : GU CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01) ISRT RECVABLE

The GU call in Step1 is issued to set the parentage at SHIPTO segment. Then the ISRT call is issued with an unqualified SSA. The segment that is to be inserted must always be identified with an unqualified SSA. If the SSA for the final segment, in the ISRT call, that is being inserted is qualified, DL/I gives an error. Thus, the RECVABLE segment can also be inserted as follows. ISRT CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

RECVABLE
where the RECVABLE segment is left unqualified. If the ISRT call is issued as the one above then there is no need to issue a GU or GN call for establishing the parentage. IMS knows whether the program is going to load a database from scratch or insert segments into an existing database from the processing options specified in the PCB. PROCOPT=L, allows the program to issue Insert calls in the load mode to load a database from scratch. A value LS allows the program to issue Insert calls in the load mode and indicates that segments must be loaded in ascending sequence. Value A allows the program to issue Get, Insert, Replace and Delete calls. Value AS allows the program to issue Get, Insert, Replace, Delete calls and indicates that new segments must be inserted in ascending sequence. With values A and AS, insert calls can only be used to insert segments into an existing database. Value I indicates that only Insert calls in the insert mode can be issued. Value IS indicates that only insert calls in the insert mode are allowed, and those segments must be in ascending sequence.

30

Segments with non-unique key or no key :

If the new segment has a unique sequence field, it is added in its proper sequential position. In some cases the lower level segment types in the database may not be having any key field. In some cases the key field may not be unique. In any one of these situations, there are some procedures to be followed. The Segment type definition, SEGM statement, must contain information that tells IMS where to insert new occurrences of that segment type. The RULES parameter of the SEGM statement is used for this purpose. SEGM NAME=BUYER,PARENT=SHIPTO,BYTES=72, RULES=FIRST The three available options for coding the RULES operand are FIRST, LAST, and HERE. This parameter, which is called as insert rule, tells IMS where in the twin chain to insert a new segment when a segment does not have a unique key field. The insert rule FIRST indicates that new segments are inserted at the beginning of the twin chain. The insert rule LAST indicates that new segments are inserted at the end of the twin chain. LAST is the default if no rules operand specified. The Insert rule HERE indicates that the new segments are inserted in the current position. A new segment is inserted just before the segment on which current position is established. Note that with some limitations, F and L command codes will override the rules specified for segment insertion by the data base administrator. The possible combinations are : 1. F and L command codes can override a rule of Here. 2. Command code L can override a rule of First. 3. Changing First to Here and overriding Last are not possible. Though the position specified by insert rules is transparent to the user, it is advisable for the user to know these definitions, so that the DL/I calls can be coded effectively.

Status Code Check :

Following each ISRT call, the status of the call whether successful or not needs to be checked. There is a two-position field in the PCB called status code field. It keeps track of what happened as a result of the call. When ISRT call is used to add segments to an existing database, the status codes for the following codes needs to be checked. (Blank), GE, II. Blank indicates that the insert call is successful. Return Status II indicates that the segment occurrence tried to add is already existing i.e., duplicate. When multiple SSAs are used and when the DL/I cannot satisfy the call with the specified path, a status code GE is returned, which means at least one of the segment occurrences requested is not present. When ISRT call is used to load the database, the status code check should include the following codes. (Blank), LB, LC, LD, LE. Blank indicates that the insert call is successful. Status code LB indicates that the program tried to load the same segment twice. Status code LC indicates that the segments being loaded are not in hierarchical sequence. The status code LD indicates that no parent for segment being loaded. The status code LE indicates that the segment types are not being presented to the program in the right sequence.

31

GET HOLD CALLS :

If at all, the data of a segment needs to be modified or deleted, the details needs to be retrieved with a hold on the segment occurrence, so that no other person can do the similar operation on that. To achieve this there are three function codes for the Get-Hold retrieval calls. They are GHU GHN GHNP - Get-Hold-Unique - Get-Hold-Next - Get-Hold-Next-within-Parent

The above three function codes perform similar functions as that of the three retrieval calls (GU, GN, GNP). The Get-Hold-Unique call corresponds to the Get-Unique call, the Get-Hold-Next call corresponds to the Get-Next call, and Get-Hold-Next-within-Parent call corresponds to Get-Next-within-Parent call. The Get-Hold call brings the segment occurrence into the I/O area and also causes IMS to save information about the segment. The program can then examine the segment image in I/O area and decide whether the segment occurrence needs to be deleted or replaced. No other calls are allowed that reference the same PCB, between the time that the program issues the Get-Hold call and the time that it issues the Delete or Replace call. If the program issues a call other than a Delete or Replace, that call nullifies the effect of the Get-Hold call and the program is then not allowed to issue a Delete or Replace call until another Get-Hold call is issued. The same types of SSAs are used with Get-Hold calls as are used with non-hold Get calls. The status codes that IMS returns are also identical. The only difference between Get-Hold calls and Get calls is that with Get-hold calls the program is allowed to follow the call with a delete or replace call. Following a non-hold get call with a delete or replace is not allowed.

General Rules to be followed for DLET and REPL Calls :

There are four general rules, needs to be followed before deleting or replacing any segment occurrence. They are : 1. The DLET or REPL call needs to be preceded by Get-Hold call which brings the segment occurrence into the I/O area and also causes IMS to save information about the segment. 2. No other calls are allowed that reference the same PCB, in between the Get-Hold call and Delete or modify call. 3. No SSAs to be included, when issuing a call with the DLET or REPL function code. The only exception to this rule is a delete or replace call following a get-hold call that specifies one or more SSAs using the D command code. The D command code causes more than one segment to be brought into the I/O area with a single call. 4. The program is not allowed to modify the key field of the segment image in the I/O area.

32

Deleting a segment : (DLET call)

The DLET call is used to delete a segment occurrence from the database. This has to be preceded by a successful Get-Hold call. Suppose, if a RECVABLE segment is to be deleted which is child of SHIPTO segment whose sequence num. is 01 which is under the CUSTOMER with num. DV0001. The DL/I calls to achieve this requirement is : Step1 : GHU CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

RECVABLE (RSINVNUM=R00001)
Step2 : DLET The GHU call in Step1 is issued to bring the RECVABLE segment into the I/O area. Then the DLET call is issued with an unqualified SSA. As because the GHU call mentioned above is not a path call, only RECVABLE segment is retrieved with a hold into the I/O area. Note that the DLET function, deletes RECVABLE segment along with its child segment occurrences, if any are present. If the get hold call that immediately precedes a delete is a path call, then the delete operates on the entire path. Once the path call is issued, the entire path can be deleted by simply issuing the delete call. Alternately the scope of delete can be limited, by supplying one unqualified SSA without command code. The segment that the unqualified SSA names will be deleted, along with all of its dependents. However segments above it along the path retrieved will remain in the database.

Status Code Check :

When DLET call is issued to delete segment occurrences of a database, the status codes for the following codes needs to be checked. DA. (Blank), DJ,

Blank indicates that the delete call is successful. Return Status DJ indicates that the program has issued a delete call without a preceding Get-Hold call. The DA status code is returned, if the key field of the segment image in the I/O area is changed before the program issues the Delete call.

Replacing a segment : (REPL call)

The REPL call is used to update the segment occurrence of the database. This has to be preceded by a successful Get-Hold call. Once the segment is in the I/O area, the program can make any desired changes other than modifying the key field. Suppose, if a SHIPTO segment is to be modified. The following is the DL/I call sequence required to this task. Step1 : Step2 : GHU CUSTOMER(CUSTNUM =DV0002) SHIPTO (SHPTOSEQ=02) REPL

After retrieving the desired SHIPTO segment with the Get-Hold call and making the necessary changes to the segment image in the I/O area, the program then issues a call using the REPL function code.

33

When a program uses a Get-Hold path call to bring more than one segment into the I/O area, the Get-Hold path call can be followed by a replace call that references one or more SSAs. When multiple segments are retrieved using a Get-Hold path call and a Replace call is issued with no SSAs, all the retrieved segments are replaced. The Replace call can reference SSAs that include the N command code to indicate which segments are not to be replaced.

Status Code Check :

When REPL call is issued to delete segment occurrences of a database, the status codes for the following codes needs to be checked. DA. (Blank), DJ,

Blank indicates that the replace call is successful. Return Status DJ indicates that the program has issued a replace call without a preceding Get-Hold call. The DA status code is returned, if the key field of the segment image in the I/O area is changed before the program issues the replace call.

MULTIPLE POSITIONING :
IMS provides two options for keeping track of position within a database: single positioning and multiple positioning. One and only one of these options is specified in the PCB statements of PSB. Note that single positioning or multipositioning is not a characteristic of a database, but it is how DL/I allows a program to view a database. The same data base can be processed with either single or multiple positioning by different programs, which technique a program uses is determined by the programs PSB. In terms of DL/I resource usage, theres practically no performance difference between the two types of positioning. PRINT PCB SENSEG SENSEG SENSEG SENSEG PSBGEN END NOGEN TYPE=DB,DBDNAME=CUSTDBD,KEYLEN=30,PROCOPT=A, POS=S NAME=CUSTOMER NAME=SHIPTO,PARENT=CUSTOMER NAME=RECVABLE,PARENT=SHIPTO NAME=PAYMENT,PARENT=RECVABLE PSBNAME=CUSTPSB,LANG=COBOL

The above PCB shows a situation where the single positioning option has been specified. Note that POS=S indicates single position. This can be made as multiple positioning by changing POS parameter to M. PRINT PCB SENSEG SENSEG SENSEG SENSEG PSBGEN END NOGEN TYPE=DB,DBDNAME=CUSTDBD,KEYLEN=30,PROCOPT=A, POS=M NAME=CUSTOMER NAME=SHIPTO,PARENT=CUSTOMER NAME=RECVABLE,PARENT=SHIPTO NAME=PAYMENT,PARENT=RECVABLE PSBNAME=CUSTPSB,LANG=COBOL

Single positioning allows IMS to maintain only one current position, and that position is always last hierarchical path referenced. When operating in the multiple position mode, IMS maintains a separate position for each dependent segment type at each level in the data base.

34

Consider the Logical view of the Customer Database shown below. Also Assume that there is a one-to-one relationship between ADJUSTMENT, PAYMENT, LINEITEM. To retrieve these segments, not being particular about the sequence of the segments, the following Get-Unique call followed by a series of Get-Next-Within-Parent calls accomplishes the retrieval.
LOGICAL VIEW OF CUSTOMER DATABASE

CUSTOMER

SHIP-TO

RECEIVABLE

PAYMENT

ADJUSTMENT

LINE ITEM

Step1 :

GU CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

RECVABLE (RSINVNUM=R00001)
Step2 : GNP With the above call all PAYMENT segments are retrieved first, followed by all the ADJSTMNT segments followed by LINEITEM segments. If one-to-one relationship between the segments needs to be maintained (While retrieving), the above call sequence is not appropriate. It would be better to retrieve a PAYMENT segment, followed by its corresponding ADJSTMNT segment, followed by the corresponding LINEITEM segment. Consider the call shown below.

35

Step1 :

GU CUSTOMER(CUSTNUM =DV0001) SHIPTO (SHPTOSEQ=01)

RECVABLE (RSINVNUM=R00001)
Step2 : GNP PAYMENT Step3 : GNP ADJSTMNT Step4 : GNP Step5 : ......... GNP LINEITEM PAYMENT

In the above call sequence, the set of Get-Next-Within-Parent calls retrieve set of PAYMENT, ADJSTMNT, LINEITEM first time. If IMS is maintaining single position within a database, the Steps 2, 3, 4 works fine. But Step 5 returns a GE status code indicating that there are no more PAYMENT segments under the parent. This is because, Step 4 keeps the pointer position at first LINEITEM, which is later in the hierarchy (After all Payment and Adjustment segments, then comes, first Lineitem segment). To retrieve the second PAYMENT segment, IMS has to remember the position of the previous PAYMENT segment retrieved. To achieve this requirement, Multiple Positioning is the correct choice. Once the multiple positioning is defined, the CUSTOMER database three hierarchical paths are considered as independent. They are as shown below.
Three Hierarchical Paths in the Customer Database Path1 Path2 Path3

CUSTOMER

CUSTOMER

CUSTOMER

SHIP-TO

SHIP-TO

SHIP-TO

RECEIVABLE

RECEIVABLE

RECEIVABLE

PAYMENT

ADJUSTMENT

LINE ITEM

36

If multiple position is being used and a PAYMENT segment is retrieved on a call to the CUSTOMER database, then IMS saves the keys of the segments in Path 1 of the figure shown above as the current position. If a LINE ITEM segment is retrieved on the next call, then IMS will save the current position in Path 3. Further more, if a ADJUSTMENT segment is retrieved on a third call, then IMS will also save the current position in Path 2. At this point IMS would be maintaining a current position in each of the three hierarchical paths. In other words, if multiple positioning is being used, current position in a given hierarchical path is not lost by subsequent retrievals in different paths. GN and GNP calls always proceed forward from the Current position. Under multiple positioning, each hierarchical path may have its own current position. Thus, a search to satisfy a GN or GNP call still proceeds in a forward direction, but it proceeds from the last position in the specified hierarchical path. GU and ISRT calls are affected by multiple positioning only if missing SSA levels must be implied by IMS. The rules of implication for multiple positioning are the same as those for single positioning. Since the rules for implied SSAs depend on current position and there is a current position for each hierarchical path, caution should be taken to ensure that the desired parent segments will be implied. DLET and REPL calls are not directly affected by multiple positioning. They are, however indirectly affected by Get Hold calls.

37

Advantages of Multiple Positioning : 1. Greater degree of Data Independence :

The use of multiple positioning allows the programmer to code programs which are insensitive to the order of segment types at a given hierarchical level. As shown above, program can issue calls for PAYMENT, ADJUSTMENT and LINEITEM segments in any desired order. In other words, multiple positioning allows programs to be written so that major changes to the physical structure of a database (such as changing the left to right order of segment types on a given level) do not necessitate the rewriting of these programs.

2.

Parallel Processing :

The use of multiple positioning allows parallel processing of different segment types on a given hierarchical level. Consequently, it is possible to process ADJUSTMENTsegments, PAYMENTS segments, LINEITEM segments, and then return to process more ADJUSTMENT segments without losing current position in any of the separate hierarchical paths.

MULTIPLE PCBs :
Another method of maintaining position in more than one place in a given database is through the use of multiple PCBs. One PCB is defined for each unique position the programmer wishes to maintain. Also a program may require access to two different logical data structures, each describing different segments in the same database. Thus the programs PSB may contain more than one PCB for the same database. In COBOL program ENTRY statement normally includes a parameter for each PCB statement included in the PSB. The parameters must be coded in the same order in which the PCBs appear in the PSB. Figure below shows COBOL coding to access three PCBs.

LINKAGE SECTION.
01 PCB-1. 03 DATA-BASE-NAME 03 CURRENT-SEGMENT-LEVEL 03 STATUS-CODE 03 DLI-PROCESSING-CODE 03 RESERVED-FOR-DLI 03 SEGMENT-NAME-FEEDBACK 03 LEN-OF-CONCATENATED-KEY 03 NUMBER-OF-SENSITIVE-SEG 01 PCB-2. ......... ........ PIC PIC PIC PIC PIC PIC PIC PIC X(08). X(02). X(02). X(04). S9(09) COMP. X(08). S9(09) COMP. S9(09) COMP.

PROCEDURE DIVISION.
ENTRY .......... .......... DLITCBL USING PCB-1 PCB-2.

38

Multiple Positioning VS Multiple PCBs :

Multiple positioning is a means of maintaining more than one position in a database. The use of multiple PCBs extends the capabilities of multiple postioning. When multiple positioning is used, IMS maintains a position in each hierarchical path. However, if it is necessary to maintain two positions in the same path, then multiple positioning is not adequate. Since a PCB allows a unique and independent position to be maintained, multiple PCBs could be employed to maintain more than one position in a given hierarchical path. The multiple positioning method is limited to a single database record. If all the positions to be maintained are not within the same database record, then multiple positioning is not sufficient. But if multiple PCBc are used, IMS can use each PCB to maintain a position which is not dependent on any other position. Thus, simultaneous position in several database records is possible using multiple PCBc for the same database. Multiple PCBs may be used in place of multiple positioning in any application. To accomplish this, one PCB is required for each hierarchical path in the database.

39

FAST PATH DATA BASES:

Fast path is an optional feature of IMS that is specifically designed for certain types of on-line system. The fast path feature is available only with IMS DC, not with IMS batch or DL/I with CICS. The processing carried out on behalf of one input message to is called a transaction. Although individual transactions themselves may be very simple, the system may be required to handle a very high transaction rate, say several thousand transactions a minute. The Fast Path feature is intended for applications having high transaction rate, comparatively simple database processing. The fast path feature provides both special data communications facilities and two special data base structures, the Main Storage database (MSDB) and the Data Entry database (DEDB). Main storage and data entry databases have a simpler structure than other IMS databases and provide better performance for certain kinds of operation. Data entry database is a restricted form of hierarchy that is kept on secondary storage in the usual way but is partitioned into area for enhanced availability and other reasons.

MAIN STORAGE DATABASE :

Main storage database is a root-only database that is kept in main storage throughout system operation. Small tables of reference information-for example timetables, currency conversion tables, interest rate tables are good candidates for implementation of MSDB. It has another good facility i.e., update performance. Data base updates are not made immediately after each update call. Instead, all updates requested by a given application program are performed at one time, ie., after synchronization point has been reached. In the message processing program, a synchronization point occurs each time the program issues a get-unique call to the I/O PCB. In a batch program, a synchronization point is reached each time the program issues an IMS SYNC call. There are two different types of MSDB that can be used. These are terminal related MSDBs and non-terminal related MSDBs. The fast path feature provides an additional call that can be used to update data in an MSDB segment occurrence. The field call is used to update the data in a specific field in an MSDB segment occurrence. The normal method used to update a segment occurrence is to retrieve it using a Get-hold call, thus preventing other users from accessing the segment. The segment is then updated and the lock on the record is removed. In order to increase performance, the field call allows several users to access the same MSDB segment occurrence at the same time by allowing applications to update the segment occurrence at the field level.

Terminal Related MSDB:

In a terminal related MSDB, each segment occurrence in the data base is owned by a specific logical terminal. The key of each MSDB record occurrence consists of the logical terminal name of its owner. However, the logical terminal name does not reside in the segment occurrence itself; the logical terminal name simply serves as the mechanism for locating individual segment occurrences in the MSDB. This arrangement is appropriate when each terminal requires its own dedicated storage area, an example is cash-issuing system, in which a record must be kept for each terminal of the cash on hand at that terminal.

40

In a fixed terminal-related MSDB, there is a separate segment occurrence in the database for each logical terminal. Occurrences cannot be inserted or deleted; they can be retrieved and updated only. In a dynamic terminal-related MSDB, an application program is allowed to insert and delete the segment occurrences that is related to the logical terminal invoking the program.

Non-Terminal-Related MSDB:
With a non-terminal-related MSDB, segment occurrences are not associated with specific logical terminals. A fast path application program can read and update any segment occurrence in the database. The key can be chosen in any desired manner by the DBA. The DBA can use the logical terminal name as a record key, in which case the logical terminal name does not reside in the segment itself. Alternately, the DBA can choose the key all or part of the segments sequence field.

DATA ENTRY DATABASE:

A data entry database is a more conventional type of database than an MSDB. It is structured in a similar manner to an HDAM database and is maintained in direct access storage rather than in main storage. However the characteristics of a data entry database make it well suited for highperformance applications that must provide very rapid response times. DEDB is best suited for storing databases that use a simple hierarchical structures. Although a DEDB behaves to the application program a similar manner to an HDAM data, its physical structure is quite different. In a conventional HDAM database, the entire logical data base structure is spread across the whole database. If multiple data sets are used, the structure is broken up on a segment basis, and parts of each data base record may be contained in multiple data sets. In DEDB, multiple data sets can be used, with each data set designated as an area. Each area contains segment occurrences of all types, and all segment occurrences that make up a given data base record are always stored in the same physical area. The area approach makes it possible for the DBA to implement very large data bases. Each area is independent of all other areas. If a failure occurs in one area, it can be taken out of service without affecting access to segment occurrences in the other areas.

41

SECONDARY INDEXING :
The secondary index in IMS can be used to index a given segment on the basis of any field in that segment or in any physical dependent of that segment. Generally the use of a secondary index is transparent to the application program. Given the existence of a secondary index, the user may process the corresponding data base in the secondary sequence defined by that index. If the index target segment is not the physical root, selecting the secondary sequence will cause a restructuring of the hierarchy, in particular, the index target segment will become the root in this restructuring. In the secondary sequence, the indexed field acts as the root segment sequence field. The user sees exactly as many data base records as there are segment occurrences containing the indexed field in the physical database. These records are sequenced in ascending order of that field. This resulting rearragement of the database structure is called a secondary data structure. A secondary index is implemented in the form of a self-contained data base that stores a series of pointers which point to segments in the data base being indexed. Note that the secondary index is a separate data base. So each secondary index is described as a separate DBD. The link between the secondary index database and main database is specified in the DBD. Secondary data structures dont change the way the data base segments are stored on the disk; they just alter the way DL/I presents those segments to application programs. The field on which the index is based may actually be a concatenation of up to five fields, not necessarily contiguous, taken in any order. A Source Segment is the segment from which the value used in the secondary index is taken. It may be a target segment or a physical dependent of the target. A Target Segment is the segment pointed to by a secondary index. It is the segment that will be retrieved when the index is used. A Pointer Segment is the segment in the Secondary Index database which contains the index value and a pointer to the target.

PSBGEN requirements for Secondary Indexing:

DL/I will not automatically use the secondary index in the program, unless the proper processing sequence for the database is specified on the PROCSEQ parameter of the PCB macro. If it is not specified, processing is done using the normal hierarchical sequence for the database. For the PROCSEQ parameter, the DBA codes the DBD name for the secondary index database that will be used. Further explanation of PSBs and how they look like is explained in the respective places of the following examples. The customer data base is considered to explain the secondary index concept. There are many possible secondary indexes that could be constructed for the data base. They are : 1. 2. 3. 4. Both source and target segments are root segments. Source segment is dependent and Target segment is Root. Both source and target segments are dependent segments of Same segment Both source and target segments are dependent segments, but they are of

type. different segment types.

42

1.

Both Source and Target Segments are Root Segments:

In the Customer DBD defined earlier, the customer segment is having unique key field as CUSTNUM, which means the CUSTOMER segment can be accessed in Ascending order of CUSTNUM sequence. To access the CUSTOMER segment in CUSTNAME sequence, can be done using the secondary index. In order to establish any secondary index, a DBD for that index is required together with entries in the DBD for the database being indexed to indicate the field the index is to be based on and other details. The index will then automatically be maintained as the database is subsequently updated. To define the secondary index, two additional statements in the DBD are required. LCHILD XDFLD NAME=(XCSTMER1,XCSTDBD1),POINTER=INDX NAME=XCSTNAME,SRCH=CUSTNAME

These two statements must appear together as shown in the CUSTDBD1 below. They may appear anywhere after the SEGM statement for the CUSTOMER, and before the next SEGM statement. In this example, the Source segment is CUSTOMER (CUSTNAME is a part of this segment), and CUSTOMER segment itself is the target segment. The LCHILD statement specifies that the CUSTOMER segment is indexed by the segment XCSTMER1 in the database defined in the DBD called XCSTDBD1 which defines the secondary index database. The POINTER=INDX entry specifies that the link between CUSTOMER and XCSTMER1 is really an index connection rather than a logical-child/logical-parent connection. The XDFLD statement specifies the field on which the secondary index is to be built. The DL/I call which forces IMS to use the secondary index in searching for the CUSTOMER with CUSTNAME RELIANCE PETROLEUM is GU CUSTOMER (XCSTNAME=RELIANCE PETROLEUM)

The GU will cause IMS to fetch the RELIANCE PETROLEUM index segment and then to fetch the CUSTOMER segment this index points to. Note that the retrieved segment is exactly as usual - specifically it does not include an extra field corresponding to XCSTNAME. The CUSTDBD1 is as follows: PRINT DBD DATASET SEGM FIELD FIELD LCHILD XDFLD FIELD FIELD ........ SEGM FIELD ........ NOGEN NAME=CUSTDBD1,ACCESS=HIDAM DD1=CUST1,DEVICE=3350 NAME=CUSTOMER,PARENT=0,BYTES=128 NAME=(CUSTNUM,SEQ,U),BYTES=6,START=1,TYPE=C NAME=CUSTNAME,BYTES=31,START=7,TYPE=C NAME=(XCSTMER1,XCSTDBD1),POINTER=INDX NAME=XCSTNAME,SEARCH=CUSTNAME NAME=CSTADD1,BYTES=31,START=38,TYPE=C NAME=CSTADD2,BYTES=31,START=69,TYPE=C NAME=SHIPTO,PARENT=CUSTOMER,BYTES=124 NAME=(SHPTOSEQ,SEQ,U),BYTES=2,START=1,TYPE=C

DBDGEN
FINISH END

43

The DBD for Secondary Index is as follows: PRINT DBD DATASET SEGM FIELD LCHILD DBDGEN FINISH END NOGEN NAME=XCSTDBD1,ACCESS=INDEX DD1=XCUST1,DEVICE=3350 NAME=XCSTMER1,PARENT=0,BYTES=128 NAME=(CUSTNAME,SEQ),BYTES=31,START=1,TYPE=C NAME=(CUSTOMER,CUSTDBD1),INDEX=XCSTNAME

The PSB required for this example is: PRINT PCB SENSEG SENSEG PSBGEN END NOGEN TYPE=DB,DBDNAME=CUSTDBD1,KEYLEN=30,PROCOPT=L, PROCSEQ=XCSTDBD1 NAME=CUSTOMER NAME=SHIPTO,PARENT=CUSTOMER PSBNAME=CUSTPSB1,LANG=COBOL

Note that PROCSEQ parameter is added to the PCB macro so that the program uses the secondary index defined. Also note that there will not be any change in the hierarchy. In other words, this secondary sequence will not cause the restructuring of the hierarchy of the data base.

2.

Source Segment is Dependent and Target Segment is Root:

The following DL/I call represents a possible solution to this problem: To find Customer numbers for all customers who have the SHIPCITY as BANGALORE. GN CUSTOMER*D SHIPTO (SHIPCITY=BANGALORE)

To get the required results following assumptions are to be made: Pointer is initially placed at the start of the database. Ignore the question of eliminating duplicate customer numbers from the result. In the above call SHIPTO segment is also retrieved, though it is not necessary. An efficient solution to this problem can be achieved using secondary index, indexing CUSTOMER segment on the basis of SHIPTO values. In which case SHIPTO segment becomes the Source segment and CUSTOMER segment is the Target segment. The CUSTDBD needs to be defined as shown below.

44

PRINT DBD DATASET SEGM FIELD FIELD FIELD .......... LCHILD XDFLD SEGM FIELD FIELD FIELD FIELD FIELD FIELD SEGM FIELD ........

NOGEN NAME=CUSTDBD2,ACCESS=HIDAM DD1=CUST2,DEVICE=3350 NAME=CUSTOMER,PARENT=0,BYTES=128 NAME=(CUSTNUM,SEQ,U),BYTES=6,START=1,TYPE=C NAME=CUSTNAME,BYTES=31,START=7,TYPE=C NAME=CSTADD1,BYTES=31,START=38,TYPE=C NAME=(XCSTMER2,XCSTDBD2),POINTER=INDX NAME=XSHPCITY,SEARCH=SHIPCITY,SEGMENT=SHIPTO NAME=SHIPTO,PARENT=CUSTOMER,BYTES=124 NAME=(SHPTOSEQ,SEQ,U),BYTES=2,START=1,TYPE=C NAME=SHIPADD1,BYTES=31,START=34,TYPE=C NAME=SHIPADD2,BYTES=31,START=65,TYPE=C NAME=SHIPCITY,BYTES=18,START=96,TYPE=C NAME=SHPSTATE,BYTES=2,START=114,TYPE=C NAME=SHIPZIP,BYTES=9,START=116,TYPE=C NAME=BUYER,PARENT=SHIPTO,BYTES=72 NAME=BUYRNAME,BYTES=31,START=1,TYPE=C

DBDGEN
FINISH END The DBD for Secondary Index is as follows: PRINT DBD DATASET SEGM FIELD LCHILD DBDGEN FINISH END NOGEN NAME=XCSTDBD2,ACCESS=INDEX DD1=XCUST2,DEVICE=3350 NAME=XCSTMER2,PARENT=0,BYTES=128 NAME=(SHIPCITY,SEQ),BYTES=18,START=1,TYPE=C NAME=(CUSTOMER,CUSTDBD2),INDEX=XSHPCITY

The secondary Index will contain one index segment for each SHIPTO occurrence in the customer database. Each such index segment will point to the corresponding CUSTOMER occurrence (the parent of the SHIPTO concerned). The secondary processing sequence for the customer database is defined by ascending values of SHIPTO segment. The PSB required for this example is: PRINT PCB SENSEG SENSEG SENSEG SENSEG PSBGEN END NOGEN TYPE=DB,DBDNAME=CUSTDBD2,KEYLEN=30,PROCOPT=L, PROCSEQ=XCSTDBD2 NAME=CUSTOMER NAME=SHIPTO,PARENT=CUSTOMER NAME=RECVABLE,PARENT=SHIPTO NAME=PAYMENT,PARENT=RECVABLE PSBNAME=CUSTPSB2,LANG=COBOL

45

Now the DL/I call can be written as

GN CUSTOMER (XSHPCITY=BANGALORE) In the above call, it looks as if XSHPCITY is a field within the CUSTOMER segment. Each Iteration of this code causes IMS to fetch the next index segment for BANGALORE and then to fetch the CUSTOMER segment that this index segment points to. Note that there will not be any change in the hierarchy. In other words, the secondary sequence will not cause the restructuring of the hierarchy of the data base.

3.

Both source and target segments are dependent segments :

(Same segment type)

Assuming an application that use the CUSTOMER database, requires direct access to receivable segments based on invoice number of RECVABLE segment. The existing structure forces us to go through the customer path to retrieve a RECVABLE segment. This can be avoided by defining a secondary index for it. CUSTOMER database needs to be indexed in sequence by invoice number - the sequence field not of the root segment, but of the RECVABLE segment. As a result this secondary index allows to access the RECVABLE segments in invoice number sequence. In this example the source segment is RECVABLE segment (RSINVNUM is a field of this segment) and, RECVABLE segment itself is the target segment. The CUSTDBD needs to be defined as shown below. PRINT DBD DATASET SEGM FIELD FIELD .......... SEGM FIELD LCHILD XDFLD FIELD FIELD FIELD .......... NOGEN NAME=CUSTDBD3,ACCESS=HIDAM DD1=CUST3,DEVICE=3350 NAME=CUSTOMER,PARENT=0,BYTES=128 NAME=(CUSTNUM,SEQ,U),BYTES=6,START=1,TYPE=C NAME=CUSTNAME,BYTES=31,START=7,TYPE=C NAME=RECVABLE,PARENT=SHIPTO,BYTES=57 NAME=(RSINVNUM,SEQ,U),BYTES=6,START=1,TYPE=C NAME=(XRECVBL1,XCSTDBD3),POINTER=INDX NAME=XINVNUM,SEARCH=RSINVNUM NAME=RSINDATE,BYTES=6,START=7,TYPE=C NAME=RSPONUM,BYTES=25,START=13,TYPE=C NAME=RSPRDTOT,BYTES=4,START=38,TYPE=P

DBDGEN
FINISH END The DBD for Secondary Index is as follows: PRINT DBD DATASET SEGM FIELD LCHILD DBDGEN FINISH END NOGEN NAME=XCSTDBD3,ACCESS=INDEX DD1=XCUST3,DEVICE=3350 NAME=XRECVBL1,PARENT=0,BYTES=57 NAME=(RSINVNUM,SEQ),BYTES=6,START=1,TYPE=C NAME=(RECVABLE,CUSTDBD3),INDEX=XINVNUM

46

The PSB required for this example is: PRINT PCB SENSEG SENSEG SENSEG SENSEG SENSEG SENSEG SENSEG PSBGEN END NOGEN TYPE=DB,DBDNAME=CUSTDBD3,KEYLEN=30,PROCOPT=L, PROCSEQ=XCSTDBD3 NAME=RECVABLE NAME=SHIPTO,PARENT=RECVABLE NAME=CUSTOMER,PARENT=SHIPTO NAME=BUYER,PARENT=SHIPTO NAME=PAYMENT,PARENT=RECVABLE NAME=ADJSTMNT,PARENT=RECVABLE NAME=LINEITEM,PARENT=RECVABLE PSBNAME=CUSTPSB3,LANG=COBOL

The Secondary index defined changes the apparent hierarchical structure of the database, as because when data is accessed using secondary index, the index target segment (RECVABLE) is presented to the program as if it were a root segment, even if it is not the root segment of the database. The Figure below shows the secondary data structure for the customer database when accessed by the secondary index.

Secondary Data Structure

RECEIVABLE

SHIP-TO

PAYMENT

ADJUSTMENT

LINE ITEM

CUSTOMER

BUYER

4.

Both source and target segments are dependent segments :

(Different segment types)

Assuming an application that uses the CUSTOMER database, requires direct access to receivable segments based on adjustment date of ADJSTMNT segment. For this example the Source Segment is ADJSTMNT segment and the Target segment is RECVABLE segment. Like in the previous example, the structure of the database is changed because of secondary index.

47

The CUSTDBD needs to be defined as shown below. PRINT DBD DATASET SEGM FIELD FIELD .......... SEGM FIELD LCHILD XDFLD FIELD FIELD FIELD .......... NOGEN NAME=CUSTDBD4,ACCESS=HIDAM DD1=CUST4,DEVICE=3350 NAME=CUSTOMER,PARENT=0,BYTES=128 NAME=(CUSTNUM,SEQ,U),BYTES=6,START=1,TYPE=C NAME=CUSTNAME,BYTES=31,START=7,TYPE=C NAME=RECVABLE,PARENT=SHIPTO,BYTES=57 NAME=(RSINVNUM,SEQ,U),BYTES=6,START=1,TYPE=C NAME=(XRECVBL2,XCSTDBD4),POINTER=INDX NAME=XADJDATE,SEARCH=AADJDATE NAME=RSINDATE,BYTES=6,START=7,TYPE=C NAME=RSPONUM,BYTES=25,START=13,TYPE=C NAME=RSPRDTOT,BYTES=4,START=38,TYPE=P

DBDGEN
FINISH END The DBD for Secondary Index is as follows: PRINT DBD DATASET SEGM FIELD LCHILD DBDGEN FINISH END NOGEN NAME=XCSTDBD4,ACCESS=INDEX DD1=XCUST4,DEVICE=3350 NAME=XRECVBL2,PARENT=0,BYTES=57 NAME=(AADJDATE,SEQ),BYTES=6,START=1,TYPE=C NAME=(RECVABLE,CUSTDBD4),INDEX=XADJDATE

The PSB required for this example is: PRINT PCB SENSEG SENSEG SENSEG SENSEG SENSEG SENSEG SENSEG PSBGEN END NOGEN TYPE=DB,DBDNAME=CUSTDBD4,KEYLEN=30,PROCOPT=L, PROCSEQ=XCSTDBD4 NAME=RECVABLE NAME=SHIPTO,PARENT=RECVABLE NAME=CUSTOMER,PARENT=SHIPTO NAME=BUYER,PARENT=SHIPTO NAME=PAYMENT,PARENT=RECVABLE NAME=ADJSTMNT,PARENT=RECVABLE NAME=LINEITEM,PARENT=RECVABLE PSBNAME=CUSTPSB4,LANG=COBOL

48

LOGICAL DATABASES: Logical relationship is a path between segments that otherwise would be unrelated. A logical relationship is always between two segments. Although those segments are usually in separate physical databases, that does not have to be the case; a logical relationship can also connect two segments within the same physical database.
CUSTOMER DATABASE INVENTORY DATABASE

CUSTOMER

VENDOR

ITEM SHIP-TO

STOCK LOCATION BUYER RECEIVABLE

PAYMENT

ADJUSTMENT

LINE ITEM

49

Consider the two independent databases (Customer and Inventory) the structures are as shown above. In the Customer database, assume, a particular receivable segment might have several subordinate line item segments, each for different product. Notice that the key of LINE ITEM segment consists of 3 byte Vendour code and 5 byte Item number. In the Inventory DB there are three segments Viz., Vendor segment, Item Segment, Stock Location segments. Each Vendor will have lot of items in turn each item can be placed at different stock locations. Relevent portions of the two DBDs are shown below for reference.

CUSTOMER DBD:
SEGM FIELD FIELD FIELD FIELD NAME=LINEITEM,PARENT=RECVABLE,BYTES=16 NAME=(ITKEYVEN,SEQ,U),BYTES=3,START=1,TYPE=C NAME=ITKEYNUM,BYTES=5,START=4,TYPE=C NAME=LIUNTPRC,BYTES=4,START=9,TYPE=P NAME=LIQUANTY,BYTES=4,START=13,TYPE=P

INVENTORY DBD:
SEGM FIELD FIELD FIELD FIELD NAME=INITMSEG,PARENT=INVENSEG,BYTES=48 NAME=(INITMNUM,SEQ),BYTES=5,START=1,TYPE=C NAME=INITMDES,BYTES=35,START=6,TYPE=C NAME=INITMPRC,BYTES=4,START=41,TYPE=P NAME=INITMCST,BYTES=4,START=45,TYPE=P

The item number of Line Item segment (CUSTOMER) and Item number of Item segment (INVENTORY) are same. Access to Stock Locations segment can be provided by adding this segment (Stock Location Segment - INVENTORY) to the hierarchical structure of the CUSTOMER database, performing a new DBDGEN and reloading the database including the new stock location segment occurrences. The new database would then contain the stock location information, which is as shown below. As per the database structure above, the Stock Location information is already existing in Inventory Database. So it would be redundent to store it again in CUSTOMER database. One way to gain access to both the databases is to code a PSB that contains two PCBs, one for each physical database. In such case application programs could provide the program logic to tie together the two databases. The other approach is to use the logical relation ship concept. This provides a method for hooking two or more databases together in such a way that application programs can work with them as if they are of single logical data structure.

50

CUSTOMER DATABASE

CUSTOMER

SHIP-TO

BUYER

RECEIVABLE

PAYMENT

ADJUSTMENT

LINE ITEM

STOCK LOCATION

A Logical database is an ordered set of logical database record occurrences. Like a physical database record, a logical database record is a hierarchical arrangement of fixed-length segments. Like a physical database, a Logical database is defined by means of a DBD. However a logical database differs from a physical database in that it has no existence in its own right; instead it is defined in terms of one or more existing physical databases. Specifically each logical database record occurrence consists of segments from several distinct physical database record occurrences. Thus logical database imposes a hierarchical structure on the data that is different from the hierarchical structure represented by the underlaying physical databases; in other words it provides the user with an alternative view of the data. In IMS the logical database is really part of the conceptual level rather than the external level. Logical database will ideally look exactly like a physical database to the user, atleast as far as retrieval is concerned.

51

There are three ways in which a logical relationship can be established or Unidirectional Logical Relationship Bidirectional physically paired Logical Relationship Bidirectional virtually paired Logical Relationship Unidirectional Logical Relationships:

implemented. These methods of implementation are as follows:

In this type of relationships, logical connection goes from logical child (via physical structure) to the logical parent in one direction. A one-way path is established using a pointer in the logical child. As shown In the example below, a unidirectional logical path is created from the CUSTOMER database to the INVENTORY database, which would provide access to product data in the inventory database from the line item segment in the customer database. Instead of duplicating the STOCK LOCATION segment in the CUSTOMER database, a new pointer is created. In logical relationship terminology, the pointer segment in the CUSTOMER physical database is called a Logical Child Segment. The segment it points to the other segment in the INVENTORY database is called a Logical Parent.
CUSTOMER DATABASE INVENTORY DATABASE

CUSTOMER

VENDOR

SHIP-TO

Logical Parent

ITEM

BUYER

RECEIVABLE

Physical Parent

STOCK LOCATION

PAYMENT

ADJUSTMENT

LINE ITEM Logical Child

The Customer and Inventory Databases with a Unidirectional Logical Relationship

52

A particular receivable segment in the CUSTOMER database might have several subordinate line item segments, each for different product. Each of those line item segments, in turn, has a different logical parent in the inventory database. Note that one logical child segment occurrence has only one logical parent occurrence. In the figure, the logical relationship can be used to access from the CUSTOMER to the INVENTORY database. It cannot be used to access from the INVENTORY to the CUSTOMER database, because the ITEM segment of INVENTORY database does not point to the CUSTOMER database. The change required to be made in the two physical DBDs are shown below. CUSTOMER DBD: SEGM FIELD FIELD FIELD FIELD NAME=LINEITEM,PARENT=((RECVABLE),(INITMSEG,P,INDBD)), NAME=(ITKEYVEN,SEQ,U),BYTES=3,START=1,TYPE=C NAME=ITKEYNUM,BYTES=5,START=4,TYPE=C NAME=LIUNTPRC,BYTES=4,START=9,TYPE=P NAME=LIQUANTY,BYTES=4,START=13,TYPE=P BYTES=16

INVENTORY DBD:
SEGM FIELD LCHILD FIELD FIELD FIELD NAME=INITMSEG,PARENT=INVENSEG,BYTES=48 NAME=(INITMNUM,SEQ),BYTES=5,START=1,TYPE=C NAME=(LINEITEM,CUSTDBD) NAME=INITMDES,BYTES=35,START=6,TYPE=C NAME=INITMPRC,BYTES=4,START=41,TYPE=P NAME=INITMCST,BYTES=4,START=45,TYPE=P

In the CUSTOMER database, the DBD coding that differs from normal DBD coding is that for the logical child LINEITEM In the SEGM statement for LINEITEM: The PARENT= parameter has two parents specified.Two parents are specified because LINEITEM is a logical child and therefore has both a physical and logical parent. The physical parent is RECVABLE. The logical parent is INITMSEG, specified after RECVABLE. Because INITMSEG exists in a different physical database from CUSTDBD, the name of its physical database, INDBD, must be specified. Between the segment name INITMSEG and the database name INDBD is the letter P. The letter P stands for physical, which means the database name followed it is a separate physical database. In the INDBD database, the DBD coding that differs from normal DBD coding is that an LCHILD statement has been added. This statement names the logical child LINEITEM. Because the LINEITEM segment exists in a different physical database from INITMSEG, the name of its physical database, CUSTDBD, must be specified. It is possible to establish two unidirectional relationships. Then either physical database can be entered and the logical child in either can be used to cross to the other physical database. However, IMS treats each unidirectional relationship as a one-way path. It does not maintain data on both paths. If data in one database is inserted, deleted, or replaced, the corresponding data in the other database is not updated. This maintenance problem does not exist in both bidirectional physically paired-logical and bidirectional virtually paired-logical relationships.

53

Bidirectional Physically Paired Logical Relationship:

A bidirectional physically paired relationship links two segment types, a logical child and its logical parent, in two directions. A two-way path is established using pointers in the logical child segments. Figure below shows a bidirectional physically paired logical relationship that has been established between the CUSTOMER and INVENTORY databases.
CUSTOMER DATABASE INVENTORY DATABASE

CUSTOMER

VENDOR

SHIP-TO

Logical Parent

ITEM

BUYER

RECEIVABLE

Physical Parent

STOCK LOCATION Logical Relationship

LINE ITEM Real Logical Child

PAYMENT

ADJUSTMENT

LINE ITEM Real Logical Child

The Customer and Inventory Databases with a Bidirectional Physical Logical Relationship

A physically paired logical relationship can be established between two segment types in the same or different databases. The relationship shown in Figure allows either the CUSTOMER or the INVENTORY database to be entered. When either of the databases is entered, a path exists using the logical child to access one database from the other. In a physically paired relationship, a logical child is stored in both databases. However, if the logical child has dependents, they are only stored in one database. For example, IMS maintains data in both paths in physically paired relationships. If LINEITEM is deleted from the CUSTOMER database, IMS deletes from the INVENTORY database all INITMSEG segments which point to that particular LINEITEM segment. If data is changed in a logical child segment, IMS changes the data in its paired logical child segment. Or if a logical child segment is inserted into one database, IMS inserts a paired logical child segment into the other database. With physical pairing, the logical child is duplicate data, so there is some increase in storage requirements. In addition, there is some extra maintenance required because IMS maintains data on two paths. In the next type of logical relationship ie., Bidirectional virtually paired Logical Relationship, this extra space and maintenance do not exist, however, IMS still allows to enter either of the database.

54

Bidirectional Virtually Paired Logical Relationship: A bidirectional virtually paired relationship is like a bidirectional physically paired relationship in that: It links two segment types, a logical child and its logical parent, in two directions, establishing a two-way path. It can be established between two segment types in the same or different databases.

Figure below shows a bidirectional virtually paired relationship between the CUSTOMER and INVENTORY databases. Notice that although there is a two-way path, a logical child segment exists only in the CUSTOMER database. Going from the CUSTOMER to the INVENTORY database, IMS uses the pointer in the logical child segment. Going from the INVENTORY to the CUSTOMER database, IMS uses the pointer in the logical parent, as well as the pointer in the logical child segment.
CUSTOMER DATABASE INVENTORY DATABASE

CUSTOMER

VENDOR

SHIP-TO

Logical Parent

ITEM

BUYER

RECEIVABLE

Physical Parent

STOCK LOCATION Logical Relationship

LINE ITEM Virtual Logical Child

PAYMENT

ADJUSTMENT

LINE ITEM Real Logical Child

The Customer and Inventory Databases with a Bidirectional Virtual Logical Relationship

To define a virtually paired relationship, two logical child segment types are defined in the physical databases involved in the logical relationship. Only one logical child is actually placed in storage. The logical child defined and put in storage is called the real logical child. The logical child defined but not put in storage is called the virtual logical child. IMS maintains data in both paths in a virtually paired relationship. However, because there is only one logical child segment, maintenance is simpler than it is in a physically paired relationship. When, for instance, a new CUSTOMER segment is inserted, only one logical child segment has to be inserted. For a replace, the data only has to be changed in one segment. For a delete, the logical child segment is deleted from both paths.

55

Notice the trade-off between physical and virtual pairing. With virtual pairing, there is no duplicate logical child and maintenance of paired logical children. However, virtual pairing requires the use and maintenance of additional pointers, called logical twin pointers.

Rules for Defining Logical Relationships in Physical Databases:

Note that in all cases below, references are to segment types, not occurrences.

Logical Child:
A logical child must have a physical and a logical parent. A logical child can have only one physical and one logical parent. A logical child is defined as a physical child in the physical database of its physical parent. A logical child is always a dependent segment in a physical database, and can, therefore, be defined at any level except the first level of a database. A logical child in its physical database cannot have a physical child defined at the next lower level in the database that is also a logical child. A logical child can have a physical child. However, if a logical child is physically paired with another logical child, only one of the paired segments can have physical children.

Logical Parent:
A logical parent can be defined at any level in a physical database, including the root level. A logical parent can have one or more logical children. Each logical child related to the same logical parent defines a logical relationship. A segment in a physical database cannot be defined as both a logical parent and a logical child. A logical parent can be defined in the same physical database as its logical child, or in a different physical database.

Physical Parent :
A physical parent of a logical child cannot also be a logical child.

56

Rules for Defining Logical Databases:

The root segment in a logical database must be the root segment in a physical database. A logical database must use only those segments and physical and/or logical relationship paths defined in the physical DBD referenced by the logical DBD. The path used to connect a parent and child in a logical database must be defined as a physical relationship path or a logical relationship path in the physical DBD referenced by the logical DBD. Physical and logical relationship paths can be mixed in a hierarchic segment path in a logical database. Additional physical relationship paths, logical relationship paths, or both paths can be included after a logical relationship is crossed in a hierarchic path in a logical database. These paths are included by going in upward directions, downward directions, or both directions, from the destination parent. When proceeding downward along a physical relationship path from the destination parent, direction cannot be changed except by crossing a logical relationship. When proceeding upward along a physical relationship path from the destination parent, direction can be changed. Dependents in a logical database must be in the same relative order as they are under their parent in the physical database. If a segment in a logical database is a concatenated segment, the physical children of the logical child and children of the destination parent can be in any order. The relative order of the children or the logical child and the relative order of the children of the destination parent must remain unchanged. The same concatenated segment type can be defined multiple times with different combinations of key and data sensitivity. Each must have a distinct name for that view of the concatenated segment. Only one of the views can have dependent segments. Figure 69 shows the four views of the same concatenated segment that can be defined in a logical database. A PCB for the logical database can be sensitive to only one of the views of the concatenated segment type.

57

How Logical Relationships Affect Programming:

The calls you issue to process segments in logical relationships are the same calls that you use to process other segments. However, the processing is different in the following ways: how the logical segment looks in your I/O area, what the DB PCB mask contains after a retrieve call, and how you can replace, delete, and insert physical and logical parent segments. Because it is possible to access segments in logical relationships through the logical path or the physical path, the segments must be protected from being updated by unauthorized programs. When the DBA defines logical relationships, it defines a set of rules that determine how the segments can be deleted, replaced, and inserted. Defining these rules is a database design decision. If the program processes segments in logical relationships, the following information from the DBA is required. What segments look like in the I/O area when they are retrieved Whether or not the program is allowed to update and insert segments What to do if a DX, IX, or RX status codes are received

Inserting a logical child segment has the following requirements: In load mode, the logical child can be inserted only under its physical parent. Logical parent in the I/O area need not be supplied. In update mode, the format of the logical child is different, depending on whether it is accessed from its physical parent or from its logical parent. If accessed from its physical parent, the format of the logical child is the concatenated key of the logical parent followed by intersection data. If accessed from its logical parent, the format of the logical child is the concatenated key of the physical parent, followed by intersection data. The logical child can be inserted or replaced depending on the insert rule for the logical or physical parent. Unless the insert rule of the logical or physical parent is PHYSICAL, the logical or physical parent must be supplied in the I/O area following the logical child.

58

Status Codes for Logical Relationships:

The following status codes that apply specifically to segments involved in logical relationships. These are not all of the status codes that you can receive when processing a logical child segment or a physical or logical parent. If you receive one of these status codes, it means that you are trying to update the database in a way that you are not allowed to. Check with the DBA or person responsible for implementing logical relationships at your installation, to find out what the problem is. DXIMS did not delete the segment because the physical delete rule was violated. If the segment is a logical parent, it still has active logical children. If the segment is a logical child, it has not been deleted through its logical path. IX You tried to insert either a logical child segment or a concatenated segment. If it was a logical child segment, the corresponding logical or physical parent segment does not exist. If it was a concatenated segment, either the insert rule as physical and the logical or physical parent does not exist, or the insert rule is virtual and the key of the logical or physical parent in the I/O area does not match the concatenated key of the logical or physical parent. RX The physical replace rule has been violated. The physical replace rule was specified for the destination parent and an attempt was made to change its data. When a destination parent has the physical replace rule, it can be replaced only through the physical path.

59