【俺的】COBOL→Java言語移行ガイド（導入） #Java

はじめに

検証環境
PC: MacBook Air(mid2020)
OS: macOS Big Sur 11.5.1
COBOL: GnuCOBOL 3.1.2.0
C: 12.0.5 (gcc -dumpversionの結果)

Javaのタグを付けましたが、今回はあまり関係ありません。

COBOLからJavaへの移行について

COBOLが生まれてから60年以上たった今、COBOLを採用している企業の一部では、Javaなどオープン系言語へのマイグレーションが進みつつあります。
実際ググると、なぜマイグレーションが進んでいるのかはあちこちに書かれているのですが、自身で調べたことや考えを、勉強としてまとめてみようと思います。
また、別記事（後日）では、COBOLとJavaで書き方がどう変わるのかも書いてみようと思います。

なぜCOBOLからJavaへの移行が進むのか

これにはいくつか理由があります。

1. COBOLの運用ができる人がいない

このご時世、入社していきなり「私COBOLできます！」なんて人は超超稀ではないでしょうか。自分自身も学生時代はCOBOLの存在は知っていたものの「そんなもんもう使ってる企業ないだろ」といった感じでしたので、入社してCOBOL研修があると聞いたときはかなりびっくりしました。
ただ、COBOL言語自体は事務処理言語だけあって、基本文法が単純な上、OpenCOBOLやGnuCOBOL等を使えばパソコンでも勉強できます。
どちらかというと、個人的に覚えるのに大変なのは運用で使うJCLだと思います。オンライン処理であれば、「ここをクリックすればこれが動く」といった感じで想像がつきやすいです。特にOpenCOBOLは実際、記述言語はCOBOLですが、コンパイルの際は、一度Cに変換してからgccで実行ファイルを作成します。なので、フロントエンドがサーブレット、バックエンドがOpenCOBOLの場合、実際やってることはJavaからgccでコンパイルした実行ファイルを動かすだけですので、まださらに想像がつきやすいと思います（リクエストデータをどうやってLINKAGEに渡すのかはおいといて）。

COBOLソースのC変換

たとえばこんな単純なCOBOLソースがあったとします。

      *--1---------2---------3---------4---------5---------6
       IDENTIFICATION DIVISION. 
       PROGRAM-ID. ZAMA8722.
       DATA DIVISION.
       WORKING-STORAGE SECTION. 
       01 HELLO-MSG.
         02 FILLER PIC X(12) VALUE "HELLO WORLD!".    
       PROCEDURE DIVISION.
        EXAMPLE-ST.
           DISPLAY HELLO-MSG.
        EXAMPLE-EX.
           STOP RUN.

これを cobc -Cコマンドで叩くと

$ ls
EXAMPLE.cbl
$ cobc -C EXAMPLE.cbl
$ ls
EXAMPLE.c     EXAMPLE.c.h   EXAMPLE.c.l.h EXAMPLE.cbl

Cソースが出来上がります。

話を戻しまして…。
では逆に、メインフレームで動くバッチだとどうでしょうか。
メインフレームで動くバッチ処理では通常、JCLを使ってCOBOLプログラムを動かします。ちなみに、

JCL 【Job Control Language】ジョブ制御言語
JCLとは、メインフレームのOSなどで利用できるプログラミング言語の一種で、実行する処理（ジョブと呼ばれる）の名前や使用する装置などをシステムに対して指示することができるもの。
JCL（ジョブ制御言語）とは - IT用語辞典 e-Words

です。まぁ今で言えばShell Scriptみたいな存在でしょう。
これこそ実践できる機会が少ないです。JCLはOpenCOBOLのようにパソコン上で動かせる環境がないので、実際の環境で動かす以外ありませんし、入出力の定義の書き方がテープですので、テープについても学ばなければいけません。
なので、個人的にCOBOLができる人というより、COBOLプログラムを運用できる人が少ないし、育成も大変だと思っています。
とはいえCOBOL自体もできる人がいないのも現状ですので、たとえ情報系大学・専門学校卒を採用しても、1から教育し直しになることがほとんどですので教える側も教えられる側も大変です。

2. メインフレームを売っているメーカーが少ない

COBOLが市場からなくなっていくと同時に、メインフレーム本体やその部品を販売するメーカーは減ってきています。内、販売のみで生産委託するメーカーもありますので、生産しているメーカーはもっと少ないです。
日本のメーカーだと、例えば日立は2017年にメインフレーム製造を撤退し、開発はOSだけです。生産は全部IBMに丸投げ状態になっています。¹
同記事によると、2017年現在で国内稼働台数が約150台、そこから年々10%ずつ減少しているそうです。²
もしいま使っているメインフレームが撤退したメーカーであれば、万が一故障したときのサポートもどうなるかわかりませんし、たとえ壊れなかったとしても、メインフレームが古くなったとき、販売しているメーカーから買うのも確かにありですが、メインフレームのメーカーを変えるとJCLなどが多少変わってきたりして、それはそれでマイグレーションが必要なので、そこまでするなら一層オープン系に...といった感じでしょうか。

マイグレーションのいいところ

システム総入れ替えするくらいですから、いいことはあります。

1. 人材確保・教育が容易になる

