Part IX: Capstones

Putting It All Together

You have spent eight parts building skills. Part I gave you foundations. Part II taught you design. Part III made you a file processing practitioner. Part IV equipped you with data manipulation tools. Part V taught you modularity. Part VI brought you into the world of databases and transactions. Part VII gave you professional development practices. Part VIII showed you the enterprise architecture that ties everything together.

Now it is time to use all of it at once.

The three capstone projects in Part IX are different from anything you have done in this textbook so far. They are not chapter exercises that practice a single skill. They are not case studies that illustrate a single concept. They are comprehensive projects — each one a major undertaking — that require you to integrate skills from every part of the textbook into a working, production-quality system.

This is deliberate. In the enterprise, COBOL programs do not exist in isolation. A single program might involve structured control flow (Part II), multi-file processing (Part III), string handling and table lookups (Part IV), calls to subprograms (Part V), embedded SQL and CICS transactions (Part VI), systematic testing (Part VII), and awareness of batch pipeline architecture (Part VIII). The capstone projects are designed to exercise all of these skills together, because that is how they are used in practice.

The capstones are also designed to be challenging. They will stretch you. They will require you to make design decisions without being told the "right" answer, because in many cases there is no single right answer — there are tradeoffs, and the skill is in evaluating those tradeoffs and making a defensible choice. They will require you to manage complexity — multiple programs, multiple files, multiple data structures, multiple processing steps — at a scale larger than anything you have tackled before. And they will require you to produce not just working code but code that meets the quality standards this textbook has established: readable, well-structured, defensively programmed, and thoroughly tested.

If Part I through Part VIII taught you the notes, Part IX asks you to play the symphony.

Capstone 1: A Complete Banking System (Chapter 43)

The first capstone project brings GlobalBank's core banking system to life. You will design and implement a simplified but realistic core banking system that handles account management, transaction processing, interest calculation, and statement generation. The system spans batch and online processing, uses DB2 for persistent data storage, and is structured as a modular collection of COBOL programs that call each other through well-defined interfaces.

This capstone integrates skills from every part of the textbook:

From Part II, you will apply structured programming principles and defensive programming techniques to every program in the system. Each program will follow the main-control pattern, use meaningful paragraph names, employ scope terminators consistently, and validate all inputs.

From Part III, you will implement file-based processing for transaction intake (reading daily transaction files), statement generation (producing formatted customer statements), and regulatory reporting (creating fixed-format extract files for submission to regulatory agencies).

From Part IV, you will use string handling to parse and format account data, table processing to manage in-memory lookup tables (transaction codes, interest rate tiers, branch information), and date processing for interest calculation and statement date ranges.

From Part V, you will decompose the system into modular subprograms: a date utility, a validation module, an interest calculation engine, a transaction posting routine, and a statement formatting module. Each subprogram will have a clean interface defined through the LINKAGE SECTION, and all parameter passing will follow the conventions established in Part V.

From Part VI, you will implement DB2 database access for account and transaction data, CICS online programs for account inquiry and transaction entry, and transaction design patterns that ensure data integrity in a concurrent processing environment.

From Part VII, you will develop a test plan for the system, create unit tests for key subprograms, and perform code review using the checklist approach covered in the quality chapter.

From Part VIII, you will design the batch processing pipeline — the sequence of jobs that runs nightly to post transactions, calculate interest, assess fees, and generate statements — with checkpoint/restart capability and control file balancing.

The scope is deliberately ambitious. A real core banking system has millions of lines of code; your capstone will have thousands. But the patterns, the architecture, the design decisions, and the professional practices will be the same patterns, architecture, decisions, and practices that Maria Chen and her team apply to GlobalBank's production system every day.

Maria herself might comment on the capstone's design: "This is a toy system by production standards. But the habits it builds are production habits. If you can design this system well — if you can make the pieces fit together, handle the edge cases, and produce code that another programmer can read and trust — you are ready for the real thing."

Capstone 2: A Legacy Modernization Case Study (Chapter 44)

The second capstone project gives you something that no amount of new-code development can provide: experience with legacy code. You will receive a pre-written COBOL system — deliberately designed to reflect the characteristics of real legacy code — and your task will be to understand it, document it, assess it, and modernize it.

The legacy system is a claims processing application inspired by MedClaim. It was "written" in a style that reflects the conventions of the 1980s: minimal comments, cryptic data names, GO TO-based control flow, no copybooks, no subprograms, hardcoded values, and business logic buried in deeply nested conditionals. It works — it processes claims and produces correct output — but it is unmaintainable by modern standards.

Your modernization task proceeds in phases:

Phase 1: Archaeology. Read the code. Understand what it does. Document the business rules it implements. Create a program flow diagram. Identify the data structures and their relationships. This phase exercises the legacy code archaeology skills from Part VIII, Chapter 41.

Phase 2: Assessment. Evaluate the code against the quality standards established in Part VII. Identify specific problems: dead code, unreachable paragraphs, unvalidated inputs, missing error handling, hardcoded values that should be parameterized, and business logic that should be extracted into subprograms.

Phase 3: Refactoring. Restructure the code without changing its behavior. Replace GO TO with structured control flow. Add scope terminators. Rename data items to be meaningful. Extract copybooks for shared data definitions. Decompose the monolithic program into subprograms with clean interfaces. Add defensive checks for input validation and error handling. This phase is the most demanding — it requires you to modify working code carefully, testing after each change to ensure that you have not broken anything.

Phase 4: Enhancement. With the code modernized, add a new feature: a capability that the business has requested but that the original legacy code could not accommodate without major surgery. The refactored code, with its modular structure and clean interfaces, should make this enhancement straightforward — demonstrating that the investment in modernization pays dividends when the system needs to evolve.

