【COBOL】コボラー集まれ！！！【事務処理】

1 名前：デフォルトの名無しさん [2006/05/01(月) 18:32:38 ] いるだろ？語ろうぜ 520 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 10:00:31 ] >>502 25年以上前だが、COBOLでRDBを作ったよ。 1989年まではSQLではなくてPrologで動作してた。 521 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 19:15:34 ] ＞25年以上前だが、COBOLでRDBを作ったよ。 どんな商用DB? 522 名前：wolf ◆8VH3XAqjlU mailto:sage [2007/09/20(木) 21:38:39 ] >>520 25年以上前だが、JavaでRDBを作ったよ。 2014年まではSQLで動作してた。 --- 2037年**月**日、あるJava'erの生涯より --- 523 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 22:46:09 ] だからおまえらここはコボラーを叩くスレじゃねえ。 コボラーが集まって話をするスレだ。スレタイ嫁よ。 どうしても発言したいなら、コボラーがJavaを できるだけCOBOL風に使えるような主砲をアドバイスしろ。 とりあえず上に出てきた、main()に全ての処理をぶち込んで クラスやスコープの縛りを受けずに済む方法を考えている。 メソッド定義を各プロシージャ定義になぞらえて メソッドを順に呼び出すやり方だ。 しかしCOBOLのPERFORM〜UNTILに相当する 条件付きメソッド呼び出し方法がないっぽい。 やっぱりJavaはここいらが弱い。 524 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 22:52:12 ] PERFORM xxx UNTILは条件付きっていうより繰り返し構文って感じだろ。 while や for で置き換えれば良い。 525 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 22:55:51 ] while(condition() == false){ method(); } 526 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 22:56:55 ] >main()に全ての処理をぶち込んで >クラスやスコープの縛りを受けずに済む方法を考えている。 自殺したいならそうするといい 生き延びたければJavaが体現しているソフトウェア工学の教えを真面目に学び取れ どうせCOBOLだけじゃ生き延びられんのだ 527 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 23:11:18 ] ソフトウェア工学ｗｗｗ 528 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 00:56:51 ] >PERFORM〜UNTILに相当する >条件付きメソッド呼び出し方法がない breakも無いくせに、何いっちゃってんの？ 529 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 01:05:56 ] GOTOがあるだろ。 530 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 01:12:31 ] >コボラーがJavaをできるだけCOBOL風に使えるような主砲をアドバイス どんだけ恥知らずなんだよ 他の言語使いがこんなこというの聞いたことないよ 531 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 01:42:25 ] フリーフォーマットの言語ではそんなに細かい構文まで 言語が用意してやる必要はないのだよ 単に基本的な要素を組み合わせればいいだけだ 532 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 07:34:14 ] ＞しかしCOBOLのPERFORM〜UNTILに相当する ＞条件付きメソッド呼び出し方法がないっぽい。 ＞やっぱりJavaはここいらが弱い。 いや、COBOLerの頭が弱いとしか思えんが・・・。 533 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 12:28:28 ] 金に糸目を付けないで、処理速度、ユーザビリティー共に優れた システム作れって案件があったら、オールCOBOLもオールJava も選択されないで、各々の特例を生かした、混在型のシステムが できあがる。 お互いの弱いところをつつき合ったって、どっちも納得する訳なかろ？ ま、どっちもどっち、ここでバカみたいに言い合っている奴らの程度が 低いってこった。 534 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 12:47:40 ] なんだよ特例って特性だろ まだわかってないバカがいるみたいだからもう一度いうぞ COBOLに生かすべき特性なんてないし、JavaがCOBOLに劣る点なんて一つもない むしろ混在型のシステムなんか、オールCOBOLにすら劣るだろうな 535 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 15:38:39 ] やれやれ。Javaを万能だと思いこんで長期間安定して稼働してる堅牢なシステムを わざわざJavaで書き直して、バグや負荷に耐えられなかったりでまともに動かない マヌケなものにしてどうすんの。 COBOLの悪口並べ立てて、Javaでなら安く済むかのように吹聴し、Javaで置き換える ように説得したあげくに、まともに動かないものを客に押しつけて、しかもその修正に まで金をとるんだから、はっきり言えば詐欺みたいなもんだ。 そこに流用すべき資産があるかぎりCOBOLは最強。動くか動かないかなんていう 低次元な心配は全く必要ない。UI部分にVBを組み合わせれば無敵。 536 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 15:52:28 ] 全く同じ仕様でいいなら、COBOL→Javaのマイグレーションは簡単なんだよ 気付いてないかもしれないけど、Javaに移行っていった時点で潜在的に非機能要件がいっぱい増えてんの スケーラビリティやらセキュリティやらなんやら、な COBOLが最強も何も、COBOLじゃJavaと同じモノ自体が作れないんですよ それから、Javaが万能なんてだれも思ってないぜ COBOLが無能過ぎるだけ 537 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 16:36:23 ] >>536 へー （・∀・）ﾆﾔﾆﾔ 538 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 16:45:21 ] >>537 古臭い煽りに敢えてレス そろそろコボラは観念して勉強始めろ 何一つ勉強しない分際で、現役気取ってんじゃねぇ 若しくはとっとと引退しろ 539 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 18:04:16 ] そういう文句はバグ数0でプログラミングできるようになってから言え。 期限も守れない、大風呂敷広げた仕様の半分も満たせない、それで一人前のつもりか？ COBOLerならきちんと完成させてからソース水増しする余裕すらあるというのに。 540 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 18:14:25 ] バグ数0でコード書けるのが良いことだと、 いまだに信じ込んじゃってるからなあ 541 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 18:19:28 ] >>538 ありゃ。カチンときちゃいましたか。カチンと。 そんなにいちいち他人の一言に反応してると、自分の啓発がおろそかになって 数年後には、ゆとり世代に同じこと言われてると思うぞ。 言語がどうのってこだわっているようじゃ、とても勉強しているとは思えない。 一生PGとして生きていくならいいけど、いい年したPGなんてここで馬鹿にされる コボラとなんら変わりないね。 一番使えないのは、PGMの勉強だけして安心している仕様書待ちのプログラマ。 言語なんてのは、使うときになれば直ぐに覚えられるだろ。 そんなに覚えが悪いのか？ 542 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 18:24:31 ] >>541 カチンとなんて、素で来ませんよ 最近2ch始めた方でしたか？ よかったら最近勉強されてること教えてください そのとき読んだ本なども、できれば 543 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 18:54:46 ] ＞言語がどうのってこだわっているようじゃ、とても勉強しているとは思えない。 全員が別に言語がどうのと拘っているのではなくCOBOLerが一方的に COBOLという言語にしがみ付いている感があるが。 Javaをやる連中は他の言語も齧っている感があるが、 COBOLerはオンリーワン的なイメージあるよな。 教育係とかもちょっとやった事あるけどCOBOLの上がりの人間が 一番物覚えが悪いよ。 説明しても「私は今までコレでやってきた」と机上コーティング始めるし。 それで他の人間よりも品質が上とか仕事が早いとかなら許せるけど、 そんなワケがないし。 で、テメエの能力の低さを「今までは・・・、」とか「COBOLでやれば・・・」とか愚痴りだす。 あからさまに向いていない案件でもCOBOLを持ち出したりするし。 漏れもCOBOLで向いているところはCOBOLでやればいいと思うし、 COBOLもそんな悪い言語ではないと思うが、COBOLerという人種が癌ではある。 544 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 21:21:55 ] 全員が別に言語がどうのと拘っているのではなくJava厨が一方的に Javaという言語にしがみ付いている感があるが。 C++をやる連中は他の言語も齧っている感があるが、 Java厨はオンリーワン的なイメージあるよな。 教育係とかもちょっとやった事あるけどJavaの上がりの人間が 一番物覚えが悪いよ。 説明しても「私は今までコレでやってきた」とEclipse使い始めるし。 それで他の人間よりも品質が上とか仕事が早いとかなら許せるけど、 そんなワケがないし。 で、テメエの能力の低さを「今までは・・・、」とか「Javaでやれば・・・」とか愚痴りだす。 あからさまに向いていない案件でもJavaを持ち出したりするし。 漏れもJavaで向いているところはJavaでやればいいと思うし、 Javaもそんな悪い言語ではないと思うが、Java厨という人種が癌ではある。 545 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 21:53:56 ] まじ意味わかんねえよな机上コーディング 546 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 21:59:47 ] >>542 > 最近2ch始めた方でしたか？ （・∀・）ﾆﾔﾆﾔ 本で勉強って考え自体がねえ。 システムってのは構築することが目的ではなくて、ユーザが使ってユーザが欲しい 容を用意するのが目的。どれだけ画期的なロジックを組み込もうが、メンテナンス性 がよかろうが、ユーザの求めるものでなければ何も意味はないよ。 何のシステムを開発しているのかは知らないけど、言語の勉強よりもその業務を知って エンドユーザの声を聞くことが重要なんじゃないかな？ ユーザの求めるものを現状のプラットフォームで構築するのがエンジニアの役割。 どうしても、現在のプラットフォームで構築が不可能であったり、困難である場合は リプレースの提案となる訳だけど、業務を理解していないPGの言うことなんかに、聞く耳 もってもらえないよ。 >>543 その通り。 COBOLも出来て困ることはないわけだし、職能によっては勉強が必要なわけ。 なのにJavaの方がCOBOLよりすぐれているんだから、置き換えてCOBOLなんて 捨ててしまえ。なんてレスばかりで、程度の低さが鼻につくわけさ。 547 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 22:06:12 ] >>545 机上コーディングするのは器財や環境が高価だった頃の名残じゃない？ 未だにやっているのは、そろそろ引退の輩なので無視の方向で Javaしか書けないヤツは十中八九字が汚いから字の練習にやってみるのはいいかもな 548 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 22:09:24 ] いったんCOBOLに慣れ親しんだらもう 他の言語を学ぶ気が起きないんだよ。 キーワードが大文字で記号が少なく、見やすい。簡潔。 Javaの醜いソースは見るに堪えない。 549 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 22:15:40 ] >>541はいきなりC++やASMでコーディングが出来ちゃう神様。 550 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 22:22:19 ] ユーザが求めているものは汎用機とCOBOLで作ったシステムではないのだ もうすぐこの世からなくなるコンピュータと もうすぐこの世からなくなる古代語で書かれたシステムが 欲しいと思ってる奴などほんとはいない それを口八丁で騙してなんとか延命を図っているのがコボラーなわけだ 551 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 22:37:28 ] ユーザがCOBOLかJavaかを気にしていると思っている馬鹿発見 552 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 23:12:23 ] >>551 言語を気にする香具師も居る。主に情シに。 十中八九デスマ確定案件になるがな。 Java でフレームワーク使ったら早くて安いんだろ？　ってヴァカと COBOL こそが安定していて枯れているから安全だ　ってアフォ、な。 それでもって 前者は仕様変更を幾ら行っても全然 OK！　って勘違いをしていて、 後者はまず現行システムのドキュメント化を丸投げしてくるドキュソ というパターンが多いな。 頼むからどっちも死滅してくれ。 553 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 23:57:54 ] >>552 情sysは件のユーザからは外れるだろ つーか、情sysは言語気にしろよww 554 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 00:02:00 ] なんか、7年くらい前のJ2EE vs .NETを思い出すなあ。。。 555 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 02:44:54 ] >>554 そんなのあったか？ 556 名前：デフォルトの名無しさん [2007/09/22(土) 07:10:09 ] >>536 ＞＞全く同じ仕様でいいなら、COBOL→Javaのマイグレーションは簡単なんだよ この作業がどれだけしんどいものかは、貿易保険のシステム（COBOL:500万ステップ） のマイグレーションで証明されましたが・・・ 当初2年弱の予定→4年 IBMのPMが2回交代 予算は2.5倍に膨れ上がる ちなみに、COBOL:500万ステップ　→　Java：400万ステップ　になりました COBOL：8行＝Java：1行じゃないんかいな COBOL→UNIX-COBOL（マイクロフォーカス社のアレね）のマイグレーションの方が時間とお金を節約できるので、 そちらを選ぶ会社も多い 中堅生保のシステムはCOBOL:2500万ステップ 大手だと1億を超えるところもある（手広くやるとシステムも巨大化するので） 557 名前：デフォルトの名無しさん [2007/09/22(土) 07:13:57 ] たったの500万ステップであのザマだったのに1億ステップやる？ それ以前にどうやって解析要員と開発要員を集めるんだ？ ただでさえ脱ITが多いのに COBOL→UNIX-COBOLへツール変換＋調整を選ぶでしょ JCL→シェルにツール変換できるし 558 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 07:56:46 ] ＞ちなみに、COBOL:500万ステップ　→　Java：400万ステップ　になりました ＞COBOL：8行＝Java：1行じゃないんかいな だから>>543みたいなCOBOLerがJavaやるとそんな感じになる COBOLerが無能と言ういい証明なんだろ？ 漏れだったらCOBOL比較で1/5の人員でクリアできる自信あるけど。 #ま、営業的にボるので1/3くらいにしとくが。ｗ 559 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 08:11:14 ] 漏れも保険関係のシステムやったことあるけど500万ステップってすげーな。 相当に無駄テーブルやらが無駄PGMがテンコ盛りな希ガス。 たぶん、死にモジュールや期限切れ機能とか整理されていない状態で なおかつ担当者もよく解ってない保険の掛け金管理とかやっていて、 移行中に年金問題よろしくな「おい、この客の掛け金の計算合わないぜ！」 って感じで公表できない問題のすり合わせで時間かかる事があった。 つか、この手のシステムで移行で問題なのは既存の設計が穴満載で、 その場をしのげればオッケイ的なCOBOLerの体質にあるな。 で、資料もお約束でメンテされてないので、COBOLerの作ったゴミソースを 解読しなきゃいけないが、それを頼んだCOBOLerがさらに間違えて解釈して デスマスパイラルが深まるってオチ。 相当に割り切りのいいPMがいてCOBOLのシステムを全否定する勢いでリプレースしないと 逆に地獄を見ると思うよ。 中途半端なマイグレーションはCOBOLerが組んだシステムだと鬼門。 言語が悪いんじゃなくて、主にシステム作る人間が悪いと思う。 極稀に設計を見ると美しいなー、って人もいるから。 560 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 08:20:39 ] 500万ステップが400万になったからって 何がどうというものでもないな。多いことには変わりない。 そんなにまでしてJavaにして何かメリットあんの？ 流行の言語で作り直してハイカラ気分を味わいたいとか？ 今COBOLでちゃんと動いてりゃそれでいいじゃん。 システム開発は保守的であるべきだ。 561 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 08:23:56 ] >今COBOLでちゃんと動いてりゃそれでいいじゃん。 現場の底辺はそれ考えでいいと思う。W ただ会社を運営する層はシステム部門が金食い虫の無能集団と思っているから 今後の開発・運用費を安くする為にシステムをリプレースするんだろ。 そして現状はCOBOLerの質があまりに悪いので気持ちマシなJavaなり .NETなり流れていくんだろ。 562 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 08:41:30 ] 安くなるはずがなんで開発期間延びて予算が数倍に膨れあがるんだ？ 563 名前：556,557 [2007/09/22(土) 08:56:37 ] >>558 ？？？？？ ざっくりとした役割分担は、 コボラー：解析、仕様書作成、ランフロー作成、データ移管 Javaプログラマ：開発、テスト です コボラーがJavaで開発したわけではありません 基本的にコボラーは開発には参加していません ちなみに結合テストの段階で単体レベルのバグが出て、このプロジェクトは何度も 仕切り直しています。 >>559 保険で500万ステップは小さい方です 中堅生保のシステムはCOBOL:2500万ステップ程度です 大手は1億ステップを超えます 設計の失敗を実装で取り戻すことはよくあります しかし、残念ながらCOBOLシステムを全否定すると仕様がさっぱりわからなくなります ドキュメントはもちろんありませんし、ユーザー、ユーザー側SEの業務理解度も低く、 解析する以外に手がなかったのです >>560,561 マイグレーションの目的はもちろん保守開発、運用コストの削減です UNIX-COBOL、もしくは、Javaにすることには多いに意味があります 貿易保険のシステムの場合は、現行汎用機では完全にキャパオーバーしていて、 上位機種にするか、マイグレーションするかの選択をせまられ、後者を選んだ結果です 564 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 08:57:55 ] >>558 > 漏れだったらCOBOL比較で1/5の人員でクリアできる自信あるけど。 まぁ、俺も幼稚園の頃は世界征服とかできる自信あったしな。 565 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 09:08:07 ] 保険業がいつまで存在する物なのか知らないが、 一億ステップは魅力的だなぁ。宝の山だ。 566 名前：デフォルトの名無しさん [2007/09/22(土) 09:14:30 ] ＞コボラー：解析、仕様書作成、ランフロー作成、データ移管 ＞Javaプログラマ：開発、テスト ＞です ＞コボラーがJavaで開発したわけではありません ＞基本的にコボラーは開発には参加していません えと、それは９割くらいの割合でデスマの原因はコボラーにあると思うけど。 それで「コボラーは開発には参加していません」って・・・。 頭大丈夫？ 567 名前：556,557 [2007/09/22(土) 09:17:05 ] >>558 何か勘違いをしているようなのではっきりと言います ・まず、あなたやあなたの所属する会社が請け負える案件ではありません ・このプロジェクトはユーザ側とベンダーが対立し、破綻しかけました 　その原因はベンダーのPMの期待を裏切るユーザ側の業務理解度の低さと 　当初見積もりの甘さ、Java開発チームのレベル、生産性の低さにあります ・結局、Javaプログラマに関しては、当初予定の2倍以上の人員を投入しています ・業を煮やしたユーザ側はNRIにコンサルティングを数度依頼しています ・日本IBMは3人目のPMに本国のテスリック氏を投入し、現場レベルからたて直し、 　このプロジェクトはやっと収束しました この案件はマイグレーション案件としては超メジャーなもので、 ツール変換するかJavaにするかの判断材料として使われます 568 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 09:18:04 ] >>566 おかしいのは君の頭だ。 開発に参加したのはジャバラーで、 ジャバラーがCOBOLソースを解析しながら やったらデスマになっちまいましたってことだろ。 569 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 09:18:18 ] >>563 >しかし、残念ながらCOBOLシステムを全否定すると仕様がさっぱりわからなくなります >ドキュメントはもちろんありませんし、ユーザー、ユーザー側SEの業務理解度も低く、 >解析する以外に手がなかったのです えと、それはコボラーが悪いって事でFA それJavaじゃんくてC/C++/C#でも同じデスマが待っているし。 つか最初から予定調和じゃん。 それでCOBOL以外はダメポみたいな事言われても「キチガイですか？」って 返答しかできんが。 570 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 09:21:02 ] >>567 つまり、567の会社の人材は開発＆運用＆経営そろって無能って事でFA 571 名前：デフォルトの名無しさん [2007/09/22(土) 09:22:57 ] なんか釣りまマジレスかしらんけどコボラーがこんな程度の考えだから あの現場ではデスマがなくならないんだと思う 572 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 09:37:53 ] だからコボラーがひっちゃかめっちゃかにしたシステムを どうリプレースするかという時に、コボルのソース解析することになったら おしまいだという話でしょ Javaうんぬんじゃなく 573 名前：デフォルトの名無しさん [2007/09/22(土) 09:45:59 ] >>566 完全リニューアルのマイグレーション案件について少しは調べてからにしたら？ 現行ソースの解析は、「要件」を定義する為のもの 要件は「事務基準」＋「解析結果」から作成 これは決めてからは変えてない この案件は別に要件が間違っていて止まったわけではないよ 574 名前：デフォルトの名無しさん [2007/09/22(土) 09:52:56 ] >>570 そうなっちゃうよねw 天下のIBMだけど ユーザーは賠償云々を含めてマジギレだったし （NRIは火消し役） まさか、勘違いしてないと思うけど、 COBOL&JCLからの単純トレスがそっくりそのままJavaになると思ってないよね だいたい機能追加しまくってるのにステップ数減ってるでしょw 575 名前：デフォルトの名無しさん [2007/09/22(土) 09:54:22 ] つかさ、Java使いの人たちはUNIX-COBOLの存在をあまり知らないんじゃない？ 金融業界が汎用機のリプレースで選ぶのは最近はUNIX-COBOLが多いよ。 金融業界で影響力を持つ野村総研がこのパターンを推進しているから。 LinuxやHP-UXというとJavaしかない！みたいな風潮が一時あったせいで誤解されているけど、 最近の金融屋はJavaのマイグレーションが失敗事例続きで懲りているからね。 最近の流行は、Linux＋Oracle＋Pro*COBOLというパターンだね。 OracleがPro*COBOLに力を入れているおかげで、OracleとCOBOLの相性は 抜群だからね。（個人的にはPro*Cなんか比較にならないくらい優れていると思う） COBOLにはMicroFocusやHitachiのコンパイラを採用。 Javaも使っているけど、画面系に特化したところが中心。バックエンドなロジックは Javaには任せない。JDBCは一括大量バッチ処理が苦手だから。 576 名前：デフォルトの名無しさん [2007/09/22(土) 10:00:36 ] 結論を言うと、 コボラー、ジャバラー、どっちも悪い、でFAだ でもこの超有名案件で超がんばったのはジャバラーの方 単純トレスから、要件、外設、内設、〜、実装したのは間違いなくジャバラー 相当やりにくかったと思うよ コボラーは裏でひそかにCOBOL現行ソースに保守開発対応を入れてたんだわ Javaでの完全リニューアルがこけたときの為に もちろんジャバラーには内緒で ごめんね、信用してなかったわけじゃないんだよ 保険のシステムだし、こっちも保険ってことで許してね 577 名前：575 [2007/09/22(土) 10:00:54 ] おっと、ちょっと上のほうに同業者がいたようだ。 ここでいう同業者って、金融や保険のバックエンド開発に携わっている ミッションクリティカルなシステム屋のことね。 このスレでJava最高っていってる人って、フロントエンドばかりやっている 人っぽさそうだからな。 ところで、最近のJDBCは明るくないんだけど、少しは機能改善されているのかな？ 昔のJDBCでは1行ずつしかFETCHできなかったよね。 Pro*COBOLだったた1回のFETCHで500件くらいを一気にホスト変数に格納できて メモリ上で高速に処理できた。この機能は最近のJDBCにはあるのかな？ 578 名前：575 [2007/09/22(土) 10:05:16 ] ×Pro*COBOLだったた 　　　↓ ○Pro*COBOLだったら バックエンドってやっぱりバッチの世界だから、大量データを一気に 処理するバッチ機構がJavaに備われば、けっこう嬉しいんだけどね。 JCP見る限り、そっちの世界に走る気はないようだね。 579 名前：デフォルトの名無しさん [2007/09/22(土) 10:11:35 ] つか、この貿易保険の一件で、MF-COBOLを選択するユーザーが増えた気がする 何せ、変換ツールさえ正しければ、現行システムをそっくりそのまま UNIXに持ってけちゃうから もちろんDBが変わったり、オンラインのプログラムは調整が必要だったりはする けど、リスクが少ない そして何より、コボラーがそのまま使える 喜べコボラー UNIXをおぼえればC系言語がわからなくても仕事はあるぞ COBOLとMF-COBOLはほとんど一緒 （若干命令語が違うが、それは慣れる） お前ら、これからも保守でウマーだw 580 名前：575 [2007/09/22(土) 10:16:28 ] ＞何せ、変換ツールさえ正しければ、現行システムをそっくりそのまま ＞もちろんDBが変わったり、オンラインのプログラムは調整が必要だったりはする ここらへんの単純マイグレーションって最近は中国に丸投げだね。 だからマイグレーションそのものではCOBOLerは食えない。 需要があるとしたら、マイグレーション後の保守工程からだろうね。 581 名前：デフォルトの名無しさん [2007/09/22(土) 10:18:14 ] コボラーだって薄汚いソースを読むのはつらいのに そんなに攻めるなよ ちょっとくらい読み間違えるさ コボラーだもの・・・ 582 名前：デフォルトの名無しさん [2007/09/22(土) 10:24:15 ] >>580 中国人が変換して、ソースを調整してるってことですか？ オープン系の人から中国人のソースでひどい目に遭った話をよく聞くから なんかやだなぁ コンパイルすら通らないソースを納品してくるとか テスト全然してないとか・・・ 保守でウマーだとしても 583 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 10:41:25 ] それは少し前までの話。 日本のソフトハウスに優秀な企業からブラックな企業まであるように、 中国のソフトハウスもピンキリということですよ。 最近は中国の優秀なソフトハウスの選別も済んできていて、 高品質な仕事をするところだけに発注しているよ。 日本のプログラマはこの先、コボラ、ジャバラ問わず ますます数が減るだろうね。 584 名前：デフォルトの名無しさん [2007/09/22(土) 10:47:48 ] 中国人はタグは中国語で書くのですか？ それとも日本語？ 585 名前：デフォルトの名無しさん [2007/09/22(土) 10:53:26 ] ありがとうCOBOL、そしてさようならCOBOL 586 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 10:53:34 ] コボちゃんスレなんか上げるなよ。臭い。 587 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 11:34:24 ] 設計実装を分業したり、コーディングなんてだれでもできると言ったり COBOL世界でしか通用しない戯言を一般化してしまう厚顔無恥さに腹が立つ 588 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 11:40:38 ] 実装できない奴が設計したりするからな 589 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 12:00:36 ] 日常的にCOBOLやってる人って、タイピング早いの？ 自分は遅いから、COBOL初体験の時辛かった・・・ 590 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 12:32:10 ] Java厨、黙っちゃったね 591 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 14:05:35 ] >>577 遅レスになった。すまんの。 JDBC にあるもの ・一度に FETCH する件数の指定 （一気に配列に格納はできない） ・複数の SQL の同時実行 （異なる SQL でも同時実行。INSERT & UPDATE 混在おｋ） COBOL と比べて一長一短だ。 COBOL のグループ項目への一気に格納は便利だが、 COBOL が固定長配列しか扱えない泣き所があるため、 量が可変なデーターに対して最適な閾値を決めるのは難しいと思ってる。 JDBC は FETCH にループを回さなきゃいけないけど、 ライブラリまでは一度に読み込んでくれるのでレスポンスは稼げる。 調査のために COBOL & C と比較したが大差はない。 いや、細かく言うと C < COBOL < JAVA となるが僅差だ。 ボトルネックになる程度の差はないって事。 複数の SQL の同時実行は新規データと更新データが混ざってる時なんか便利だが、 それを意識してプログラムすると値のバインドに名前解決を選択することになる。 添え字解決より若干速度が遅く、これを数百のカラム数×数万件の単位でやると、 それなりにレスポンスに響いてくる。 （既存システムのテーブルを捨てられるならここまで酷くはならないが、 　そうも行かない事も多いよな？） COBOL と JAVA の処理速度ってーのは実は大差ない。 もちろん、どちらも適切にプログラムを書き、 DB もそれぞれに最適化した場合だがな。 592 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 14:14:16 ] 一気に配列に格納はできないことが短所とは思えないけどなあ 配列やArrayListにぶちこもうと思えば造作も無い 593 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 15:31:43 ] COBOLerの欠点は、RDBを生かした設計が出来ない事だろう。 594 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 15:37:31 ] 終わってんだろ、それｗ 595 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 16:42:21 ] 汎用モジュールのパラメータのグループ変数領域を初期化する。 階層型DB1親セグのデータの受け皿のグループ変数領域を初期化する。 階層型DB1子セグのデータの受け皿のグループ変数領域を初期化する。 階層型DB2親セグのデータの受け皿のグループ変数領域を初期化する。 階層型DB2子セグのデータの受け皿のグループ変数領域を初期化する。 階層型DB3親セグのデータの受け皿のグループ変数領域を初期化する。 階層型DB3子セグのデータの受け皿のグループ変数領域を初期化する。 汎用モジュールのパラメータを初期化する。 入力ファイルを読み込む。 入力ファイルがEOFだったとき、読み取れなかったときの例外処理を書く。 汎用モジュールのパラメータに、階層型DB1を表すリテラルをセットする。 汎用モジュールのパラメータに、キーとして入力ファイルのレコードにあるコード1をセットする。 汎用モジュールのパラメータに「ダイレクトリード」を表すマジックナンバーをセットする。 汎用モジュールのパラメータに、親セグを表すリテラルをセットする。 汎用モジュールをCALLする。 汎用モジュールのパラメータから戻り値にあたるグループ変数を階層型DB1親セグのデータの受け皿のグループ変数領域に格納する。 階層型DB1親セグのデータの受け皿のグループ変数領域にあるコード2を取得し、汎用モジュールのパラメータにキーとしてセットする。 汎用モジュールのパラメータに「ダイレクトリード」を表すマジックナンバーをセットする。 汎用モジュールのパラメータに、子セグを表すリテラルをセットする。 汎用モジュールをCALLする。 汎用モジュールのパラメータに、階層型DB2を表すリテラルをセットする。 汎用モジュールのパラメータに、キーとしてコード1をセットする。 汎用モジュールのパラメータに「ダイレクトリード」を表すマジックナンバーをセットする。 汎用モジュールのパラメータに、親セグを表すリテラルをセットする。 汎用モジュールをCALLする。 汎用モジュールのパラメータから戻り値にあたるグループ変数を階層型DB2親セグのデータの受け皿のグループ変数領域に格納する。 596 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 16:43:45 ] 階層型DB2親セグのデータの受け皿のグループ変数領域にあるコード3を取得し、汎用モジュールのパラメータにセットする。 汎用モジュールのパラメータに「ダイレクトリード」を表すマジックナンバーをセットする。 汎用モジュールのパラメータに、子セグを表すリテラルをセットする。 汎用モジュールをCALLする。 汎用モジュールのパラメータから戻り値にあたるグループ変数を階層型DB2子セグのデータの受け皿のグループ変数領域に格納する。 汎用モジュールのパラメータに、階層型DB3を表すリテラルをセットする。 汎用モジュールのパラメータに、キーとしてコード1をセットする。 汎用モジュールのパラメータに「ダイレクトリード」を表すマジックナンバーをセットする。 汎用モジュールのパラメータに、親セグを表すリテラルをセットする。 汎用モジュールをCALLする。 汎用モジュールのパラメータから戻り値にあたるグループ変数を階層型DB3親セグのデータの受け皿のグループ変数領域に格納する。 以下をＸ回繰り返す。 　汎用モジュールのパラメータに、階層型DB3を表すリテラルをセットする。 　階層型DB3親セグのデータの受け皿のグループ変数領域にあるコード4を取得し、汎用モジュールのパラメータにセットする。 　汎用モジュールのパラメータに「シーケンシャルリード」を表すマジックナンバーをセットする。 　汎用モジュールのパラメータに、子セグを表すリテラルをセットする。 　汎用モジュールをCALLする。 　汎用モジュールのパラメータから戻り値にあたるグループ変数を階層型DB3子セグのデータの受け皿のグループ変数領域に格納する。 　階層型DB3子セグのデータの受け皿のグループ変数領域にあるコード5と階層型DB1子セグのデータの受け皿のグループ変数領域にあるコード5、 　および階層型DB3子セグのデータの受け皿のグループ変数領域にあるコード6と階層型DB2子セグのデータの受け皿のグループ変数領域にあるコード6が同じなら、 　階層型DB3子セグのデータの受け皿のグループ変数領域にあるコード7を出力ファイルに書き込む。 597 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 16:47:20 ] ↓ select コード7 from　 DB1-1, DB1-2, DB2-1, DB2-2, DB3-1, DB3-2 where　DB1-1.コード1 = 引数 　 and DB2-1.コード1 = 引数 　 and DB1-2.コード2 = DB1-1.コード2 　 and DB2-2.コード3 = DB2-1.コード3 　 and DB3-2.コード4 = DB3-1.コード4 　 and DB3-2.コード5 = DB1-4.コード5 　 and DB3-2.コード6 = DB1-4.コード6 598 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 17:30:06 ] ProCOBOLしかやったことないコボラ−な俺 上のやつが階層型DBってやつかい？ 599 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 18:46:59 ] 階層型DBってわかりやすいんだよなあ。 テーブルの親子関係が、文字通り家系図みたいに 上から下へと定義されてるからね。設計がサクサク進む。 DBアクセスおよび取り出したデータの処理をいちいち プログラムでしてやらなきゃならんけど、わかりやすく 保守しやすい。 RDBは階層という概念がないため、テーブル数が増えると 設計者の脳内スタックに負担をかけ、開発・保守が非常に 困難となってくる。 600 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 19:39:25 ] はあ、保守が困難っすか…… どう見てもRDBの方が扱いやすそうなんですが。 "One fact One place"の原則って知ってる？ データに更新かけたいとき、方々のDBに好き勝手なフォーマットで記録されてるそいつらの整合性を保つのにどれだけの手間がいるだろうね。 固定長のレコードで記録されてるから、桁数や項目の拡張もやりにくくて、 「個人情報データは20桁目〜305桁目と1050桁目〜1054桁目と1080桁目〜1100桁目、 　所属組織データは306桁目〜500桁目と1055桁目〜1068桁目」みたいな構成がしょっちゅうでてきたり、 ひどいのになると、5桁のデータを記録するとき、上3桁と下2桁が別の領域に記録されてたり。 構造体がちゃんと作られてない場合、レコードのレイアウトを見ながら直接桁数を切ってデータやりとりしたり。 601 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 19:48:43 ] 道具の使い方が簡単だからといって、複雑な作業が簡単になるはずはないわな コボラはよくフラグを使うが、開発回次を重ねるごとにフラグの管理が異常に困難になっていく 602 名前：デフォルトの名無しさん [2007/09/22(土) 20:26:52 ] Java使いの無意味なクラス分割とかモナー そういえばJ2EEのデザパタとか酷いよな 昔からある構造化の考え方をSession Facadeだの何だの さも新しい概念であるかのように喧伝して ただの構造体をValue Objectとか言ってるのは笑えたよ EJBも結局Stateless Session Beanしか使い物にならずに廃れたし 結局DOAなんてイキがってたのが、実装には到底使えない 机上の空論だと分かって、やがて構造化設計に戻っていったのに、 それを認めたくないからってデザパタなんて言葉でごまかしてな 603 名前：デフォルトの名無しさん [2007/09/22(土) 21:06:29 ] >>602 デザインパターンの意味を知って発言してるとは 到底思えないんだけど。 これも釣りなの？ 604 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 21:09:15 ] 都合が悪いとすぐ釣りとしか書かない人物 ずっとこのスレに常駐ｗｗ 605 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 21:10:49 ] デザインパターンって、所謂GoFのでしょ？ オブジェクト指向に特化した考え方の中に、むりやり構造化の概念を 詰め込んでいるのが滑稽だという意味じゃないの？ 606 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 21:40:28 ] COBOLer（失笑）…… Java 叩きはまだしも、 OO 叩きはじめると底の浅さが露見するから迂闊な事はやめとこうぜ。 データ主体に考える事ができない時点で、 OO のオの字も理解してないってバレバレになるからさ。 607 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 21:43:33 ] オブジェクト指向は構造化なんかとっくの昔に包含してますから 608 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 21:44:44 ] 無理やり構造化のって意味不明もいいとこ Javaのメソッドは手続きじゃん 構造化設計のノウハウは全てそのまま使えるだろ 609 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 21:58:23 ] >>603=>>606wwww 具体的に反論できないバカ データ主体に考えて成功した大規模プロジェクトを挙げてみな >>607=>>608 その割りには構造化をバカにするのが典型的なJava厨の特徴ﾌﾟｷﾞｬｰ あと時間はもっとずらしてレスしようぜ どうせ1人の自演なんだろうがな 610 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 21:59:30 ] >>602 そもそもデザインパターンてのは 使い古された設計の手法を パターン化して共通言語にしましょうていうのが 狙いだから「こんなの今までも使ってたよ」て 馬鹿にすること事態が間違ってる。 大体Javaに特化した話でもなんでもないし。 OO指向のパターンでなければ Cで組んでもそれこそCOBOLで組んでも 間違いではない。 611 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 22:01:35 ] OOのことは全然分からないコボラ−ですが、 データ指向（DOA）の失敗の果てにサービス指向（SOA）が 生み出されたと聞いたことあるのですが。（Javaな人に） 612 名前：デフォルトの名無しさん [2007/09/22(土) 22:02:44 ] > OO指向のパターンでなければ うわ！全然分かってないじゃん！！ 613 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 22:04:24 ] 構造化をバカにする？ どのレスのことよ 614 名前：デフォルトの名無しさん [2007/09/22(土) 22:04:39 ] はっきりと言えることは、 現在コボラーの人は10年後もコボラーの可能性が高い 現在Java房の人は10年後異業種に転職しているか、死んでいる可能性が高い 615 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 22:05:32 ] えー？普通デザパタってOOに対して使う言葉でしょ？ めちゃめちゃ広義に捉えた場合は知らんが、普通デザパタといえばOO。 wikiにもGoFの考え方が書いてあるじゃん。 [Design patterns] solve specific design problems and make object-oriented designs more flexiblem elegant, and ultimately reusable. They help designers reuse successful designs by basing new designs on prior experience. A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them. 616 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 22:07:39 ] デザパタ論議はオブスレでどうぞ いくらなんでもここでやるのはどうかと思うぞｗ 617 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 22:07:53 ] プログラマのレベルって、どの言語を使っているか、じゃなくて どんなシステム開発を行ってきたかだと思うんだけど。 金融歴20年のコボラ−と、Webアプリ5年のジャバラだったら どっちを採用すると思う？ 618 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 22:10:04 ] >>617 どう考えてもJavaのほうだろ。アホか 5年のコボラと20年のジャバラだと、まだちょっと悩むがな 619 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 22:10:51 ] そもそもバッチ処理中心のCOBOLと Webアプリ中心のJava自体、生息地帯が違いすぎるだろ 不毛な議論 620 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 22:11:46 ] >>618 ひぇぇぇぇ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef