See The bind process for an overview of the bind process.
When binding multiple programs into an application plan, be aware of the way in which DB2® uses time stamps. For each program, the DB2 precompiler:
At bind time, the DBRM for each program is bound into the package or plan that you have specified. In addition, DB2 updates its catalog table SYSIBM.SYSDBRM with one line for each DBRM, together with its time stamp. At execution time, DB2 checks the time stamps for each SQL statement, and returns a -818 SQL code if the time stamp for the DBRM and the time stamp it has placed in the source program are different (in our example, if Td1 and Ts1 are different, or Td2 and Ts2 are different). To avoid -818 SQL codes, use one of the following strategies:
When you bind a plan, a number of options are available. Almost all bind options are application dependent and should be taken into account during the application design. You should develop procedures to handle different BIND options for different plans. Also, the procedures should be able to handle changes in BIND options for the same plan over time.
The following sections describe some specific recommendations for BIND options with CICS®:
RETAIN® means that BIND and EXECUTE authorities from the old plan are not changed.
When the RETAIN option is not used, all authorities from earlier GRANTs are REVOKED. The user executing the BIND command becomes the creator of the plan, and all authorities must be reestablished by new GRANT commands.
This is why it is recommended that you use the RETAIN option when binding your plans in the CICS environment.
It is recommended that you use Cursor Stability (CS) unless there is a specific need for using Repeatable Read (RR). This is recommended to allow a high level of concurrency and to reduce the risk of deadlocks.
Note that the isolation level is specified for the complete plan. This means that if RR is necessary for a specific module in CICS, then all the DBRMs included in the plan must also use RR.
Also, if for performance reasons you decide to group a number of infrequently used transactions together to use the same DB2ENTRY and let them use a common plan, then this new plan must also use RR, if just one of the transactions requires RR.
A plan is bound with VALIDATE(RUN) or VALIDATE(BIND). VALIDATE(RUN) is used to determine how to process SQL statements that cannot be bound.
If a statement must be bound at execution time, it is rebound for each execution. This means that the statement is rebound for every new unit of work (UOW).
Binding a statement at execution time can affect performance. A statement bound at execution time is rebound for each execution. That is, the statement must be rebound after each syncpoint. It is not recommended that you use this option with CICS.
Note that using dynamic SQL does not require VALIDATE(RUN). Nevertheless, dynamic SQL implies that a statement is bound at execution.
You should use VALIDATE(BIND) in a CICS DB2 environment.
The general recommendations for these parameters are described in Selecting BIND options for optimum performance. The parameters change from plan to plan and over time, because they are related to the transaction rate.