メインフレームのオープン化～アセンブラ☞COBOL変換編⑥～

はじめに

アセンブラは「CPU に近い制御」を前提とした言語であり、COBOL は「業務ロジックの可読性」を重視した言語です。

そのため、アセンブラ的に正しい実装をそのまま COBOL に持ち込むと、動作はしても保守性の低いコードになりがちです。

本記事では、実際の移行作業で頻出する

「ASM 的には正しいが、COBOL では避けるべきコードパターン」

を 5 つに整理して紹介します。

---

パターン①：GOTO 依存の制御構造

■ ASM 的な書き方

BNE LOOP1

BE EXIT

👉 分岐命令で処理を飛ばすのが基本。

■ COBOL に直訳すると

IF A NOT = B

 GO TO LOOP1

END-IF

IF A = B

 GO TO EXIT

END-IF

👉 処理の流れが追いづらく、スパゲッティ化しやすい。

■ COBOL 的に望ましい書き方

PERFORM UNTIL A = B

 ...

END-PERFORM

👉 制御構造を使い、処理の意図を明確にする。

---

パターン②：1 バイトフラグによる状態管理

■ ASM 的な書き方

・X'00' / X'FF' で状態管理

・フラグレジスタや 1 バイト領域で制御

■ COBOL に直訳すると

IF FLAG = X"FF"

👉 フラグの意味が読み取れず、可読性が低い。

■ COBOL 的に望ましい書き方

IF END-OF-DATA = TRUE

👉 意味のある名前＋論理値で、意図が一目で分かる。

---

パターン③：型を信用せず MOVE を連鎖させる

■ ASM 的な書き方

PACK ...

UNPK ...

👉 数値⇔文字の変換を頻繁に行う前提。

■ COBOL に直訳すると

MOVE A TO B

MOVE B TO C

MOVE C TO D

👉 “とりあえず MOVE” の連鎖が発生し、型の意味が曖昧になる。

■ COBOL 的に望ましい考え方

・PIC でデータ型を明確化する

・不要な MOVE を排除する

・「データの意味」を中心に設計する

👉 COBOL は型定義が強力なので、変換処理を減らせる。

---

パターン④：ワークエリアの汎用化（汚染）

■ ASM 的な書き方

・同じ領域に別用途のデータを格納

・再利用前提のワークエリア設計

■ COBOL に直訳すると

01 WORK-AREA PIC X(100).

👉 何が入るか分からない「ブラックボックス領域」になり、デバッグ不能。

■ COBOL 的に望ましい設計

・用途ごとに領域を分ける

・意味単位で構造化する

・必要なら 01 レベルを複数に分割する

👉 「意味のあるデータ構造」にすることで保守性が大幅に向上。

---

パターン⑤：サブルーチンが外部状態に依存

■ ASM 的な書き方

・レジスタ前提

・ワーク領域前提

・外部状態に依存した処理

■ COBOL に直訳すると

PERFORM DATACHK.

👉 何を渡しているのか不明。PERFORM は引数を持てないため、意図が隠れる。

■ COBOL 的に望ましい書き方

CALL 'DATACHK' USING DATA-AREA

👉 必要なデータを明示的に渡すことで、処理内容が読み取れる。

---

まとめ

アセンブラと COBOL では、言語が想定している世界が根本的に異なります。

ASM で「正しい」書き方をそのまま再現しようとすると、COBOL では可読性や保守性を損なう結果になりがちです。

重要なのは、処理を再現することではなく、設計を置き換えること。

COBOL では、制御構造・意味の明確化・明示的なインターフェースを意識することで、移行後のシステムを長く保守できる形にできます。