Application programs developed using embedded SQL must be bound to each database with which they will operate. On platforms where these functions are available, you can do this using the Command Center and the Configuration Assistant.
Binding should be performed once per application, for each database. During the bind process, database access plans are stored for each SQL statement that will be executed. These access plans are supplied by application developers and are contained in bind files which are created during precompilation. Binding is a process of processing these bind files by a host or System i™ database server.Because several of the utilities supplied with DB2 Connect™ are developed using embedded SQL, they must be bound to a host or System i database server before they can be used with that system. If you do not use the DB2 Connect utilities and interfaces, you do not have to bind them to each of your host or System i database servers. The lists of bind files required by these utilities are contained in the following files:
Binding one of these lists of files to a database will bind each individual utility to that database.
If a DB2 Connect server product is installed, the DB2 Connect utilities must be bound to each host or System i database server before they can be used with that system. Assuming the clients are at the same fix pack level, you need to bind the utilities only once, regardless of the number of client platforms involved.For example, if you have 10 Windows® clients, and 10 AIX® clients connecting to DB2 Universal Database™ (UDB) for OS/390 and z/OS via DB2 Connect Enterprise Server Edition on a Windows server, do one the following:
In addition to DB2 Connect utilities, any other applications that use embedded SQL must also be bound to each database that you want them to work with. An application that is not bound will usually produce an SQL0805N error message when executed. You might want to create an additional bind list file for all of your applications that need to be bound.For each host or System i database server that you are binding to, do the following:
Note: The BINDADD and the CREATE IN COLLECTION NULLID privileges provide sufficient authority only when the packages do not already exist. For example, if you are creating them for the first time.
If the packages already exist, and you are binding them again, then the authority required to complete the task(s) depends on who did the original bind.
grant select on table to nullid with grant option
db2 connect to DBALIAS user USERID using PASSWORD db2 bind email@example.com blocking all sqlerror continue messages ddcsmvs.msg grant public db2 connect reset
Where DBALIAS, USERID, and PASSWORD apply to the host or System i database server, ddcsmvs.lst is the bind list file for z/OS, and path represents the location of the bind list file.
For example drive:\sqllib\bnd\ applies to all Windows operating systems, and INSTHOME/sqllib/bnd/ applies to all Linux® and UNIX® operating systems, where drive represents the logical drive where DB2 Connect was installed and INSTHOME represents the home directory of the DB2 Connect instance.
You can use the grant option of the bind command to grant EXECUTE privilege to PUBLIC or to a specified user name or group ID. If you do not use the grant option of the bind command, GRANT EXECUTE (RUN) individually.To find out the package names for the bind files, enter the following command:
ddcspkgn @bindfile.lstFor example:
ddcspkgn @ddcsmvs.lstmight yield the following output:
Bind File Package Name ------------------------------ ------------------------------ f:\sqllib\bnd\db2ajgrt.bnd SQLAB6D3To determine these values for DB2 Connect execute the ddcspkgn utility, for example:
ddcspkgn @ddcsmvs.lstOptionally, this utility can be used to determine the package name of individual bind files, for example:
BIND command REBIND command db2rbind - Rebind all packages command