Binding an application
You must bind the DBRM
that is produced by the SQL statement processor to a package before
your DB2® application can run. 
About this task
Each package that you bind can contain only one DBRM.
Because you do not need a plan or package to execute the SET CURRENT PACKAGESET statement, the ENCODING bind option does not affect the SET CURRENT PACKAGESET statement. An application that needs to provide a host variable value in an encoding scheme other than the system default encoding scheme must use the DECLARE VARIABLE statement to specify the encoding scheme of the host variable.
You must bind plans locally, regardless of whether they reference packages that run remotely. However, you must bind the packages that run at remote locations at those remote locations.
For C and C++ programs whose corresponding DBRMs are in HFS files, you can use the command line processor to bind the DBRMs to packages. Optionally, you can also copy the DBRM into a partitioned data set member by using the oput and oget commands and then bind it by using conventional JCL.
From a DB2 requester, you can run a plan by specifying it in the RUN subcommand, but you cannot run a package directly. You must include the package in a plan and then run the plan.
Develop a naming convention and strategy for the most effective and efficient use of your plans and packages.
- To bind a new plan or package, other than a trigger package, use
the subcommand BIND PLAN or BIND PACKAGE with the option ACTION(REPLACE).
To bind a new trigger package, re-create the trigger associated with the trigger package.
- Binding a DBRM to a package
You can bind a DBRM to a package and then bind that package to a plan. - Binding an application plan
An application plan can include package lists. - Bind process for remote access
You can use several different bind processes to enable access to data at a remote server. - Binding a batch program
Before a batch program can issue SQL statements, a DB2 plan must exist. - Conversion of DBRMs that are bound to a plan to DBRMs that are bound to a package
You must bind all DBRMs into a package, and bind the packages into a
plan. One package can have only one DBRM. - Converting an existing plan into packages to run remotely
If you have an existing application that you want to run at a remote location by using remote access, you need a new plan that includes those remote packages in its package list. - Setting the program level
The program level defines the level for a particular module. This information is stored in the consistency token, which is in an internal DB2 format. Overriding the program level in the consistency token is possible, if needed, but generally not recommended. - DYNAMICRULES bind option
The DYNAMICRULES bind option and the run time environment determine the values for the dynamic SQL attributes. - Dynamic plan selection
It is beneficial to use dynamic plan selection and packages together. You can convert individual programs in an application that contains many programs and plans, one at a time, to use a combination of plans and packages. This process reduces the number of plans per application; having fewer plans reduces the effort that is needed to maintain the dynamic plan exit routine.