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

1 名前：デフォルトの名無しさん [2006/05/01(月) 18:32:38 ] いるだろ？語ろうぜ 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歳のハローワークで コボラは無能であり日本から消えていく存在だと言っていたな 653 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 02:38:36 ] ●●は○○だからダメっていうレッテル貼りに終始してる奴って 自分の無能さから目を背けてるだけだったりするんだよね。 654 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 02:59:11 ] ｺﾎﾞﾗは馬鹿だけど ｺﾎﾞﾗ叩きはそれに輪を掛けて馬鹿だったって事か 655 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 10:33:50 ] 亀レスだけど ＞最近の流行は、Linux＋Oracle＋Pro*COBOLというパターンだね。 某金融系の某○立が似た事やってんだけど、 こっちとしてはデータが出来れば文句ないが、 Oracleのテーブルに主キーなし、インデックスなし、全カラムnull可で ユーザー側でそのデータで分析やろうとしても３０分〜３時間くらい 結果が返ってこないワケだが・・・。 もう少し某日○はRDBの事を勉強してください。おながいします。 ぶっちゃけ漏れがSQL+JDBCアプリ組んだ方が１００倍速いです。 656 名前：デフォルトの名無しさん [2007/09/23(日) 10:38:03 ] >>655 つうかＥｘｃｅｌＶＢＡでフロント組んでも勝てるじゃね 657 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 10:45:18 ] それは日立が無能なのであって言語とは関係ない DB設計をプログラマがやるような超小規模な案件なら話は別だがな 658 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 10:45:45 ] >>656 いや、それはAccess+VBAがフロントエンドのシステムでつ。 そのOracleと連携してアレコレしているそうですけど、 根本的に実効速度を無視している感ありで、 ユーザーが「遅いよー」とゴネでも「データ量が多いのでそれくらい時間かかります」 とかヌカしやがった。ｗ さすが年金問題な某日○だな、と思いました。 漏れがIBMの鯖で試しにテーブル移植しサンプルをJava+SQLで作ったら たら100倍近く早くなったけどサ。 659 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 10:51:43 ] >>657 主に日立が無能なのは同意だけど、ユーザーの要望に合わせて 言語を選択するのは、規模関係ないと思うけど。 COBOLでもデータ分析に適したリレーショナルなＤＢシステム作れると思うけど、 やっぱCOBOLerが設計すると横長DBになりがちではあるよ。 純(?)なSQL上がりな人間からするとSQL発行できれば、CでもJavaでもVBAでも 言語はどれでもよかったりするけど、COBOLerとExcel信者は 横長志向だとｵﾓ。 660 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 10:54:03 ] 主キーがないってすげえな 661 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 11:26:51 ] ＞普通に銀行のシステム子会社を渡り歩けばいい。 ＞銀行のシステム開発は人手がいくらあっても足りない。 この間、システム共同化とかいって地銀のシステム子会社の エンジニアは軒並み仕事がなくなったワケだが。 地銀系はこの流れになっていくとｵﾓ。 なんか都銀のパッケージを不思議に啓蒙している不思議な経営陣だから。 漏れの知るところの都銀のシステム子会社(某○菱系)だと仕事はあるにはあるけど、 孫会社や下請けに丸投げの中間マージン搾取会社となっているフシがあるから、 あんまし銀行系の開発ってお勧めしない。特に某○菱は死ぬほど金払いが悪い。 他の都銀は金払いいいのか知らんけど。似たようなモノだとｵﾓ。 662 名前：デフォルトの名無しさん mailto:sage [2007/09/23(日) 11:32:25 ] なんで中間搾取会社なんてのが存在できるんだろうな 合理化という言葉はどこに消えてしまったんだろう 663 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 00:09:09 ] コボラにDB設計やらせると主キーなしのテーブルができるって、、、 それってどこかに元ネタがあってそれが広まった都市伝説じゃないの？ ファイルにソートキーつけまくってブレイク処理しまくる処理に慣れている コボラが、キーの概念を知らないというのは考え難いんだけど。 664 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 00:15:27 ] 俺の今いる職場、COBOLつかってないし、元々の設計者がCOBOLerかどうかも分からんけど、 トランザクションに主キーが無い。 665 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 00:42:49 ] 別に主キーなんてなくてもいいじゃん。 COBOLの世界じゃ、レコードの格納順番が そのままキーということが非常に多い。 666 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 01:00:59 ] ＞トランザクションに主キーが無い。 ごめん意味不明 667 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 05:44:14 ] >>663 都市伝説もなにも実在する以上の証明はないワケですが。 変に汎用機慣れしているとユーザーサイドの使い勝手と言うか、 COBOLの「全件読んでからブレイク集計」と一般的SQLの「情報を 集合で扱う」概念が身にしみてないだけだろう。 668 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 08:54:16 ] > 実在する以上の証明はない お前の周りだけだろ つかお前>>631だろ？？根拠のない断言大杉 貴様のことを「思い込み厨」と命名するｗｗ 669 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 09:05:16 ] ここでCOBOL叩いている人って、実際のCOBOLの知識なさそう。 ネットの記事や２ｃｈだけ読んで思い込んでいるというか。。。 家にこもってないで外に出ろ！現実を見ろ！ 670 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 12:40:25 ] >>666 後ろに「データ／ファイル／テーブル」などと付けなきゃ分からんか？ 要するに取引データみたいな物のことだが、、 一つの取引を特定できないって状況なんだよ。 671 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 12:54:26 ] ここでCOBOLer叩きしてるヤツが馬鹿だという事がよく分かった コボラを叩きたいんなら、他スレでやってくれ 672 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 13:17:34 ] >>670 やっぱり、意味不明。 673 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 14:29:42 ] コボラ叩きの言ってることの方が説得力があるぞ コボラ叩きを叩いてる連中の発言には中身が何も無い 674 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 16:33:18 ] >>673 それ、冗談で言ってるんだよな？(笑) コボラ叩きはレッテル貼りしかしてないじゃないか。 675 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 16:55:09 ] 仕様の枯れてない言語は嫌なんだよなあ。 Javaはすぐに次のバージョンが出てしまう。 俺なんか1.2の参考書の勉強がまだ終わってないぜ。 676 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 20:40:56 ] 今までオープン系を10年近く経験してきたが、 「トランザクションに主キーが無い」はおろか という表現はいまだかつて聞いたことないな。 677 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 22:25:24 ] ＞コボラ叩きはレッテル貼りしかしてないじゃないか。 主キーがないやら、インデックス知らないとか具体例満載で 説明されているのに「レッテル貼り」とは日本語読めない人か？ つかコボラーは釣りかマジレスか解らん池沼が多いな。

---

---

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

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