This capstone is unique in that it starts with someone else's code rather than a blank page. That is deliberate, because in the enterprise, you will spend far more time reading and modifying existing code than writing new code from scratch. The ability to take a messy, undocumented program and transform it into a clean, maintainable one — without breaking it in the process — is one of the most valuable skills a COBOL programmer can possess.

James Okafor at MedClaim would recognize this capstone immediately. "We do this kind of work every quarter," he says. "Take a legacy module, understand it, clean it up, add the new feature the business needs. It is not glamorous work. But it is essential work, and doing it well requires every skill you have."

Capstone 3: Batch-to-Real-Time Migration (Chapter 45)

The third capstone project addresses one of the most common — and most challenging — modernization scenarios in enterprise computing: migrating a process from batch to real time.

You will start with a batch COBOL system that processes insurance policy renewals. The current system runs nightly: it reads a file of policies approaching their renewal date, calculates renewal premiums based on claims history and rate tables, generates renewal notices, and updates the policy database. This batch process works, but the business wants to offer real-time renewal quoting — the ability for an agent or a customer on the web to request an immediate renewal quote, see the premium, and approve the renewal online.

This migration requires you to:

Analyze the batch system to understand its processing logic, identify which parts can be reused in a real-time context, and determine which parts must be redesigned.

Design the real-time architecture. The real-time system will be a CICS application that accepts renewal requests, invokes the premium calculation logic, displays the result, and processes the renewal if approved. The premium calculation logic — the core business rules — should be extracted into subprograms that both the batch and real-time systems can call, avoiding code duplication.

Implement the CICS application with pseudo-conversational design, BMS screens, DB2 database access, and the error handling that online applications require.

Maintain the batch system alongside the real-time system. The batch process does not go away — it still handles policies that are not renewed online, generates reminder notices, and performs end-of-day reconciliation. The two systems must coexist, sharing the same database and the same business logic subprograms.

Test the integrated system to verify that batch and real-time processing produce consistent results, that database integrity is maintained when both systems access the same data, and that the real-time system meets response time requirements.

This capstone is the most architecturally complex of the three. It requires you to think at the system level — not just about individual programs but about how programs interact, how data flows between batch and online processing, and how to manage the transition from one architectural pattern to another without disrupting operations.

Derek Washington at GlobalBank has lived through a similar migration. "We moved the balance inquiry from batch-updated snapshots to real-time DB2 queries," he recalls. "The technical work was significant, but the hardest part was the transition — running both systems in parallel, verifying that they produced the same results, and gradually shifting traffic to the real-time system while keeping the batch system as a fallback. That transition planning is what separates a successful migration from a failed one."

What the Capstones Demand

Each capstone project is designed to take significant effort — comparable to a major term project or a professional development assignment. They are not exercises you will finish in an evening. They are projects that require planning, design, iterative development, testing, and refinement.

The capstones demand:

Integration. You cannot complete any capstone by applying skills from a single part of the textbook. Each capstone requires you to combine file processing, data manipulation, modular design, database access, transaction processing, testing, and architectural thinking into a coherent whole.

Judgment. The capstone specifications are deliberately less prescriptive than chapter exercises. You will need to make design decisions — how to structure the programs, how to design the database, how to organize the batch pipeline, how to handle error conditions — and defend those decisions based on the principles you have learned.

Quality. The capstone deliverables are not just working programs. They include documentation, test plans, and code that meets the readability and maintainability standards established throughout the textbook. Producing code that works is necessary but not sufficient.

Persistence. The capstones are hard. You will get stuck. You will make design decisions that you later regret and have to undo. You will encounter bugs that take hours to diagnose. This is normal. This is what enterprise programming feels like. The ability to persist through difficulty, to debug systematically rather than randomly, and to deliver a complete, working system despite the challenges — that is the ultimate skill this textbook aims to develop.

The Characters' Farewell

The characters who have guided you through this textbook — Maria, Derek, Priya, James, Sarah, Tomas — are composites drawn from the experiences of real enterprise COBOL professionals. Their challenges are real challenges. Their mistakes are real mistakes. Their insights are real insights.

As you work through the capstone projects, imagine them looking over your shoulder. Maria is checking your program structure and your defensive coding. Derek is asking why you made that design decision and whether there is a better way. Priya is reminding you of what it felt like to be confused by legacy code and encouraging you to write code that future Priyas can understand. James is verifying that your business logic matches the requirements exactly. Sarah is reading your code and asking whether it does what the documentation says it does. Tomas is checking whether your batch jobs will actually run in the production environment.

If all six of them would approve your work, you have succeeded.

Beyond the Capstones

When you complete the capstone projects, you will have done something significant: you will have moved from a beginning COBOL programmer to an intermediate one. You will have skills that are in demand at enterprises around the world. You will be able to read, write, maintain, and modernize COBOL systems that process the transactions, claims, and data flows that global commerce depends on.

But "intermediate" is not the end of the journey. There are advanced topics beyond the scope of this textbook — COBOL compiler internals, advanced DB2 optimization, CICS system programming, mainframe capacity planning, and the deep domain expertise that comes only from years of experience with specific business systems. The intermediate skills you have developed here are the foundation for that continued growth.

The COBOL ecosystem needs you. The systems that run the world need programmers who understand them — programmers who can maintain them, modernize them, and ensure that they continue to serve the businesses and the people who depend on them. You are now equipped to be one of those programmers.

The programs you write from this point forward will run in production environments where they matter. Write them with care. Write them with discipline. Write them with the knowledge that someone — perhaps decades from now — will read your code and either thank you for its clarity or curse you for its obscurity.

Choose to be thanked.