Part VI: Database and Transaction Processing

Where COBOL Meets the Database

Parts II through V built your skills in writing well-structured, modular COBOL programs that process files and manipulate data. Those skills are necessary and valuable. But they are not sufficient for the work that most enterprise COBOL programmers actually do, because most enterprise COBOL programs do not operate in isolation — they interact with databases and transaction processing monitors that manage shared data across thousands of concurrent users.

This is where the story changes. File processing is largely a single-user, single-program affair: your program opens a file, processes it, and closes it. Database and transaction processing is a multi-user, multi-program affair: your program accesses shared data that hundreds of other programs — and thousands of online users — are accessing at the same time. The rules change. The risks multiply. The skills required go beyond COBOL syntax into the realm of database design, transaction semantics, concurrency control, and systems architecture.

Part VI takes you into this territory. It is, by many measures, the most important part of this textbook, because database and transaction processing is what the majority of production COBOL programs do. The ATM transaction that debits your checking account, the insurance claim that gets adjudicated while you wait on the phone, the airline reservation that books your seat before someone else takes it — all of these involve COBOL programs interacting with databases through transaction processing monitors, and all of them depend on the concepts and skills covered in these six chapters.

DB2 and Embedded SQL: The Relational World

IBM's DB2 is the dominant relational database in the mainframe world, and the majority of new COBOL database programming involves embedded SQL — SQL statements coded directly within COBOL programs, compiled by a special precompiler that translates the SQL into COBOL CALL statements to the DB2 runtime.

If you have studied SQL in a database course, you know the language: SELECT, INSERT, UPDATE, DELETE, JOIN, WHERE, GROUP BY. Embedded SQL in COBOL uses the same SQL — the same syntax, the same semantics, the same relational logic. What differs is the context. Instead of typing SQL into an interactive query tool, you embed it in a COBOL program, surrounded by EXEC SQL and END-EXEC delimiters. Instead of seeing results on a screen, you receive them in COBOL data items defined in WORKING-STORAGE or the LINKAGE SECTION. Instead of dealing with one query at a time, you write programs that issue dozens or hundreds of SQL statements as part of a larger business process.

The integration between COBOL and SQL is both elegant and intricate. Host variables — COBOL data items referenced in SQL statements — bridge the gap between COBOL's fixed-field data model and SQL's relational data model. The SQLCA (SQL Communication Area) reports the success or failure of each SQL operation, and checking SQLCODE after every SQL statement is the database equivalent of checking FILE STATUS after every file operation. Cursors allow COBOL programs to process multi-row result sets one row at a time, which fits naturally into COBOL's record-at-a-time processing style.

At GlobalBank, DB2 is the primary database for the core banking system. Account balances, transaction histories, customer demographics, loan details — all reside in DB2 tables. Maria Chen's team writes COBOL programs that issue embedded SQL to query and update these tables, and they do so within the framework of CICS transactions that ensure consistency and recoverability.

Learning embedded SQL in COBOL is not just about syntax. It is about understanding the interaction between two very different programming paradigms: COBOL's procedural, record-at-a-time approach and SQL's declarative, set-at-a-time approach. A good COBOL/DB2 programmer knows how to write SQL that the DB2 optimizer can execute efficiently, how to design cursor-based processing that minimizes lock contention, and how to handle the error conditions that database operations inevitably produce.

CICS: The Transaction Processing Monitor

If DB2 is the database, CICS (Customer Information Control System) is the traffic cop. CICS is a transaction processing monitor — a piece of system software that manages the execution of online transactions, handling the details that make concurrent multi-user processing possible: terminal I/O, task management, storage management, program loading, security, logging, and recovery.

When a bank teller enters an account number on a terminal and presses Enter, CICS receives the request, starts a task, loads the appropriate COBOL program, provides it with the terminal input, and manages its execution. The COBOL program processes the request — reading from and writing to DB2 databases, formatting screens, calling subprograms — and CICS manages the transaction boundaries: the points at which the program's changes to shared data become permanent (COMMIT) or are rolled back (ROLLBACK).

CICS programming in COBOL has its own vocabulary and its own patterns. You will learn about EXEC CICS commands: SEND MAP and RECEIVE MAP for terminal I/O, READ and WRITE for VSAM file access, LINK and XCTL for program-to-program communication, SYNCPOINT for transaction control, and HANDLE CONDITION (or the more modern RESP/RESP2 approach) for error handling. You will learn about the BMS (Basic Mapping Support) facility for defining screen layouts, about pseudo-conversational programming (the dominant pattern for CICS online programs, where the program returns control to CICS between user interactions to free resources), and about the COMMAREA (Communication Area) that carries data between pseudo-conversational program iterations.

At MedClaim, CICS is the platform for the online claims inquiry system. When a customer service representative looks up a claim status, a CICS COBOL program receives the inquiry, queries DB2 for the claim details, formats the information on a BMS screen, and sends it to the representative's terminal. The representative can then view related claims, check payment history, or initiate a review — each action triggering another CICS transaction that another COBOL program handles.

Priya Kapoor at GlobalBank found CICS programming to be the steepest learning curve of her first year. "Batch programs are linear," she explains. "They start, they process, they end. CICS programs are event-driven — they respond to user actions, they manage state across interactions, and they share resources with hundreds of other tasks running at the same time. It is a different way of thinking about programming."

She is right. And Part VI is designed to teach you that different way of thinking.

IMS: The Hierarchical Alternative

