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 host or AS/400 database server. For more information about binding, refer to the Application Development Guide.
Because several of the utilities supplied with DB2 Connect are developed using embedded SQL, they must be bound to a host or AS/400 database server before they can be used with that system. If you do not use the DB2 Connect utilities and interfaces listed in Table 2, you do not have to bind them to each of your host or AS/400 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 DB2 Connect Enterprise Edition (formerly DDCS Multi-user Gateway) is installed, the DB2 Connect utilities must be bound to each host or AS/400 database 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 Universal Database 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 F, 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 host or AS/400 database server that you are binding to, do the following:
SYSADM or
SYSCTRL or
BINDADD and CREATE IN COLLECTION NULLID
| 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. |
system.syscatalog
system.syscolumns
system.sysindexes
system.systabauth
system.syskeycols
system.syssynonyms
system.syskeys
system.syscolauth
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 host or AS/400 database server, 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.lst
For example:
ddcspkgn @ddcsmvs.lst
might yield the following output:
Bind File Package Name
------------------------------ ------------------------------
f:\sqllib\bnd\db2ajgrt.bnd SQLAB6D3
For your reference, Table 2 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 2. 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 last 3 characters of a package name represent:
- The last digit of the year the product was released
- The platform of the product
where: A = AIX D = OS/2
W = Windows 3.1 N = Windows NT/95/98
M = Macintosh G = Silicon Graphics
H = HP-UX U = Solaris
X = Sinix Nixdorf S = SCO
P = Power PC X = Parallel edition
To determine these values for DB2 Connect Version 6 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: