COBOLを無理矢理コンバートしたSQLバッチの方がメンテ不能

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

日経のCOBOLクラウドを見て違和感があるのは、COBOLのPGをそのまま持って行くということ。世代的には、本来はより良い形で受け渡しをしたり、むしろ無くしたり、硬直した実態をなんとかしたい、というのが現場の長の実感のはずで、その辺の機微がわかっていないような気がする。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

COBOLのSCは最後の手段で、SCの仕組みは昔からあったけど、イマイチだった。やり方とか、必要な部分をちゃんと明確にするのがマイグレーションであって、なんかベンダーロックインの助長ツールのアピールの場になっている気がしないでもない。そもそも記事にE/Uのコメントがゼロって・・

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

AsakusaでCOBOLコンバーターができないか？といえば多分できる。ただ、なんとなく違和感があるのは、E/Uサイドが必要としているのは単純なSCではなく、より良い形バッチ処理で、設計思想や安定・安全性は維持したままでの、目通しの良い仕組みだと思うのよね。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

COBOLについては、そもそも新規でちゃんとかける人材がどんどん減っているし、仮に若い世代にCOBOLやれ、といってもモチベーションが下がるだけ。結局誰もメンテできないコードの存続が続くわけで、システムは所詮人だ、と言う部分はあるので。受け渡しの全体的な絵が必要ではないかな、と。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

バッチについては、「止めてはいけない」という大前提のもとで、ある意味妥協しつつなんとかメンテしてきた、というのが現状なわけで。ハード限界やソフト限界が近いをそもそもどうにかしたい、というのがニーズなはずで。仮想化とかそのまま持って行くというのは、まぁニーズはあるのはわかるけど。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@megumeru @nakayoshix まぁCOBOLクラウドについては、基幹バッチのどうするか？的な問題の方が、本来大きいわけで。そもそも特定言語の話ではないはずなのですが。・・COBOLの言葉の方が一人歩きしますね。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

そういやソートだけはPigでやる、とかいう話になってて、残りはCOBOLそのままよ的な話だったような気もするが、それでOSSって言ってもなぁ、とか思う。作る方もアレな感じだが、そこと組むとか言ってる某社もどうかな、とは思う。

中村 良幸 (Nakamura Yoshiyuki) @nakayoshix

@okachimachiorz1 @megumeru レガシー化したCOBOLerの救済的な意味合いが強い言葉なのかもしれませんね。BASICやDelphiクラウドは多分意味がないでしょう。Fortranクラウドは性能が出なさそうな感じしか(^^; 私はクラウド菩薩です。(ｷﾘｯ

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@nakayoshix まぁFortranは、次世代は事実上HPCへそのまま移行という気もしているので。

中村 良幸 (Nakamura Yoshiyuki) @nakayoshix

@okachimachiorz1 まあそういうことですよね。私は(自称)HPCおじさんでもあるので、その方面もウォッチしていきたいと思っています。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@nakayoshix ですな～。Fortranクラウドってのよりは素直にHPC環境を普通につかいましょう～って方が、Fortran的には正しい気がしますね・・・

中村 良幸 (Nakamura Yoshiyuki) @nakayoshix

@okachimachiorz1 グリッド・コンピューティングももはや死語でしょうか？

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@showyou いや、多分、今後はMapreduceを裸で書くってのはすげー減ると思うんですよ。生産性低すぎだから。んじゃ～、Pig・Hive・AsakusaのローカルUTってどこまでできるの?って話ですね。あとCIにどう組み込みか、とかそんな感じですね。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@nakayoshix それはさすがに死語でしょうw。今はSharedNothingが全盛期なので、多分そのうちSharedSometingに移行すると思います。グリッドだとSharedEverythingのイメージがあるので、その前提でのグリッドはない、と思います。

Geforce RTX 3060Ti @showyou

@okachimachiorz1 昨晩のHadoop話ですと、擬似分散環境なら起きないけど完全分散になったときに起きる問題、とかもありそうですね。Pig/Hive/AsakusaのUTは同意っす。Pigで延々集計した後にエラーでて終了、とか泣けますし。。

中村 良幸 (Nakamura Yoshiyuki) @nakayoshix

@okachimachiorz1 私のHPC世界は、11年前のAlphaWS(21264)で止まっているので、最近の事情にはとんと疎くて…(^^; 先日開催されたOSC2011北海道の懇親会の後、札幌C++勉強会の若手の皆さんと深夜まで語る機会があり、再びHPC熱に感染しました。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@showyou 分散でのエラーってのは微妙で単純な環境バグもあるんですけど、そもそもHadoopがかなりピーキーな仕様なので、なんか今まで表にでなかったヤツが、はずみで顕在化するということもあって、その場合はハマリますね。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@nakayoshix HPCはGPGPUとかも盛り上がっているので、技術計算ではリベンジ来ると思いますよ。ただ、アルゴリズム変更がなにげに出そうな気もするので、その辺は知恵がいるかと。

中村 良幸 (Nakamura Yoshiyuki) @nakayoshix

@okachimachiorz1 まさに仰る通りそのGPGPUの話しを延々と…ｗ CUDAとかその辺の用語は聞いたことがあるだけで実際にプログラミングをしたことはなかったのですが、それでもすごく面白かったです。最近は札幌のC++が熱いです！ http://t.co/D0c7NxV

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@nakayoshix なるほど。C++ですかw。頑張ってください！

Suguru ARAKAWA @ashigeru

@okachimachiorz1 既存資産の流用という観点ではそんなもんじゃないかなと思います。ただ、こっちが抱えてる問題を向こうは増幅して抱えることになりかねない感じも

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@ashigeru まぁあと二年で人が完全にいなくなりますってお客さんもいますし。人的な話がおおきいかな、と。流用っていうより目をつぶってデッドエンドをひたすら、ばく進状態になりかねないな、と。

ぎじん @gijin_ob

@okachimachiorz1 これを模索してるところは結構多いのはその通りなんですが、結局決め手に欠けているのと、現状の分析で息切れするパターンだったりしますね。でリプレース案件にしてリプレースするときに地獄見て、無理矢理コンバートして後日また地獄見るみたいな。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@gijin_ob 適切なリプレース手法がなかったのが最大の敗因ですね。そもそも非同期データフローの仕組みを、同期集合演算処理のSQLに移行しようした時点負けっぽい感じですからね。

ぎじん @gijin_ob

@okachimachiorz1 そうなんですよね。でもってそこで無理矢理Pro*COBOLとかで無理矢理SQLなんて組み入れるからさらに話が根深くなり・・・フェッチで一件ずつ読んで、ってそこまでしてCOBOL？みたいな。まぁ当時は仕方ない道だったのかもしれないですけど。