Chapter 41: Capstone Project -- Key Takeaways

Chapter Summary

The capstone project brings together every skill and concept covered throughout this textbook into a single, comprehensive banking application. This is not a toy example or a simplified exercise; it is a multi-program system that implements the core functions of a banking operation: customer management, account administration, transaction processing, interest accrual, fee assessment, statement generation, and regulatory reporting. The system spans all three major processing modes that enterprise COBOL applications use: batch processing (sequential file and VSAM operations driven by JCL job streams), online transaction processing (CICS-based screens for teller and customer operations), and database access (DB2 for relational data storage and SQL-based queries). Building this application demonstrates that the individual skills -- data definition, file processing, arithmetic, program structure, DB2 access, CICS programming, and testing -- combine into a coherent, production-quality system.

The chapter guided you through the full system development lifecycle as it applies to a COBOL enterprise application. It began with requirements analysis and system design: identifying the business functions the system must support, designing the data model (customer, account, transaction, and configuration tables), defining the batch job stream architecture, and specifying the CICS transaction flow for online operations. The implementation phase then built each component in a logical progression: first the shared copybooks and data structures, then the batch programs for account opening and transaction posting, followed by the CICS programs for online inquiry and transaction entry, and finally the batch programs for end-of-day processing (interest accrual, fee assessment, statement generation).

The capstone project also emphasized the non-coding aspects of enterprise COBOL development that are just as important as writing the programs: designing copybooks that are shared consistently across all programs, writing JCL that orchestrates multi-step batch processing with proper condition code checking and restart capability, implementing error handling that logs diagnostics without abending the entire batch run, building audit trails that satisfy regulatory requirements, and creating test plans that exercise both normal and exceptional processing paths. The project demonstrated that building a banking system is not about writing one brilliant program but about designing a coordinated system of programs, data structures, job streams, and operational procedures that work together reliably.

Key Concepts

• System design for a COBOL banking application begins with identifying the major subsystems (customer management, account management, transaction processing, end-of-day processing, reporting) and defining the data flows between them.
• Shared copybooks are the foundation of system consistency: the customer record copybook, account record copybook, transaction record copybook, and constants copybook are included by every program that accesses these data structures, ensuring uniform field definitions and condition names.
• The batch processing architecture defines a sequence of programs executed through JCL job streams, with each step producing output that feeds into the next: transaction sorting, validation, posting, overdraft processing, interest accrual, fee assessment, and report generation.
• CICS online programs provide real-time access to the banking system for account inquiry, balance display, transaction entry, and customer maintenance, using BMS maps for screen presentation and COMMAREA for pseudo-conversational state management.
• DB2 tables replace or complement VSAM files for data that requires relational access, SQL-based reporting, and concurrent multi-user access; the account and customer tables use DB2 while high-volume transaction processing may use VSAM for performance.
• Transaction processing in the capstone project follows the same lifecycle as production banking systems: validation (account exists, status active, sufficient funds), memo posting (available balance adjustment), and final posting (ledger balance update during batch).
• Interest accrual programs process every interest-bearing account nightly, calculating daily interest based on the account balance and rate, accumulating the accrued amount, and posting it to the account on the designated monthly posting date.
• Fee assessment programs apply monthly maintenance fees, overdraft fees, excessive transaction fees, and other charges based on account attributes and activity, using table-driven fee schedules loaded from configuration files.
• Statement generation combines account information, transaction history, interest summaries, and fee summaries into formatted output, with proper page breaks, running balances, and regulatory disclosures.
• Error handling strategy uses a hierarchical approach: individual field validation errors are logged and counted (soft errors that allow processing to continue), while system-level errors (file I/O failure, DB2 error, CICS abend) are trapped, logged, and result in controlled program termination with an appropriate return code.
• The audit trail captures every significant action: account opens and closes, transaction posts, balance changes, fee assessments, and parameter changes, with timestamp, user ID, program name, and before/after values.
• JCL design for the batch job stream includes condition code checking (IF/THEN/ELSE), restart/checkpoint logic, GDG (Generation Data Group) management for output files, and IDCAMS steps for VSAM file maintenance.
• Testing the capstone project requires test data that covers multiple account types, various transaction types and amounts, boundary conditions (zero balance, maximum balance, overdraft scenarios), and multi-day processing cycles (to verify interest accrual over time).

Common Pitfalls

• Designing programs in isolation: Each program in the system depends on shared data structures and processing conventions. Designing programs independently without coordinating copybooks, file formats, and processing sequence leads to integration failures.
• Not defining the batch job stream early: The JCL job stream defines the order of execution, file passing between steps, and error handling. Designing programs without understanding their position in the batch flow often produces programs that cannot be integrated smoothly.
• Inconsistent return code conventions: If one program uses return code 4 for warnings and another uses it for errors, the JCL condition code checking will behave unpredictably. Establish and document return code standards before coding begins.
• Skipping the design phase: Jumping directly to coding without designing the data model, processing flow, and program interfaces results in rework when programs do not fit together. Even in a learning exercise, spending time on design saves more time during implementation.
• Hardcoding configuration values: Interest rates, fee amounts, regulatory thresholds, and processing dates should be loaded from parameter files or database tables, not embedded in program source code. Hardcoded values require recompilation to change.
• Not testing end-of-day processing as a complete cycle: Testing individual programs in isolation does not verify that the full batch cycle produces correct results. Run the complete job stream with known test data and verify all outputs, including control totals, reports, and updated master files.
• Ignoring concurrent access in CICS programs: When a CICS online transaction and a batch program both access the same VSAM file or DB2 table, locking and deadlock issues can arise. Design the system to minimize contention between online and batch processing.
• Building without version control: Even a capstone project should use version control (Git) for all source code, copybooks, JCL, and test data. Without version control, tracking changes, reverting mistakes, and coordinating multi-program modifications becomes impossible.

