DB2 Connect User's Guide

Binding Applications and Utilities

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 4, 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:

ddcsmvs.lst

For MVS or OS/390

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 DB2 Connect Enterprise Edition 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 server, do the following:

1. Bind ddcsmvs.lst from one of the Windows clients.
2. Bind ddcsmvs.lst from one of the OS/2 clients.
3. Bind ddcsmvs.lst from one of the AIX clients.
4. Bind ddcsmvs.lst from the DB2 Connect server.

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:

1. Make sure that you have sufficient authority for your host or AS/400 database server management system:

   MVS or OS/390

   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 AS/400 database server, ddcsmvs.lst is the bind list file for MVS, and path represents 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 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, 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 4 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 4. 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

   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
   

   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.

   For more information on bind options, refer to the Command Reference.

   Notes:

   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. 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 may 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 AS/400 database server should be expected to produce some warnings. For example, when binding against DB2 for VM, numerous warning messages may result since DB2 for VM does not permit cursors to be declared as "WITH HOLD".

   2. If you are connecting to a DB2 Universal Database 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 AS/400 database server. Also, to connect to a DB2 Universal Database database, we recommend 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 may need to bind the utilities on these clients to DB2 Connect. See Appendix E, Binding Utilities for Back-Level Clients for more information.