Category: ims Db

IMS DB – Recovery ”; Previous Next The database administrator needs to plan for the database recovery in case of system failures. Failures can be of many types such as application crashes, hardware errors, power failures, etc. Simple Approach Some simple approaches to database recovery are as follows − Make periodical backup copies of important datasets so that all transactions posted against the datasets are retained. If a dataset is damaged due to a system failure, that problem is corrected by restoring the backup copy. Then the accumulated transactions are re-posted to the backup copy to bring them up-to-date. Disadvantages of Simple Approach The disadvantages of simple approach to database recovery are as follows − Re-posting the accumulated transactions consumes a lot of time. All other applications need to wait for execution until the recovery is finished. Database recovery is lengthier than file recovery, if logical and secondary index relationships are involved. Abnormal Termination Routines A DL/I program crashes in a way that is different from the way a standard program crashes because a standard program is executed directly by the operating system, while a DL/I program is not. By employing an abnormal termination routine, the system interferes so that recovery can be done after the ABnormal END (ABEND). The abnormal termination routine performs the following actions − Closes all datasets Cancels all pending jobs in the queue Creates a storage dump to find out the root cause of ABEND The limitation of this routine is that it does not ensure if the data in use is accurate or not. DL/I Log When an application program ABENDs, it is necessary to revert the changes done by the application program, correct the error, and re-run the application program. To do this, it is required to have the DL/I log. Here are the key points about DL/I logging − A DL/I records all the changes made by an application program in a file which is known as the log file. When the application program changes a segment, its before image and after images are created by the DL/I. These segment images can be used to restore the segments, in case the application program crashes. DL/I uses a technique called write-ahead logging to record database changes. With write-ahead logging, a database change is written to the log dataset before it is written to the actual dataset. As the log is always ahead of the database, the recovery utilities can determine the status of any database change. When the program executes a call to change a database segment, the DL/I takes care of its logging part. Recovery – Forward and Backward The two approaches of database recovery are − Forward Recovery − DL/I uses the log file to store the change data. The accumulated transactions are re-posted using this log file. Backward Recovery − Backward recovery is also known as backout recovery. The log records for the program are read backwards and their effects are reversed in the database. When the backout is complete, the databases are in the same state as they were in before the failure, assuming that no another application program altered the database in the meantime. Checkpoint A checkpoint is a stage where the database changes done by the application program are considered complete and accurate. Listed below are the points to note about a checkpoint − Database changes made before the most recent checkpoint are not reversed by backward recovery. Database changes logged after the most recent checkpoint are not applied to an image copy of the database during forward recovery. Using checkpoint method, the database is restored to its condition at the most recent checkpoint when the recovery process completes. The default for batch programs is that the checkpoint is the beginning of the program. A checkpoint can be established using a checkpoint call (CHKP). A checkpoint call causes a checkpoint record to be written on the DL/I log. Shown below is the syntax of a CHKP call − CALL ”CBLTDLI” USING DLI-CHKP PCB-NAME CHECKPOINT-ID There are two checkpoint methods − Basic Checkpointing − It allows the programmer to issue checkpoint calls that the DL/I recovery utilities use during recovery processing. Symbolic Checkpointing − It is an advanced form of checkpointing that is used in combination with the extended restart facility. Symbolic checkpointing and extended restart together let the application programmer code the programs so that they can resume processing at the point just after the checkpoint. Print Page Previous Next Advertisements ”;

