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.

• ddcsmvs.lst for OS/390^® or z/OS^®

• ddcsvse.lst for VSE

• ddcsvm.lst for VM

• ddcs400.lst for OS/400^®

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.

• Bind ddcsmvs.lst from one of the Windows clients.

• Bind ddcsmvs.lst from one of the AIX clients.

• Bind ddcsmvs.lst from the DB2 Connect server.

• All the clients are at the same service level. If they are not then, in addition, you might need to bind from each client of a particular service level

• The server is at the same service level as the clients. If it is not, then you need to bind from the server as well.

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.

1. Make sure that you have sufficient authority for your host or System i database server management system:

   OS/390 or z/OS

   The authorizations required are:

   • 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.

   VSE or VM

   The authorization required is DBA authority. If you want to use the GRANT option on the bind command (to avoid granting access to each DB2 Connect package individually), the NULLID user ID must have the authority to grant authority to other users on the following tables:

   • 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

   OS/400

   *CHANGE authority or higher on the NULLID collection.

2. Issue commands similar to the following:

      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 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.lst

   For example:

      ddcspkgn @ddcsmvs.lst

   might yield the following output:

                                                                         
    Bind File                      Package Name                          
    ------------------------------ ------------------------------        
    f:\sqllib\bnd\db2ajgrt.bnd     SQLAB6D3                                                                       

   To determine these values for DB2 Connect 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

   Note:

   1. Using the bind option sqlerror continue is required; however, this option is automatically specified for you when you bind applications using the DB2^® tools or the Command Line Processor (CLP). Specifying this option turns bind errors into warnings, so that binding a file containing errors can still result in the creation of a package. In turn, this allows one bind file to be used against multiple servers even when a particular server implementation might flag the SQL syntax of another to be invalid. For this reason, binding any of the list files ddcsxxx.lst against any particular host or System i database server should be expected to produce some warnings.

   2. If you are connecting to a DB2 database through DB2 Connect, use the bind list db2ubind.lst and do not specify sqlerror continue, which is only valid when connecting to a host or System i database server. Also, to connect to a DB2 database, it is recommended that you use the DB2 clients provided with DB2 and not DB2 Connect.

3. Use similar statements to bind each application or list of applications.

4. If you have remote clients from a previous release of DB2, you might need to bind the utilities on these clients to DB2 Connect.

Related reference
BIND command REBIND command db2rbind - Rebind all packages command