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.
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.
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.
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.
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 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.
ddcspkgn @bindfile.lst
For
example: ddcspkgn @ddcsmvs.lst
might yield
the following output:
Bind File Package Name
------------------------------ ------------------------------
f:\sqllib\bnd\db2ajgrt.bnd SQLAB6D3
ddcspkgn @ddcsmvs.lst
ddcspkgn bindfile.bnd