What happens during SQL processing

The main DB2® activities involved in processing CICS® transactions with SQL calls are:

These main activities are performed for each transaction. The exact work involved in each activity depends on the DB2CONN and DB2ENTRY options, the BIND options, and whether packages are used.

Thread creation

The following activities can occur at thread creation time, depending on the BIND options (the authorization check is always performed at thread creation time):

The control block for an application plan, the SKCT, is divided into sections. The header and directory of an SKCT contain control information; SQL sections contain SQL statements from the application. A copy of the SKCT, the CT, is made for each thread executing the plan. Only the header and directory are loaded when the thread is created, if they are not already in the EDM pool.

The SQL sections of the plan segments are never copied into the CT at thread creation time. They are copied in, section by section, when the corresponding SQL statements are executed. For a protected thread with RELEASE(DEALLOCATE), the CT increases in size until all segments have been copied into the CT.

If the SQL statements for the transaction are bound to a package rather than a plan, DB2 uses a skeleton package table (SKPT) rather than an SKCT, and a package table (PT) rather than a CT. The SKPT is allocated when the first SQL statement is executed; it is not allocated when the thread is created.

SQL processing

The following activities can occur for each SQL statement processed, depending on thread reuse and the BIND options.

If the SQL statement is in a package, the SKPT directory and header are loaded. The PT is allocated at statement execution time, rather than at thread creation time, as in the case with the SKCT and the CT for plans bound using ACQUIRE(ALLOCATE).

Commit processing

The following activities can occur at commit time, depending on your BIND options:

Thread release

Transactions release the thread they are using at different times. If the transaction is terminal-oriented, or non-terminal-oriented and NONTERMREL=YES is specified in the DB2CONN, the thread is released at SYNCPOINT as well as at end of task (EOT). This makes it efficient to use a protected thread for transactions issuing many SYNCPOINTS, if combined with the BIND options ACQUIRE(ALLOCATE) and RELEASE(DEALLOCATE). In this case the resources to do the following activities are saved for each syncpoint:

Threads are not released at SYNCPOINT time if:

If the transaction is not terminal-oriented and you specify NONTERMREL=NO, the thread is released at EOT only. You do not need to use a protected thread to get thread reuse after an EXEC CICS SYNCPOINT command. You may still want to use a protected thread if this is a frequently used transaction. The BIND options ACQUIRE(ALLOCATE) and RELEASE(DEALLOCATE) give the same advantages as for the terminal-oriented transactions with many syncpoints.

Thread termination

The following activities can occur at thread termination time, depending on the BIND options:

Related concepts
Defining the CICS DB2 connection
Using the DB2 group attach facility
The MAXOPENTCBS system initialization parameter and TCBLIMIT
How threads are created, used, and terminated
Selecting thread types for optimum performance
Selecting BIND options for optimum performance
Coordinating your DB2CONN, DB2ENTRY, and BIND options
[[ Contents Previous Page | Next Page Index ]]