IMS DB – Quick Guide ”; Previous Next IMS DB – Overview A Brief Overview Database is a collection of correlated data items. These data items are organized and stored in a manner to provide fast and easy access. IMS database is a hierarchical database where data is stored at different levels and each entity is dependent on higher level entities. The physical elements on an application system that use IMS are shown in the following figure. Database Management A Database Management system is a set of application programs used for storing, accessing, and managing data in the database. IMS database management system maintains integrity and allows fast recovery of data by organizing it in such a way that it is easy to retrieve. IMS maintains a large amount of world”s corporate data with the help of its database management system. Transaction Manager The function of transaction manager is to provide a communication platform between the database and the application programs. IMS acts as a transaction manager. A transaction manager deals with the end-user to store and retrieve data from the database. IMS can use IMS DB or DB2 as its back-end database to store the data. DL/I – Data Language Interface DL/I comprises of application programs that grant access to the data stored in the database. IMS DB uses DL/I which serves as the interface language that programmers use for accessing the database in an application program. We will discuss this in more detail in the upcoming chapters. Characteristics of IMS Points to note − IMS supports applications from different languages such as Java and XML. IMS applications and data can be accessed over any platform. IMS DB processing is very fast as compared to DB2. Limitations of IMS Points to note − Implementation of IMS DB is very complex. IMS predefined tree structure reduces flexibility. IMS DB is difficult to manage. IMS DB – Structure Hierarchical Structure An IMS database is a collection of data accommodating physical files. In a hierarchical database, the topmost level contains the general information about the entity. As we proceed from the top level to the bottom levels in the hierarchy, we get more and more information about the entity. Each level in the hierarchy contains segments. In standard files, it is difficult to implement hierarchies but DL/I supports hierarchies. The following figure depicts the structure of IMS DB. Segment Points to note − A segment is created by grouping of similar data together. It is the smallest unit of information that DL/I transfers to and from an application program during any input-output operation. A segment can have one or more data fields grouped together. In the following example, the segment Student has four data fields. Student Roll Number Name Course Mobile NUmber Field Points to note− A field is a single piece of data in a segment. For example, Roll Number, Name, Course, and Mobile Number are single fields in the Student segment. A segment consists of related fields to collect the information of an entity. Fields can be used as a key for ordering the segments. Fields can be used as a qualifier for searching information about a particular segment. Segment Type Points to note − Segment Type is a category of data in a segment. A DL/I database can have 255 different segment types and 15 levels of hierarchy. In the following figure, there are three segments namely, Library, Books Information, and Student Information. Segment Occurrence Points to note − A segment occurrence is an individual segment of a particular type containing user data. In the above example, Books Information is one segment type and there can any number of occurrences of it, as it can store the information about any number of books. Within the IMS Database, there is only one occurrence of each segment type, but there can be an unlimited number of occurrences of each segment type. IMS DB – DL/I Terminology Hierarchical databases work on the relationships between two or more segments. The following example shows how segments are related to each other in the IMS database structure. Root Segment Points to note − The segment that lies at the top of the hierarchy is called the root segment. The root segment is the only segment through which all dependent segments are accessed. The root segment is the only segment in the database which is never a child segment. There can be only one root segment in the IMS database structure. For example, ”A” is the root segment in the above example. Parent Segment Points to note − A parent segment has one or more dependent segments directly below it. For example, ”A”, ”B”, and ”E” are the parent segments in the above example. Dependent Segment Points to note − All segments other than the root segment are known as dependent segments. Dependent segments depend on one or more segments to present complete meaning. For example, ”B”, ”C1”, ”C2”, ”D”, ”E”, ”F1” and ”F2” are dependent segments in our example. Child Segment Points to note − Any segment having a segment directly above it in the hierarchy is known as a child segment. Each dependent segment in the structure is a child segment. For example, ”B”, ”C1”, ”C2”, ”D”, ”E”, ”F1” and ”F2” are child segments. Twin Segments Points to note − Two or more segment occurrences of a particular segment type under a single parent segment are called twin segments. For example, ”C1” and ”C2” are twin segments, so do ”F1” and ”F2” are. Sibling Segment Points to note − Sibling segments are the segments of different types and the same parent. For example, ”B” and ”E” are sibling segments. Similarly, ”C1”, ”C2”, and ”D” are sibling segments. Database Record Points to note − Each occurrence of the root segment, plus all the subordinate segment occurrences make one database record. Every database record has only one root segment but it may have any number of segment occurrences. In standard file processing, a record is a unit of data that an application program uses for certain operations. In DL/I, that unit of data is known as a segment. A single database record

