CICS and DB2

If you have any questions about the content of this page, please contact CICS Requests for  clarification

This section discusses CICS considerations regarding  DB2:


Compilation Process

CICS DB2 programs are compiled  with special CICS Batch Procedures. A DB2 pre-compiler step is executed ahead of  the normal CICS pre-compiler. A batch TSO step is executed after the linkedit to  perform the plan bind process. The DB2 pre-compiler converts EXEC SQL statements  to COBOL calls, much like the CICS pre-compiler converts EXEC CICS statements to  COBOL calls. The DB2 pre-compiler creates a DBRMLIB (bound database request  module) entry that is passed to the bind step. The bind step at the end is told  the DB2 target system and the plan name and type. It uses that information along  with the DBRMLIB data to construct the Plan.


You must not use EXEC SQL COMMIT or EXEC SQL ROLLBACK commands in a CICS  application. Since CICS is the coordinator of the two phase commit process, you  must use EXEC CICS SYNCPOINT or EXEC CICS SYNCPOINT ROLLBACK commands instead.

DB2 Plan

The DB2  plan contains date and time stamps, and all the details about how DB2 data is to  be handled by programs. It is used by DB2 while CICS programs are accessing DB2.  They have names and come in a variety of types, more later.

CICS Transaction Role

The  first thing to grasp is the tie between the DB2 PLAN (name and type) and the  CICS transaction. The DB2 to CICS connection type is specified at the  transaction level. That is, all programs running under a particular transaction  must interact with DB2 in the same way.

CICS to DB2 Connection Types

The NWRDC was an early  user of DB2. We have seen the interface between CICS and DB2 evolve over time.  First, we had a "static" bind. A CICS transaction was bound to a unique DB2  plan. This made it very difficult to have applications that spanned multiple  programs or multiple transactions sharing DB2 programs. Next they invented  "dynamic" plan selection. That was when the plan name was defaulted to the  current program name. This was much better, but came with some troubling side  affects, particularly the need to commit updates before another DB2 program  could be invoked.

Now we have plan packages, the most flexible  arrangement yet. Simply put, your DBRMLIB entries are bound as packages. Then  the bound application plan contains "pointers" to the appropriate individual  packages. That plan is then associated with however many CICS transactions as  appropriate. Complete interaction is then permitted.

Plan Packages

We  recommend all DB2 applications be designed to use plan packages. One bound  application plan is usually defined to contain pointers to all the plan packages  for a particular institution. All that institution's CICS transactions are then  identified to use that bound application plan name. We recommend that all CICS  DB2 applications be converted to plan packages as they make it through the  maintenance cycle.

CICS And  DB2 Security

In order for a CICS program to access a DB2 plan,  CICS must be granted authority for that plan. We recommend that CICS be given  unrestricted access to DB2 plan data. As always, CICS's transaction security  (bolstered by application coding) is depended upon to insure an individual's  proper use of all CICS resources including DB2.