Case Study 25.1: GlobalBank Account Class Hierarchy

Background

GlobalBank's core banking system, GLOBALBANK-CORE, manages 2.3 million transactions daily across checking, savings, and loan accounts. The system was originally written in 1987 as procedural COBOL with VSAM files and later migrated to DB2. As the system grew to 1.2 million lines, architectural concerns emerged: adding a new account type (such as a money market account or a certificate of deposit) required changes in dozens of programs.

Priya Kapoor proposed a proof-of-concept: rewrite the account management module using OO COBOL to evaluate whether the approach could reduce the cost of future account type additions.

The Challenge

The existing system used a monolithic record layout for all account types, with type-specific fields occupying shared positions via REDEFINES:

       01  ACCT-RECORD.
           05  ACCT-NUMBER         PIC X(10).
           05  ACCT-HOLDER         PIC X(40).
           05  ACCT-TYPE           PIC X(2).
           05  ACCT-BALANCE        PIC S9(11)V99 COMP-3.
           05  ACCT-TYPE-DATA      PIC X(50).
           05  ACCT-CK-DATA REDEFINES ACCT-TYPE-DATA.
               10  CK-OVERDRAFT   PIC S9(9)V99.
               10  CK-MONTHLY-FEE PIC S9(5)V99.
               10  FILLER         PIC X(35).
           05  ACCT-SV-DATA REDEFINES ACCT-TYPE-DATA.
               10  SV-INT-RATE    PIC V9(4).
               10  SV-MIN-BAL     PIC S9(9)V99.
               10  FILLER         PIC X(37).

Adding a new account type meant modifying this record, updating every EVALUATE statement that branched on ACCT-TYPE, and retesting every program that used ACCT-RECORD.

The OO Design

Priya's class hierarchy separated each account type into its own class:

  • BankAccount: Base class with common data (number, holder, balance, status) and operations (deposit, withdraw, get balance)
  • CheckingAccount: Added overdraft limit, monthly fee, per-transaction fee
  • SavingsAccount: Added interest rate, minimum balance, withdrawal counter
  • LoanAccount: Added principal, rate, term, payment calculation

Each class encapsulated its own data and operations. Adding a new account type meant creating a new class file — no changes to existing classes.

Implementation Results

The proof-of-concept took three weeks to build (two weeks of learning OO COBOL, one week of coding). Priya documented these findings:

Advantages observed: - Adding a new account type required one new file, zero changes to existing code - Each class was self-contained and testable independently - The inheritance hierarchy eliminated duplicated code (common operations defined once in BankAccount) - Polymorphism through interfaces allowed generic reporting code

Disadvantages observed: - Compilation required Micro Focus COBOL; IBM Enterprise COBOL on z/OS could not compile the full hierarchy - Runtime performance was 15% slower than the procedural version (method dispatch overhead) - Only Priya and one external consultant could maintain the OO code - Debugging tools had limited OO support

Decision

GlobalBank's IT steering committee reviewed the proof-of-concept and decided not to adopt OO COBOL for production — yet. The performance gap and skills gap were too significant for a system processing 2.3 million transactions daily. However, they adopted Priya's design principles in their procedural code: better encapsulation through structured copybooks, cleaner CALL interfaces between programs, and documented "class-like" program groupings.

Discussion Questions

  1. Was the steering committee's decision correct? What conditions would need to change for OO COBOL to become viable at GlobalBank?
  2. How does the 15% performance overhead change your analysis if the system processes 100 transactions/day vs. 2.3 million/day?
  3. Priya applied OO design principles to procedural code. What are the limits of this approach? At what point does the lack of language-level OO support become a bottleneck?
  4. If GlobalBank had chosen to adopt OO COBOL, what migration strategy would you recommend for the existing 1.2 million lines of procedural code?