Case Study 1: GlobalBank Daily Transaction Report

Background

Every business day, GlobalBank produces the Daily Transaction Report — a 132-column listing of all transactions processed in the previous 24 hours. This report is used by:

• Branch managers: To review their branch's activity
• Compliance officers: To identify unusual transaction patterns
• Operations staff: To verify batch processing completed correctly
• Auditors: As part of the daily audit trail

The report is organized by account number. For each account, all transactions are listed in date/time order, followed by an account subtotal. The grand total at the end must reconcile with the batch control totals from the nightly processing run.

The Problem

The existing report program (GBRPT00) was written in 1992 using manual control break logic. It is 847 lines of COBOL and has been modified dozens of times over the years. Derek Washington has been asked to add a new column (branch code) to the detail line. After studying the code for two days, he is frustrated.

"I can see where the detail line is formatted," Derek tells Maria, "but the page overflow logic is interleaved with the control break logic, which is interleaved with the accumulation logic. I changed one line count check and the subtotals started printing on the wrong page. It's fragile."

Maria proposes a rewrite using Report Writer: "The old program is a maintenance nightmare. Report Writer will separate the report structure from the processing logic. Future changes — adding a column, changing the page layout, adding a control level — will be data changes, not code changes."

Requirements

1. 132-column report output with ASA carriage control
2. Page heading on every page: report title, date, time, page number
3. Column headers below the page heading
4. Detail lines with: account number (GROUP INDICATE), date, time, type, amount, branch, description
5. Account subtotal: total amount, transaction count
6. Grand total: total amount, total transaction count
7. Report footing: end-of-report marker

Design

Maria and Derek design the report layout on paper first:

Line  Content
----  -------
  1   GLOBALBANK DAILY TRANSACTION REPORT                          PAGE: nnnn
  2   REPORT DATE: yyyy/mm/dd    REPORT TIME: hh:mm:ss
  3   -----------------------------------------------------------------------
  4   ACCOUNT    DATE        TIME     TYPE          AMOUNT  BRANCH DESCRIPTION
  5   -----------------------------------------------------------------------
  6     ACCOUNT: XXXXXXXXXX  Account Name Here
  7   XXXXXXXXXX yyyy/mm/dd  hhmmss   DEPOSIT     99,999.99 XXXXX  XXXX...
  8              yyyy/mm/dd  hhmmss   WITHDRAWAL  99,999.99 XXXXX  XXXX...
 ...
 n    -----------------------------------------------------------------------
 n+1   ACCOUNT SUBTOTAL:                        999,999.99         COUNT: 999
 ...
 55   -----------------------------------------------------------------------
 56   === GRAND TOTAL:                       99,999,999.99         COUNT: 99999
 57   -----------------------------------------------------------------------
 58   *** CONTINUED ***                                           PAGE nnnn

Implementation Highlights

The Report Writer approach reduced the program from 847 lines to 287 lines — a 66% reduction. Key decisions:

1. CONTROLS ARE FINAL, TXN-ACCT-NUM: Single control level (account), plus FINAL for grand total
2. PAGE LIMIT 60: Standard 60-line page
3. FIRST DETAIL 6: Leaves room for 5-line page heading
4. LAST DETAIL 54: Allows detail lines through line 54
5. FOOTING 58: Control footings and page footings fit in lines 55-58
6. GROUP INDICATE on account number: Shows account only on first detail line per group

Results

Lessons Learned

1. Declarative beats procedural for standard reports: The report structure is visible in the REPORT SECTION without tracing procedural logic.

2. Separation of concerns: Changing the report layout (adding columns, adjusting positions) requires changes only in the REPORT SECTION, not in the PROCEDURE DIVISION.

3. Automatic page handling eliminates a class of bugs: The page overflow bugs that plagued GBRPT00 are impossible with Report Writer because page management is automatic.

4. SUM cascading prevents accumulation errors: Manual programs can have subtle bugs where an accumulator is reset at the wrong point or added to the wrong total. Report Writer's automatic SUM cascading eliminates these.

Discussion Questions

1. What factors would argue against the Report Writer rewrite in a different organization?
2. How would you handle a requirement to add conditional highlighting (e.g., marking transactions over $10,000)?
3. If the report needed to be produced in both text and CSV format, how would you modify the approach?
4. How would you test that the new GBRPT01 produces identical output to the old GBRPT00?