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

1 名前：デフォルトの名無しさん [2006/05/01(月) 18:32:38 ] いるだろ？語ろうぜ 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 ひぇぇぇぇ 621 名前：デフォルトの名無しさん [2007/09/22(土) 22:21:18 ] 金融歴20年のコボラ−はもう派遣か請負しかないよ まともな会社に社員採用はまずない 622 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 22:28:48 ] 普通に銀行のシステム子会社を渡り歩けばいい。 銀行のシステム開発は人手がいくらあっても足りない。 あまりにデータ量が多い＆ミッションクリティカルなため、 メインフレーム＋コボルでしか運用できないのだ。 623 名前：デフォルトの名無しさん [2007/09/22(土) 22:35:29 ] >>622 ああ、その手があった 生保、損保の子会社もあるね データ量＝契約件数＊1.4倍くらいあるから、マジで半端ないw 正直外資系、年俸制とかはヤバそうだけど、やってる人いる？ 求人内容には18:30には帰宅しています、なんて載ってるけど、どう考えても 嘘だよな 派遣：2次受けの会社（客先常駐）も含む 624 名前：デフォルトの名無しさん [2007/09/22(土) 22:38:26 ] 保険や金融はねえ、最低でも100人月以上の仕事だから 人手はとにかく足りないんだよねえ 625 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 22:38:59 ] いまだにATMが24時間動いてないのは コボラーが夜間にシステムとめて変な処理してるからだろ いい加減目を覚ませよ お前らのやってることは間違いだらけだ 626 名前：デフォルトの名無しさん [2007/09/22(土) 22:39:18 ] 俺派遣コボラー（直近は一般派遣）だけど、 元請のユー子とかに入れたりするのかな 現在30歳だけど・・・ もうムリかな・・・ 627 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 22:44:52 ] >>625 通信系のバックも汎用機なんですが。。。 628 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 22:59:55 ] >>625 金融系のシステムでやってるのが オンライン処理だけだとでもおもってるの？ そもそもバッチ処理を動かすことと オンラインシステムを止めることは関係ないし 最初の設計段階で24時間稼動まで考えて なかったんだからそう動いてないシステムが まだ存在するのは当たり前で 言語の問題ではない。 基幹系のシステムをちゃんと勉強してね JAVAでやるにしたって必要な知識でしょ 629 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 23:01:26 ] Javaが基幹系をやるケース自体レアだと思うけどなあ 一時期はそういう風潮もあったけど 今ではIBMも含めてどのSIもそんな提案してないでしょ 失敗して責任とらされるの怖いもんね 630 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 23:10:09 ] >>626 力量にもよるだろうけど 団塊が一気に抜けることを考えると 今一番必要な世代ってな気もする 逆に言えば移るなら今かもね 色々いってるけど 俺らが現役の間は絶対にCOBOLは 無くならないよ、つか無くせない 631 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 23:20:45 ] いや、そりゃ無くならないとは思うよ(無くなって欲しいけどｗ) でもそれって、コボラは概して不勉強であり、周りに害を与える存在であるって事実と なんら関わりないことだよね？ 632 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 23:26:01 ] まあ絶滅はしないにせよ現代言語に置き換えられていく流れは変わりようがない 633 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 23:27:46 ] そういえば以前いた現場では、バッチ処理が昼間動いてたよ。 何時間か置きにデータをDBに格納するの。COBOL関係ないけどね。 そういう状況下では別に夜間止める必要ないな。 俺のやった仕事で言えば、メインフレームからOracleへのリプレースで COBOLで書いていた夜間の集計処理をPL/SQLに置き換えるってのはあった。 一方でWebシステムのサーバーサイドにCOBOL使ったりしてるところもある。 F社の何とかステージとやらで...製品知識無いんであまり説明できないけど。 結局音頭取ってる人間次第で使う言語や構成が変わるんだろうね。 634 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 23:36:27 ] > でもそれって、コボラは概して不勉強であり、周りに害を与える存在であるって事実と > なんら関わりないことだよね？ ソースは？ 635 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 23:46:29 ] ソースねぇ・・・ Java使いが叩かれるのも、コボラが叩かれるのも そこには幾許かの真実があるからだと思うけど まず、あんたはどう思ってんのよ 636 名前：デフォルトの名無しさん [2007/09/23(日) 00:00:49 ] IBMがシステムマイグレーションで完全Javaリニューアルを提案するとは思えないw もう懲りたべ 637 名前：デフォルトの名無しさん [2007/09/23(日) 00:06:23 ] 話をすりかえるなよ。 ソース出せよソース。 638 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 00:08:14 ] 脳内ソースだろｗｗ 真実だってよ　笑っちまうｗｗ 「思う」なんていわずにソースだして断言してみろよ 639 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 00:35:38 ] ソース出せとか、いつの時代の煽りだよｗ 何にでも乗り遅れるのがコボラか？ｗｗ 640 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 00:50:43 ] ソースが出せない電波厨房の負け惜しみ劇場が始まりましたｗｗｗｗｗ 641 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 01:03:43 ] 悲惨だな 642 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 01:17:08 ] 今頃必死でネット上でソースをかき集めようとしている 涙目の>>639の姿が目に浮かぶ 643 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 01:19:52 ] アホなコボラーの例をいくつあげればいいんだ？ 644 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 01:40:19 ] いいから早くソースを出せ。話はそれからだ。 645 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 01:42:21 ] ソースと思ってあげても君らがソースと思わなかったら意味がないからな 何をあげればソースと認めるのか、そこをまず聞こうか 646 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 01:49:53 ] ﾌﾟｯ 647 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 01:50:46 ] コボラー相手に論理的な話し合いなど不可能ということかな 648 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 02:01:46 ] もうどう考えたって敗北してんだから　大人しくいなくなればいいのに これ以上負け惜しみを重ねることもあるまい　惨めな気持ちになる 649 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 02:04:42 ] だーかーらー 「コボラは概して不勉強であり、周りに害を与える存在である」 と類似する文書を書いてあるソースを出せっつーの それができねーならとっとと尻尾を巻いて消えろよ、この四つ足が 650 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 02:05:53 ] 試しに「コボラ 不勉強」でぐぐったら、出てきたのほとんど2chだったぞ藁 651 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 02:06:01 ] コボラ進退窮まって自演かよ ひでぇなこりゃｗ 652 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 02:21:47 ] 村上龍は13歳のハローワークで コボラは無能であり日本から消えていく存在だと言っていたな

---

---

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

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