Case Study 11.1: GlobalBank's Nightly Batch Window

Background

Every business day at 6:00 PM Eastern, GlobalBank's online transaction processing system (CICS) closes for the day and produces TXN-DAILY — a sequential file containing a complete record of every transaction processed since the previous close. The nightly batch window must complete all processing before the online system reopens at 6:00 AM the following morning.

The Batch Pipeline

GlobalBank's nightly processing consists of 23 job steps that process 47 sequential files. The critical path involves four programs that process TXN-DAILY:

Step Program Input Output Avg Time
1 TXN-VALID TXN-DAILY TXN-VALID-OUT, TXN-REJECT 12 min
2 TXN-POST TXN-VALID-OUT, ACCT-MASTER Updated ACCT-MASTER 28 min
3 TXN-REPORT TXN-VALID-OUT RPT-DAILY (print) 8 min
4 TXN-ARCHIVE TXN-VALID-OUT TXN-HIST (append) 6 min

Total critical path: approximately 54 minutes for 2.3 million records.

The Challenge: Volume Growth

In 2019, GlobalBank processed an average of 1.1 million transactions per day. By 2024, mobile banking growth pushed that to 2.3 million — more than double. The batch window, once comfortably finishing by 2 AM, was now completing at 4:30 AM, leaving only 90 minutes of slack before the 6 AM deadline.

Maria Chen was tasked with reducing the batch window without rewriting the programs.

The Investigation

Maria profiled each step and found:

TXN-VALID (Step 1)

  • Problem: The TXN-DAILY file had been allocated with a block size of 1,500 bytes (10 records per block) — a setting from 1992 that no one had changed. The output files had similarly small blocks.
  • Solution: Changed BLOCK CONTAINS to 0 RECORDS in all FD entries and updated the JCL to use system-determined block sizes. The result: 27,000-byte blocks (180 records per block).
  • Result: Processing time dropped from 12 minutes to 4 minutes.

TXN-POST (Step 2)

  • Problem: The program was reading ACCT-MASTER (VSAM KSDS) with random access for each transaction. With 2.3 million transactions touching approximately 800,000 unique accounts, many accounts were read multiple times.
  • Solution: Added a pre-sort of TXN-VALID-OUT by account number, then processed sequentially through the sorted file, accumulating all transactions for each account before performing a single READ/REWRITE on ACCT-MASTER.
  • Result: VSAM I/O operations dropped from 2.3 million to 800,000. Processing time dropped from 28 minutes to 11 minutes.

TXN-REPORT (Step 3)

  • Problem: The report program was writing a 132-character record with BLOCK CONTAINS 1 RECORDS (unblocked).
  • Solution: Changed to BLOCK CONTAINS 0 RECORDS.
  • Result: Processing time dropped from 8 minutes to 3 minutes.

TXN-ARCHIVE (Step 4)

  • Problem: The archive program used OPEN EXTEND on TXN-HIST, which was a single sequential file containing all historical transactions. After 5 years, the file was 180 GB, and OPEN EXTEND had to position to the end.
  • Solution: Changed TXN-HIST from a single flat file to a GDG (Generation Data Group), creating a new generation each day. OPEN OUTPUT to a new file instead of EXTEND to a massive file.
  • Result: Processing time dropped from 6 minutes to 2 minutes.

Results

Step Before After Improvement
TXN-VALID 12 min 4 min 67%
TXN-POST 28 min 11 min 61%
TXN-REPORT 8 min 3 min 63%
TXN-ARCHIVE 6 min 2 min 67%
Total 54 min 20 min 63%

The batch window now completes by 1:30 AM, providing 4.5 hours of slack — enough headroom for continued growth.

Lessons Learned

  1. Blocking is the single most impactful performance optimization for sequential files. Changing from small blocks to system-optimal blocking provided 60%+ improvement with zero code changes (only FD and JCL changes).

  2. Always use BLOCK CONTAINS 0 RECORDS. There is almost never a reason to specify a fixed block size in a new program. Let the system optimize.

  3. Sequential access beats random access when you need most of the file. Sorting transactions by account key and processing them sequentially was a bigger win than any I/O tuning.

  4. Growing files need architectural solutions. A 180 GB sequential file that grows daily is an architectural problem, not a tuning problem. GDG solved it cleanly.

  5. Profile before optimizing. Maria's investigation revealed that the biggest bottleneck (TXN-POST) was not a sequential file problem at all — it was a VSAM random access problem. The fix involved adding a sequential sort step.

Discussion Questions

  1. Why does blocking have such a dramatic effect on sequential file performance? Calculate the number of physical I/O operations for 2.3 million 150-byte records with a block size of 1,500 bytes vs. 27,000 bytes.

  2. Maria added a SORT step before TXN-POST. This sort takes about 3 minutes. Explain why adding a 3-minute step saves 17 minutes overall.

  3. What risks does the GDG approach introduce for the archive? How would you handle queries that need to search across multiple generations?

  4. If GlobalBank's transaction volume doubles again (to 4.6 million per day), what further optimizations would you recommend?