• コラム

はじめまして。舞呉コボ郎と申します。「まいご」じゃありません。「まいぐれ」です。 私は当社で30年以上、マイグレーションとCOBOLに取り組んできました。 2024年を迎え、コボ郎のカラータイマーも点滅し始めたので、何か記録に残すことで微力ながらCOBOLに関わる方、これからCOBOLに携わる予定のある方のお役に立てるようなことがないかと思いを巡らせ、コラムを始めることにしました。 当社が約30年取り組んできたマイグレーションの軌跡と最近肩身が狭くなってきたCOBOLのお勉強に役立つ情報をお届けしていこうと思います。 COBOLに取り組まなくてはならなくなった初心者の方や、何となくCOBOLを使ってきた方に、COBOLを深く理解して活用するための虎の巻になるといいなぁ…と思っています。

初回はCOBOLとマイグレーションについて、コボ郎の所感を述べさせていただきます。

COBOLの言語特性として良いところは

悪いところは、

COBOLは1959年に生まれ、現在まで使われ続けています。衰退期にはありますが、まだまだ大量のCOBOLが本番運用されています。
まだCOBOLが残っている企業のシステムは、超ミッションクリティカルだったり、移行が難しいアセンブラなどの資産が大量に稼働していたり、その両方だったりします。
現在の技術ではCOBOLをすべて無くすためには莫大なマンパワーが必要で、この先しばらくは、うまくCOBOLと付き合っていくことが必要だと思います。自然なJavaに変換するAIが出始めているようですが、広く使えるようになるにはまだまだ時間がかかりそうです。

もし、COBOL技術者の確保が困難で、かつ高齢化しているのであれば、若い技術者を教育して増やすのも一つの手だと思います。COBOLの習得はコツをつかんでしまえば簡単です。
若いエンジニアにとっても、JavaやC#だけでなく、COBOLを習得してハイブリッドになっておけば、ニッチなCOBOL市場で高条件の仕事に巡り合うチャンスも大いにあるでしょう。

COBOLを別言語に書き換えても、ジョブやプログラムの構成を変更しない場合は、保守のやり方は基本的に変わりません。本質的な問題は、業務ノウハウの習得や継承が難しいことなのです。例えば、あるジョブが異常終了した際に、調べなければならない対象ソースや復旧対象のデータ、再実行方法などは変わりません。移行対象システムの重要性や保守頻度と、言語を書き換えることによるメリット（COBOL撤廃によるランニングコスト低減など）とデメリット（移行時コストの増大と移行後保守性の低下など）を多面的に評価して、移行先の言語を決めるべきだと思います。

重要度の高いシステムのうち「業務ノウハウが肝だが継承がうまくいってない」システムは、再構築して自社のエンジニアに業務ノウハウを植え付けることが望ましいです。生産性を上げるために、当社製「WebPerformer」のようなローコード開発ツールを用いることもお勧めです。

1990年代。バブルが崩壊し、企業は設備投資が控えられるような節約生活に突入。マイグレーションという言葉がまだマイナーだった頃のお話です。
某社が主力として使っていたメインフレームの一つが製造停止になってしまうことを契機に、別機種のメインフレームへのマイグレーションをシャカリキになって約5年やりました。大規模でミッションクリティカルなシステムが多く、アセンブラも大量にある難易度の高いマイグレーションでした。

アセンブラの再構築は、コボ郎が中心で行い、苦労と達成感が大きかったので、少しご紹介したいと思います。
移行元では、オンラインの業務プログラムの画面送受信や罫線や色の変更を簡易化して開発生産性を上げるために、アセンブラ共通プログラムを用いていました。アセンブラ共通プログラムを廃止し、移行先の標準的な画面インターフェースを用いるようにオンライン業務プログラムを手修正する方法もありますが、その場合は手修正による品質低下は免れません。オンライン業務プログラムのインターフェースを変えずに、移行先OS配下で同じ機能が実行できるように代替の共通プログラムを再構築することで、オンライン業務プログラムのツール変換を可能としました。

アセンブラはツール変換できなかったので、人手でアセンブラを解析して、フローチャートを作成し、現状機能を把握した上で、代替共通プログラムを開発しました。アセンブラの解析は、レジスタとメモリー間の転記やビット操作の内容はコーディングから直接的に把握できるので、フローチャートに落とすまでは機械的な作業で、比較的容易でした。
しかし、出来上がったフローチャートを眺めて何をしているのかを把握することは難しく、何をしているかの謎が解けた時は、パズルが解けたような感覚で喜びもひとしおでした。

約30年前のマイグレーションへの対応方法は、次のとおりでした。

この時の「メインフレーム to メインフレーム」マイグレーション技術が当社のマイグレーションの礎になっています。
なお、当社のマイグレーションで扱ってきたメインフレームのOSは、IBM OS390／z/OS 、NEC ACOS-6／ACOS-4／ACOS-2、三菱電機 GOS、富士通 MSP、日立 VOS3です。今となっては、無くなってしまった懐かしいOSもありますね。

　⇒詳細は次回へ続く

コボ郎が社会人になって教わった初めての言語はPL/Ⅰでした。当時、講師の先生が、PL/Ⅰで「一番大切なのは移送と条件判定だ」と言われていたことがコボ郎のCOBOL技術の根底にあります。COBOLのMOVE命令とIF命令をしっかりマスターすることが、COBOL技術上達の早道です。本当にそうです。

今回は、MOVE元と先の項目属性によって転記の種類が英数字転記か数値転記に決まること、英数字転記とは何か、数値転記とは何か、IFの左辺と右辺の項目属性によって比較の種類が英数字比較か数値比較に決まること、英数字比較とは何か、数値比較とは何かについて説明します。 次の問題を解いたあと、解答と解説をご覧ください。

MOVEとIFの動作の概略は理解いただけたでしょうか？
次回は属性のバリエーションをパック10進数や2進数などに拡げ、MOVEとIFについて深堀りします。

• ⇒詳細は「第二回 メインフレーム to UNIX 編」へ続く

• お問い合わせフォームはこちら

※記載の会社名、製品名などは、それぞれの会社の商標もしくは登録商標です。
※免責事項
・当コラムに記載した内容に関して、いかなる保証もするものではありません。
・記載内容は予告なく変更する可能性があり、記載内容に誤りがあった場合でも一切責任を負いかねます。