これは先程の「COBOLの運用ができる人がいない」の反対で、Javaなどのオープン系言語は、情報系大学・専門学校卒であれば、経験者も豊富です。
また、オープン系言語であれば資料や技術記事がネットにゴロゴロ転がっていますし、当然パソコンでも動きますので、教育やスキルアップも容易になります。

2. クラウド化が進められるようになる³

これはネット記事を見て「あ〜！確かに」ってなりました。
書きたいことは参照先が全てですので、そちらの記事をご覧ください。

3. COBOLにおいてのリコンパイルがなくなる

これは大規模システムの開発を担うエンジニアにとっては超負担軽減になるのではないでしょうか。
そうです。COBOLにおいてのリコンパイルがなくなります。

COBOLにおいてのリコンパイル

COBOLでは通常、テープのレイアウトを外部に持たせ（COPYファイル）、それを複数のCOBOL資源で共有します。
例えば、COPYファイルが

       *--1---------2---------3---------4---------5---------6
       01 HELLO-MSG.
         02 FILLER PIC X(12) VALUE "HELLO WORLD!".

で、COBOLソースが

      *--1---------2---------3---------4---------5---------6
       IDENTIFICATION DIVISION. 
       PROGRAM-ID. ZAMA8722.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       COPY  "./RAYOUT.cbl".   
       PROCEDURE DIVISION.
        EXAMPLE-ST.
           DISPLAY HELLO-MSG.
        EXAMPLE-EX.
           STOP RUN.

のとき、COBOLソースをコンパイルすると、出力結果は

HELLO WORLD!

ですが、これがもしCOPYファイルが

      *--1---------2---------3---------4---------5---------6
       01 HELLO-MSG.
         02 FILLER PIC X(9) VALUE "GOOD BYE!".

となったとき、COPYファイルを変更しただけでは、出力は

HELLO WORLD!

のままです。そこで、最新のCOPYファイルを取り込むには、COBOLソースをもう一度コンパイルする必要があります。これがいわゆる「COBOLにおいてのリコンパイル」です。
リコンパイルすれば

GOOD BYE!

最新のCOPYファイルが取り込まれ、出力メッセージが変わります。

1つのCOPYファイルを複数のCOBOLソースで使用ている場合、COPYファイルが変更になると、それを使用しているCOBOLソースは全部リコンパイル対象になります。大規模システムになると、1COPYファイルに対して、使用しているCOBOLプログラムは数十個では済まない時があり、そうなるともちろん、リコンパイル漏れが発生する可能性も出てきます。
しかし、オープン言語ではテープレイアウトも何も、COPYファイルに相当するものがないので、こういったリコンパイルはガサッとなくなります。

マイグレーションの課題・懸念点

ただし、いいことばかりではありません。

1. マイグレーションが原因のバグが起こりかねない

マイグレーションする上で一番怖いのはおそらくこれです。
今まで安定し、稼働実績のあるプログラムを、違う言語で同じ処理を書き直すわけですから、「今まで安定していた処理にバグが起きる」といったリスクは当然上がってきます。
せっかく新しいシステムにしたのにバグだらけになってしまうと近代化改修大失敗です。

2. 信頼性が下がる

メインフレームの売りは信頼性だと思っています。JANOGの資料によれば、メインフレームのMTBF（平均故障間隔）は99.999%と言われています。⁴これは、1年間で約5分程度しかシステムの停止を許さないことになります。
対してサーバの稼働率は、ググってみると99.99%であるところが大半でした。その差はわずか0.009%ですが、計算すると、99.99%だと1年間で53分弱システム停止することになり、その差は約10倍です。
これが通常のWebサービスならまだしも、お金を取り扱う金融や保険業界では痛手だと思います。

3. これはこれでコストがかかる

COBOL人口が減っている今、COBOLエンジニアは希少価値となりつつあるため、必然的にコストが上がります。いわゆる運用コストです。オープン系へのマイグレーションでコストがかかるのは、反対に初期コストです。
オープン系に移行するということは、今まで使用してきたメインフレームをサーバに、COBOLソースをオープン系ソースに変えることになりますから、初期コストが大きくなります。また、今のCOBOLエンジニアをJavaエンジニアに育成する必要もありますから、そこでもコストが発生します。
ただ、オープン系のエンジニアはたくさんいますし、サーバも導入してしまえば、運用コストはCOBOLより抑えることができるのではないでしょうか。

本日はここまで

情報系の大学を卒業して、COBOL業務に就任して数年の視点で、なぜマイグレーションが進んでいるのかをまとめてみました。
もちろん、どこか間違っていることもあると思いますので、その際はコメントで教えていただけますと幸いです。
次は、COBOLとJavaで書き方がどう変わるのかを、基本文法あたりから書いてみようと思います。
閲覧、ありがとうございました。

続編はこちら→全体構造編

日立がメインフレーム製造から完全撤退、開発はOSだけ | 日経クロステック（xTECH） ↩
年々10%減少している件は、xTECHでなくて読めなかったので、この記事を参考
生き残るメインフレーム｜のぞえ/Hideki Nozoe｜note ↩
COBOLからJavaへのマイグレーションの前に知っておくべきこと ⋆ ONETECH Blogs ↩
メインフレームサーバーの凄さについて ↩

【俺的】COBOL→Java言語移行ガイド（導入）