1248725839**[情報整理]question:1248422316の一時コピー(作業用・コメント編)

dev_zer0 2009-07-24 21:39:23

COBOL単体だけだと大して意味はありません
・固定長レコード
・JCL
・大手ベンダーの保守(ハード＆ソフト)
のセットになると強力になるのです
　
さらに
・歴史や経緯を知らないと訳がわからない混沌とした仕様
・うっかりシステムを止めてしまうと莫大な違約金を払うという責任
があったりすると誰も手出しができなくなります

ikasamt 2009-07-24 23:47:45
dev_zero0さん。コメントありがとうございます！
参考になりました。
＞固定長レコード
どのような点でこれが有利に成るのでしょうか？また他言語等で実装しにくい理由は？固定長なら別にどんな言語でも高速に処理する手段を持っていると思うので、差別化しづらいと思いました。
＞JCL
http://ja.wikipedia.org/wiki/Job_Control_Language
メインフレームでの開発経験が全くないので（Linuxばっかりです）、イメージがわかないのですが、参考になるURL等ありましたら教えて下さい。
＞大手ベンダーの保守
確かに自前でSIするのはコストなので大手ベンダーにべったりは管理が楽ですね。反面ブラックボックスになりますよね。

ikasamt 2009-07-25 00:28:29

銀行ってトランザクションのACIDを維持する代わりに、すべてをバッチ処理にしてしまって、重複やキャンセルクエリを省いてるんですかね。だとしたらびっくりするくらい単純だし不便だなー。株とか外貨とかの場合はどうしてるんだろう。詳しく歴史や仕様が書かれた本があればいいのですが。
今回質問したのはcobolの優れた点を自分が全く知らないという好奇心と、SIerの本丸はここら辺だと思うのでWEB屋だと同じかそれ以上のことが１００分の１の予算で出来るんだぞということを証明してみたいという夢があり、そのための下調べです。
もし「WEB屋には無理だ」という意見のかたがいたら迷わず懸念点を教えてください。

khazad-Lefty 2009-07-25 09:21:53

ここには書いてないですが、銀行系なら丸め誤差の話は無視できないんじゃないでしょうか？
COBOLがデフォルトで10進をサポートしているというのは結構大きいとおもいます。
http://ronspace.cocolog-nifty.com/blog/2008/10/fortran-cobol-2.html
http://ronspace.cocolog-nifty.com/blog/2008/10/post-2512.html
とはいえ、上記のようにJAVAでも多少冗長な記述は必要だとはいえ(実はそうでもない？)、
上記のように対応しているわけで、日本でもフロントエンドから少しずつ置き換えられているのは事実ですし、アメリカあたりだともう少し置き換えは進んでいるという話を聞きます。

ikasamt 2009-07-26 01:14:08
＞khazad-Lefty
ありがとうございます。
具体的な事象についての資料で参考に成ります。
参考に調べてみたら面白い書き込み見つけました。
http://pc12.2ch.net/test/read.cgi/tech/1158154668/560
他の方がおっしゃっている「明文化されてない仕様」ってこういう演算精度まわりでのこととかも含みそうですね。確かにこれは暗黒だなぁ。
standard_one 2009-07-26 10:53:03
少し論点がずれるけど、PHPに移行なんてなったら質の悪い自称技術者がいっぱい集まってきちゃいそうだなぁって思った。
「コードだけ納品すればいいッスか？」
いいわけねーだろｗ

ikasamt 2009-07-26 13:49:09
standard_one さん
コメントありがとうございます。
php周りのWEB業界も決して美しいもんじゃないですからね。コードを読まずに設計を理解せずに既存のソースをちょこちょこ書き換えて納品する技術者も多いと思います。
皆さんの回答やコメントを読ませていただきながら思ったのは、僕のcobol銀行業界に対する疑問不満ってphp/java/rubyも含む疑問不満で、「なぜ問題を切り分けで小予算／少人数で実装＋検証が可能な最小単位でサービスを作らないのか」「なぜ大プロジェクトの名の下に巨大な人月単価での仕事を発注／受注するのか」という所のようです。乱暴な言い換えをすると、「クラスがどーだとかテーブル設計がどーだとか、言わずに、特定のビジネスロジックを体現する1k行程度のhttpデーモンいくつも作って、疎結合させた方が、大規模開発に向いてるんじゃないのか？」という感じですね。
もしまだこの質問を見て回答やコメントを書いていただける方がいらっしゃたら、是非その辺りについても意見を伺いたいです。

keino 2009-07-26 22:56:05

人間は理屈じゃなく感覚で動きたかったり、面倒くさいことは回避しようとするもんだからね。
世の中はその欲求を満たすように自動化できることは、自動化してきた。
だけど誰かが自動化するための仕組みを考えて実現させているわけで、その仕組みを作っているのはやっぱり人間なんだよね。
自動化する部分が多くなるほど、仕組みは複雑なるのでシステムが大規模になる。複雑なプログラムを作るのは大変なので、またその作業を自動化しようとしていろんな言語が開発された。でもその言語で書かれたことを装置に判るように書き換える作業も複雑になっている。
無限ループですね。

