ケルビン氏の『なんでCOBOLがリプレースされんのかという話』

木村岳史(東葛人) @toukatsujin

正しすぎる認識だ→COBOLには他の人が書いたコードを分かりにくくする「悪い文化」がある。例えば、COBOLでは「グローバル変数」しか使えない。COBOLはその悪い文化と共に消えていくしかない COBOLは難しいか、記者が試しにコードを書いてみた tech.nikkeibp.co.jp/atcl/nxt/colum…

𝕏 𝕃（おおきなえる）🌸 @ellnore_pad_267

｢しか使えない｣だと！！？！？ なるほど。。それは酷い twitter.com/toukatsujin/st…

ケルビン＠斜壊人 @legendkelbin

@ellnorePZDR297 前提に語弊があって、そもそもプログラム一本単位でコンパイルしてロードモジュールを生成する、というかそれしかできない。なので、変数にグローバルもローカルもなく、そのプログラムで使うものをまとめて定義する、という形しか取れないというのが真かな。

𝕏 𝕃（おおきなえる）🌸 @ellnore_pad_267

@legendkelbin んん！？ 強引に例えると、1クラス（もっと言えばスタティックメソッド1本）しか定義できないJavaでJARを沢山作るイメージ？？？？

ケルビン＠斜壊人 @legendkelbin

@ellnorePZDR297 そのイメージであってます。 だから処理はjar一発かけるのではなく、大量のjarを順序よく一本ずつ実行していくイメージになります。

𝕏 𝕃（おおきなえる）🌸 @ellnore_pad_267

@legendkelbin バッチ処理みたい

ケルビン＠斜壊人 @legendkelbin

@ellnorePZDR297 みたいというか、バッチ処理そのものなので。ちなみにプログラムを実行するにはJCLというヤツが必要ですが、これがjarを自動起動するためのshellに該当するイメージです。

𝕏 𝕃（おおきなえる）🌸 @ellnore_pad_267

@legendkelbin んー？、？ バッチ処理用の言語でシステム開発してるってこと？？？基幹システム並みにでかいヤツを？？ いくらなんでも無理があるのでは。。。

ケルビン＠斜壊人 @legendkelbin

@ellnorePZDR297 してますよ。だから数百数千のプログラム組んでるんです。多分、他言語にリプレースしたら規模はぐっと小さくなると思いますが。

𝕏 𝕃（おおきなえる）🌸 @ellnore_pad_267

@legendkelbin そんな印象を受けました。 リプレース（むしろRewrite）を阻害してるのはなんだと思いますか？ 大は小を兼ねる理論で行けば別に固定長云々やなんかの文化そこまでネックにならないと思えますが。 ソースコード自体に流用性が無さすぎるので実質スクラッチになることですかね。

ケルビン＠斜壊人 @legendkelbin

これあえて引用にしてツラツラ書きます。色々とあるんだけど、まあ代表的なのをいくつか。なんでCOBOLがリプレースされんのかという話。 twitter.com/ellnorePZDR297…

ケルビン＠斜壊人 @legendkelbin

要因1　単純置換できない COBOLの特性上、普通ならSQL1本で済むようなものを何本ものプログラムをかませて作成しており、それら全部のプログラムから編集仕様を抽出して集約する必要がある。これがまずひたすらに労力がかかる。

ケルビン＠斜壊人 @legendkelbin

要因2　共通関数が実質作れない 普通ならば汎用的なロジックは関数化して使うと思うが、COBOLは個々のプログラムに仕込まれている場合が殆ど。最悪、プログラム数本に渡って処理している。これを拾い上げる必要がある。数千本のプログラムから。これも発狂ネタ。

ケルビン＠斜壊人 @legendkelbin

ちょっと補足すると、COBOLは基本的にコンパイル時に関数を静的リンクでロードモジュールに組み込んでしまうので、関数を修正すると使っているプログラムを全てリコンパイルし稼働確認するという地獄作業がある。そのため、関数化をあえて避けている傾向がある。

ケルビン＠斜壊人 @legendkelbin

要因3　処理時間 「数百万件の取引データをDBに取り入れ、数千表の帳票を出力するのを数時間でやる」というのが汎用機以外だと事実上難しかった。Oracleだと多分数倍の時間食っちゃうと思う。これはAWSで解消できそうなので、某メガバンとかは検討に入ってるね。

ケルビン＠斜壊人 @legendkelbin

参考までに。私が見た某銀行の外為夜間バッチは大体500処理。プログラムだと1200位かな。出力帳票は400位。これを入力データ20万件位で5,6時間で流す。一業務でこの規模なので全体はこの10倍以上かな。

ケルビン＠斜壊人 @legendkelbin

要因4　DB整理 Oracleなら必要なテーブルさえあればよく、必要に応じてビューをちょっと作ったりするが、いかんせんCOBOLだとビューに相当する中間データが鬼のようにある。何が必要で何が要らないかの取捨選択を数百数千のデータに項目単位で行う必要がある。ER図書くだけでも気が遠い。

ケルビン＠斜壊人 @legendkelbin

要因5　設計書が古い せめてExcelになっててくれればいいが、最悪手書きのPDFで、しかも更新されてませんでしたオチとかが普通にある。 リライトするかリプレース側で新規作成するかのどっちかだと思うが、これも結構な数あるので地獄の作業になることうけあいである。

ケルビン＠斜壊人 @legendkelbin

ざっと思いつく理由を挙げたけども。 ぶっちゃけ聞くけど、これやりたいエンジニアさんているのかね？ 後こうお客様側も数十億規模になりかねんわけだが、ただのリプレースにそこまで払えるのかな？ て考えると現状維持にそりゃなるよなって感じです。