Binding applications and utilities (Db2 Connect Server)

Application programs developed using embedded SQL must be bound to each database with which they will operate. For information about the binding requirements for the IBM® data server package, see the topic about Db2® CLI bind files and package names.

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 an IBM mainframe database server.

Because several of the utilities supplied with Db2 Connect are developed using embedded SQL, they must be bound to an IBM mainframe 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 IBM mainframe database servers. The lists of bind files required by these utilities are contained in the following files:
  • ddcsmvs.lst for System z®
  • ddcsvse.lst for VSE
  • ddcsvm.lst for VM
  • ddcs400.lst for IBM Power Systems

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 IBM mainframe 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 for z/OS® via Db2 Connect Enterprise Edition on a Windows server, perform one of the following steps:
  • 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.
This example assumes that:
  • 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.

For each IBM mainframe database server that you are binding to, perform the following steps:
  1. Make sure that you have sufficient authority for your IBM mainframe database server management system:
    System z
    The authorizations required are:
    • SYSADM or
    • SYSCTRL or
    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 previously 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
    • system.sysuserauth
    On the VSE or VM system, you can issue:
       grant select on table to nullid with grant option
    IBM Power Systems
    *CHANGE authority or higher on the NULLID collection.
  2. Issue commands similar to the following commands:
       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 IBM mainframe 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, 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
    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
    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 IBM mainframe 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 IBM mainframe database server. Also, to connect to a Db2 database, it is recommended that you use the Db2 clients provided 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.