【JaviteDefuser】COBOL550万行をJavaで再構築へ

　　COBOL550万行をJavaで再構築へ　　
　　　 - 日本貿易保険がアプリ開発とハードを完全分離して調達 -

　 http://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20040518/1/

COBOL550万行をJavaで再構築へ
日本貿易保険がアプリ開発とハードを完全分離して調達
日経コンピュータ2004年5月3日号，15ページより
独立行政法人の日本貿易保険は4月12日、同社の基幹システムである
「保険業務システム」の再構築計画を公表した。現状のシステムは、
COBOLプログラムで約550万ステップとなる巨大な“レガシー・システム”。これを、Javaで再開発する。2006年1月に稼働開始する計画である。

Nanite Defuser(核兵器無効化ナナイト)ならぬジャヴァイトデフューザー(COBOL無効化Java)だ！

日本貿易保険の総務部 畑（はた）幸宏システム室長は、「1992年に開発した当初は約
250万ステップだったが、継ぎ足しの開発でコードは倍以上になり、保守コストが大きく
なってきた」と再構築に至った事情に言及する。

　ただ再構築には、もう一つのきっかけがあった。
「（電子政府構築のため内閣に設定した組織）IT戦略本部から“レガシー刷新”の指示
がきた」（畑システム室長）のだ。現状のシステムは、NECのメインフレームACOS-6で
稼働している。レガシー刷新は、自民党の「e-Japan重点計画特命委員会」が出した指
針に基づき、IT戦略本部を通じて中央省庁全体で進めているが、同システムはその
第1号となる。

　再構築は、日本貿易保険が入札をかけた結果、主に日本IBMが担当することになった。
現状のシステムを三つの新システムに分割して開発する。 (1)保険業務の基幹部分であ
る「保険業務システム」、(2)会計や総務業務のための「会計総務システム」、(3)再保険
処理のための「再保険特別会計システム」、である。メインとなる(1)を日本IBMが落札し、
開発費用は39億7950万円。

　調達先ベンダーの選定には、政府関係でこれまでにない方法を取り入れた。日本貿易
保険は、アプリケーション開発とハードウエアの調達を全く切り離した。日本IBMの金融
システム事業部 第一事業部第一営業部の安部欣也クラスターサービスマネージャー
は、「公共系の入札で自社を見渡した限りでは例がない」と異例な条件であることを明
かす。

　ハードウエアの調達は今年末に入札を行う予定である。畑システム室長は、「アプリケ
ーションは、OSやミドルウエア、ハードウエアの構成にかかわらず稼働するようベンダー
には伝えてある」と語る。Javaによる開発を必須条件にしたことは、Webアプリケーション
であることに加えてハードウエア非依存を狙ったためだ。

　ハードウエアに依存しない形で開発ができるかどうかに対して日本IBMの金融
ソリューション・センター保険第四ソリューション・サービスの
福島崇夫ICP-ITスペシャリストは、「サーバー向けJava技術のJ2EEを用いる範囲
であれば移植性をある程度確保できる」とする。逆に言えば、OSやミドルウエアに
依存する部分は、変更のリスクを日本IBMが抱える。

　また安部マネージャーは、「ハードウエアが他社製になった場合に性能や障害に
対してどのように保証するのか問題は残る」と指摘する。例えば、ハードウエア設計
を前提にした、性能向上や障害対策のためのアプリケーション設計ができない。
ハードウエア非依存のアプリケーション開発がコスト減につながるのか、
あるいはコスト増になってしまうのか、結果を注目したい。

これこそがCOBOLer最後の仕事というやつですな。
Javaへのリプレースが終わったらCOBOLerとしての仕事は無くなる。

CDMAOneを撤去したらそれ専門の仕事がなくなりリストラ対象にされるかのような

COBOLシェア縮小への道を意味する出来事だ　

デスマーチになりませんように。

>6
もうなっているだろ