IMS DB Questions and Answers ”; Previous Next IMS DB Questions and Answers has been designed with a special intention of helping students and professionals preparing for various Certification Exams and Job Interviews. This section provides a useful collection of sample Interview Questions and Multiple Choice Questions (MCQs) and their answers with appropriate explanations. SN Question/Answers Type 1 IMS DB Interview Questions This section provides a huge collection of IMS DB Interview Questions with their answers hidden in a box to challenge you to have a go at them before discovering the correct answer. 2 IMS DB Online Quiz This section provides a great collection of IMS DB Multiple Choice Questions (MCQs) on a single page along with their correct answers and explanation. If you select the right option, it turns green; else red. 3 IMS DB Online Test If you are preparing to appear for a Java and IMS DB Framework related certification exam, then this section is a must for you. This section simulates a real online test along with a given timer which challenges you to complete the test within a given time-frame. Finally you can check your overall test score and how you fared among millions of other candidates who attended this online test. 4 IMS DB Mock Test This section provides various mock tests that you can download at your local machine and solve offline. Every mock test is supplied with a mock test key to let you verify the final score and grade yourself. Print Page Previous Next Advertisements ”;

IMS DB – Useful Resources ”; Previous Next The following resources contain additional information on IMS DB. Please use them to get more in-depth knowledge on this topic. Useful Links on IMS DB IBM IMS – IBM”s official page for IMS Wikipedia – Wikipedia reference for IBM Information Management System Useful Books on IMS DB To enlist your site on this page, please drop an email to [email protected] Print Page Previous Next Advertisements ”;

IMS DB – Data Retrieval ”; Previous Next The various data retrieval methods used in IMS DL/I calls are as follows − GU Call GN Call Using Command Codes Multiple Processing Let us consider the following IMS database structure to understand the data retrieval function calls − GU Call The fundamentals of GU call are as follows − GU call is known as Get Unique call. It is used for random processing. If an application does not update the database regularly or if the number of database updates is less, then we use random processing. GU call is used to place the pointer at a particular position for further sequential retrieval. GU calls are independent of the pointer position established by the previous calls. GU call processing is based on the unique key fields supplied in the call statement. If we supply a key field that is not unique, then DL/I returns the first segment occurrence of the key field. CALL ”CBLTDLI” USING DLI-GU PCB-NAME IO-AREA LIBRARY-SSA BOOKS-SSA ENGINEERING-SSA IT-SSA The above example shows we issue a GU call by providing a complete set of qualified SSAs. It includes all the key fields starting from the root level to the segment occurrence that we want to retrieve. GU Call Considerations If we do not provide the complete set of qualified SSAs in the call, then DL/I works in the following way − When we use an unqualified SSA in a GU call, DL/I accesses the first segment occurrence in the database that meets the criteria you specify. When we issue a GU call without any SSAs, DL/I returns the first occurrence of the root segment in the database. If some SSAs at intermediate levels are not mentioned in the call, then DL/I uses either the established position or the default value of an unqualified SSA for the segment. Status Codes The following table shows the relevant status codes after a GU call − S.No Status Code & Description 1 Spaces Successful call 2 GE DL/I could not find a segment that met the criteria specified in the call GN Call The fundamentals of GN call are as follows − GN call is known as Get Next call. It is used for basic sequential processing. The initial position of the pointer in the database is before the root segment of the first database record. The database pointer position is before the next segment occurrence in the sequence, after a successful GN call. The GN call starts through the database from the position established by the previous call. If a GN call is unqualified, it returns the next segment occurrence in the database regardless of its type, in hierarchical sequence. If a GN call includes SSAs, then DL/I retrieves only segments that meet the requirements of all specified SSAs. CALL ”CBLTDLI” USING DLI-GN PCB-NAME IO-AREA BOOKS-SSA The above example shows we issue a GN call providing the starting position to read the records sequentially. It fetches the first occurrence of the BOOKS segment. Status Codes The following table shows the relevant status codes after a GN call − S.No Status Code & Description 1 Spaces Successful call 2 GE DL/I could not find a segment that met the criteria specified in the call. 3 GA An unqualified GN call moves up one level in the database hierarchy to fetch the segment. 4 GB End of database is reached and segment not found. GK An unqualified GN call tries to fetch a segment of a particular type other than the one just retrieved but stays in the same hierarchical level. Command Codes Command codes are used with calls to fetch a segment occurrence. The various command codes used with calls are discussed below. F Command Code Points to note − When an F command code is specified in a call, the call processes the first occurrence of the segment. F command codes can be used when we want to process sequentially and it can be used with GN calls and GNP calls. If we specify an F command code with a GU call, it does not have any significance, as GU calls fetch the first segment occurrence by default. L Command Code Points to note − When an L command code is specified in a call, the call processes the last occurrence of the segment. L command codes can be used when we want to process sequentially and it can be used with GN calls and GNP calls. D Command Code Points to note − D command code is used to fetch more than one segment occurrences using just a single call. Normally DL/I operates on the lowest level segment specified in an SSA, but in many cases, we want data from other levels as well. In those cases, we can use the D command code. D command code makes easy retrieval of the entire path of segments. C Command Code Points to note − C command code is used to concatenate keys. Using relational operators is a bit complex, as we need to specify a field name, a relational operator, and a search value. Instead, we can use a C command code to provide a concatenated key. The following example shows the use of C command code − 01 LOCATION-SSA. 05 FILLER PIC X(11) VALUE ‘INLOCSEG*C(‘. 05 LIBRARY-SSA PIC X(5). 05 BOOKS-SSA PIC X(4). 05 ENGINEERING-SSA PIC X(6). 05 IT-SSA PIC X(3) 05 FILLER PIC X VALUE ‘)’. CALL ”CBLTDLI” USING DLI-GU PCB-NAME IO-AREA LOCATION-SSA P Command Code Points to note − When we issue a GU or GN call, the DL/I establishes its parentage at the lowest level segment that is retrieved. If we include a P command code, then the DL/I establishes its parentage at a higher level segment in the hierarchical path. U Command Code Points to note − When a U command code is specified in an unqualified SSA in a GN call, the DL/I restricts the search for the segment. U command code

