Case Study 1: GlobalBank Branch and Account Type Lookup System

Background

GlobalBank's daily statement generation process must look up two pieces of information for every account record: the account type description (from a small, stable code table) and the branch name (from a larger, frequently updated branch table). The current system uses inefficient file lookups for both, performing disk I/O for every single account record. Maria Chen has tasked Derek Washington with converting both lookups to in-memory table operations.

The Problem

The statement generation program processes approximately 1.2 million accounts per nightly batch. Each account record contains a 2-character account type code and a 6-character branch ID. The current program: - Opens the account type file and reads sequentially for each lookup (8 account types) - Opens the branch file and reads sequentially for each lookup (340 branches) - Takes 47 minutes to complete the batch run

Maria's target: under 12 minutes.

Design Decisions

Derek works with Maria and Priya Kapoor to make three key design choices:

  1. Account types: Hardcoded using REDEFINES — only 8 entries, rarely changes, binary search
  2. Branch table: File-loaded into ODO table — 340 entries, updated monthly, binary search
  3. Error handling: Separate counters for each table's lookup failures

Implementation

Data Definitions

      * Account Type Table - hardcoded, 8 entries
       01  ACCT-TYPE-VALUES.
           05  FILLER PIC X(32)
               VALUE "CHCHECKING ACCOUNT            ".
           05  FILLER PIC X(32)
               VALUE "CCCREDIT CARD                 ".
           05  FILLER PIC X(32)
               VALUE "CDCERTIFICATE OF DEPOSIT      ".
           05  FILLER PIC X(32)
               VALUE "IRAINDIVIDUAL RETIREMENT      ".
           05  FILLER PIC X(32)
               VALUE "LNLOAN ACCOUNT                ".
           05  FILLER PIC X(32)
               VALUE "MMMONEYMARKET                 ".
           05  FILLER PIC X(32)
               VALUE "MTMORTGAGE                    ".
           05  FILLER PIC X(32)
               VALUE "SASAVINGS ACCOUNT             ".

       01  ACCT-TYPE-TABLE REDEFINES ACCT-TYPE-VALUES.
           05  AT-ENTRY  OCCURS 8 TIMES
                         ASCENDING KEY IS AT-CODE
                         INDEXED BY AT-IDX.
               10  AT-CODE  PIC X(2).
               10  AT-DESC  PIC X(30).

      * Branch Table - file-loaded, up to 500 entries
       01  BRANCH-TABLE-AREA.
           05  BR-COUNT  PIC 9(4) COMP VALUE ZERO.
           05  BR-ENTRY  OCCURS 1 TO 500 TIMES
                         DEPENDING ON BR-COUNT
                         ASCENDING KEY IS BR-ID
                         INDEXED BY BR-IDX.
               10  BR-ID      PIC X(6).
               10  BR-NAME    PIC X(40).
               10  BR-REGION  PIC X(2).

Processing Logic

The key to the performance improvement is that each table is loaded once at initialization and then searched entirely in memory. The 1.2 million disk reads per table are eliminated entirely, replaced by fast in-memory binary searches.

Results

After implementation, the batch run completed in 8 minutes — a 83% reduction. Derek's analysis showed: - Account type lookups: average 3 comparisons per lookup (log2(8) = 3) - Branch lookups: average 9 comparisons per lookup (log2(340) ~ 8.4) - Total comparisons for 1.2M accounts: ~14.4 million (vs. millions of disk I/O operations before)

Lessons Learned

  1. Sort order matters: The hardcoded account types must be in alphabetical order for SEARCH ALL. Derek initially had them in business priority order and spent an hour debugging "not found" results.
  2. ODO validation is essential: During testing, a corrupted branch file had a blank record that set BR-COUNT to zero. The program abended. Adding validation caught this immediately.
  3. Measure before and after: Maria required benchmark numbers before approving the change for production, confirming the improvement was real.

Discussion Questions

  1. Why was hardcoding appropriate for account types but not branches?
  2. What would happen if a new account type were added without updating the REDEFINES table?
  3. How could the branch lookup be made even faster if branches were assigned sequential numeric IDs?
  4. What monitoring should be added to detect lookup failure rate increases in production?