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

問題は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コード撲滅運動には丁度良い動きだな