Considerations for binding packages at a remote location

Scope of a remote bind

When you bind or rebind a package at a remote site, DB2® checks authorizations, reads and updates the catalog, and creates the package in the directory at the remote site. DB2 does not read or update catalogs or check authorizations at the local site.

After you bind a remote package, you can bind, rebind, or free the remote package from the local site or at the remote site.

Authorization for binding and running packages at a remote location

To bind a package at a remote DB2 system, you must have all the privileges or authority there that you would need to bind the package on your local system. To bind a package at another type of a system, such as DB2 for Linux, UNIX, and Windows, you need all privileges that the other system requires to execute the SQL statements in the package, and to access the data objects to which the package refers.

Communications database requirements for binding packages at a remote location

When you bind a package at a remote site, the local communications database must be able to resolve the location name in the package to a remote location.

Remote access through a stored procedure

If a local stored procedure uses a cursor to access data, and the cursor-related statement is bound in a separate package under the stored procedure, you must bind this separate package both locally and remotely. In addition, the invoker or owner of the stored procedure must be authorized to execute both local and remote packages. At your local requesting system, you must bind a plan whose package list includes all of those local and remote packages.