Validating authorization for executing plans or packages

The owner of a plan or package must have authorization to execute all static SQL statements that are embedded in the plan or package. A bind operation always checks whether a local object exists and whether the owner has the required privileges on it. However, you do not need to have the authorization when the plan or package is bound. The objects to which the plan or package refers do not even need to exist at bind time. If the initial checking fails, an error message is returned. You can choose whether the failure prevents the bind operation from completion by using the VALIDATE option on the BIND PLAN and BIND PACKAGE commands.

The following values for the VALIDATE option determine how Db2 is to handle existence and authorization errors:

RUN

If you choose RUN for the VALIDATE option, the bind succeeds even when existence or authorization errors exist. Db2 checks existence and authorization at run time.

BIND

If you choose BIND for the VALIDATE option, which is recommended, the bind fails when existence or authorization errors exist. Exception: If you use the SQLERROR(CONTINUE) option on the BIND PACKAGE command, the bind succeeds, but the package's SQL statements that have errors cannot execute.

The corresponding existence and authorization checks for remote objects are always made at run time. Authorization to execute dynamic SQL statements is also checked at run time. Applications that use the Resource Recovery Services attachment facility (RRSAF) to connect to Db2 do not require a plan.