DB2 Bind Manager overview

IBM® DB2® Bind Manager for z/OS® (also referred to as DB2 Bind Manager) streamlines the development, testing, and implementation of DB2 applications by alleviating one of the principal bottlenecks affecting these processes—the DB2 bind.

Preparing a DB2 application for processing involves several steps. The particular combination and sequence of these steps depend on the environment where the application is developed and the environment where it will run. However, nearly all applications require some form of compilation or language translation as well as linkage editing to create an executable load module. Some applications require further preparation steps that are unique to their particular environments, such as a CICS® new copy function. Precompilation and binding are two directly-related preparation steps that are specific to DB2.

Before you can compile a program using embedded (static) SQL, it must first be processed by the DB2 precompiler. The precompiler performs several essential functions:
  • It performs extensive validation of the SQL statements. This includes verifying syntax and structure, and matching host language variables and their attributes to the SQL statements that reference them.
  • It replaces SQL statements with appropriate host language statements, usually some form of subroutine call. It also inserts a timestamp value into the source program. This timestamp is used by DB2 integrity checking.
  • It extracts the SQL statements and stores them in a condensed form as a Database Request Module (DBRM).

After a program with embedded SQL is successfully processed by the DB2 precompiler and the appropriate host language compiler, it must undergo a DB2 bind before it is issued. Binding establishes a fixed relationship between a program and the databases it will access.

The bind process is complex and involves selecting access paths to the data, further SQL verification, and various other checks and validations. Until a program is successfully bound, it cannot access DB2 data.

The primary input to the bind process is the DBRM that was created when the program was processed by the precompiler. During the bind process, DB2 uses information in the DBRM to create a valid connection between the application program and the DB2 databases it will access.

The result of the bind is an application plan or package, which is stored in the DB2 catalog. The plan or package contains a timestamp value that is compared at the time it is issued to the one existing in the program. If the two do not agree, the program fails with a SQL return code of -818 or -805. This timestamp validation process causes applications to be rebound after every compilation, whether the SQL statements were modified or not.

Binding should be avoided whenever possible. The need to bind applications before using them requires time and valuable system resources.

As an application platform and enterprise data repository, DB2 becomes increasingly mission-critical. Effective and efficient use of DB2 is often vital to an enterprise's success. This means not only that the online operation of the database must be robust and reliable, but also that the process of developing and implementing applications be made as efficient and free of roadblocks as possible. It is this latter requirement that DB2 Bind Manager addresses.