We use DB2 Bind for a lot of things, for example, it will check for authorization and syntax error. It will also do query performance, query optimization. It is very very important because whatever precompiler does I based on DCLGEN and BIND process does syntax checking using DB2 catalog tables.
Bind performs the authorization check. Checks the syntax of the SQL syntax using the DB2 catalog table. This is more important because the syntax check done by precompiler is done using DCLGEN. Provides the run time instruction for the SQL which is present in DMRM. Each SQL statement is parsed and the best access method is chosen. It also do DB2 optimization.
The most important error and syntax Checking is done by Bind process and it checks for syntax using DB2 catalog table. So, it checks for all the syntax related error for SQL related statements.
Bind Process read DBRM which is created in precomplier stage and creates access path to read data. Access path along with consistency token is stored in DB2 catalog tables as a package. Every package is bound into package list or collection, Collection name is specified by package parameter. A Collection is a group of Packages that are included in one or more Plans. The QUALIFIER parameter of the bind is used to direct the SQL to the specific set of DB2 objects (tables, views, aliases or synonyms) qualified by this name. Apart from building plans and packages, bind also validates -
The below is the BIND JCL to bound the DB2 + COBOL program.
//STEP01 EXEC PGM= IKJEFT01
//SYSTSIN DD *
DSN
BIND PLAN(plan-name)
VALIDATE(validate-opt) -> BIND, RUN
MEMBER(DBRM-member-name)
ISOLATION(isolation level) -> CS,RR,UR
RELEASE(release-options) -> COMMIT, DEALLOCATE
LIB(‘DBRM LIBRARY’)
/*
The bind process establishes a relationship between an application program and its relational data. This step is necessary before you can execute your program. Currently, DB2 allows you two basic ways of binding a program: to a package, or directly to an application plan.
Even when they are bound into packages, all programs must be designated in an application plan. BIND PLAN establishes the relationship between DB2 and all DBRMs or packages in that plan. Plans can specify explicitly named DBRMs, packages, collections of packages, or a combination of these elements. The plan contains information about the designated DBRMs or packages and about the data the application program intends to use. It is stored in the DB2 catalog.
The bind process establishes a relationship between an application program and its relational data. This process is necessary before you can execute your program.
During the precompilation process, the DB2® precompiler produces both modified source code and a database request module (DBRM) for each application program. The modified source code must be compiled and link-edited before the program can be run. DBRMs must be bound to a package. You can then associate that package with a particular application plan
During the bind process, DB2 also completes the following actions, Validates object references in the SQL statements of the program, such as table, view, and column names, against the DB2 catalog. Because the bind process occurs before program execution, errors are detected and can be corrected before the program is executed.
Verifies the authorization of the bind process to specify the program owner and the authorization of the specified owner to access data that is requested by SQL statements in the program. Selects the access paths that DB2 uses to access data for the program. DB2 considers factors such as table size, available indexes, and others, when selecting the access paths.
When determining the maximum size of a plan, you must consider several physical limitations, including the time required to bind the plan, the size of the EDM pool, and fragmentation. As a general rule, the EDM pool should be at least 10 times the size of the largest DBD or plan, whichever is greater.
To bind individual DBRMs into packages, use the BIND PACKAGE subcommand. Packages provide the flexibility for you to test different versions of a program without having to rebind everything in the application plan.
All packages must be designated in an application plan. Use the BIND PLAN command to build such an application plan, allocate resources for the plan, and specify which packages are associated with that plan. Plans can specify packages, collections of packages, or a combination of these elements. If you specify one or more DBRMs to include in the plan (by using the MEMBER option of BIND PLAN), DB2 automatically binds those DBRMs into packages and then binds those packages into the plan. The plan contains information about the designated packages and about the data that the application programs intend to use. The plan is stored in the DB2 catalog.
PACKAGE
Package contains optimized access path (OAP) which is generated by optimizer of BIND which is non- executable component. Package can contains one or more DBRMS. Package is an intermediate component between the DBRM and PLAN. The main advantage of the package is, rebind is not required when any change in sub program. Compilation of subprogram is only sufficient.
PLAN
Plan contains also optimized access path, which is executable component. Plan will be used to execute the program. Plan will have the best access path to retrieve the data from database by using the SQLs coded in the program.
MEMBER
MEMBER is nothing but the DBRM name for the program stored in the DBRM library.
The Start Bind Process is used to bind an application after the Application has been completed or if a new Binder is needed. An Application must be selected in order to begin the Bind Process.
Binding an Application
Select an Application from the Client Manager Application tab. Expand the Processes menu and click Start Bind Process. The Binding an Application screen appears that will allow changes to be made to the term of the policy, effective or expiration date of the policy, and will indicate the date that the binder will expire (default number of days is based upon settings in the Maintenance Module).
The status of the application will change from “Pending” to “Bound”. A binder number will be automatically generated by the system but can be changed by the user if necessary.