Quick Reference

      * Shared copybook: Account record (CPYACCT)
       01  ACCT-MASTER-RECORD.
           05  ACCT-NUMBER         PIC X(12).
           05  ACCT-CIF-NUMBER     PIC X(10).
           05  ACCT-TYPE-CODE      PIC X(03).
               88  ACCT-CHECKING   VALUE 'CHK'.
               88  ACCT-SAVINGS    VALUE 'SAV'.
           05  ACCT-STATUS-CODE    PIC X(01).
               88  ACCT-ACTIVE     VALUE 'A'.
               88  ACCT-CLOSED     VALUE 'C'.
           05  ACCT-LEDGER-BAL     PIC S9(11)V99 COMP-3.
           05  ACCT-AVAIL-BAL      PIC S9(11)V99 COMP-3.
           05  ACCT-INT-RATE       PIC 9V9(06).
           05  ACCT-INT-ACCRUED    PIC S9(09)V99 COMP-3.

      * Batch program structure pattern
       PROCEDURE DIVISION.
       0000-MAIN.
           PERFORM 1000-INITIALIZE
           PERFORM 2000-PROCESS
               UNTIL WS-EOF-INPUT
           PERFORM 3000-FINALIZE
           STOP RUN
           .

       1000-INITIALIZE.
           OPEN INPUT  TRANSACTION-FILE
           OPEN I-O    ACCOUNT-MASTER-FILE
           OPEN OUTPUT REPORT-FILE
                       ERROR-FILE
                       AUDIT-FILE
           PERFORM 1100-READ-TRANSACTION
           .

       2000-PROCESS.
           PERFORM 2100-VALIDATE-TRANSACTION
           IF WS-VALID
               PERFORM 2200-POST-TRANSACTION
               PERFORM 2300-WRITE-AUDIT
           ELSE
               PERFORM 2400-WRITE-ERROR
           END-IF
           PERFORM 1100-READ-TRANSACTION
           .

       3000-FINALIZE.
           PERFORM 3100-WRITE-CONTROL-TOTALS
           CLOSE TRANSACTION-FILE
                 ACCOUNT-MASTER-FILE
                 REPORT-FILE
                 ERROR-FILE
                 AUDIT-FILE
           MOVE WS-RETURN-CODE TO RETURN-CODE
           .

      * CICS pseudo-conversational pattern
           EVALUATE WS-EIBCALEN
               WHEN 0
                   PERFORM FIRST-TIME-THROUGH
               WHEN OTHER
                   PERFORM PROCESS-INPUT
           END-EVALUATE
           EXEC CICS RETURN
               TRANSID('ACIQ')
               COMMAREA(WS-COMMAREA)
               LENGTH(LENGTH OF WS-COMMAREA)
           END-EXEC
           .

      * DB2 account inquiry
           EXEC SQL
               SELECT ACCT_NUMBER,
                      ACCT_TYPE,
                      LEDGER_BALANCE,
                      AVAIL_BALANCE
               INTO :WS-ACCT-NUMBER,
                    :WS-ACCT-TYPE,
                    :WS-LEDGER-BAL,
                    :WS-AVAIL-BAL
               FROM ACCOUNT_MASTER
               WHERE ACCT_NUMBER = :WS-INPUT-ACCT
           END-EXEC
           EVALUATE SQLCODE
               WHEN 0
                   PERFORM DISPLAY-ACCOUNT-INFO
               WHEN 100
                   MOVE 'ACCOUNT NOT FOUND' TO WS-MSG
               WHEN OTHER
                   PERFORM DB2-ERROR-HANDLER
           END-EVALUATE

      * JCL batch job stream (excerpt)
      //BANKDAY  JOB (ACCT),'DAILY BATCH',CLASS=A
      //*
      //STEP01   EXEC PGM=TRNSORT
      //STEP02   EXEC PGM=TRNVALID,
      //         COND=(4,LT)
      //STEP03   EXEC PGM=TRNPOST,
      //         COND=(4,LT)
      //STEP04   EXEC PGM=INTACCR,
      //         COND=(4,LT)
      //STEP05   EXEC PGM=FEEASSMT,
      //         COND=(4,LT)
      //STEP06   EXEC PGM=STMTGEN,
      //         COND=(4,LT)

What's Next

Chapter 42 concludes the textbook with a comprehensive COBOL career guide. You will learn about the current job market for COBOL programmers, career paths from junior developer through architect and management, professional certifications, interview preparation strategies, complementary skills that increase your marketability, and the future outlook for COBOL in the enterprise. Having built a complete banking application in this capstone project, you are now equipped to begin a professional COBOL career.