メインフレームのオープン化～アセンブラ→COBOL変換【番外編】

はじめに

本シリーズでは、メインフレーム環境で稼働していたアセンブラ（ASM）プログラムを COBOL へ移行する過程で直面した課題を中心に紹介してきました。

今回は少し視点を変えて、変換作業そのものではないが、実際の現場では確実に必要になった作業について触れます。いわば「番外編」「付録編」のような位置づけです。

移行作業は、プログラムを変換して終わりではありません。

オープン環境で動かすためのビルド周りの整備も、確実に必要な工程でした。

---

Makefile 作成を依頼された背景

アセンブラから COBOL への変換作業が一段落しつつあった頃、次の依頼が届きました。

「COBOL をコンパイルするための Makefile を作ってほしい」

対象となる COBOL プログラムは複数本。コンパイル方法はほぼ共通ですが、数が多い。

正直なところ、

「1本や2本なら手で書けるけれど、この数を全部手作業で作るのは厳しい…」

というのが最初の感想でした。

---

手作業での Makefile 作成の問題点

手で Makefile を作る場合、次のような問題が見えてきます。

・ほぼ同じ内容を何度も書く必要がある

・プログラム名の書き間違いが起きやすい

・修正が入ると、すべての Makefile を直す必要がある

・作業者によって書き方が微妙に変わる

特に今回は 対象プログラム数が多い ことがネックでした。

「とりあえず作る」ことはできますが、後からの修正や再実行に耐えない作業になってしまいます。

---

自動生成という判断

そこで考えたのが、

Makefile を手で作るのではなく、“作る仕組み”を作る

という方法です。

・Makefile の雛形（テンプレート）を用意

・コンパイル対象のプログラム名だけを差し替える

・対象プログラム分を一括で生成する

この形にしておけば、

・何度でも作り直せる

・修正が入ってもテンプレートを直すだけでよい

・作業ミスを大幅に減らせる

---

なぜ Perl を使ったのか

今回の自動生成ツールに使ったのは Perl でした。理由はとてもシンプルです。

・昔、テキスト処理の学習で Perl を触ったことがあった

・文字列置換やファイル生成が得意な言語

・一時的なツールであり、速度や UI は不要

流行している言語ではありませんが、今回の用途では Perl が最も素直に書けると感じました。

「昔勉強しただけの知識」が、このタイミングで役に立ったのは正直うれしい経験でした。

---

実装の概要

実装自体はそこまで複雑ではありません。大まかな流れは次の通りです。

１．Makefile の雛形をテキストファイルとして用意

２．コンパイル対象となる COBOL プログラム名をリスト化

３．Perl で以下を実装

　　・雛形ファイルを読み込む

　　・プログラム名部分を置換する

　　・プログラムごとの Makefile を出力

４．対象プログラム分を一括で処理

つまり、「Makefile を作るプログラム」を作ったという形になります。

---

実際に得られた効果

・Makefile 作成時間の大幅短縮

・人為的ミスの削減

・修正が入っても再生成するだけで対応可能

・将来的な自動ビルド（Jenkins 等）にもつなげやすい構成

一度仕組みを作ってしまえば、何度でも同じ品質で再利用できる のが大きなメリットでした。

---

振り返り

今回の作業を振り返ると、

・Perl を「昔勉強しただけ」で終わらせていなかったこと

・手作業を前提にしなかったこと

・変換以外の周辺作業にも目を向けたこと

これらが結果的に役に立ちました。

オープン化案件では、

変換作業そのものだけでなく、その前後の作業も含めて品質が決まる

と改めて感じました。

---

おわりに

今回はアセンブラ→COBOL 変換という本編から少し外れた、Makefile 自動生成 の話を書きました。

本編では扱いきれない、

・ビルド

・テスト

・自動化

・周辺ツール

といった話題は、今後も「番外編」として書くかもしれません。

同じようなオープン化案件に関わる方の、何かしらの参考になれば幸いです。

---