【COBOL現新移行検証⑤】ファイル定義 ─ FD句とI/O挙動の差異

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第5回です。

---

1. なぜファイル定義を独立観点としたのか

COBOLにおけるFD句は、単なる構造宣言ではありません。

• RECORDING MODE
• BLOCK CONTAINS
• レコード長
• 固定長／可変長
• ラベルレコード

これらは、実行環境と密接に結びついています。

言語仕様は同じでも、
I/Oの前提が変われば動作が変わります。

---

2. 検証観点

以下の観点で確認しました。

1. OPEN時の挙動
2. READ時のレコード解釈
3. レコード長の扱い
4. EOF検知のタイミング
5. 固定長／可変長の差

---

3. 検証コード例

       IDENTIFICATION DIVISION.
       PROGRAM-ID. FILE-CHECK.
       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT INFILE ASSIGN TO "test.dat"
               ORGANIZATION IS SEQUENTIAL.

       DATA DIVISION.
       FILE SECTION.
       FD INFILE
           RECORDING MODE IS F
           BLOCK CONTAINS 0 RECORDS.

       01 IN-REC.
           05 IN-A PIC X(5).
           05 IN-B PIC 9(3).

       WORKING-STORAGE SECTION.
       01 EOF-FLAG PIC X VALUE "N".

       PROCEDURE DIVISION.
           OPEN INPUT INFILE
           PERFORM UNTIL EOF-FLAG = "Y"
               READ INFILE
                   AT END MOVE "Y" TO EOF-FLAG
                   NOT AT END
                       DISPLAY IN-A " " IN-B
               END-READ
           END-PERFORM
           CLOSE INFILE
           STOP RUN.

---

4. 実行結果差異

4.1 OPEN時

観点	現行	次期
BLOCK指定あり	正常	警告／無視
RECORDING MODE F	正常	正常

---

4.2 レコード長差異

ケース	現行	次期
レコード短い	自動パディング	エラー発生
レコード長い	切り捨て	エラー発生

---

4.3 EOF検知

EOF判定のタイミングに差が出るケースあり。

• READ直後
• 次READ時

環境依存。

---

5. 実データ比較（バイトレベル確認）

検証では、実際のデータファイルをそのまま使用し、
出力結果だけでなく「バイト列」も比較しました。

5.1 テストデータ（固定長8バイト）

ABCDE123
FGHIJ456

5.2 16進ダンプ（現行）

41 42 43 44 45 31 32 33
46 47 48 49 4A 34 35 36

5.3 16進ダンプ（次期）

41 42 43 44 45 31 32 33 0D 0A
46 47 48 49 4A 34 35 36 0D 0A

※0D 0A は CRLF（改行コード）

---

5.4 差異のポイント

① 改行コードの扱い

環境	レコード終端解釈
現行	物理レコード単位
次期	改行コード単位

改行コードをレコードの一部として解釈する場合、
レコード長がずれます。

---

② レコード長不一致

FDで定義したレコード長と実データ長が一致しない場合：

ケース	現行	次期
短いデータ	パディング	エラー
長いデータ	切り捨て	エラー

---

③ READ挙動ログ差

ログ比較（概念例）：

現行

READ SUCCESS
RECORD LENGTH = 8

次期

FILE ERROR
INVALID RECORD LENGTH

---

5.5 本質的な違い

ホスト環境では、

• ブロック単位管理
• 物理レコード長固定

が前提でした。

オープン環境では、

• OSの改行コード
• テキストモードI/O

の影響を受けます。

つまり、

同じFD定義でも、データの“区切り方”が違う

可能性があります。

---

5.6 設計反映

検証結果を踏まえ、以下を実施しました。

1. 改行コードの統一（バイナリモード使用）
2. レコード長の明示定義
3. BLOCK句の整理
4. 可変長ファイルの再設計
5. 入力データ妥当性チェック追加

---

5.7 結論

I/Oは「動いているように見える」ことが最も危険です。

差異は出力内容ではなく、
データの解釈方法に潜んでいます。

移行では、

レコード境界が一致しているか

を確認する必要があります。