フラットファイルデータベースはメインフレームで一般的であり、固定幅フィールドにデータを格納します。例えば、「JOHN SMITH 12343rd St」のような典型的なエントリは、「JOHN」が8文字、「SMITH」が8文字を占めることを知っていることに依存しています。この厳格な構造は、ミドルネームのイニシャルを追加するような変更を非常に困難にし、多くの場合、新しいテーブル、データ移行、およびすべての消費ソフトウェアの更新が必要になります。これを軽減するために、スマートな開発者は「パディング」を導入し、レコード内に余分な文字を予約しました。例えば、レコードは未使用スペース16文字で終わる場合があります。ミドルネームのイニシャルのような新しいフィールドが必要になった場合、パディングを縮小することで挿入でき、レコード全体の長さの変更を回避できます。この方法は、洗練されてはいませんが、高価なスキーマの再作業やデータのシャッフルを防ぎます。パディングはレコード全体に分散されることが多く、新しい列がこれらの予約されたスペースを消費できるようになります。最終的にパディングがなくなる可能性がありますが、この戦略は、大規模なオーバーホールなしでフラットファイルスキーマの運用寿命を大幅に延ばします。ブレンダのチームは、そのようなVSAMフラットファイルを使用するメインフレームシステムをサポートしており、最新のRDBMSへのデータ抽出が必要でした。ETLプロセスが作成され、メインフレームチームがファイル構造を詳細に説明する「コピーブック」を提供しました。しかし、ETL開発者はパディングを誤って扱い、フィールドを分割して、パディングの一部が個別のデータ要素として扱われるようにしました。当初、パディング文字はレポートから削除され、フィールドを連結することで再構築が機能したため、これは無害に見えました。決定的なエラーは、インフライト機能がパディングを消費していなかった本番メインフレームのみでテストしたことでした。これらの機能が本番メインフレームで稼働を開始すると、ETLプロセスによって生成されたレポートは、使用されたパディングからの余分なデータで破損しました。ETL開発者は請負業者であり、彼らのソリューションは限定的なテストに基づいて「設計どおりに機能した」ため、彼らはそれをやり直すことを拒否しました。その結果、メインフレームチームは、既存のレポートへの影響を避けるために、代替のパディングフィールドを見つけることを余儀なくされました。