Preparing DB2 Application Plans › Connecting Plans to Applications › Specifying Plans Independently of Transaction-IDs in CICS › DB2ENTRY PLANEXIT Versus Plan Name Exit

DB2ENTRY PLANEXIT Versus Plan Name Exit

In summary, two types of exits are involved in plan switching in CA Ideal.

CA Ideal supplies the Planexit named @IADRCTX for use in the CICS environment. You cannot modify it. The CICS attach facility calls it when the first SQL statement is executed in a logical unit of work. The DB2ENTRY for this transaction-ID specifies PLNEXITNAME=@IADRCTX.

The plan name exit is available under CICS. The user supplies it as needed. (You can use the sample exits described in previous pages.) CA Ideal calls it at the point when CA Ideal is about to call the CICS attach facility with the first SQL statement in a logical unit of work. This exit can also modify the plan name to use. Under CICS, CA Ideal stores its plan name in a CICS temporary storage record for later access by the exit. (The exit in turn provides the plan name to the DB2 attach facility.)

When you use a plan name exit to modify the plan name or select a new plan name, the new value is not available to the $PLAN function. This means that the plan DB2 uses might not be the same as the plan the $PLAN function returned. The plan that DB2 actually uses can display in an Error Procedure as the value of the function $ERROR-DB2-PLAN.

If an application calls a non-Ideal subprogram that executes SQL statements and if that SQL might be the first in a logical unit of work, then you must specify Y (yes) for the Update DB2? field on the non-Ideal program IDE panel, even if the SQL in the subprogram does not actually update DB2.

If an application calls a non-Ideal subprogram that is identified as containing SQL, CA Ideal assumes that the SQL is executed. Therefore, if the call is detected in a new logical unit of work before the first SQL statement in CA Ideal, it is assumed to be the first SQL request in the new logical unit of work. The CA Ideal plan name exit, if enabled, is invoked before calling the non-Ideal subprogram. The non-Ideal subprogram is identified in the plan name exit's parameter list as PLAN-SUB-PROGRAM.

Example

Consider the following scenarios to understand better.

You can use the SET $PLAN PDL statement to optionally specify a logical identifier for the next plan to use. This logical identifier is not necessarily the actual plan name. This level of indirection lets you avoid hard coding actual plan names in your programs (which require compilation for any change to plan names). This is useful, for example, if the plan name at a satellite location is slightly different from the plan name used at the development site. Since the program specifies a logical identifier, you can choose the actual plan name outside the PDL code based on site considerations. But the CA Ideal plan name exit can base the choice of actual plan name on any available criteria. Use of SET $PLAN is entirely optional.

1. At customer site ABC, program names are always six characters long. Each program has its own plan. In the Development environment, plan names are formed by prefixing a D before the program name and in production, by prefixing a P. In this example, the SET $PLAN statement is not used. The CA Ideal plan name exit program simply checks for the current program name and generates the appropriate plan name.
2. At customer site XYZ, plan names are generated by a more complex algorithm. The program can generate a character string at the start of any logical unit of work. The letter X is prefixed to form the actual plan name. In this case, the SET $PLAN statement specifies the generated string, for example, SET $PLAN = 'PLAN03'. The plan name exit then prefixes an X, resulting in an actual plan name of XPLAN03.
3. At customer site PQR, plan names are actually hard coded in the program. In this case, the program specifies SET $PLAN = 'xxxx', and there is no CA Ideal plan name exit. The string specified as xxxx becomes the actual plan name.