COBOLとJava両方を使うからどうしてもデスマーチに。
COBOLを使っている時点で即デスマーチ。
ただしこの壁を乗り越えればCOBOLをあのシステムから
抹消することができ今後デスマーチが起こる生起確率が下がる。

使用言語が原因であるデスマーチなんぞ無いぞ
その言語しか知らないゆえに誤った判断をしてしまい、
それがデスマの原因（の一つ）になることはあるが（W

これでいっそうぬるぽが市民権を得るわけだな。

>>9
全くだ。
結局、Java でオブジェクト指向って何すかプログラミングをやって、
デスマーチになって、
プロジェクトがぐじゃぐじゃになって、
ぐじゃぐじゃをぐじゃぐじゃに保守することになる。

まあ、余程スキルの高い開発陣なら話は別だが、
39億も使うようなプロジェクトじゃ、
どっかに癌を抱えてるわな

と、COBOLでデスマったコボラーが申しております。

オブジェクト指向なCOBOLを作った方がいいんじゃないのか？

Objective COBOL 2004 Professional Edition

じゃ、それで

で、これでさクラスが全部
Class001111
Class002131

とか連番でさ、
継承とかしてなくてさ、
全部publicでさ、

笑えるかんじになるんだろ。（開発してるやつ以外は）

ｼｽﾃﾑは刷新されるが、
使う香具師も作る香具師も運用保守する香具師もﾎﾞｺﾗｰだからな。
連番はお約束だろうな。

IBMだと、ハードだけは自社製をぶちこんで
運用保守で甘い汁を吸い続けるってのがお約束な訳だが。
どうなるのやら。

COBOL・汎用機関連2chスレッド　http://pwiki.chbox.com/pukiwiki.php?COBOL

■情報システム＠2ch掲示板

メインフレームってこの先どうなの？
（00/12/19） http://mimizun.com:81/2chlog/infosys/science.2ch.net/infosys/kako/977/977231011.html
↑
情報処理にはＣＯＢＯＬが最高の言語である！
（02/01/10） http://mimizun.com:81/2chlog/infosys/science.2ch.net/infosys/kako/1010/10106/1010636100.html

■プログラム技術＠2ch掲示板
↑
COBOLなら、オレに聞け！
（02/07/30） http://snapshot.publog.net/html/tech/2002/07/30/024437.html
（01/10/12） http://pc3.2ch.net/tech/kako/1002/10028/1002890663.html

■プログラマー＠2ch掲示板
↑
メインフレーム万歳
（04/04/11） http://snapshot.publog.net/html/prog/2004/04/11/203647.html
（03/10/09） http://snapshot.publog.net/html/prog/2003/10/09/002335.html
↑
COBOLerの頭の構造
（03/11/03） http://snapshot.publog.net/html/prog/2003/11/03/221559.html
（03/08/22） http://pc.2ch.net/test/read.cgi/prog/1061479188/l50
↑
COBOL屋をけなすスレ
（04/04/20） http://snapshot.publog.net/html/prog/2004/04/20/230726.html
（02/08/09） http://pc3.2ch.net/test/read.cgi/prog/1028859171/
（02/07/28） http://pc.2ch.net/prog/kako/1027/10278/1027824043.html
（02/07/14） http://pc.2ch.net/prog/kako/1026/10265/1026572598.html
（02/04/21） http://pc.2ch.net/prog/kako/1019/10193/1019365551.html
（02/03/31） http://pc.2ch.net/prog/kako/1017/10175/1017546043.html
（02/03/01） http://pc.2ch.net/prog/kako/1014/10149/1014926968.html

COBOL開発でデスマって聞いたことないね。

java開発でデスマっていえばそこらじゅうに転がってるだろうけど。

片や枯れてて技術者も経験豊富。
片やどかたで技術者もごみ。

俺はcobolでもjavaでも開発したいと思わないけど。
無理にでもやれといわれればcobolかな。

