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 Client 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 simply a process of processing these bind files by a DRDA Server. For more information about binding, refer to the Administration Guide.
Because several of the utilities supplied with DB2 Connect are developed using embedded SQL, they must be bound to a DRDA server before they can be used with that system. If you do not use the DB2 Connect utilities and interfaces listed in Table 1, you do not have to bind them to each of your DRDA 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 DB2 Connect Enterprise Edition (formerly DDCS Multi-user Gateway) is installed, the DB2 Connect utilities must be bound to each DRDA server; once from each type of client platform, before they can be used with that system.
For example, if you have 10 OS/2 clients, 10 Windows clients, and 10 AIX clients connecting to DB2 for OS/390 via a DB2 Connect Enterprise Edition for Window NT gateway, do the following:
| Note: | This assumes all the clients are at the same service level. If they are not then, in addition, you may need to bind from each client of a particular service level. Refer to Appendix D. "Binding Utilities for Back-Level Clients" if you have clients prior to DB2 Version 2.1. |
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 DRDA server database 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. A If you did the original bind and you are doing the bind again, then having any of the above listed authorities will allow you to complete the bind. B If your original bind was done by someone else and you are doing the second bind, then you will require either the SYSADM or the SYSCTRL authorities to complete the bind. Having just the BINDADD and the CREATE IN COLLECTION NULLID authorities will not allow you to complete the bind. It is still possible to create a package if you do not have either SYSADM or SYSCTRL privileges. In this situation you would need the BIND privilege on each of the existing packages that you intend to replace. |
On the VSE or VM system, you can issue:
grant select on table to nullid with grant option
db2 connect to DBALIAS user USERID using PASSWORD
db2 bind path@ddcsmvs.lst blocking all
sqlerror continue messages ddcsmvs.msg grant public
db2 connect reset
Where DBALIAS, USERID, and PASSWORD apply to the DRDA server database, ddcsmvs.lst is the bind list file for MVS, and path is the location of the bind list file.
For example drive:\sqllib\bnd\ applies to all Intel operating systems, and INSTHOME/sqllib/bnd/ applies to all UNIX operating systems, where drive is the logical drive where DB2 Connect was installed and INSTHOME is 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, you must 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 SQLAB6D3
For your reference, Table 1 shows the bind files and package names that are used by different components
of DB2 Connect. In some cases, different bind files and packages are used on
different operating systems.
Table 1. Bind Files and Packages
| Component | Bind file | Package | MVS or OS/390 | VSE | VM | OS/400 |
|---|---|---|---|---|---|---|
| Binder (used by the GRANT bind option) | db2ajgrt.bnd | sqlabxxx | yes | yes | yes | yes |
| DB2 Call Level Interface | ||||||
| Isolation level CS | db2clics.bnd | sqll1xxx | yes | yes | yes | yes |
| Isolation level RR | db2clirr.bnd | sqll2xxx | yes | yes | yes | yes |
| Isolation level UR | db2cliur.bnd | sqll3xxx | yes | yes | yes | yes |
| Isolation level RS | db2clirs.bnd | sqll4xxx | yes | yes | yes | yes |
| Isolation level NC | db2clinc.bnd | sqll5xxx | no | no | no | yes |
| Using MVS table names | db2clims.bnd | sqll7xxx | yes | no | no | no |
| Using OS/400 table names (OS/400 3.1 or later) | db2clias.bnd | sqllaxxx | no | no | no | yes |
| Using VSE/VM table names | db2clivm.bnd | sqll8xxx | no | yes | yes | no |
| Command Line Processor | ||||||
| Isolation level CS | db2clpcs.bnd | sqlc2xxx | yes | yes | yes | yes |
| Isolation level RR | db2clprr.bnd | sqlc3xxx | yes | yes | yes | yes |
| Isolation level UR | db2clpur.bnd | sqlc4xxx | yes | yes | yes | yes |
| Isolation level RS | db2clprs.bnd | sqlc5xxx | yes | yes | yes | yes |
| Isolation level NC | db2clpnc.bnd | sqlc6xxx | no | no | no | yes |
| REXX | ||||||
| Isolation level CS | db2arxcs.bnd | sqla1xxx | yes | yes | yes | yes |
| Isolation level RR | db2arxrr.bnd | sqla2xxx | yes | yes | yes | yes |
| Isolation level UR | db2arxur.bnd | sqla3xxx | yes | yes | yes | yes |
| Isolation level RS | db2arxrs.bnd | sqla4xxx | yes | yes | yes | yes |
| Isolation level NC | db2arxnc.bnd | sqla5xxx | no | no | no | yes |
| Utilities | ||||||
| Export | db2uexpm.bnd | sqlubxxx | yes | yes | yes | yes |
| Import | db2uimpm.bnd | sqlufxxx | yes | yes | yes | yes |
where xxx depends on the type of client platform and what service you have applied.
The following are the respective xxx values:
4C0 DB2 Client Application Enabler for AIX Version 2.1 4D0 DB2 Client Application Enabler for OS/2 Version 2.1 4W0 DB2 Client Application Enabler for Windows Version 2.1 6A3 DB2 Client Application Enabler for AIX 6D3 DB2 Client Application Enabler for OS/2 Version 2.1.2 6H3 DB2 Client Application Enabler for HP-UX 6G3 DB2 Client Application Enabler for Silicon Graphics Version 2.1 6M2 DB2 Client Application Enabler for Macintosh Version 2.1.2 6N1 DB2 Client Application Enabler for Windows 95 and NT Version 2. 6P1 DB2 Client Application Enabler for Windows NT (PPC) Version 2.1 6S1 DB2 Client Application Enabler for SCO OpenServer Version 2.1.2 6U3 DB2 Client Application Enabler for Solaris 6W4 DB2 Client Application Enabler for Windows Version 2.1.2 6X3 DB2 Client Application Enabler for SINIX 7C0 DB2 Universal Database Version 5
For the most recent version of this information, refer to Installing and Configuring DB2 Clients. To determine these values for DB2 Connect V5.0 execute the ddcspkgn utility, for example:
ddcspkgn @ddcsmvs.lst
Optionally, this utility can be used to determine the package name of individual bind files, for example:
ddcspkgn bindfile.bnd
If your DB2 for MVS/ESA system has the fix for APAR PN60988 installed (or if it is a later release than Version 3 Release 1), you can also add the bind files for isolation level NC to the ddcsmvs.lst file.
Bind options are discussed in detail in the Command Reference.
Notes: