DLI - Database Language Interface

Enhanced Definition

DLI, or Database Language Interface, is the programmatic interface used by application programs (primarily COBOL, PL/I, and Assembler) to interact with IBM's Information Management System (IMS) hierarchical databases on z/OS. It provides a set of call statements, known as DL/I calls, that allow applications to retrieve, insert, update, and delete data segments within an IMS database. DLI acts as the bridge between the application logic and the IMS database management system. DLI, or Database Language Interface (often referred to as DL/I), is the programmatic interface used by application programs (primarily COBOL, PL/I, and Assembler) to interact with IBM's Information Management System (IMS) databases. It provides a set of call statements that enable applications to retrieve, insert, update, and delete data within IMS hierarchical databases.

Key Characteristics

- Host Language Integration: DL/I calls are embedded directly within application programs written in host languages like COBOL, PL/I, and Assembler, rather than being a standalone query language.
- IMS DB Specific: DLI is exclusively designed for interacting with IMS Database (IMS DB), which is a hierarchical database management system. It does not interface with relational databases like DB2.
- Segment-Level Operations: All DL/I operations (Get, Insert, Replace, Delete) are performed at the segment level, reflecting the hierarchical structure of IMS databases.
- Program Specification Block (PSB): Applications access IMS databases through a PSB, which contains one or more Program Communication Blocks (PCBs). Each PCB defines an application's specific view of a database or logical database.
- Procedural Navigation: Unlike SQL, DLI requires explicit programmatic navigation through the database hierarchy using calls like GU (Get Unique), GN (Get Next), and GNP (Get Next within Parent).
- Status Codes: Every DL/I call returns a status code in the PCB's IOAREA to indicate the success or failure of the operation, requiring applications to implement robust error handling.

Use Cases

- Batch Data Processing: COBOL batch programs frequently use DLI to process large volumes of IMS data for tasks such as report generation, data extracts, or nightly updates.
- Online Transaction Processing (CICS/IMS DC): CICS transactions and IMS DC message processing programs utilize DLI to provide real-time access and updates to IMS databases for critical business applications.
- Data Migration and Conversion: Utility programs are often written using DLI to extract data from existing IMS databases or load data into newly structured IMS databases.
- Application Development: New applications requiring persistent storage in IMS DB are developed using DLI calls embedded in their business logic to manage data.

Related Concepts

DLI is inextricably linked to IMS DB, serving as the sole programmatic interface for accessing its hierarchical data. Application programs written in COBOL, PL/I, or Assembler embed DLI calls to perform database operations. These calls operate within the context defined by a Program Specification Block (PSB) and its associated Program Communication Blocks (PCBs), which dictate the application's view and access rights to the database. For online applications, DLI calls are executed under the control of CICS or IMS DC, while batch programs are typically executed via JCL that defines the necessary IMS environment.

Best Practices:

Optimize DL/I Call Sequences: Design application logic to minimize redundant GU calls and efficiently use GN and GNP to navigate the database, reducing I/O and CPU overhead.
Robust Error Handling: Always check the DL/I status code after every call and implement appropriate error recovery or logging mechanisms for common status codes like GE (Not Found) or GA (End of Database).
Manage Commit Points: For update programs, establish regular commit points (e.g., SYNCPOINT in CICS, CHKP in batch) to release database locks, ensure data integrity, and facilitate recovery in case of failures.
Effective Segment Search Arguments (SSAs): Utilize qualified SSAs to precisely target segments and minimize the number of segments IMS has to scan, significantly improving query performance.
PSB/PCB Design for Security and Performance: Design PSBs and PCBs to provide only the necessary database views and access types for each application, enhancing security and potentially improving performance by limiting scope.