サービス
サービスを探す
プロ人材を探す
仕事を探す
ブログを探す
メインフレームのオープン化～アセンブラ☞COBOL変換編⑦～
記事コラム
メモリ破壊の正体と、インターフェース再構築の舞台裏
はじめに
本シリーズでは、メインフレームのオープン化に伴うアセンブラ（ASM）から COBOL への移行について、実務で直面した課題とその対応を紹介しています。
今回はその中でも、最も危険で、発見が難しい「メモリ破壊問題」と、そこから派生したインターフェース再設計について取り上げます。
現行システムでは、DB アクセスに使用する入出力エリア（I/O エリア）が引数で受け渡されていました。しかし、そのサイズはプログラムごとに異なり、レイアウトも統一されていませんでした。この事実は関係者の間で「なんとなく」共有されていたものの、長年問題なく動いていたため、誰も手を付けていませんでした。
今回の移行でも当初は、
・現行の COBOL 資産は修正したくない
・ASM 部分だけを COBOL 化したい
・共通サブルーチンで吸収したい
という方針でした。
しかし、この判断が後に大きな問題へとつながります。
想定していた構造
COBOL（業務ロジック）
↓
ASM（I/O 制御）
↓
COBOL（DB ハンドラ）
↓
DB
今回の移行では、この ASM 部分を COBOL で書き直し、共通サブルーチンとして置き換える計画でした。
問題の本質：I/O エリアサイズの不一致
DB アクセスに使用される I/O エリアは、呼び出し元の COBOL プログラムごとにサイズが異なっていました。
・あるプログラム：200 バイト
・別のプログラム：500 バイト
・レイアウトも微妙に異なる
これらは仕様書に明記されておらず、暗黙の契約で成り立っている状態でした。
ASM ではこの曖昧さが許容されてしまいます。
・アドレス＋決め打ち長でアクセス
・境界チェックなし
・呼び出し側が“暗黙に”合わせている
しかし、COBOL に置き換えると、この曖昧さがそのまま問題として表面化します。
バグの発見：疎通確認で異常発生
変換後のプログラムを用いた疎通確認で、以下のような異常が発生しました。
・データが意図せず変わる
・別領域が書き換わる
・条件によって再現したりしなかったりする
調査の結果、原因は明確でした。
引数として渡された I/O エリアのサイズが、サブルーチン側の想定より小さい。
呼び出し元は 200 バイトしか確保していないのに、サブルーチン側は 300 バイト分アクセスしていたため、隣接メモリの上書き（メモリ破壊）が発生していました。
なぜ防げなかったのか
この問題が厄介なのは、以下の理由によります。
・CALL は基本的に参照渡し（アドレス渡し）
・コンパイル時にサイズチェックがない
・実行時にも保護されない
つまり、「動くかどうかは完全に実行時依存」という状態です。
ASM 時代は問題にならなかったものの、COBOL 化により「構造の明示化」が求められたことで、長年の矛盾が露呈しました。
当初の対応方針が破綻
当初の狙いは、
・共通サブルーチンで吸収する
・呼び出し元の COBOL は無修正
しかし、I/O エリアのサイズが呼び出し元依存である以上、共通化は成立しないという結論に至りました。
これは単なる実装の問題ではなく、インターフェースの不整合だったためです。
最終対応：インターフェースの再設計
① I/O エリアサイズを最大長で統一
01 IO-AREA PIC X(1024).
② 親プログラムも修正
すべての CALL 元で、統一されたサイズを使用するよう変更しました。
③ ラッパ化による機械的修正
影響範囲が広いため、
・共通ラッパを作成
・呼び出し部分を機械的に置換
これにより、修正漏れを防止しました。
得られた効果
・メモリ破壊が解消
・インターフェースが明確化
・将来的な保守性が向上
結果として、暗黙仕様を明示仕様に変換するという大きな改善につながりました。
まとめ
今回の対応を一言でまとめると、
ASM が許容していた曖昧なバイナリ契約を、COBOL で明示的なインターフェースに再設計したということになります。
・I/O エリアのサイズ不一致はメモリ破壊を引き起こす
・共通サブルーチンでは吸収できない問題がある
・問題の本質は「実装」ではなく「インターフェース」
・解決には呼び出し元を含めた再設計が必要
そして今回の経験で強く感じたのは、
「動いているから正しい」ではなく、「契約が正しいか」を見る重要性でした。
メインフレームのオープン化では、こうした“長年隠れていた問題”が表面化するケースが少なくありません。移行は単なる変換ではなく、設計を見直す機会でもあると実感しました。