> 　ハードウエアの調達は今年末に入札を行う予定である。畑システム室長は、「アプリケ
> ーションは、OSやミドルウエア、ハードウエアの構成にかかわらず稼働するようベンダー
> には伝えてある」と語る。Javaによる開発を必須条件にしたことは、Webアプリケーション
> であることに加えてハードウエア非依存を狙ったためだ。

この時点でデスマが見えてきてるな。まぁ、関わる奴らは
頑張れよといいたい。

死人がでなきゃいいけど〜

COBOLでやっていればいいじゃん。Javaにしたから保守性が上がるとか
どっからそんな迷信が沸いて来るの？結局オープン系の技術者の単価が
安いから、新規性を謳うためにはダウンサイジングしかないのでJavaになった
とか言い出すんだろ？

どこの紺猿のしごとですか？
（余計なことを・・・）

COBOLで別にいいじゃんよねぇ。

そこでNetCobolですよ。

でも強引にでもオープン系の技術を採用でもしないと、
新規の開発案件なんて掘り起こせないからね。

＞COBOL開発でデスマって聞いたことないね。
いまの４０代にんなこと言ったらぬっころされるぞ。

まあ、最近はCOBOLデスマってのは無いんだ。
部族伝承レベルなんだが「やってはいけない事」が蓄積されてきてるしな
環境も長期安定だし(w

このスレを見た部長から居酒屋に連行されそうです。
責任を取ってください。

君ら、デスマデスマって、ほんとのデスマに遭ったことがあるのか？
デスマデスマ言いたいだけちゃうんかと

んだ、スレタイのレガシーモノだって、COBOLでの壮絶なデスマの末55MStまでふくれたんだろうに。

あ、5.5Mだw

50万ステップくらい一人で書くから3億くれ

この案件どこ行けば拾えるん？
案件くれ

しっかし思い切ったことをするもんだ。

変換マクロで作ってやるから
１億クレ

なんでJavaなんだ？Rubyにしろよ。

終わる頃にはSunがIBMに買われてたりしてな

まずは

> 開発費用は39億7950万円

この時点でかなり吹っかけられてるだろ。
新規開発の金額だよな。移行じゃねー。

そんで実際javaにしてみたらやっぱり
継ぎ足しでシステムふくれて行って
思ったより機器の保守費用も安くならなくて

「かわんねーじゃん」ってことになるだろうね。
たのしみだなー。

かわんねーじゃん、にならないと漏れら人貸しは儲からないわけでｗ。いいんじゃないっすかね。

うまいこと丸め込んだもんだ。さすがはIBMの紺猿

２次受け、３次受けの悲哀が目に浮かぶ。

終わった言語で書かれたシステムを
終わろうとしてる言語で再構築してどーすんの？

JavaからC#へのトランスレータを開発したら儲かるかな。

その程度じゃもうからね。
C++からJavaへのトランスレータのほうがもうかる。
Java → C#への以降とくらべ非常に困難だから

Javaって終わりかなぁ。
あと１０年もたせないとな。

ブレイクしてから５年たってないからね。
COBOLのように数回のリプレースを経ないと、根付かないと思われ。

>>13-14
だったらVirtual Machine上で動くCOBOLを作ったほうがまし。
もちろんオブジェクト指向大前提で。
ちゃんとガーベッジコレクタも搭載し実装多重継承も禁止し
型安全性も高め例外処理もしっかりと実装しジェネリックスも利用可能で
堅牢性の高いCOBOLを作るべきだ。

そうでなければCOBOLを捨てJavaを使え

ということになる。

>>44
なんかさ、簡単ぽくない？それ。J♯とか言ったりして。あれ？

Javaが終わりということにしたいヤシがいるだけだろ。
どのみち、仮にJavaが終わったとしても
Javaを習得して損をすることは無いわけだが。
未来の言語はJavaライクな言語しかないのだから。

だれも習得する話題なんてしてないでしょ。
４０億投資してCOBOLで書かれた膨大なコードをJavaで書き直す話でしょ。

それは、COBOLerに与えられた最後の仕事だった・・・・・・・。

COBOLer最後の仕事・・・・・・・。
それは、以下の内容だった。　

今からJavaを勉強すること・・・・・・・・・・・。
COBOLをJavaにリプレースすること・・・・・・・・・・・。
COBOLを捨てること・・・・・・・・・・・・・。
最後にオブジェクト指向を学ぶこと・・・・・・・・・・。
この仕事を見事完遂したときには、今後二度とCOBOLに触らないこと・・・・・・・・・・。
今後、二度とCOBOLコードを繁殖させないこと・・・・・・・・・。

んで、この仕事はｺﾎﾞﾗがやるのかそれともJavaﾄﾞｶﾀがやるのか。

ひょっとして､､､､
JavaにするのはCOBOLプログラマを確保できないからなんじゃ､､､､､

COBOLerが書いたJavaのソースを見たことがある・・・death。

>>54
正解。
地獄を見るだろうなぁ。PGは。。。

全国のJavaPGの皆さん良かったですね。おしごとですよぉ。

だからさ。金額的に見てもリプレースじゃないでしょ。

新規開発だよ新規開発。

まぁクライアントが金持ってるみたいだからいいんじゃ
ないの？Javaやってる馬鹿PGにも仕事ができてよかった
じゃん。

でまたCOBOLのようなJavaの糞ソースが積み上げられると。

3000行のクラス、継承なしみたいな。

やっぱりUMLとか書くの？

Javaでもやっぱりカーソル作って一行づつフェッチして合計したりとか。

全部staticだったり。

そいでPrivateメソッドにM010-012とか階層つけた番号の名前つけて、
呼び出し階層図Excelで書くと。

未踏プロジェクトに応募すればいいのに

先生。DATA DIVISIONがありません。

先生、このX項目は何桁でしょうか？最大長が示されないと不安です！

なんでJavaなのかが激しく疑問・・・

>>68
そりゃ安いPGを大量に揃えられてIBMがウハウハだからさ。

>>68
こういう場合JAvaよりなにが最適なんだ？

>Javaによる開発を必須条件にしたことは、Webアプリケーション
>であることに加えてハードウエア非依存を狙ったためだ。

そこでPerlですよ。

やっべ、Aを大文字にしちまった。
これがばれたらJames Goslingに殺されそうだ。

Rub・・・ゴメン。許してくれ。

　　そ　こ　で　Ｒ　ｕ　ｂ　ｙ　で　す　よ　

>>73
そのあとにyが付くようであれば、今から沢村を送り込みますよ。

JavaとRubyとPerlの中間とって、
マシン語でどうだ？

お前ら何言ってるの？
.netで決まりだろ！

つうかさ、Javaって上位互換性とか保たれていくの？
それにサンマが手を引いたらどうなるんだろ。

そりゃIBMがやるさ。もうみんなEclipseつかってんだぜ？

IBMはただのSIerでしょ

>>79
IBMがそんな間抜けだと思ってるのかよｗ

>>79
EclipseつーよりもWASな

>独立行政法人の日本貿易保険
>レガシー刷新は、自民党の「e-Japan重点計画特命委員会」が出した指針に基づき、
>IT戦略本部を通じて中央省庁全体で進めているが、同システムはその第1号となる。

政府つーか自民党主導ねえ。貿易保険つーぐらいだから航空機船舶?国交省(旧建設)がらみかな?
公共投資の下ろし先としちゃ高速道路もダムも駄目になったから今度はコンピュータつー感じすか?
裏の事情が透けて見えそうだね(w
情報ゼネコン丸投げの下、紺猿が派遣会社ドヤ街から人足集めてデスマの現場につっこむのであろうな。
公共投資でドカチン、ドカチン。ますますドカタがかってきたな>Java(w

>>78
だから変わりに何を使えばいいのか教えれ
おまえの案を持ってIBMに行ってくるから

>>84
は？おもしろいね、君。

>>85
俺は目的の為ならSamuelの尻の穴に舌を突っ込む覚悟だぜ
貴様は大歳とイチャイチャやってろ

>>84
コボルでいいじゃん。

COBOLのままだとPGを集められないからでしょうね。

村上龍によればCOBOLプログラマーはみんな死んじゃってるらしいですしね。

変換ツール作るか、展開形出力して以降、アセンブラで保守すれ。

大手金融機関はＣＯＢＯＬどころかＰＬ／１で作った膨大な業務アプリ
抱え込んで身動きとれなくなってるところ結構あるからなあ。
あっちの方が大変だろ。

PL/I と COBOL、書ける必要はないが読めるようになっておくと、
そこそこ案件ありそうだな。

いや、俺はやりたくないけどな。(w

これでJavaPGがドカタだと言い張るならそれは全員元コボラとしか言いようがない。

JVM上で動くPL/IとCOBOLがあれば、それをコンパイルしてバイトコードで
保守すればよろ氏

なぜドカタと呼ばれているのかいまだにわかってない奴がいるな。

COBOLとJava両方を熟知していないとリプレースは不可能なわけで。
COBOLerが必須。
Javaを知らないCOBOLerをしっかり教育してシゴいてやらんといけないわけですなあ

>>95
ドカタ呼ばわりしたい理由はCOBOLerやアンチJavaの僻み以外に理由はないでしょ。

40代のオッサンが必死にJavaはドカタ言語だと主張しているみたいです。

COBOLerドカタ化Java(COBOLerを消去するJavaプロジェクト)っていうならわかるがなw

究極のリプレーサですな

Java知ってる人にCOBOL勉強してもらう
のだと思うが

提供されたフレームワーク、ライブラリ、サンプルソースを切り貼りするだけだから
ﾄﾞｶﾀ言語というのかと思ってたよ。

昔の大工と違って、最近の工員（作業員）は、建材会社のパネルを組み合わせる
だけで家を建てるでしょ？技術なんか何もいらない。

おいらの知ってるとある大手金融機関。

制御系．．．．．アセンブラ。
業務系．．．．．ＰＬ／ｌ（一部ＣＯＢＯＬ）

↑を全部Ｊａｖａにリプレース？気が狂うなｗ。

本当にそれでいいのだろうか・・・・。

COBOLの様な処理ってさ、現代じゃストアドが担当するんじゃないのん？
PL/SQLでいいじゃん。

>>105
C/Sで書くなら、Server側ロジックとストアドになるだろうなぁ…
ただ、運用保守の関連で、PL/SQLを保守できる人材が確保できないとかで、
ストアドが良いと言ったにもかかわらず蹴られたことあり。
結局全部Server側のJavaBeanにロジック実装。
ストアドにすればもっとパフォーマンス上げられたんだが。
まぁしかたねーな。

>105
ストアドでオンライン書くのか？
あんた神だね

＞昔の大工と違って、最近の工員（作業員）は、建材会社のパネルを組み合わせる
＞だけで家を建てるでしょ？技術なんか何もいらない。
昔は技術もあったし、それを活かして仕事してた。それが住宅メーカーの下請けとして仕事をしているうちに
技術もなくなった。もう家一棟建てられる大工自体、少ないんじゃないのか？

ドカタPGが馬鹿だと言うつもりはないけど、ああいう仕事ばかりしてると馬鹿っぽくなるのは
確かだろうね。食っていくためにはしかたないんだけど。

なんで、DB周りとかシステム構造とかに話題がいかないのかなぁ。そっちの方が本質的だと思うんだけど
あっ・・・。JavaとCOBOLの対比を楽しむスレだからか？。シツレーしました

>107
OASだっけ？OWSだっけ？ストアドからHTML吐き出せるヤシ。

そういえば、最近のDBってHTTPでストアド呼べるよね。どうでもいいけど。

SELECT文でXMLも吐けるよ。

>>110
OWS 2.0→WAS 3.0→OAS 4.0だね。最近はJSPを真似てPL/SQL Server Pages
なんてのもあったと思う。
で、俺も105の言う通り、分散トランザクションがどうのとか面倒言わずに
バックエンドはストアドに任せれば？と思うんだけど、
元記事を見ると入札条件がプラットフォーム、ミドルウェアにできるだけ
依存しないこと、となってるようだね。。。

COBOLerのPL/SQLはかなりイカしてますた。
やっぱり非条件SELECTで全レコードとってきてロジックで集計するのな。orz

必ずWHERE句無しカーソル開いてぐるぐる〜。

>>114
こういう神がいた。
そいつはすんごい腕利きのSE/PGで
そのせいか、>>114が指摘するようなcoboler
がいっぱいのプロジェクトの責任者になってしまった。

そいつは既存コードをみて、あるプログラムを一週間で
しあげてきた。

cobolerの非条件セレクトやロジックを検出し、そいつを
条件付きセレクトに変えたり、ロジックをソースレベルで
最適化したりする、トランスレータを作ってきたのだ。
もちろん、既存コードとの新コードを自動テストする機能
までつけてきた。

結果、実行速度は３０００％もupした。

が、そのコードとそいつがどうなったかと言うと、まわり
から総スカンで廃棄、そいつはやめさせられてしまった。

理由は、金がとれなくなるのと、既存コードを書いたやつ
からのバッシング。また今まで関連した人間の責任問題に
まで発展する可能性があった。（ここまでパフォーマンス
があがってしまったので。）

そのトランスレータは捨てられ、そのSE/PGは転職して
しまったよ、、、いまは、農業をやっているとのことだ。

続き

許せないのはそのあとだ。

COBOLERのリーダだったやつが
そのコードを自分のものとして、
提出したのだ。

そいつはいま、取締役、そのコードは
現役稼働。その会社はCOBOLER保守
ツールを活用し、急成長。

世の中狂ってる。

トランスレータは捨てられたんじゃないの？

>>118
まずそんなトランスレーターが存在するわけないということに気づけ。

ﾈﾀだよﾈﾀ。

全部シングル�d

>>119
いや、こういうトランスレータって別に作れるだろ。
コンパイラの知識が詳しくあるやつなら、結構なところ
まで行けるはず。もとのが糞コードが、単純にかいて
あれば、それだけやりやすいとおもけどな

>>119
いや、こういうトランスレータって別に作れるだろ。
コンパイラの知識が詳しくあるやつなら、結構なところ
まで行けるはず。もとのが糞コードが、単純にかいて
あれば、それだけやりやすいとおもけどな

>>119
常識的には存在するわけないんだが、COBOLerが絡むとなると常識が
通用しない場合もあるわけで…

その手のロジックを書く時に「これこれのソースをコピペしてから
この部分を必要に応じてこういう書式に基づいて書き換える」と
いう規約に基づいて書かれたコードの場合、トランスレータで
対応できてしまう場合もあり得るという…
この種の糞規約に限って、書式に関してだけは機械的に処理し得る程の
厳密な制限を課していたりするわけで…

>>123
その程度だけでなく、コンパイラの最適化の
応用で、非条件SELECTー＞ロジックで結びつけてる
くらいだったら、行けそうな気もする、。

話の腰を逆方向にクラッシュするけど、このリプレースの意義について。

・マシンリプレース(これだけで夜間バッチコースが8分コースになる例も多い)後、
COBOLの実行体のっけて、何らかのラッピング技術で抽象化して、
それをJavaClassとして用い、つじつま合わせる。

とかって、無意味だったり、現実的に不可能だったりします？
（2000年くらいの日経コンに例を見たような…）

上記なら、レガシーはスピードUP、新規はすべてJava設計になるから、いいかなぁと。
あ、でもレガシー側だれもメンテできないや。

一人後言ｽﾏｿ

なんでc系ではなくてjavaなの？
cの方が速いンじゃないの？
ねぇなんでなんで？

>>126
>>1-3まで読め、それでわからなかったらお前は馬鹿だ。

問題はCMP Entity Beansを使うヤシが少ないことだ。
ほとんどのプロジェクトがStateless Session Beansばかりつかっている。
これではCOBOLerとあまりかわらない。

>>128
CMPはEJB 3.0が出るまで待つのが正解だった。
なんであんな複雑な設定をシコシコしないといけないのか
EJB 2.0の仕様を嬉々として覚えて悦に入ってた人たちこそ開発者に向いてないよ

ハードに依存しないっつったらCの方がいいんじゃないの？
WebアプリのとこはPerlにすればいいじゃん。

いっそのこと全部Per（ｒｙ

>>129
DBアクセスはCの仕様の範囲外だろ。よく読め。

>117　俺から見ると、そいつは普通の勝ち組だな。
「能力がある奴が常に評価される」なんて勘違いする奴のほうが馬鹿。
駄目人間を使う立場・駄目上司と戦うになったときは、自分もある程度変わらないといけない、
コードを書く以外のパワーゲームが必要なんだよ。

実感こもっててﾘｱﾘﾃｨのあるレスだな。

>>130
はい、わかりましたので、知ったかぶりの学生は黙っててください。

おっさん＾＾

ふつーにっき。
Diarypage [余談,備忘録,日常]

May 27, 2004
COBOLからJavaへ?

http://blog.livedoor.jp/eikiti86/archives/715173.html

JavaJava　Java
みんな〜の悩み〜

>>114
>やっぱり非条件SELECTで全レコードとってきてロジックで集計するのな。orz

それなら、SQLPLUSとかで全件アンロードしてファイルを作ってロジックで集計するが遥かにいい。
実力があるコボラならそうすると思うが。

2006年1月稼動なら、そろそろＵＭＬ作成に取り掛かっていないと間に合わないよな。

>>139
それってうちの職場でも50代コボラーがやってるけど、
集計した後SQL*Loaderでロードするんでしょ？
1行エラーデータがあったら即abendなんだもん。
運用担当に迷惑かけるので激しくやめてほしい

>1行エラーデータがあったら即abendなんだもん。
それは、アベンドさせるべきなのでは？

>運用担当に迷惑かけるので激しくやめてほしい
運用担当は歓迎するでしょう。ＣＰＵ使用率がかなり下がる。
テスターさんは大変でしょうが。

>>141
>集計した後SQL*Loaderでロードするんでしょ？

updateでいいじゃない？

>>142
＞それは、アベンドさせるべきなのでは？
そういうことを作ったコボラー本人が言うから周囲は怒るんですよ
だったら自分で夜中起きてリランしてくれよってね。
…これじゃ「COBOL屋をけなすスレ」だ。スレ違いスマ蘇

>そういうことを作ったコボラー本人が言うから周囲は怒るんですよ

テストが不十分なんですね。で、バッチから壊れたデータが紛れ込んでしまう。
おまいさんが、テストをやってあげたら？

それか、おまいさんがバッチ用ＤＢインターフェースを作って、
それをつかった更新しか認めないようにルールを作ってしまう。とか。

ははは、COBOL屋もJava屋も、ダメな香具師が受けるに決まってるプロジェクトなんだから、ろくなことになるわけないな。
IBMは香ばしいねぇ！5年前と何も変わってないのな
あぁ、ﾜﾛﾀ！

この後予測される展開。

ハード側もIBMが入札。
ハード(ﾟдﾟ)ｳﾏｰなので、ｿﾌﾄ側は適当な外部仕様だけやって、逃亡。
例のごとく他の企業がそのケツを拭くが、
ケツを拭いているように見せて、さらに仕様を糞にして
下に丸投げ、丸投げ、丸投げ。
下の方の請けた企業が糞仕様で糞コードを書き、糞システム完成、ただし動かない。

「動くけど役に立たない」のほうが正確なような

で、日系あたりが特集をやるわけだが

たぶん動かないだろうな。もしくは動かせたけど死人の山のデスマーチ。
言語がうんぬんは何の問題にもならないだろう。

もっと一般的な問題が成功と失敗の分水嶺になるだろう。
分割統治をいかにうまくやるか。
iterative な開発〜評価サイクルを維持できるか。

でもこういう試みには関わってみたいな。
COBOLer的なメンタリティを持つ奴は排除の方向で。

>>106
>ストアドにすればもっとパフォーマンス上げられたんだが。

おっと、ストアドどころか、JOIN禁止だろ。この手のProjは。（藁

StoredFunctionが、なぜどういう理由で禁止になるというのだ？
まじにわからん

>>152
>>106によると保守らしいぞ。

>>152
アプリケーションロジックはDBから極力外して、APサーバで全て処理する。
APサーバは数を増やせばリニアに性能が上がるからその方が拡張性が高い。

・・・んだそうです。

ISAMのようなテーブル構造なんだろうなぁ

ザ・フライのような、Javaで書かれたCOBOLライクな何とも言えない
妖怪が産み出されているのでしょう

いっこうにテーブル構成が決まってこないので、
自分の中だけで常識的に属性を分類、テーブルに分割、識別子決めをしてアプリ設計を進めていた。

こないだテーブル設計担当者の個人フォルダに「DB設計.xls」というファイルを見かけた。
1シートに「列名」「キー」「必須」「説明」の4列のみ見出しがあって、
ずらっと300行くらい何か書いてあった。

いったい何の資料だろうなあ。
"DB"って書いてあるけど、こんな内容ではまさかデータベースのことじゃないだろうし。


ああ、いつになったらデータベース設計資料が上がってくるんだろうなあ……。

>>157
後で出すからとりあえず作り始めちゃってよ。

struts+spring+hibernateでつくるらしいぜ

ストアドをCOBOLで書けるDBを設計し実装するところから始めればよい。

>>160
頭いいな！おまえ！

そしてピリオド打ち間違えてDBあぼーん

>>151
そこまで酷くはなかった。

ただ、そもそものTable設計も微妙で、
その辺でパフォーマンス落とさないためにView張りたかったんだが、それは禁止されたよ。
その結果、８個くらいのTableをjoinしたものを四つくらいUNIONするような
糞SQLが量産された。
もちろん、beanの中でStringBufferで連結。(w

あれメンテするの辛いだろうなぁ…
極力ﾒﾝﾃやりやすいように配慮はしたつもりだが、SQL部はどうにもならん。
開発中のTable変更ですら、結構痛かったし(w

（2004/6/23） COBOLコンソーシアム Web Site
【セミナースケジュール】
セミナースケジュール「第7回 インターネット時代のCOBOL活用セミナー〜EAと基幹系システムの再構築〜」を掲載

http://www.cobol.gr.jp/calendar/seminar/040727.html

>>146
「ははは」しかいえなくなるほどドトネト厨＝C・Perl厨はレベルが下がってしまったか

終わる頃にはJavaが終わりそうだな。

終わる頃には>>166の人生が終わりそうだな。

>>1のソースが日経コンピュータだったので、
「動かないコンピュータ・特別編」に掲載されるに1000ｳｫﾝ

動かないコンピュータは、>>168のブレイン

>>168のような動かない脳みそなんていらないよ。
本当に動く脳みそだったらもっとポジティブに考えるはずだ

ジャヴァイトディフューザー？

業務を見直したほうがいいのに

これも見直しの一つ

本当に業務を見直して、Java らしいコードを書けば、
せいぜい 5000 行ぐらいで片付いてしまうんだろうな。

ジャヴァイトブレイン

ジャヴァネットたかた

COBOLコード撲滅運動には丁度良い動きだな