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 also go through DB2's bind process. The bind process is a DB2 process that produces 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 execution time.

The plans are held within 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 routine that determines which plan to use for the transaction that has requested a thread of that type.

For more information, read the following sections:

Preparing a CICS application program that accesses DB2

Figure 4 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 steps.

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. See The bind process for an explanation of the bind process.

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 steps for more information.

Figure 4. Steps to prepare a CICS application program that accesses DB2
 The text above explains this diagram in full.

The bind process

Before any CICS application that accesses DB2 can run, it needs to go through the bind process. For the bind process, you require:

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 the DB2 Universal Database™ for OS/390® and z/OS® Application Programming and SQL Guide. See Bind options and considerations for programs for more detail on options you should choose during the bind process in the CICS DB2 environment..

Plans, packages and dynamic plan exits

An application plan allows application programs to access DB2 data at execution time. It contains the bound (operational) form of the SQL statements from the DBRMs that were built from the application programs. It also relates the whole application process to the local instance of DB2 where it will be used.

The operational SQL statements from a DBRM can be placed straight into the plan, in which case we say that the DBRM is bound into a plan. Alternatively, you can bind a DBRM into a package (using the BIND PACKAGE command), which contains the operational SQL statements from a single DBRM. You can group related packages into collections. You can then include the package name or collection name in a list of packages, and bind the list of packages into the plan. A single plan can contain both a package list, and DBRMs bound directly into the plan. You can create a plan using the DBRMs from a single CICS application, or you can use the DBRMs from more than one application to create a single plan.

As well as being created, application plans need to be maintained. If the SQL statements change in one or more of the application programs using a plan, you need to rebuild the DBRMs for the changed application programs. If you bound the old versions of those DBRMs directly into your plan, you need to identify all the DBRMs that are bound directly into that plan, for both the changed programs and any unchanged programs, and bind them all into the plan again. While you are binding the DBRMs into the plan, applications cannot use the plan to access DB2. However, if you bound the old versions of the DBRMs for the changed application programs into packages, and then included the names of the packages (or of the collections containing them) on the package list in the plan, you do not need to bind any other packages or directly-bound DBRMs into the plan again. You simply bind the new versions of the DBRMs for the changed application programs into packages with the same names as the old versions. You do not need to bind the plan again--it locates the new versions of the packages. While you are changing the packages, application programs can still use the other packages and directly-bound DBRMs in the plan. See What to bind after a program change for more information on maintaining plans.

Each thread into DB2 relates to a plan--see Overview: How threads work for more information about threads. 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). When CICS requests the use of a thread for an application to access DB2, it tells DB2 the name of the plan associated with that type of thread, and DB2 locates the plan. The definition for each type of thread can either name a specific plan, or it can name a dynamic plan exit, a routine that determines which plan to use for the transaction that has requested the thread.

If the definition of the pool thread or entry thread names a specific plan, all the transactions that use that type of thread must use that plan. The transactions that can use a type of entry thread are specified in the DB2ENTRY and DB2TRAN definitions for the thread. If the DB2ENTRY definition for the thread names a specific plan, the DBRMs from all the application programs that could run under all those transaction IDs must be bound into the same plan, or bound into packages that are then listed in the same plan. If the DBRMs from any of the application programs that run under those transaction IDs are bound directly into the plan, and you change the SQL statements in any of those application programs, the whole plan will be inaccessible while you bind all the directly-bound DBRMs into the plan again. This means that no transaction can use that type of entry thread while you are maintaining the plan. Pool threads could be used by any of your CICS applications that access DB2, so if the DB2CONN definition names a specific plan for the pool threads, the plan needs to be prepared and maintained using the DBRMs from all those applications. If any of the DBRMs have been bound directly into the plan, the whole plan will be inaccessible during maintenance, and no transaction will be able to use a pool thread.

There are two ways to avoid making types of thread unavailable while you are maintaining plans. The best solution is to avoid binding DBRMs directly into plans, by using packages instead. If you bind each separate DBRM as a package and include them in package lists in plans, the plans are still accessible while you are maintaining individual packages. While you are carrying out maintenance work on a particular program, the pool threads or entry threads related to plans involving that program are still available, because the plans are still accessible. This means that you can safely name a specific plan for each thread. If you want to start using packages, see Using packages and the DB2 Universal Database for OS/390 and z/OS Application Programming and SQL Guide for details of how to implement packages.

An alternative solution, developed before packages were available in DB2, is to use a dynamic plan exit. Using a dynamic plan exit means that you do not have to name a specific plan for each type of thread, so even when a particular plan is inaccessible during maintenance, the threads are still available. To implement this solution, you create many small plans for your CICS applications, each containing the DBRMs from a few closely-related programs. Then, instead of specifying a plan name in the PLAN attribute of the DB2CONN or DB2ENTRY definition for each type of thread, you specify an exit program in the PLANEXITNAME attribute. When an application program issues its first SQL statement and a certain type of thread is requested, the exit program that you have specified in the thread definition selects the plan to use for that application program. If a particular plan is inaccessible during maintenance, the application programs requiring that plan cannot use a thread, but other application programs can use the same type of thread with their own plans. However, note that once a particular instance of a type of thread has been created for an application program to use, that thread instance is associated with the plan that the dynamic plan exit selected. For another application program to reuse the thread, it must use the same plan. If the dynamic plan exit selects a different plan for the application program, it must find or create a different thread with the correct plan. This reduces the opportunities for thread reuse. See Dynamic plan exits for more information on dynamic plan exits.

Related concepts
Overview of the CICS DB2 interface
Overview: How CICS connects to DB2
Overview: How threads work
Overview: How you can define the CICS DB2 connection
Requests to DB2
[[ Contents Previous Page | Next Page Index ]]