"메인프레임에서 흔히 사용되는 플랫 파일 데이터베이스는 고정 폭 필드에 데이터를 저장합니다. "JOHN SMITH 12343rd St"와 같은 일반적인 항목은 "JOHN"이 8자, "SMITH"가 8자 등을 차지한다는 것을 아는 것에 의존합니다. 이러한 엄격한 구조는 중간 이니셜 추가와 같은 수정 작업을 매우 어렵게 만들며, 종종 새로운 테이블, 데이터 마이그레이션, 그리고 모든 소비 소프트웨어의 업데이트를 필요로 합니다.이를 완화하기 위해 숙련된 개발자들은 레코드 내에 추가 문자를 예약하는 "패딩"을 도입했습니다. 예를 들어, 레코드는 사용되지 않은 16자의 공간으로 끝날 수 있습니다. 중간 이니셜과 같은 새로운 필드가 필요할 때, 패딩을 줄여서 삽입할 수 있으며, 전체 레코드 길이에 대한 변경을 피할 수 있습니다. 이 방법은 우아하지는 않지만, 비용이 많이 드는 스키마 재작업과 데이터 셔플링을 방지합니다.패딩은 종종 레코드 전체에 분산되어 새로운 열이 이러한 예약된 공간을 소비할 수 있도록 합니다. 결국 패딩이 부족해질 수 있지만, 이 전략은 주요 개편 없이 플랫 파일 스키마의 운영 수명을 크게 연장합니다.브렌다의 팀은 이러한 VSAM 플랫 파일을 사용하는 메인프레임 시스템을 지원했으며, 이는 현대적인 RDBMS로의 데이터 추출을 필요로 했습니다. ETL 프로세스가 생성되었고, 메인프레임 팀은 파일 구조를 자세히 설명하는 "카피북"을 제공했습니다.그러나 ETL 개발자들은 패딩을 잘못 처리하여 필드를 분할했고, 패딩의 일부가 별도의 데이터 요소로 취급되었습니다. 처음에는 패딩 문자가 보고서에서 제거되고 필드를 연결하여 재구성이 이루어졌기 때문에 무해해 보였습니다.결정적인 오류는 패딩을 소비하는 인플라이트 기능이 없는 프로덕션 메인프레임에 대해서만 테스트했다는 것입니다. 이러한 기능이 프로덕션 메인프레임에서 라이브로 전환되었을 때, ETL 프로세스에서 생성된 보고서는 이제 사용된 패딩의 불필요한 데이터로 손상되었습니다.ETL 개발자들은 계약자였고 그들의 솔루션은 제한된 테스트를 기반으로 "설계대로 작동했기" 때문에 재작업을 거부했습니다. 결과적으로 메인프레임 팀은 기존 보고서에 영향을 미치지 않기 위해 대체 패딩 필드를 찾아야 했습니다."