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
- SyncPoints
- DB2 Plan
- CICS Transaction Role
- CICS to DB2 Connection Types
- Plan Packages
- Security
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.
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.
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.
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.
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.
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.