walkingreed 2009-07-27 10:33:07

>お金をかける前にたとえ遠回りでもゼロから再構築してユニットテストが通ればOKの状態にすればいいのに、と思ってしまいます。
単体テスト通ればOKで済むならいいですが、実際問題その程度のテストじゃまともに動かないでしょう。

>特定のビジネスロジックを体現する1k行程度のhttpデーモンいくつも作って、疎結合させた方が、大規模開発に向いてるんじゃないのか？
勘定系での大規模開発は経験ないですが、自分の経験から考えてその程度の考えでまともに動くものができるとは思えません。
それ単体でそれっぽく動くのを作るのは確かに簡単でしょうけどね。

銀行ほど大規模なシステムじゃないですし内容が全く違いますが仕事でFortranとかアセンブラとかからCへの移植は経験ありますけど、仕様書は一応ありましたけど結局はソース読まないと話になりませんでしたね。
あとプラットフォームが違ってくるから、OSレベルの違いにも対応が必要だったりします。
アセンブラの時はbit数の違いも、バイトオーダーの違いもでてきたりで。

dev_zer0 2009-07-27 20:18:05

> １．高負荷のトランザクション処理が出来る
という意味で他の言語(というより環境)が真似できないことで
　
固定長レコード「のみ」を扱うことにより、作成したプログラムがメモリをどれぐらい使うのかを予め予測できる。
JCLでメモリ制限やCPU制限を設けることにより全てのプログラムを止めずに
ほぼ100%のCPU、メモリを使いきることができます。
　
これが他の環境だとプログラムが占有するメモリ量を予め見積もれず、
また、そのプロセスに割り当てられるメモリ量も制限できないので
あるプロセスが暴走してしまうと、他のプロセスが仮想メモリに追いやられたりして
そのマシン上にあるほかのプロセスも遅くなりがちです。
しかも、マルチスレッドなんかで作っていたりするとそのプロセスが死んでしまうと
そのプロセス上で動作しているスレッド全てがお亡くなりになります。
　
まぁ、そこら辺は基幹系になってくれば監視する人間がいる筈なんで
異常を検知すればすぐにオペレータが飛んでいくでしょう

keino 2009-07-27 22:34:41
回答5へのコメントより
＞資産計上している1000億の項目が一気にゼロ円になってしまい、会計上悪い
減価償却という言葉を知りませんか？
いままで1000億の費用がかかっていても評価額はそれよりずっと小さいです。

この話題はなかなか興味深いのですが、ikasamtさんは想像や経験則などあまり正確でない(裏付のない)ものを根拠に話を進めようとしていると感じます。そういうことでは、お金を扱うシステムや大規模で複雑なシステムに関わるのは無理だと思います。

ikasamt 2009-07-27 23:18:30
keinoさん
＞減価償却
たしかに減価償却で評価額は年々下がっていますね。
一気にゼロは誤解を招く表現でした。
＞想像や経験則などあまり正確でない(裏付のない)ものを根拠に話を進めようとしていると感じます
すみません。議論を進めているという意識は薄かったです。「個人の質問」として話を進めているつもりだったので、丁寧な議論をすることに注意が向いてませんでした！ご気分を害したことをお詫びします。
>そういうことでは、お金を扱うシステムや大規模で複雑なシステムに関わるのは無理だと思います。
申し訳ございません！出直してきます！

keino 2009-07-28 00:28:06
人力検索なので個人の質問として話を進めるのは構わないのですが、今何を知りたいのかがイメージしずらいんで、回答として書き難いと私は感じるんですよ。
逆提案をするのではなく、もうちょっと何について知りたいのか明確になるようコメントを書いて欲しいです。

chuken_kenkou 2009-07-28 20:41:06
COBOLの特性や背景については、他の方から良い回答もあるようなので、少し違う観点から。
数年前（2000年以降）のIT業界の調査で、「現在、世界で稼動中のシステムのうち、過半数はCOBOLで構築されている。」という調査結果があります。
こういったサイトで、「COBOLが現在も使われているのは、金融系くらい」と発言する人がいますが、ライフラインを支える多くのシステムは、現在でもCOBOLで構築されているものが多く、完全に脱メインフレーム、脱COBOL化された例は、世界的にも殆どありません。
ライフラインを支えるようなシステムでは、時代のニーズに合わせてDB/DC製品を中心に高性能、高信頼性に加え、いろいろな機能を実装しています。
DB/DC製品には、トランザクションを高速化するため、COBOLをターゲットにした機能を実装しているものもあります。
階層型DB、ネットワーク型DBに加え、1980年代後半にはリレーショナルDBも実用化され、埋め込みSQLも、主要メーカーから最もニーズのあったCOBOL コンパイラでいち早く提供されました。
既にあるCOBOLの資産を、すべて他の言語で書き換えるというのは容易でなく、COBOLのソースをそのままUNIXやWindowsで動かせるCOBOLが、主要メーカーから出揃っており、そういったハードの移行を行う例もあります。
また、標準COBOLの改訂も盛んに行われ、それを実装したCOBOLも主要メーカーから出揃っており、アドレス操作、オブジェクト思考、オープン化などにも対応しています。