IMS DB – Logical Database ”; Previous Next IMS database has a rule that each segment type can have only one parent. This limits the complexity of the physical database. Many DL/I applications require a complex structure that allows a segment to have two parent segment types. To overcome this limitation, DL/I allows the DBA to implement logical relationships in which a segment can have both physical and logical parents. We can create additional relationships within one physical database. The new data structure after implementing the logical relationship is known as the Logical Database. Logical Relationship A logical relationship has the following properties − A logical relationship is a path between two segments which are related logically and not physically. Usually a logical relationship is established between separate databases. But it is possible to have a relationship between the segments of one particular database. The following image shows two different databases. One is a Student database, and the other is a Library database. We create a logical relationship between the Books Issued segment from the Student database and the Books segment from the Library database. This is how the logical database looks when you create a logical relationship − Logical Child Segment Logical child segment is the basis of a logical relationship. It is a physical data segment but for DL/I, it appears as if it has two parents. The Books segment in the above example has two parent segments. Issued books segment is the logical parent and Library segment is the physical parent. One logical child segment occurrence has only one logical parent segment occurrence and one logical parent segment occurrence can have many logical child segment occurrences. Logical Twins Logical twins are the occurrences of a logical child segment type that are all subordinate to a single occurrence of the logical parent segment type. DL/I makes the logical child segment appear similar to an actual physical child segment. This is also known as a virtual logical child segment. Types of Logical Relationships A DBA creates logical relationships between segments. To implement a logical relationship, the DBA has to specify it in the DBDGENs for the involved physical databases. There are three types of logical relationships − Unidirectional Bidirectional Virtual Bidirectional Physical Unidirectional The logical connection goes from the logical child to the logical parent and it cannot go the other way around. Bidirectional Virtual It allows access in both the directions. The logical child in its physical structure and the corresponding virtual logical child can be seen as paired segments. Bidirectional Physical The logical child is a physically stored subordinate to both its physical and logical parents. To application programs, it appears the same way as a bidirectional virtual logical child. Programming Considerations The programming considerations for using a logical database are as follows − DL/I calls to access the database remains same with the logical database too. Program specification block indicates the structure which we use in our calls. In some cases, we cannot identify that we are using a logical database. Logical relationships add a new dimension to database programming. You must be careful while working with logical databases, as two databases are integrated together. If you modify one database, the same modifications must be reflected in the other database. Program specifications should indicate what processing is allowed on a database. If a processing rule is violated, you get a non-blank status code. Concatenated Segment A logical child segment always begins with the complete concatenated key of the destination parent. This is known as the Destination Parent Concatenated Key (DPCK). You need to always code the DPCK at the start of your segment I/O area for a logical child. In a logical database, the concatenated segment makes the connection between segments that are defined in different physical databases. A concatenated segment consists of the following two parts − Logical child segment Destination parent segment A logical child segment consists of the following two parts − Destination Parent Concatenated Key (DPCK) Logical child user data When we work with concatenated segments during update, it may be possible to add or change the data in both the logical child and the destination parent with a single call. This also depends on the rules the DBA specified for the database. For an insert, provide the DPCK in the right position. For a replace or delete, do not change the DPCK or the sequence field data in either part of the concatenated segment. Print Page Previous Next Advertisements ”;

