Case Study 1: GlobalBank Account Master Migration

Background

In 2019, GlobalBank's core banking system still ran on ISAM (Indexed Sequential Access Method) files — a technology that IBM had declared "end of service" decades earlier. The ACCT-MASTER file, containing 4.7 million account records, was the heart of the system. Every online inquiry, every batch update, every daily report touched this file.

Maria Chen was assigned to lead the migration from ISAM to VSAM KSDS. "People think migrating a file format is straightforward," she recalls. "But when 47 programs read that file and 12 programs update it, the scope gets real very quickly."

The Challenge

Technical Scope

  • Source: ISAM file, ORGANIZATION IS INDEXED, 350-byte fixed-length records
  • Target: VSAM KSDS, same record layout, same primary key
  • Programs affected: 47 COBOL programs, 23 JCL procedures
  • Daily volume: 2.3 million transactions processing against the file
  • Downtime window: 4 hours maximum (Saturday night maintenance window)

Constraints

  • Zero data loss — this is a bank, every penny counts
  • All 47 programs must work identically after migration
  • Performance must be equal to or better than ISAM
  • Rollback plan required in case of problems

Planning Phase

Step 1: Inventory All File References

Maria's team used a combination of JCL scanning and COBOL source analysis to find every program that referenced the ACCT-MASTER file:

Programs with ACCT-MASTER references:
  ACCT-MAINT    (CRUD - I-O)
  ACCT-INQ      (Read - Random)
  ACCT-BROWSE   (Read - Sequential/Dynamic)
  BAL-CALC      (Read/Update - I-O)
  TXN-PROC      (Read/Update - I-O)
  RPT-DAILY     (Read - Sequential)
  RPT-MONTHLY   (Read - Sequential)
  ... (40 more programs)

Step 2: Categorize Changes Required

Maria categorized each program by the changes needed:

Category Count Changes Required
SELECT only 31 Change ASSIGN clause, add FILE STATUS
SELECT + status checks 12 Above plus add INVALID KEY / status handling
Major rework 4 Rewrite file access logic entirely

The "SELECT only" programs needed minimal changes because ISAM and VSAM KSDS use the same COBOL syntax for most operations. The key difference: ISAM programs often lacked FILE STATUS checking, and Maria insisted on adding it during migration.

Step 3: Define the VSAM Cluster

Priya Kapoor designed the VSAM cluster based on the file's characteristics:

  DEFINE CLUSTER -
    (NAME(GLOBANK.ACCT.MASTER.VSAM) -
     INDEXED -
     KEYS(10 0) -
     RECORDSIZE(350 350) -
     CYLINDERS(100 20) -
     FREESPACE(15 10) -
     SHAREOPTIONS(2 3) -
     SPEED) -
  DATA -
    (NAME(GLOBANK.ACCT.MASTER.VSAM.DATA) -
     CISZ(4096)) -
  INDEX -
    (NAME(GLOBANK.ACCT.MASTER.VSAM.INDEX) -
     CISZ(2048))

Key design decisions: - CISZ(4096): 4 KB CIs, balancing random and sequential access - FREESPACE(15 10): 15% per CI and 10% free CIs for insert activity - SHAREOPTIONS(2 3): Multiple readers with one writer (cross-region), no sharing cross-system - SPEED: Skip preformatting — faster initial load

Step 4: Build a Verification Program

Before migration, the team built a comparison program that could verify record-by-record that the ISAM and VSAM files were identical:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. FILE-COMPARE.

       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT ISAM-FILE
               ASSIGN TO ISAMFILE
               ORGANIZATION IS INDEXED
               ACCESS MODE IS SEQUENTIAL
               RECORD KEY IS ISAM-KEY
               FILE STATUS IS WS-ISAM-STATUS.

           SELECT VSAM-FILE
               ASSIGN TO VSAMFILE
               ORGANIZATION IS INDEXED
               ACCESS MODE IS SEQUENTIAL
               RECORD KEY IS VSAM-KEY
               FILE STATUS IS WS-VSAM-STATUS.

This program read both files sequentially and compared every field of every record, flagging any discrepancies.

Execution

Migration Night

The migration ran during the Saturday night maintenance window:

  1. T+0:00: Stop all online systems (CICS regions)
  2. T+0:15: Run final batch updates to current ISAM file
  3. T+0:30: REPRO the ISAM file to VSAM using IDCAMS
  4. T+0:45: Run FILE-COMPARE to verify all records
  5. T+1:00: Switch JCL to point to new VSAM cluster
  6. T+1:15: Run regression test suite (subset of 12 key programs)
  7. T+2:30: Bring online systems back up
  8. T+3:00: Verify online inquiries working correctly

The IDCAMS REPRO command:

//MIGRATE  EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//INFILE   DD DSN=GLOBANK.ACCT.MASTER.ISAM,DISP=SHR
//OUTFILE  DD DSN=GLOBANK.ACCT.MASTER.VSAM,DISP=SHR
//SYSIN    DD *
  REPRO INFILE(INFILE) OUTFILE(OUTFILE)
/*

The Problem

At T+1:20, during regression testing, the BAL-CALC program abended with a file status '39' — attribute mismatch. Investigation revealed that BAL-CALC used a different COPY member for the record layout that defined the key as PIC 9(10) instead of PIC X(10). Under ISAM, this mismatch was tolerated. Under VSAM, the runtime caught it.

Fix: Updated the BAL-CALC copy member to match the authoritative layout. Recompiled. Regression passed.

Lesson: Maria added "verify all COPY members reference the same master layout" to the migration checklist.

Results

Performance Comparison

Metric ISAM VSAM KSDS Change
Random read (avg) 4.2 ms 2.8 ms -33%
Sequential scan (full file) 47 min 31 min -34%
Batch update (daily) 2.1 hrs 1.4 hrs -33%
Online inquiry response 120 ms 85 ms -29%

Lessons Learned

  1. Inventory is everything: Finding all 47 programs took longer than making the changes
  2. FILE STATUS is non-negotiable: Adding status checks to 12 programs that lacked them prevented silent failures
  3. Copy member consistency: One inconsistent copy member caused the only migration-night problem
  4. Test on equivalent data volume: Early testing with a small file missed the status '39' because the small file happened to work with either key definition
  5. Buffer tuning matters: Initial performance was only 15% better than ISAM. After Priya tuned the buffer allocation, the improvement reached 33%

Discussion Questions

  1. Why did the PIC 9(10) vs PIC X(10) mismatch work under ISAM but fail under VSAM? What does this tell you about stricter validation in modern systems?

  2. If the migration window was only 2 hours instead of 4, what steps could be shortened or parallelized?

  3. Maria chose to add FILE STATUS checking to all 12 programs that lacked it, even though this was not strictly required for the migration. Do you agree with this decision? What are the costs and benefits?

  4. The FREESPACE(15 10) allocation was based on the file's insert/update pattern. How would you determine the right free space values for a new file?