If a plan includes dynamic SQL
When using static SQL, the binder of the plan must have the privileges needed to access the data, and the authorization ID passed from CICS to Db2® need only have the privileges to execute the plan.
About this task
However, if a plan includes the use of dynamic SQL, the authorization ID passed from CICS to Db2 must possess the privileges required to access all the Db2 resources involved, both the plan and the data. For example, if you specify AUTHTYPE(USERID), the CICS user ID must be granted Db2 privileges to the Db2 resources involved in the dynamic SQL. If this user ID is also a TSO user ID, it has access to the Db2 resources directly from SPUFI, QMF, and other utilities.
If you do not want to spend too much time granting Db2 privileges, where a transaction
executes a plan that involves the use of dynamic SQL, consider using one of the following methods of
supplying an authorization ID to Db2:
- Use the SIGN option on the AUTHTYPE attribute of the DB2ENTRY definition for the thread used by the transaction. This results in the transaction having the primary authorization ID that you specified in the SIGNID attribute of the DB2CONN definition for the CICS region. (This method is not suitable where RACF is used for security checking in the Db2 address space.)
- Use the AUTHID attribute of the DB2ENTRY definition for the thread used by the transaction, to specify a standard authorization ID. Use the same authorization ID for all the transactions that need to access dynamic SQL. (This method is not suitable where RACF is used for security checking in the Db2 address space.)
- Create a RACF group, and connect your CICS users to this RACF group. Use the GROUP attribute of the DB2ENTRY definition for the thread used by the transaction, so that the RACF group is one of the secondary IDs that is passed to Db2.