CICS and DB2

CICS is the online transaction manager and DB2 is where the data lives. This module shows how a CICS program talks to DB2.

Why CICS programs use DB2

• CICS handles thousands of online transactions. DB2 stores the tables those transactions read and update.
• A CICS program issues SQL statements directly, written as embedded SQL inside the COBOL program.
• DB2 gives the program indexed access, locking and recovery, so the programmer does not manage files by hand.
• When a transaction updates both CICS resources (like temporary storage) and DB2 tables, CICS commits them together using two-phase commit.

How CICS connects to DB2

• CICS attaches to a DB2 subsystem through the CICS DB2 attachment facility, usually when the region starts.
• Every SQL request from a program passes through the CICS DB2 task-related user exit, DFHD2EX1, which hands it to DB2.
• The connection itself is defined by a DB2CONN resource definition. It names the DB2 subsystem and the connection behaviour.
• Each task that issues SQL runs it on a DB2 thread. Threads are controlled by DB2ENTRY definitions.

The moving parts

• DB2CONN - the connection between the CICS region and the DB2 subsystem. Only one is active per region.
• DB2ENTRY - decides which transactions use which DB2 plan and how many threads they may use.
• Plan - the bound access strategy for the program's SQL, created by the BIND step before the program runs.
• Thread - the DB2-side worker that actually executes the SQL for one CICS task.

Example

• Below is the smallest possible SQL statement inside a CICS COBOL program. It reads one customer name into a host variable.
• EXEC SQL SELECT CUSTNAME INTO :WS-CUST-NAME FROM CUSTOMER WHERE CUSTNO = :WS-CUST-NO END-EXEC.
• When this statement runs, CICS passes it through DFHD2EX1 to DB2, DB2 runs it on a thread, and the result comes back into WS-CUST-NAME.