Overview: Enabling CICS application programs to access Db2
A CICS® application program that accesses Db2® must be prepared in the same way as a normal CICS application program, and must also go through the Db2 bind process to produce an application plan (often just called a plan). Each plan contains the bound form of all the SQL statements from the application programs that use it, and it allows those application programs to access Db2 data at run time.
The plans are held in Db2, and each thread into Db2 relates to a plan. The plan that each type of thread uses is named on the DB2CONN definition (for pool threads) or the thread's DB2ENTRY definition (for entry threads). The plan for a particular type of thread must contain the bound form of the SQL statements from all the application programs that use that type of thread to access Db2. You can either name the plan explicitly or name a dynamic plan exit. A dynamic plan exit is a routine that determines which plan to use for the transaction that has requested a thread of that type.
Preparing a CICS application program that accesses Db2
A CICS application program that access DB must be put through a number of processes to build a DBRM and create the application load module before it enters the bind process.
Figure 1 shows the steps in preparing a CICS application program to access Db2.
The first step is to put the program through the Db2 precompiler. The Db2 precompiler builds a database request model (DBRM) that contains information about each of the program's SQL statements.
The second, third and fourth steps are the normal process for preparing any CICS application program, whether or not it accesses Db2. The second step is to put the program through the CICS command language translator. The third step is to compile or assemble the program. The fourth step is to link-edit the program with the necessary interfaces (including the CICS Db2 language interface module DSNCLI). The end product of Steps 2, 3 and 4 is an application load module that enables the program to run. For more information on these steps, see CICS Db2 program preparation.
An extra step is required to enable the program to use the information in the DBRM that was created in Step 1. This fifth step is the bind process. The bind process requires Db2, and it uses the DBRM to produce an application plan that enables the program to access Db2 data.
If you are using one of the Language Environment®-conforming compilers for COBOL and PL/I, you can combine some of these steps into a single task, because these compilers have integrated the CICS command language translator, and (depending on your version of Db2) an SQL statement coprocessor. See CICS Db2 program preparation for more information.
The bind process
- Db2
- The DBRM (database request module) produced by the Db2 precompiler for each program in the application
The DBRM contains the SQL statements that the Db2 precompiler has extracted from the application program. In the bind process, the SQL statements in the DBRM are put into an operational (“bound”) form, by being translated into the control structures that Db2 uses when it runs SQL statements. The resulting material can be made into a package, or it can be placed straight into an application plan (see Plans, packages and dynamic plan exits). The whole process is called binding the DBRM. For more information on binding, see Programming for Db2 for z/OS in Db2 for z/OS product documentation. See Bind options and considerations for programs for more detail on options you should choose during the bind process in the CICS Db2 environment.