IMS DB – Secondary Indexing ”; Previous Next Secondary Indexing is used when we want to access a database without using the complete concatenated key or when we do not want to use the sequence primary fields. Index Pointer Segment DL/I stores the pointer to segments of the indexed database in a separate database. Index pointer segment is the only type of secondary index. It consists of two parts − Prefix Element Data Element Prefix Element The prefix part of the index pointer segment contains a pointer to the Index Target Segment. Index target segment is the segment that is accessible using the secondary index. Data Element The data element contains the key value from the segment in the indexed database over which the index is built. This is also known as the index source segment. Here are the key points to note about Secondary Indexing − The index source segment and the target source segment need not be the same. When we set up a secondary index, it is automatically maintained by the DL/I. The DBA defines many secondary indexes as per the multiple access paths. These secondary indexes are stored in a separate index database. We should not create more secondary indexes, as they impose additional processing overhead on the DL/I. Secondary Keys Points to note − The field in the index source segment over which the secondary index is built is called as the secondary key. Any field can be used as a secondary key. It need not be the segments sequence field. Secondary keys can be any combination of single fields within the index source segment. Secondary key values do not have to be unique. Secondary Data Structures Points to note − When we build a secondary index, the apparent hierarchical structure of the database is also changed. The index target segment becomes the apparent root segment. As shown in the following image, the Engineering segment becomes the root segment, even if it is not a root segment. The rearrangement of the database structure caused by the secondary index is known as the secondary data structure. Secondary data structures do not make any changes to the main physical database structure present on the disk. It is just a way to alter the database structure in front of the application program. Independent AND Operator Points to note − When an AND (* or &) operator is used with secondary indexes, it is known as a dependent AND operator. An independent AND (#) allows us to specify qualifications that would be impossible with a dependent AND. This operator can be used only for secondary indexes where the index source segment is dependent on the index target segment. We can code an SSA with an independent AND to specify that an occurrence of the target segment be processed based on the fields in two or more dependent source segments. 01 ITEM-SELECTION-SSA. 05 FILLER PIC X(8). 05 FILLER PIC X(1) VALUE ”(”. 05 FILLER PIC X(10). 05 SSA-KEY-1 PIC X(8). 05 FILLER PIC X VALUE ”#”. 05 FILLER PIC X(10). 05 SSA-KEY-2 PIC X(8). 05 FILLER PIC X VALUE ”)”. Sparse Sequencing Points to note − Sparse sequencing is also known as Sparse Indexing. We can remove some of the index source segments from the index using sparse sequencing with secondary index database. Sparse sequencing is used to improve the performance. When some occurrences of the index source segment are not used, we can remove that. DL/I uses a suppression value or a suppression routine or both to determine whether a segment should be indexed. If the value of a sequence field in the index source segment matches a suppression value, then no index relationship is established. The suppression routine is a user-written program that evaluates the segment and determines whether or not it should be indexed. When sparse indexing is used, its functions are handled by the DL/I. We do not need to make special provisions for it in the application program. DBDGEN Requirements As discussed in earlier modules, DBDGEN is used to create a DBD. When we create secondary indexes, two databases are involved. A DBA needs to create two DBDs using two DBDGENs for creating a relationship between an indexed database and a secondary indexed database. PSBGEN Requirements After creating the secondary index for a database, the DBA needs to create the PSBs. PSBGEN for the program specifies the proper processing sequence for the database on the PROCSEQ parameter of the PSB macro. For the PROCSEQ parameter, the DBA codes the DBD name for the secondary index database. Print Page Previous Next Advertisements ”;

IMS DB – Structure ”; Previous Next Hierarchical Structure An IMS database is a collection of data accommodating physical files. In a hierarchical database, the topmost level contains the general information about the entity. As we proceed from the top level to the bottom levels in the hierarchy, we get more and more information about the entity. Each level in the hierarchy contains segments. In standard files, it is difficult to implement hierarchies but DL/I supports hierarchies. The following figure depicts the structure of IMS DB. Segment Points to note − A segment is created by grouping of similar data together. It is the smallest unit of information that DL/I transfers to and from an application program during any input-output operation. A segment can have one or more data fields grouped together. In the following example, the segment Student has four data fields. Student Roll Number Name Course Mobile NUmber Field Points to note− A field is a single piece of data in a segment. For example, Roll Number, Name, Course, and Mobile Number are single fields in the Student segment. A segment consists of related fields to collect the information of an entity. Fields can be used as a key for ordering the segments. Fields can be used as a qualifier for searching information about a particular segment. Segment Type Points to note − Segment Type is a category of data in a segment. A DL/I database can have 255 different segment types and 15 levels of hierarchy. In the following figure, there are three segments namely, Library, Books Information, and Student Information. Segment Occurrence Points to note − A segment occurrence is an individual segment of a particular type containing user data. In the above example, Books Information is one segment type and there can any number of occurrences of it, as it can store the information about any number of books. Within the IMS Database, there is only one occurrence of each segment type, but there can be an unlimited number of occurrences of each segment type. Print Page Previous Next Advertisements ”;

IMS DB – PCB Mask ”; Previous Next PCB stands for Program Communication Block. PCB Mask is the second parameter used in the DL/I call. It is declared in the linkage section. Given below is the syntax of a PCB Mask − 01 PCB-NAME. 05 DBD-NAME PIC X(8). 05 SEG-LEVEL PIC XX. 05 STATUS-CODE PIC XX. 05 PROC-OPTIONS PIC X(4). 05 RESERVED-DLI PIC S9(5). 05 SEG-NAME PIC X(8). 05 LENGTH-FB-KEY PIC S9(5). 05 NUMB-SENS-SEGS PIC S9(5). 05 KEY-FB-AREA PIC X(n). Here are the key points to note − For each database, the DL/I maintains an area of storage that is known as the program communication block. It stores the information about the database that are accessed inside the application programs. The ENTRY statement creates a connection between the PCB masks in the Linkage Section and the PCBs within the program’s PSB. The PCB masks used in a DL/I call tells which database to use for operation. You can assume this is similar to specifying a file name in a COBOL READ statement or a record name in a COBOL write statement. No SELECT, ASSIGN, OPEN, or CLOSE statements are required. After each DL/I call, the DL/I stores a status code in the PCB and the program can use that code to determine whether the call succeeded or failed. PCB Name Points to note − PCB Name is the name of the area which refers to the entire structure of the PCB fields. PCB Name is used in program statements. PCB Name is not a field in the PCB. DBD Name Points to note − DBD name contains the character data. It is eight bytes long. The first field in the PCB is the name of the database being processed and it provides the DBD name from the library of database descriptions associated with a particular database. Segment Level Points to note − Segment level is known as Segment Hierarchy Level Indicator. It contains character data and is two bytes long. A segment level field stores the level of the segment that was processed. When a segment is retrieved successfully, the level number of the retrieved segment is stored here. A segment level field never has a value greater than 15 because that is the maximum number of levels permitted in a DL/I database. Status Code Points to note − Status code field contains two bytes of character data. Status code contains the DL/I status code. Spaces are moved to the status code field when DL/I completes the processing of calls successfully. Non-space values indicate that the call was not successful. Status code GB indicates end-of-file and status code GE indicates that the requested segment is not found. Proc Options Points to note − Proc options are known as processing options which contain four-character data fields. A Processing Option field indicates what kind of processing the program is authorized to do on the database. Reserved DL/I Points to note − Reserved DL/I is known as the reserved area of the IMS. It stores four bytes binary data. IMS uses this area for its own internal linkage related to an application program. Segment Name Points to note − SEG Name is known as segment name feedback area. It contains 8 bytes of character data. The name of the segment is stored in this field after each DL/I call. Length FB Key Points to note − Length FB key is known as the length of the key feedback area. It stores four bytes of binary data. This field is used to report the length of the concatenated key of the lowest level segment processed during the previous call. It is used with the key feedback area. Number of Sensitivity Segments Points to note − Number of sensitivity segments store four bytes binary data. It defines to which level an application program is sensitive. It represents a count of number of segments in the logical data structure. Key Feedback Area Points to note − Key feedback area varies in length from one PCB to another. It contains the longest possible concatenated key that can be used with the program’s view of the database. After a database operation, DL/I returns the concatenated key of the lowest level segment processed in this field, and it returns the length of the key in the key length feedback area. Print Page Previous Next Advertisements ”;

IMS DB – Data Manipulation ”; Previous Next The different data manipulation methods used in IMS DL/I calls are as follows − ISRT Call Get Hold Calls REPL Call DLET Call Let us consider the following IMS database structure to understand the data manipulation function calls − ISRT Call Points to note − ISRT call is known as Insert call which is used to add segment occurrences to a database. ISRT calls are used for loading a new database. We issue an ISRT call when a segment description field is loaded with data. An unqualified or qualified SSA must be specified in the call so that the DL/I knows where to place a segment occurrence. We can use a combination of both unqualified and qualified SSA in the call. A qualified SSA can be specified for all the above levels. Let us consider the following example − CALL ”CBLTDLI” USING DLI-ISRT PCB-NAME IO-AREA LIBRARY-SSA BOOKS-SSA UNQUALIFIED-ENGINEERING-SSA The above example shows we are issuing an ISRT call by providing a combination of qualified and unqualified SSAs. When a new segment that we are inserting has a unique key field, then it is added at the proper position. If the key field is not unique, then it is added by the rules defined by a database administrator. When we issue an ISRT call without specifying a key field, then the insert rule tells where to place the segments relative to existing twin segments. Given below are the insert rules − First − If the rule is first, the new segment is added before any existing twins. Last − If the rule is last, the new segment is added after all existing twins. Here − If the rule is here, it is added at the current position relative to existing twins, which may be first, last, or anywhere. Status Codes The following table shows the relevant status codes after an ISRT call − S.No Status Code & Description 1 Spaces Successful call 2 GE Multiple SSAs are used and the DL/I cannot satisfy the call with the specified path. 3 II Try to add a segment occurrence that is already present in the database. 4 LB / LC LD / LE We get these status codes while load processing. In most cases, they indicate that you are not inserting the segments in an exact hierarchical sequence. Get Hold Call Points to note − There are three types of Get Hold call which we specify in a DL/I call: Get Hold Unique (GHU) Get Hold Next (GHN) Get Hold Next within Parent (GHNP) Hold function specifies that we are going to update the segment after retrieval. So before an REPL or DLET call, a successful hold call must be issued telling the DL/I an intent to update the database. REPL Call Points to note − After a successful get hold call, we issue an REPL call to update a segment occurrence. We cannot change the length of a segment using an REPL call. We cannot change the value of a key field using an REPL call. We cannot use a qualified SSA with an REPL call. If we specify a qualified SSA, then the call fails. CALL ”CBLTDLI” USING DLI-GHU PCB-NAME IO-AREA LIBRARY-SSA BOOKS-SSA ENGINEERING-SSA IT-SSA. *Move the values which you want to update in IT segment occurrence* CALL ‘CBLTDLI’ USING DLI-REPL PCB-NAME IO-AREA. The above example updates the IT segment occurrence using an REPL call. First, we issue a GHU call to get the segment occurrence we want to update. Then, we issue an REPL call to update the values of that segment. DLET Call Points to note − DLET call works much in the same way as an REPL call does. After a successful get hold call, we issue a DLET call to delete a segment occurrence. We cannot use a qualified SSA with a DLET call. If we specify a qualified SSA, then the call fails. CALL ”CBLTDLI” USING DLI-GHU PCB-NAME IO-AREA LIBRARY-SSA BOOKS-SSA ENGINEERING-SSA IT-SSA. CALL ‘CBLTDLI’ USING DLI-DLET PCB-NAME IO-AREA. The above example deletes the IT segment occurrence using a DLET call. First, we issue a GHU call to get the segment occurrence we want to delete. Then, we issue a DLET call to update the values of that segment. Status Codes The following table shows the relevant status codes after an REPL or a DLET call − S.No Status Code & Description 1 Spaces Successful call 2 AJ Qualified SSA used on REPL or DLET call. 3 DJ Program issues a replace call without an immediately preceding get hold call. 4 DA Program makes a change to the segment’s key field before issuing the REPL or DLET call Print Page Previous Next Advertisements ”;