Before relational databases and DB2, there was IMS (Information Management System) — IBM's hierarchical database system, first released in 1966 for the Apollo space program. IMS organizes data in a tree structure: parent segments contain child segments, which can contain their own child segments, in a hierarchy that naturally models many business data relationships (a customer has accounts, an account has transactions, a transaction has detail lines).

IMS is less prominent today than DB2, but it is far from gone. Many large enterprises — particularly in banking, insurance, and government — still run IMS databases that contain decades of critical data. These databases are stable, fast (IMS's hierarchical access paths are highly optimized), and deeply integrated with the business processes that depend on them.

Part VI covers IMS because an intermediate COBOL programmer working in the enterprise will likely encounter it. You may not write new IMS programs from scratch, but you may need to read and maintain existing IMS programs, query IMS databases from COBOL, or participate in projects that migrate data from IMS to DB2. Understanding IMS's data model, its DL/I (Data Language/I) call interface, and its relationship to COBOL programs is a practical necessity.

James Okafor at MedClaim has firsthand experience with IMS-to-DB2 migration. MedClaim's original claims database was an IMS database designed in the early 1990s, and a multi-year migration project moved the data to DB2 while keeping the IMS database online for historical queries. The migration required COBOL programs that could access both IMS and DB2 within the same transaction — a challenging integration that demanded deep understanding of both database systems.

Transaction Design Patterns

Database and transaction processing is not just about syntax — EXEC SQL, EXEC CICS, CALL 'CBLTDLI'. It is about design: how you structure your programs to interact correctly with databases and transaction monitors in a concurrent, multi-user environment.

Part VI covers several transaction design patterns that are fundamental to enterprise COBOL:

The Unit of Work Pattern defines the boundaries of a logical transaction — the set of database operations that must either all succeed or all fail. In COBOL/DB2, this is managed through COMMIT and ROLLBACK. In CICS, it is managed through SYNCPOINT. Getting the unit of work boundaries right is critical: too broad, and you hold locks on shared data for too long, causing other transactions to wait; too narrow, and you lose the ability to roll back a partial update if something goes wrong.

The Pseudo-Conversational Pattern is the standard architecture for CICS online programs. Rather than keeping a task active (and consuming resources) while a user reads a screen, the program terminates after sending the screen, and CICS starts a new task when the user responds. The COMMAREA carries state between iterations. This pattern is resource-efficient but requires careful state management — a skill that Part VI will develop.

The Cursor-Based Processing Pattern handles multi-row database queries in COBOL's record-at-a-time style. DECLARE CURSOR, OPEN, FETCH in a loop, CLOSE — this pattern is the bridge between SQL's set-oriented results and COBOL's sequential processing model. Performance considerations (cursor stability vs. repeatable read, fetch-ahead buffers, limiting result sets with WHERE clauses) are critical for production programs.

The Error Recovery Pattern ensures that database and transaction errors are handled gracefully. SQLCODE checking after every SQL statement, RESP/RESP2 checking after every CICS command, and the decision logic that determines whether an error is retryable (try again), recoverable (roll back and report), or fatal (abend with diagnostic information).

The Stakes Are Higher

Database and transaction processing raises the stakes of everything you have learned. In file processing, a bug might corrupt a file — serious, but recoverable from a backup. In database processing, a bug might corrupt shared data that hundreds of programs and thousands of users depend on. In file processing, performance inefficiency slows down one batch job. In database processing, performance inefficiency causes lock contention that degrades the entire system for every user.

The defensive programming theme of this textbook reaches its fullest expression in Part VI. Every SQL statement must be checked. Every CICS command must be checked. Every transaction boundary must be correct. Every error path must be handled. The programs you write in Part VI interact with shared, persistent, critical data, and the quality bar is correspondingly high.

What Part VI Covers

The six chapters in Part VI take you from database fundamentals to advanced transaction design:

Chapter 27: Introduction to Embedded SQL covers the basics of COBOL/DB2 programming: host variables, the SQLCA, the precompilation process, and the fundamental SQL operations — SELECT INTO, INSERT, UPDATE, DELETE — embedded in COBOL.

Chapter 28: Advanced DB2 Programming covers cursors, dynamic SQL, stored procedures, and the performance considerations — EXPLAIN, index usage, access path optimization — that distinguish competent DB2 programming from mere syntax knowledge.

Chapter 29: CICS Fundamentals introduces the CICS environment: task management, terminal I/O with BMS, program control (LINK, XCTL, RETURN), and the CICS programming model that governs how COBOL programs interact with the transaction monitor.

Chapter 30: CICS Application Design covers pseudo-conversational programming, COMMAREA design, screen navigation patterns, and the architectural decisions that determine whether a CICS application is robust and responsive or fragile and slow.

Chapter 31: IMS Database Programming covers the hierarchical data model, DL/I calls from COBOL, segment search arguments, and the practical skills for working with IMS databases in modern enterprise environments.

Chapter 32: Transaction Design Patterns synthesizes the preceding chapters into design-level guidance: unit of work design, concurrency management, error recovery strategies, and the patterns that experienced enterprise programmers apply to build reliable, performant transaction processing systems.

The Heart of Enterprise COBOL

Part VI is the heart of this textbook because database and transaction processing is the heart of enterprise COBOL. When people say that COBOL processes 95% of ATM transactions, they are talking about COBOL programs that interact with DB2 databases through CICS transactions. When people say that COBOL handles 80% of in-person retail transactions, they are talking about the same kind of programs. The skills in Part VI are not academic; they are the skills that keep the lights on.

Master them. The enterprise is counting on you.