アプリで作成

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

自分用まとめその2
19
木村岳史(東葛人) @toukatsujin

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

2019-02-05 07:40:38
ケルビン@斜壊人 @legendkelbin

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

2019-02-05 08:59:03
える@個人事業主 ❄半ニートえんじにゃー❄ @ellnore_pad_267

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

2019-02-05 09:03:04
ケルビン@斜壊人 @legendkelbin

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

2019-02-05 09:35:00
ケルビン@斜壊人 @legendkelbin

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

2019-02-05 09:49:39
える@個人事業主 ❄半ニートえんじにゃー❄ @ellnore_pad_267

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

2019-02-05 10:04:26
ケルビン@斜壊人 @legendkelbin

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

2019-02-05 10:41:21
える@個人事業主 ❄半ニートえんじにゃー❄ @ellnore_pad_267

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

2019-02-05 11:10:50
ケルビン@斜壊人 @legendkelbin

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

2019-02-05 12:11:08
ケルビン@斜壊人 @legendkelbin

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

2019-02-05 12:14:59
ケルビン@斜壊人 @legendkelbin

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

2019-02-05 12:18:16
ケルビン@斜壊人 @legendkelbin

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

2019-02-05 12:22:26
ケルビン@斜壊人 @legendkelbin

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

2019-02-05 12:29:01
ケルビン@斜壊人 @legendkelbin

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

2019-02-05 12:37:29
ケルビン@斜壊人 @legendkelbin

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

2019-02-05 12:45:40
ケルビン@斜壊人 @legendkelbin

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

2019-02-05 12:50:33
ケルビン@斜壊人 @legendkelbin

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

2019-02-05 12:55:47

コメント

いぬだわん @InuWang 2019年2月6日
COBOLは殆ど書いた事ないが、バッチ処理しか出来ないと言われてるけど普通にオンライントランザクション処理出来ると思うが… COBOL単体では無く普通はCICSと組み合わせてだけど、この辺りはJavaがアプリケーションサーバ使うのと同じ。
2
おろろ @fYe39CoQsPrbZVK 2019年2月6日
COBOL案件およびコボラーと関ってはいけないてのがここ四半世紀のエンジニアの総意なので、まあ察してくれ
2
mikumiku_aloha @mikumiku_aloha 2019年2月6日
銀行などのCOBOLのコードは、昔の「こんな条件でこんな契約すると利率がこんなにお得」というサービスが計画的にまとめられておらず思わぬところに計算が入っていて難しいと聞いたことが。その場合は言語の問題ではなく設計の問題で。
1
nekosencho @Neko_Sencho 2019年2月6日
そういや言語もだけど、ソフトの作り方というか考え方というか、そういう方面でも現在とずいぶん違うんだろうな
1
kartis56 @kartis56 2019年2月6日
構造化されてるCOBOLならライブラリ化しておけば共通関数にできる。コンパイルするときにリンクするのは他の言語と同じ。
2
kartis56 @kartis56 2019年2月6日
SQL一本ですむ処理ならSQL呼び出せばいいだけ。
1
kartis56 @kartis56 2019年2月6日
大型汎用の話らしいけど、JCLでsql呼ぶ前処理入れて一時保存しておき、COBOLで読み出して処理するのは普通にあるはず
2
むう @nyal1999 2019年2月7日
まあぶっちゃけ最大の問題は「まともに資料も残ってない上に屋上屋を重ねたような違法建築なので、リライトするにしても何が正しいのかわからん」という点。「現状仕様で」とか言われてもどこで特殊処理出てくるかわからんから、対応しようがない
1