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 混在おk) 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 ] 終わってんだろ、それw
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親セグのデータの受け皿のグループ変数領域に格納する。 以下をX回繰り返す。 汎用モジュールのパラメータに、階層型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 ] 都合が悪いとすぐ釣りとしか書かない人物 ずっとこのスレに常駐ww
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 =>>606 wwww 具体的に反論できないバカ データ主体に考えて成功した大規模プロジェクトを挙げてみな >>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 ] デザパタ論議はオブスレでどうぞ いくらなんでもここでやるのはどうかと思うぞw
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 ] いや、そりゃ無くならないとは思うよ(無くなって欲しいけどw) でもそれって、コボラは概して不勉強であり、周りに害を与える存在であるって事実と なんら関わりないことだよね?
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 ] 脳内ソースだろww 真実だってよ 笑っちまうww 「思う」なんていわずにソースだして断言してみろよ
639 名前:デフォルトの名無しさん mailto:sage [2007/09/23(日) 00:35:38 ] ソース出せとか、いつの時代の煽りだよw 何にでも乗り遅れるのがコボラか?ww
640 名前:デフォルトの名無しさん mailto:sage [2007/09/23(日) 00:50:43 ] ソースが出せない電波厨房の負け惜しみ劇場が始まりましたwwwww
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 ] コボラ進退窮まって自演かよ ひでぇなこりゃw
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可で ユーザー側でそのデータで分析やろうとしても30分〜3時間くらい 結果が返ってこないワケだが・・・。 もう少し某日○はRDBの事を勉強してください。おながいします。 ぶっちゃけ漏れがSQL+JDBCアプリ組んだ方が100倍速いです。
656 名前:デフォルトの名無しさん [2007/09/23(日) 10:38:03 ] >>655 つうかExcelVBAでフロント組んでも勝てるじゃね
657 名前:デフォルトの名無しさん mailto:sage [2007/09/23(日) 10:45:18 ] それは日立が無能なのであって言語とは関係ない DB設計をプログラマがやるような超小規模な案件なら話は別だがな
658 名前:デフォルトの名無しさん mailto:sage [2007/09/23(日) 10:45:45 ] >>656 いや、それはAccess+VBAがフロントエンドのシステムでつ。 そのOracleと連携してアレコレしているそうですけど、 根本的に実効速度を無視している感ありで、 ユーザーが「遅いよー」とゴネでも「データ量が多いのでそれくらい時間かかります」 とかヌカしやがった。w さすが年金問題な某日○だな、と思いました。 漏れがIBMの鯖で試しにテーブル移植しサンプルをJava+SQLで作ったら たら100倍近く早くなったけどサ。
659 名前:デフォルトの名無しさん mailto:sage [2007/09/23(日) 10:51:43 ] >>657 主に日立が無能なのは同意だけど、ユーザーの要望に合わせて 言語を選択するのは、規模関係ないと思うけど。 COBOLでもデータ分析に適したリレーショナルなDBシステム作れると思うけど、 やっぱ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 だろ??根拠のない断言大杉 貴様のことを「思い込み厨」と命名するww
669 名前:デフォルトの名無しさん mailto:sage [2007/09/24(月) 09:05:16 ] ここでCOBOL叩いている人って、実際のCOBOLの知識なさそう。 ネットの記事や2chだけ読んで思い込んでいるというか。。。 家にこもってないで外に出ろ!現実を見ろ!
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 ] >コボラ叩きはレッテル貼りしかしてないじゃないか。 主キーがないやら、インデックス知らないとか具体例満載で 説明されているのに「レッテル貼り」とは日本語読めない人か? つかコボラーは釣りかマジレスか解らん池沼が多いな。
678 名前:デフォルトの名無しさん mailto:sage [2007/09/24(月) 22:51:50 ] >主キーがないやら、インデックス知らないとか具体例満載で いやだから、そんな人いないから・・・てこのスレで書いてるのに。 なんでCOBOL=DB知識がないって思い込んでるんだろう、この人。 COBOLだって普通にOracleバリバリ使うのに。 それで、「トランザクションに主キーが無い」って何?
679 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 00:09:27 ] >>664 =>>670 ≠>>677 ですが、 「トランザクションに主キーが無い」はおろか という表現は、おれも>>676 ではじめてみましたよっw トランザクションテーブルに主キーが設定されてない実例はあるよって言ってるだけなんだが。。。。 おまけにCOBOLerとの関連は不明としているでしょ。ちなみに俺自身経験の半分はCOBOLだし。 俺は10年も経験ないけど、主キーの無いテーブルを見たのは初めてだったのは確か。 逆に主キーが無いテーブルってのは結構多いの?
680 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 00:21:36 ] 各レコードに5明細ずつとかわけわからん設計してるくせに 「主キーくらい知ってるわ!」と言って熱くなるコボラw
681 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 00:38:46 ] それはコボルとかコボラは関係なく 設計が馬鹿なだけで・・・
682 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 00:59:34 ] いい加減敗北を認めて去ればいいのにねぇ・・・
683 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 01:08:05 ] >>681 横長テーブルはCOBOLの言語仕様と関係ないとは言えないのでは?
684 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 01:11:20 ] なんでやねん
685 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 01:41:19 ] 敗北も何も・・・ コボラやコボルと関係ないことで叩かれてもねぇ
686 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 01:49:08 ] 金融商品のマスタテーブルや、株式・債券の約定取引テーブルなんていったら カラム数100個なんて簡単に突破する横長テーブルになると思うのだが・・・。 あと、パフォーマンスを重視した正規化崩しとして、テーブルのカラムに 項目1、項目2・・・と繰り返しを定義するのは、必ずしも間違いではない。 数テラバイトのデータを扱うDWHでは一般的な手法。スタースキーマあるいは スノーフレークスキーマの形を美しく整えるほうが大切。
687 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 02:06:30 ] DWHか、懐かしい。 購買テーブルのレイアウトに、商品コード、商品名漢字、商品名略称、商品名カナ、 商品単価、商品製造日付・・・なんて項目がずらっと並んでいるんだよね。 商品属性をマスタに出して従属させちゃいけないんだよね。
688 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 02:28:46 ] >>679 トランザクションでなくて、 取引明細テーブルに主キーがないと 言ってくれれば誰でもわかる。
689 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 02:37:26 ] たぶん彼はもう話の流れについていけなくなって 逃走間際だと思うよ
690 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 03:46:29 ] もう一つ考えられるのは、従来の トランザクションファイル(マスターファイルに対する更新要求列)を テンポラリなテーブルとして、DBに持つケース。データ管理の一元化 などで起こりうる。上の方で日立を馬鹿にした書き込みが続いていたが これなのではないか。 せっかくテーブルに仕立てたのだから、主キーくらいは設定して、 更新に行く前にチェックもしようよの意味で使ったのだろう。
691 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 06:41:08 ] >>主キーがないやら、インデックス知らないとか具体例満載で >いやだから、そんな人いないから・・・てこのスレで書いてるのに。 ナニ半島の人みたいなレスするんだか。w オマエみたいな池沼は現実に存在する。 つかOracle社の中の人が見たら笑う様なレスすんなよ。
692 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 09:47:13 ] うわあ・・・具体的な反論ができなくなっちゃってるう(笑)
693 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 10:20:59 ] 負け惜しみって惨めだねぇ
694 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 12:26:30 ] ・特定条件下で横長テーブルが妥当であることと、あらゆる条件下で横長テーブルが妥当であることとは違う ・DB詳しいコボラが存在することと、全てのコボラがDBに詳しいこととは違う よってコボラの反論はすべて詭弁以下
695 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 12:39:40 ] 会社が昼休みになったのかww >DB詳しいコボラが存在することと、全てのコボラがDBに詳しいこととは違う これってそっくりそのまま >DB詳しい蛇腹が存在することと、全ての蛇腹がDBに詳しいこととは違う にあてはまるね ほとんどの蛇腹は、create table文さえ知らないアフォな兵隊だからねww
696 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 12:44:06 ] >>695 >DB詳しい蛇腹が存在することと、全ての蛇腹がDBに詳しいこととは違う あたりまえでしょ。何を得意になってるのやら だけど、横長テーブルやフェッチを好む蛇腹は居ないんだよ 何のメリットもないから
697 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 13:06:23 ] アイタタタタタ >横長テーブル 君の職場がしょぼいテーブルしか使わない程度の案件しかやってないんでしょう >フェッチを好む フェッチの意味よく分かってないんじゃないの?
698 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 13:08:00 ] このアンチ君、2年目くらいのスキルしかないんじゃないの? 開発経験本当にあるの?単なるプログラムオタクレベルっぽい。 もしかして愛読書はWebDB Pressかい?(爆笑)
699 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 13:12:13 ] 頭痛くなってきた・・ ・特定条件下で横長テーブルが妥当であることと、あらゆる条件下で横長テーブルが妥当であることとは違う 「「「不適当な条件下で」横長テーブルを好む」蛇腹はいない」 な? バカなの? 何が「君の職場が・・」wなの? バカ? よーく考えてよ。 無理?
700 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 13:14:51 ] ひっこみがつかなくなってきたな
701 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 13:15:39 ] あ、あとさ >だけど、横長テーブルやフェッチを好む蛇腹は居ないんだよ これのソースは?
702 名前:デフォルトの名無しさん [2007/09/25(火) 13:16:11 ] うちの部下のJava使い、キーのないテーブル設計して俺に持ってきたよ。
703 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 13:17:07 ] おまいら、新人をあまりイジめるなよ
704 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 13:18:04 ] だっていじくり甲斐があるんだもんw 今の職場じゃ、無能な部下をいじめるなんてしたら問題になっちゃうからねww
705 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 13:19:39 ] あれ、順番まちがえちゃった? 俺の職場がしょぼいテーブルしか使わない程度の案件しかやってないソースと フェッチの意味よく分かってないソース はやくだせやボケ
706 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 13:23:25 ] 客観的に見てコボラは逃げに終始 説得力ゼロだな
707 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 13:26:31 ] >>702-704 なんですぐ涙目なんだよ 泣くほど悔しいんだったら、はじめから勉強しろバカ
708 名前:デフォルトの名無しさん [2007/09/25(火) 13:29:18 ] フェッチが有効なときもあるが、複雑なUpdate文を組み立てられなくてフェッチを使っているケースがよくあるね そしてフラグとIF文満載なストアードプロシージャ、どうやってメンテすればいいんだよ
709 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 13:34:55 ] ソースソースってうぜえょ >ほとんどの蛇腹は、create table文さえ知らないアフォな兵隊だからねww ほれ、ソース出してみろ それか二度とソースでごまかそうとスルナヨ糞低脳が
710 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 18:00:12 ] では、まず君のソースを見せてもらおうか? 君が最初にケンカ売ったんだかんね。 自分のソースが出せないからって転嫁するなよ。
711 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 18:05:52 ] たった1人で孤立無援の戦いを続けるMr.トランザクションに武運のあらんことを・・・ >>664 >>667 >>670 >>674 >>677 >>679 >>680 >>683
712 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 18:06:23 ] >>685 >>691 >>694 >>696 >>699 >>705 >>706 >>707 >>709
713 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 19:11:43 ] >>711-712 流石はコボラ センスは古いし、仕事はいい加減
714 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 19:44:37 ] Java使うヤツは出来るのとか出来ないのとか当たり外れが激しいとは 思うけど、COBOLerは正直、現代においては外ればっかだと思うが。 特にこのスレのコボラのマジレス(w)をみてるとな・・・。 #釣りにしても酷いが・・・
715 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 20:17:48 ] >>711-712 それは間違い。 >>664 は、 マスタ系/トランザクション系に分類したときにトランザクション系って意味でトランザクションと書いた。 マスタ系には主キーが付いているので。 >>670 は、 はじめは>>666 がトランザクション↓ここらへんの意味でとらえていると思って書いた。 www.sophia-it.com/category/transaction.jsp >>679 は、 若干カチンときてるが、俺はCOBOLer叩きでも、蛇腹でもない。(COBOLerのつもりでもないけど) すでにアンタらほど経験もありませんよって認めている。 あとのレスは俺じゃない。 それから横長に付いては、「パフォーマンスのために...」てあたりは一応知識としては知っている。 だから必ずしも否定的ではない。 >>697 これはアドバイスとして受け取っておく。 ありがとう。 俺が書きながら思い出していたテーブルは、明細は横に持っていて、横が足りないと縦を追加している。 店番号(i) 日時(i) 明細1 明細2 明細3 その他の項目 ...こんな感じ(iはインデックス) で実際に担当者がこのレコードを探し出すときに、明細の金額まで見てやっと判断してる。 だからもう少し確実なキーが要るんじゃないかと思う。
716 名前:715 mailto:sage [2007/09/25(火) 20:22:44 ] 間違えた。 >>697 -> >>688
717 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 20:29:29 ] 客観的に見て、論理性・人間性ともにアンチの方が上だな
718 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 21:49:26 ] IDが出ないから自作自演し放題だな そろそろCOBOLの質問したいんだけど、、、
719 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 22:09:47 ] >IDが出ないから自作自演し放題だな 確かにCOBOLerの自作自演がかなり酷いな・・・
720 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 22:33:21 ] いや、君のほうが必ry
721 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 22:40:04 ] なにがなんでもアンチの自作自演にしないと気が済まないのか・・・。 どーでもいいじゃん。現実のコボラーが改心するワケでもなし。
722 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 22:58:14 ] そうだな。無能な君がJavaから卒業できるわけでもないし。 Java使いなんてCOBOLer以下の最下層デジドカだという現実に目を向けなよ。
723 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 23:01:41 ] とにかく大文字だ大文字。 大文字で書けるJavaならば勉強する気になれる。 誰か作ってくれ。改造は意外と簡単なような気がする。
724 名前:デフォルトの名無しさん mailto:sage [2007/09/25(火) 23:39:43 ] COBOL勉強中。 思ったより流れが速いだけでなんだか嬉しいです。
725 名前:724 mailto:sage [2007/09/25(火) 23:42:37 ] あ、流れって、このスレの流れね。
726 名前:デフォルトの名無しさん [2007/09/25(火) 23:58:00 ] COBOL勉強するなら、端末COBOLや余分なファイルI/Oは飛ばしても構わんぞ。 基礎文法さえ押さえたら、すぐにでもOracleのPro*COBOLを勉強すべし。 オープン系COBOLは今かなり需要がある。
727 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 00:58:42 ] >>658 年金はデータだろw >>659 SQLを何度も発行するのがいやで一本化してるんでないの? ひとつの処理でテーブル10〜20使うのはざらにあるし。
728 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 01:00:26 ] Pro*COBOLはSQLが埋め込み式だから、SQLの可読性が高くていいね。 これに慣れてしまうと、VBやJavaでひたすらSQLを文字列結合している 汚らしい構文にはもう戻れない。
729 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 01:03:52 ] すぐ上に書き込みが来たので、ついでに > SQLを何度も発行するのがいやで一本化してるんでないの? DWHに限ってはそれは主目的ではないよ。 このスレにはDWHに詳しい方がいる(いた)ようなので私のような 半端モノは詳細説明を避けるけど、DWHのスレがあれば そちらで聞いてみるのもいいでしょう。
730 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 01:04:40 ] >>723 COBOLで書くなら当然大文字だけどさ、 他の言語使うならその言語の一般的なルールに従おうよ たまーに見かける小文字COBOLソース見ると、書いた奴殴りたくなるだろ?w そのまた逆も然り
731 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 01:20:08 ] それはいえる。変数の命名規約も然り。 だから、口座残高は、JavaではAccountBalance、 COBOLではKZ-ZNDKと書かねばならない。
732 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 02:37:47 ] !? KZ-ZNDK読みやすい!! 講座ズンドコ
733 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 03:09:47 ] まあコボルがクソ言語で コボラが死滅していく人種であることには 変わりはないんだけどな
734 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 06:00:19 ] 大文字で書けるJavaって・・・ 書けるだろ普通に
735 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 06:42:50 ] Javaは大文字でも出来るけど、特に意図がない限りは そりゃAccountBalanceって記述すると思うが。
736 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 06:59:52 ] >>735 >>723
737 名前:デフォルトの名無しさん [2007/09/26(水) 07:07:40 ] 変数とかメソッド名とか漢字を使うと偉く見通しがよくなるけどね 但し、漢字未対応のツールを使うと地獄が待っているが
738 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 07:37:58 ] 気分転換に質問です。 COBOLで書かれたシステムでは例えば、 摘要を構文解析して、意味を理解分類すると いうようなコードはどのように書いているの ですか。 それとも、汎く知られたソースのライブラリの ようなものがあるのですか。
739 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 13:43:52 ] >>738 COBOLには可変長の文字列といった概念は 基本的に無いんだよ。わかったな。それだけだ。
740 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 21:49:25 ] 基本的にない、だけだがな
741 名前:デフォルトの名無しさん mailto:sage [2007/09/26(水) 22:27:15 ] マルチレコードレイアウトにやられ気味。 なんじゃこりゃあぁぁぁぁ! けど、改ページを好きな所に入れられるのは超便利。
742 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 00:36:44 ] >>741 REDEFINES と / のことかな?
743 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 00:55:29 ] ある特定のカラムに特定の値があったらそのレコードはうんちゃらで、 なんちゃらの時はこんちゃらってのが、相当混乱しました。 キーなのに同じ値が複数あるし。もう慣れましたけど。 ワークスペースに複数の切り分けをした領域取ってやってましたけど、 REDEFINES使えば楽なんですかね? やってみます。 改ページはAFTER PAGEの事でっす。
744 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 00:56:55 ] REDEFINESって概念は他の言語にあるのかね?
745 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 03:35:01 ] C言語に共用体ってデータ構造があるらしいけど 挫折したからよくわからないんだ…
746 名前:デフォルトの名無しさん [2007/09/28(金) 11:02:11 ] C言語ならポインターと構造体でアクセスするだけだよ。何の不都合も無い
747 名前:デフォルトの名無しさん [2007/09/28(金) 11:36:14 ] 都合・不都合じゃなくって、REDEFINESって概念が他の言語にあるのか知りたいんだろ。 言語じゃなくて規約なら、COMがVARIANTという概念で、1つの変数にあらゆる属性の 値を入れることが出来た(主要言語はC++)。しかしこれはREDEFINESとは違うかな。
748 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 12:39:52 ] >>746 ポインタ設定するの面倒だろ。そのポインタ設定が漏れまくるから 高級言語じゃ使われないのに不都合無いって・・ REDEFINESはメモリ節約の産物だからもう必要ないだろ。
749 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 14:46:33 ] REDEFINESはCOBOLの中でも最もアセンブラ的な所だね。 REDEFINESと同様の概念がないとすると、アセンブラ的な ものから遠ざかろうとしている言語がほとんどだから ではないか。
750 名前:デフォルトの名無しさん [2007/09/28(金) 15:51:22 ] >>733 まあJAVAがクソ言語で ビジネスロジック専門自称JAVAPGが死滅していく人種であることには 変わりはないんだけどな
751 名前:デフォルトの名無しさん [2007/09/28(金) 16:23:57 ] >>748 I/Oポートを直接触る組み込みでは未だ必要な機能だよ、コボルと違ってビット単位でアクセスできるし まあシーケンシャルファイルなんてデータコンバートプログラムでしか用は無いけどね
752 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 18:57:57 ] あー、昔X68000とかでスプライトレジスタに書き込みする時に Cで構造体使っていたなぁ。 I/Oを叩く時は必要だと思うけど、COBOL的なデータ操作とかで 構造体やらREDEFINESを使ってどうこうとは今は思わんね。
753 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 19:34:32 ] STS分割する時に、なんでI/O定義書と違う定義を必要とするんだ?と思った。
754 名前:デフォルトの名無しさん [2007/09/28(金) 20:08:09 ] >>748 つうかあんた構造体とかポインタって全く解って無いだろ。ポインタ設定が漏れるって何のことだよ 勉強してから一丁前のこと言ってね
755 名前:デフォルトの名無しさん [2007/09/28(金) 20:17:28 ] ポインタ解決
756 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 22:25:28 ] >>754 はポインタ使ったこと無いのねw
757 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 23:24:38 ] なぜCOBOLだとポインタは不要なのに どうしてCではポインタが必須なのだろう。 俺の永遠の課題だ。
758 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 23:36:03 ] >>745 おれは C -> COBOLの順に勉強したんだけど、 REDEFINESを見たときに 「union(共用体) と一緒じゃん」って感想を持ったよ。 実際の使い方も似たようなものでしょ。 なんか「データ区分」みたいな項目があって使用する構造を決定する。 >>743 ちなみに、改ページはCでは'\f'フォームフィードでやったことがある。 C:構造体を関数にポインタで渡す COBOL:構造体をサブルーチンに参照渡し 存外、共通点らしき部分が見受けられますな。 COBOLは「編集項目」が便利だと思ったな。
759 名前:デフォルトの名無しさん mailto:sage [2007/09/29(土) 00:36:02 ] 誰かOOCOBOLやったことある人いないの?
760 名前:デフォルトの名無しさん [2007/09/29(土) 01:45:23 ] 最近はフレームワークをベースにビジネスロジックしか記述できない 自称JAVAPGだらけだな 「えっネットパッケージってなんですか?リフレックスAPI???」 おまえは無理しないでCOBOLでもやってろHAGEといらだつよ
761 名前:デフォルトの名無しさん [2007/09/29(土) 01:46:26 ] >>757 コボルの命令はCの関数ライブラリにあたると考えれば みなまで言わなくてもわかるだろ
762 名前:デフォルトの名無しさん [2007/09/29(土) 07:39:28 ] COBOL歴10年最近5年間ブランクありの40歳のおっさんだけど、もう需要ないかな? さすがにこの業界への再就職は厳しいかね? 他に資格とか無いし、警備員になるしかないのか。
763 名前:デフォルトの名無しさん mailto:sage [2007/09/29(土) 08:46:49 ] >>762 金融関係ならあるはずだべ by 45のオサーン
764 名前:デフォルトの名無しさん [2007/09/29(土) 11:04:18 ] 金融・保険関係はCOBOL需要いっぱいあるよ。 汎用機だけでなく最近はUNIX-COBOLも引く手数多。 後者は、UNIXの知識&Oracleの知識必須ね。 ただ、金融・保険関係は、プログラマ歴よりも金融開発歴が 重視されるので、金融業務歴がないと厳しいかな。
765 名前:デフォルトの名無しさん [2007/09/29(土) 11:20:34 ] >>763 >>764 ありがとう! 金融&UNIX&Oracleの知識はないけど頑張ってみます。
766 名前:762=765 [2007/09/29(土) 11:22:35 ] >>762 =>>765 です。
767 名前:デフォルトの名無しさん mailto:sage [2007/09/29(土) 11:22:57 ] いっそのこと運用オペレータという選択肢もあるぞw
768 名前:762=765 [2007/09/29(土) 11:32:10 ] >>767 あっても20万ぐらいだろうな。スキルも付かないし。 まあ、どっちにしても10年間頑張ってスキルを磨いても50歳。 そうなると転職は99.99・・・%無理、リストラされておしまいか。 お先真っ暗な人生しか見えない今日この頃・・・
769 名前:デフォルトの名無しさん mailto:sage [2007/09/29(土) 21:01:48 ] >>762 その年で底辺のプログラマーを目指す理由が正直わからんが。 COBOL歴は正直なんの役にも立たん。 漏れの知っている部署だと「知らなくてもすぐに覚えられるから」とか言う理由で 素人でも即プログラマーには慣れる。が、壊れるまでコキつかわれる率80%って感じだ。 まあ、壊れる壊れないは本人の資質が大きいのでデスマの経験を とくとくと語れば採用されるかも。
770 名前:デフォルトの名無しさん mailto:sage [2007/09/30(日) 05:48:17 ] 「Javaによる知能プログラミング入門」という本があり、 探索とパターン照合それからルールベースなどという章が 切られている。 Javaで書かれたPrologは多い。Prologに関して言うと最初のPrologは 1972年にマルセイユ大に於いてFORTRANで記述された。 それで、COBOLによって書かれたPrologはないかとググッてみても、 それらしきものは出てこない。1980年代には汎用機上のProlog処理系は 結構あったはずだけれどアセンブラで書かれていたのだろうか。
771 名前:デフォルトの名無しさん mailto:sage [2007/09/30(日) 08:14:11 ] 普通にアセンブラかCなんじゃねーのか? CがCで書かれたってのはある意味神業な気がするが。 とりあえずCOBOLはCOBOLで出来てないだろ。
772 名前:デフォルトの名無しさん [2007/09/30(日) 10:50:23 ] FORTRAN->Cへの書き換えは早いが、COBOL->Cの書き換えは遅い。 構文とか、商用に使いやすいとか、あまり関係ないんじゃないの?
773 名前:デフォルトの名無しさん [2007/09/30(日) 12:40:11 ] >>771 最初のC言語はB言語で書かれたんだよ。直ぐにC言語で書き直されたんだが
774 名前:デフォルトの名無しさん mailto:sage [2007/09/30(日) 13:44:16 ] むうー CをCで書くことに何の意味があるのだろうか。 この辺は理系の知識がいるな。
775 名前:デフォルトの名無しさん [2007/09/30(日) 16:01:22 ] >>762 あるとおもうよ こんなのもあるから 株式外会社COBOL www.cobol.co.jp/
776 名前:wolf ◆8VH3XAqjlU mailto:sage [2007/09/30(日) 18:06:04 ] >>774 たとえば皆さんのプログラムで正常処理とエラー処理の比率はどれくらいですか? どんな言語のコンパイラーでもただ動くだけ部分以外エラー処理とか最適化とか結構バカになりません それでAssemblerではやっていられないという事です
777 名前:デフォルトの名無しさん mailto:sage [2007/09/30(日) 22:58:29 ] >最初のC言語はB言語で書かれたんだよ。直ぐにC言語で書き直されたんだが 確かにB言語を改良した言語がC言語ではあるが、最初のCはBでは出来てないらしい。 CはCで書かれたとの事。
778 名前:デフォルトの名無しさん mailto:sage [2007/09/30(日) 23:26:06 ] でも一番最初のCはアセンブラで書かれたんだよな? 頼むそう言ってくれ! 言ってくれないと俺の頭が爆発する。
779 名前:デフォルトの名無しさん mailto:sage [2007/09/30(日) 23:50:26 ] Cが何でかかれたか、なんてスレ違いだよな! 頼むそう言ってくれ! 言ってくれないとCOBOLerがCスレに乱入する。
780 名前:デフォルトの名無しさん mailto:sage [2007/10/01(月) 01:05:03 ] 実は全てのプログラミングの言語ってC言語の派生なんだよ。
781 名前:デフォルトの名無しさん mailto:sage [2007/10/01(月) 13:43:24 ] マクロアセンブラの代わりにCを使って 書かれた言語が多いことは確かだが。
782 名前:デフォルトの名無しさん mailto:sage [2007/10/01(月) 15:08:46 ] >>781 Cが台頭するまではPL/MみたいなPL/Iのサブセットを使ったものが殆どだったが。
783 名前:デフォルトの名無しさん mailto:sage [2007/10/02(火) 17:57:50 ] COBOLはいいけど TSSがウンコ TSOの勝ち
784 名前:デフォルトの名無しさん mailto:sage [2007/10/04(木) 04:26:56 ] >>783 >TSOの勝ち それで何をするの?
785 名前:デフォルトの名無しさん mailto:sage [2007/10/04(木) 16:17:38 ] 現在、小売業の社内コボちゃんしていますが、 近々、転職を余儀なくされそうです。 金融関係は、キツイと言われていますが、実際のところ、どうなんでしょうか? (金融システムの経験は全くありません)
786 名前:デフォルトの名無しさん mailto:sage [2007/10/04(木) 18:20:24 ] 経験無いなら来ないでくれ、頼む。
787 名前:785 mailto:sage [2007/10/04(木) 19:16:21 ] >786 詳しく説明してくれたら、いきません。
788 名前:デフォルトの名無しさん mailto:sage [2007/10/04(木) 22:44:57 ] 金融システムの経験がないなら、まず門前払いだと思うが。
789 名前:デフォルトの名無しさん mailto:sage [2007/10/04(木) 23:29:09 ] キツいっつーか、金融系だと強烈に前時代的な開発スタイルだから それに耐えられるか?ってのもあると思うが。 ドキュメントは神(紙)って感じで・・・。
790 名前:デフォルトの名無しさん mailto:sage [2007/10/05(金) 00:08:18 ] 紙であるならまだいい。 古いシステムだと○○さんの頭の中だけってのも結構あるんだぜ。
791 名前:デフォルトの名無しさん mailto:sage [2007/10/05(金) 00:24:10 ] COBOLの場合トップダインで開発が進むから紙のドキュメントでも大筋で概要は分かる。 仕様変更の網羅がしっかりできていれば(コードレニューがきちんと行われていれば) 紙のドキュメントでも十分役に立つよ。 RADとかプロトタイピングとかいって最初の仕様と全く違うこと行っているのにソースのコメント がプロトタイプ版のままのモジュール(クラス)よりは絶対に役に立つ。
792 名前:デフォルトの名無しさん mailto:sage [2007/10/05(金) 06:48:46 ] >仕様変更の網羅がしっかりできていれば(コードレニューがきちんと行われていれば) >紙のドキュメントでも十分役に立つよ。 それが理想論なのは誰もが知っているワケで・・・。 >RADとかプロトタイピングとかいって最初の仕様と全く違うこと行っているのにソースのコメント >がプロトタイプ版のままのモジュール(クラス)よりは絶対に役に立つ コメントが難しいが、そう思うヤツの90%くらいはドキュメント信仰が強いだけの 能無しが言う台詞ではある。 オブジェクトにあるメソッドがブラックボックスでも大して困らない。 仮に言語がJavaだとしてJavadoc作ってあって、例外に関する仕様とdocが あれば許せる。 catch(HogeException){} なんて空の例外コーティングしてあると最悪と感じるが・・・。 まあ、漏れが現物志向ってのはあるな。 ドキュメントなんて大抵アレなケースが多いし。
793 名前:785 mailto:sage [2007/10/05(金) 09:11:05 ] >786 - 792 皆さん、貴重な御意見ありがとうございました。 取り敢えず、金融関係は、候補から外した方がよいみたいですね。
794 名前:デフォルトの名無しさん mailto:sage [2007/10/10(水) 17:20:33 ] 急に静かになったな・・・・
795 名前:デフォルトの名無しさん mailto:sage [2007/10/11(木) 21:14:59 ] www.microfocus.co.jp/support/techtips/cobol_002.asp COBOLってやっぱりすばらしい言語だね! Cなんて足下にも及ばないよ!
796 名前:デフォルトの名無しさん mailto:sage [2007/10/12(金) 00:00:56 ] >>795 そうCを責めるなよ。 そもそもCをOS記述以外に使うこと自体、 間違った使い方なんだから。 リッチーとカーニハンも、今のCの使われ方を 草葉の陰で嘆いていることだろう。
797 名前:デフォルトの名無しさん [2007/10/12(金) 00:57:05 ] >795 あんたは、そんな宣伝文句を真に受けてどうする コボラってほんまにアホや デスマ土方で頭おかしいんちゃう
798 名前:デフォルトの名無しさん mailto:sage [2007/10/12(金) 06:51:57 ] >>795 喪前がすばらしい脳ミソってのは解るな。
799 名前:デフォルトの名無しさん mailto:sage [2007/10/12(金) 10:10:25 ] ま、コボルを端から毛嫌いするヤツに限って、決裁権も選定権もなにもない三下だから、世の中なにも変わらないよ。
800 名前:デフォルトの名無しさん [2007/10/12(金) 18:16:59 ] 日本信号のプログラマはCOBOLer?(笑)
801 名前:デフォルトの名無しさん [2007/10/12(金) 21:49:05 ] 他メーカーのやつやったことあるけどC言語だったな
802 名前:デフォルトの名無しさん [2007/10/13(土) 00:28:03 ] >>801 他のメーカーのうまく動いたのはC言語、日本信号はCOBOLだったりして(笑)。
803 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 11:50:54 ] 自動改札機のカード読み取り部分にプログラムミスだろう? 組み込みでCOBOLってのは聞いたことがないが。
804 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 16:21:44 ] 組み込み機械にCOBOL、という発想が思い浮かぶ>>802 ってすごいにゃあ。 業界人には及びもつかない柔軟かつ斬新な発想。。。
805 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 16:35:04 ] でもこれほど安定して動く言語もないから 実際に組み込んでみたら凄いと思う なぜ組み込みに使われないのかは知らないけど
806 名前:デフォルトの名無しさん [2007/10/13(土) 16:42:14 ] >>805 セマフォとインターラプトとマルチスレッドを勉強してみようね
807 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 18:38:35 ] 安定して動くと言うか、あれだけ出来る事が少なくて 動く環境が限定されているんだから、そりゃ当たり前だと思うけど。
808 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 21:07:46 ] いや、そもそも事務処理を目的とした言語なのであって
809 名前:デフォルトの名無しさん [2007/10/13(土) 21:42:45 ] >>808 もう何も言うな 恥かくだけだぞ
810 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 22:45:40 ] >>807 当たり前とか簡単に言うなよ。 実際に安定して動くという事実こそは COBOL業界が長年努力して作り上げてきた かけがえのないメリットなのだぞ。 銀行や保険のシステムが年中ぶっ飛んでいたら 世の中は回っていかんでしょーが。 COBOLとCOBOLerが社会に成してきた貢献は 計り知れない。
811 名前:デフォルトの名無しさん [2007/10/14(日) 00:04:50 ] >>810 そもそも汎用機のOSやCOBOLはCOBOLで書かれていないんだが つまり安定したCOBOL環境を作ってきたのはアセンブラやC言語のエンジニアなんだよ
812 名前:デフォルトの名無しさん [2007/10/14(日) 00:23:47 ] なんでも最後はCとアセンブラの2つに行き着くのかな。まあCOBOLに限らず、と言ってもこぼらあは怒るのかなあ?
813 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 01:21:39 ] 初期のCOBOLはアセンブラで、 今のCOBOLはCOBOLで書かれていると聞いた
814 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 02:56:03 ] おめえちょっとコボルでパーサ書いてみろや
815 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 07:42:19 ] >実際に安定して動くという事実こそは >COBOL業界が長年努力して作り上げてきた >かけがえのないメリットなのだぞ。 COBOLの連中が努力しているのではなく、 汎用機を扱うメーカー(つか実質IBM)が金にモノを言わせて 独占市場となり、それの推奨言語がCOBOLだったって話なだけ な希ガス。 #RPGもあったか。 つか、今の汎用機のカーネルってアセンブラ+C++だし。
816 名前:デフォルトの名無しさん [2007/10/14(日) 12:50:24 ] 自動改札機、サーバーと切り離したら、起動したんだろ? 問題はサーバーにあり、 と思ったのだが。
817 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 14:29:46 ] COBOLってもう減価償却期間をとうに過ぎた言語だと思う今日このごろ
818 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 15:35:55 ] COBOLは事務計算用のフレームワークだと思えばいい。 何で書かれてるかはあまり重要ではない。
819 名前:wolf ◆8VH3XAqjlU mailto:sage [2007/10/14(日) 21:34:36 ] >>816 当然山勘ですが サーバーと切り離すと自主運転モードになって前日分のネガ・データで稼動したんじゃないかな?
820 名前:wolf ◆8VH3XAqjlU mailto:sage [2007/10/14(日) 21:37:44 ] >>819 あっゴメン 改札機開放したってニュースだから前日分を持っていなかったかな
821 名前:デフォルトの名無しさん [2007/10/14(日) 22:15:40 ] >>816 それだけの情報じゃどちらが悪いか判断つかないよ。サーバーからのコマンドの順序や タイミングによるものかもしれない。その場合は端末が悪いことも考えられる
822 名前:デフォルトの名無しさん mailto:sage [2007/10/15(月) 10:03:52 ] >>817 >799
823 名前:デフォルトの名無しさん [2007/10/15(月) 16:21:56 ] >>821 どうも、メーカー毎にサーバーが違っていたようだが。だから日本信号の改札機だけが 止まったらしい。COBOLer作じゃないの?(笑)
824 名前:デフォルトの名無しさん mailto:sage [2007/10/15(月) 16:30:56 ] >>823 おもしろくないのが、なんで一度で理解できない? まさか、おま・・ 現実逃避してないで首でもくくったらどうだ?
825 名前:デフォルトの名無しさん mailto:sage [2007/10/16(火) 00:35:32 ] ↑自分ワールドで何舞い上がってるんだろ
826 名前:デフォルトの名無しさん [2007/10/19(金) 16:05:31 ] COBOLって、汎用?(笑)
827 名前:デフォルトの名無しさん mailto:sage [2007/10/19(金) 17:18:58 ] うん。
828 名前:デフォルトの名無しさん [2007/10/19(金) 22:22:25 ] 事務系 ○ 技術計算× 制御系 × web系 × Winowsアプリ × 汎用?
829 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 00:21:10 ] うん。
830 名前:デフォルトの名無しさん [2007/10/20(土) 18:33:17 ] 凡庸?
831 名前:デフォルトの名無しさん [2007/10/20(土) 19:33:11 ] 朋友?
832 名前:デフォルトの名無しさん [2007/10/22(月) 15:58:53 ] 三菱東京UFJのシステム、東京三菱のシステムを残して、UFJのシステムはゆうちょ銀行に 売却するそうだ。こういうのって談合なんだろうなぁ。
833 名前:デフォルトの名無しさん [2007/10/22(月) 16:01:03 ] >>828 COBOLほど汎用を唱って、特殊な用途に使われている言語も少ないよ。 LISPとかPrologみたいな感じ。
834 名前:デフォルトの名無しさん [2007/10/24(水) 00:19:19 ] 金融系で開発&保守のSEやってますが、大手なせいで、 メインフレームのCOBOLもあれば、ダウンサイジングの中で作った C、Java、VB、Perlなんかのシステムもたっぷりあります。 (TSSでCOBOLプログラム書いてメインフレームからデータ 引っ張りだして、細かいところはPerlとかJavaで加工して 客に提出、なんて業務もしょっちゅう。) でもこんな特殊な環境で開発してきたせいで、ソフトウェア工学が 進歩してきた道のりを体感してます。 あんま、特定の言語に固執するのは意味がないんじゃないですかね。 ただ、COBOL&メインフレーム知ってると出世が速いのは あるかもしれません。COBOL世代のお偉方にJAVAをCOBOLに 翻訳して説明できるんで。
835 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 06:31:52 ] >ただ、COBOL&メインフレーム知ってると出世が速いのは 漏れの知っている金融系はまったくの逆だな。 10年以上マをやらされているヤツがほとんどだ。
836 名前:デフォルトの名無しさん [2007/10/24(水) 11:24:50 ] >>832 東京三菱とUFJのシステムってIBMと日立の違いだと思うのだけれど、開発言語は同じなの?
837 名前:デフォルトの名無しさん [2007/10/24(水) 16:10:00 ] >>836 日立A-cosだよなIBMとちょとちがう
838 名前:デフォルトの名無しさん [2007/10/24(水) 16:21:27 ] >>837 ACOS...国策的OSだなぁ。
839 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 18:18:41 ] ACOSはNECだ
840 名前:デフォルトの名無しさん [2007/10/24(水) 20:57:46 ] COBOLなんて今後ニーズあるんですかね?
841 名前:デフォルトの名無しさん [2007/10/24(水) 21:52:08 ] 金融系だけど、ほとんどEASYとJCLばかり触ってる。
842 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 21:56:57 ] >>834 金融系でもフロントはそんな感じだよね 色々経験できるのはいいけどバックの事とか全然わからないんじゃ? というか、俺がそうなんだけどw
843 名前:デフォルトの名無しさん [2007/10/24(水) 22:09:44 ] COBOLの記述について、教えてください。 ORACLEテストテーブル OLACLE-KOUMOKU VARCHAR2 300バイト ※中身は動的SQLが入っております。 これを、COBOLの画面表示するために 01 WK-KOUMOKU. 03 WK-KOUMOKU-A PIC X(60) 03 WK-KOUMOKU-B PIC X(60) 03 WK-KOUMOKU-C PIC X(60) 03 FILLER PIC X(120) 切捨て用 -------------------------------------- MOVE OLACLE-KOUMOKU TO WK-KOUMOKU -------------------------------------- DISPLAY WK-KOUMOKU-A DISPLAY WK-KOUMOKU-B DISPLAY WK-KOUMOKU-C -------------------------------------- この場合、どうしてもWK-KOUMOKU-Aの 一番最初に変な文字が表示されます。 どうすればよいのでしょうか? 可変長だとなんかヘッダついてくるみたいですが どのように除外できますか?
844 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 02:07:08 ] >>843 Pro*COBOL? たしか、 WK-KOUMOKU-Aを可変長文字列にする宣言が必要なんじゃないか? それをすると、 WK-KOUMOKU-A-LEN と WK-KOUMOKU-A-VAR (だったかな?)という二つの変数名が出来るんだったような...
845 名前:デフォルトの名無しさん [2007/10/25(木) 07:54:36 ] >>844 ありがとうございます。 さっそく、試してみます。 本当にありがとうございます。
846 名前:デフォルトの名無しさん mailto:sage [2007/10/27(土) 18:46:16 ] コボルで汎用的なCSV変換のPGMを作成したいのですが どういうPGMを作成すれば実現できるか思いつきません。 INPUT@をCSV化したい固定長ファイル INPUTAにCOBOLのCOPY句(OCCURS項目がある場合は少し加工が必要?)を指定して OUTPUTにCOPY句に合わせた CSVファイルが出力されるようなPGMが理想です。 STRINGとかUNSTRINGを駆使すれば出来そうかなくらいの 想像しか出来ません。 低脳ですいませんがアドバイスあれば宜しくお願いします。
847 名前:デフォルトの名無しさん mailto:sage [2007/10/27(土) 21:59:32 ] >>846 ttp://homepage2.nifty.com/pu-relaxroom/pro/pro-cob3.htm を参考にしたら。
848 名前:wolf ◆8VH3XAqjlU mailto:sage [2007/10/28(日) 15:31:35 ] >>846 コンパイラーで REFERENCE MODIFICATION が使えれば「4.部分参照の表記方法」を参考に サルでもわかるCOBOL入門 【ひよこグミ】 www16.plala.or.jp/hiyokogumi/3/310.html#a4
849 名前:デフォルトの名無しさん mailto:sage [2007/10/29(月) 12:06:12 ] >>846 そういう用途にCOBOLは使わないほうがいい
850 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 14:07:48 ] COBOL経験者急募
851 名前:デフォルトの名無しさん mailto:sage [2007/11/01(木) 09:33:36 ] >850 業種とかは?
852 名前:デフォルトの名無しさん mailto:sage [2007/11/01(木) 21:50:29 ] >850 どの板&スレで?
853 名前:デフォルトの名無しさん [2007/11/01(木) 23:59:10 ] 基本的な事で申し訳ないですが・・・。 COBOLのASSIGN TO hogehoge となっていた場合、JCLからならhogehogeに対応するファイルを 指定して読み込ませますよね? MFCOBOL@AIXで動かしたいのですが、 hogehogeにファイルを関連付けるのってどうやるのでしょうか? dd_hogehoge = path.to.file export dd_hogehoge で合ってます? やってみればよいのですが、しばらく実機にさわれないので、 よろしければどなたか経験者の方ご教授ください。
854 名前:デフォルトの名無しさん [2007/11/02(金) 12:53:53 ] 正直、COBOLってもうだめなの? 現役コボラーの方どうですかね?
855 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 20:33:54 ] これから新しい分野でどんどん使われるとはさすがに思わない。 けど、廃れることだけは絶対にない。 と思う。 w
856 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 21:35:39 ] 絶滅はしないだろうけど、COBOLやってるヤツはある意味 鬱病患者のように「新しい仕事がやりたい」と漏らしている。 しかし実際に新しい仕事をやることはほとんどない。 10年以上前のシステムを延々と保守し続けるだけ。
857 名前:デフォルトの名無しさん [2007/11/02(金) 22:43:03 ] >>853 そういえば、ASSIGN TO なんてあったねw 部品使ってるので、研修以来ASSIGN TO なんか見たことない。。。
858 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 23:55:13 ] >>856 なかなか見所のある奴だねぇ デスマ確定なシステム更改案件とかやってる会社に転職すればいい 常時人材を欲しているはずw
859 名前:856 mailto:sage [2007/11/03(土) 08:57:33 ] >>858 えーと、40〜50代のCOBOLしか使えないし同じ部署で10年以上いる為、 世間一般の開発常識は一切ない、ある意味素人同然なんだが・・・。 正直、今リアルタイムでCOBOLの仕事している人って世間知らずのボンボンって 印象がぬぐえないのだが・・・。 Eclipse等のIDEは見たことも触った事もないし。
860 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 10:36:39 ] >>859 > 正直、今リアルタイムでCOBOLの仕事している人って世間知らずのボンボンって それと開発と何の関係があるんだよ。 仕様通り納期を守ってシステムを作る、 それが開発者に科せられた唯一にして 最大の使命じゃないか。 他に何か資質を要求されるのかい?
861 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 11:14:02 ] その唯一にして最大の使命に、結構世間を知っているかどうかが どーゆーわけか結構関わってくるんだな、これが。 開発って、残念ながらそこまでピュアに専門知識と専門技術だけで進むものではないからね。
862 名前:856 mailto:sage [2007/11/03(土) 14:40:23 ] >>860 世間を知らないと結構大変と言うか仕事できないに近いけど。 システム開発でコーダー&テスターみたいな最底辺ならともかくとして、 「新しいシステムを作る」となると実運用やユーザー側から見た使い勝手 とか意識しながら、要件をまとめ、設計&実装するワケだが、 COBOLって未だにTSO端末のグリーン画面で80x23なテキスト画面設計して、 SNAでネットワーク&プリンタを構成して、システムバックアップはテープ命って ノリだからなぁ。 システムなんにも知らないお客さんに対して「電文」とかの普通に喋るしサ。 もうちょっと普通の一般人に解る言葉で喋ってくれないと、辛いと思う。 SNAって単語自体普通のエンジニアだって知ってるか疑わしいし。
863 名前:デフォルトの名無しさん [2007/11/03(土) 14:40:46 ] >861 あなたは結構世間を知っているんですね。 凄いね。
864 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 15:56:19 ] >>853 UNIX系の環境では、環境変数で結びつけるってやり方は多分一緒だと思うけど、 環境変数名は ASSIGN TO hogehoge なら環境変数名もhogehoge で良いと思うよ。 dd_hogehoge の dd_ をつける必要があるのかな・・? (コンパイラの違いとかあるかもしれんけど)
865 名前:デフォルトの名無しさん mailto:sage [2007/11/05(月) 10:31:04 ] >>862 MTはCOBOLだからとかそういう問題じゃないし、汎用機じゃなくてもMTは普通に使うだろ Disk to Diskのみなんてのはバックアップと言えない CMTは敷居が高いから少ないけどDAT、LTO程度は入れるべき SNAはさすがにもう使っているところ少ないだろうね。でもすごく安定したプロトコルだった Win2000まではSNAドライバを見かけたことあるけど、最近のOS用のはあるのかな? もっとも、スイッチとかルータが対応してる機器が少なくなって来ちゃってるけど
866 名前:856 mailto:sage [2007/11/05(月) 19:03:02 ] >>865 汎用機じゃないとMTは使わんとオモ。最近はかなり減ったと感じる。 何年か前は口座引き落としな全銀どーたらで使ってたりもしたけど、 電送(?)に変えてから業務なやりとりでMTは使わなくなった。 データのバックアップでDATやLTOは入れてる。 ただ未だにシステムのバックアップで1/4カートリッジ(30GB)が普通と COBOLerなエンジニアは主張してくる。エェー で、ウチの案件は未だにSNA全盛で色々とめんどくさい。 ちょっとプリンタの電源投入タイミングが悪いと手動でON/OFF しないといけない。構成が悪いって言えば悪いんだろうけど。 とにかく運用コストが高い方法を好むのよ。汎用機&COBOLerなエンジニアは。
867 名前:デフォルトの名無しさん [2007/11/05(月) 21:14:52 ] よ〜く知ってるね 凄いねw
868 名前:853 mailto:sage [2007/11/05(月) 23:13:56 ] >>864 ありがとうごぜいやす。 今度試してみます!
869 名前:デフォルトの名無しさん mailto:sage [2007/11/06(火) 09:10:10 ] バックアップはやはりCMTに限る。 ドライブ装置とメディアの信頼性が他とは圧倒的に違う。 DAT・DLT・LTOも使ってるけど、装置・メディアとも しょっちゅう故障してて使い物にならん。
870 名前:デフォルトの名無しさん mailto:sage [2007/11/06(火) 09:19:31 ] CMT無くなるって噂が・・・(製造終了)
871 名前:デフォルトの名無しさん mailto:sage [2007/11/06(火) 11:11:20 ] >>866 だから、DATもLTOもMTだってば CMTはドライブどころかメディアも丈夫だから 値段は高いけど、信頼性も高い ウチ10年位ワークテープとして使われている CMTメディアあったよw で、全銀どーたらって全銀手順のことでしょ? それがEDI(電送) EDIで送れるデータ量ならいいけど、到底無理な 場合も多々あって、そういう場合はやっぱりCMT 通函じゃないけどある程度丈夫じゃないと、コスト 云々よりも確実なデータ流通が滞る LTOはいくらか丈夫だけど、DATは使い捨てする 位の気持ちで使わないと泣きをみる
872 名前:デフォルトの名無しさん mailto:sage [2007/11/06(火) 22:13:23 ] 2chのしょっちゅう故障するってのはどーも微妙だったり。 ウチはCMTが一番トラブル多い、理由は「エンジニアが丈夫だからと過信してミスをする」ケース。(w LTOは問題なし、DATは最初から1年交換ってノリで運用している。 まあテープ関連の業務は正・副作成して作業しているから 多少壊れてもいーや、感はある。 今の電送は県民単位で処理可能なデータ量なんで、漏れの地方では使わんな。 仮に電送が止まったらテープで運送って対策しているから、最初から 「やっぱりテープが安心」ってやり方はしてない。最終手段として捕らえている。 ただ東京都とかが回線が胡散臭くて安定して送れない状況と言うならそうなのかもしれん。 田舎モノでスマソ。 あとテープ装置を漏れがあんまし推奨しない理由は運用のおばちゃん(とは限らんが)に 高価なデッキを触らすに抵抗がある。 人間は間違えるナマモノって印象があるからな。
873 名前:デフォルトの名無しさん mailto:sage [2007/11/07(水) 09:02:37 ] 今でもオープンリールMTで「シュコー…キュルキュルキュル」と普通にIN-OUT テープ折れ曲がったら其処をハサミでチョッキン!! ほらまだ使えんじゃね〜か しかしハード保守契約は切れてて綱渡り なのにCOBOLは今日も安定 バッチジョブをチョチョイっといじってコンパイル あれ落ちちゃった?? コンソールの赤い文字が小憎らしいじぇ かな入力モードはデフォ 俺の通り過ぎたPCから若造たちの「げっカナモード」の悲鳴が心地いい それから マッチングの前には必ずレコードクリアをするんだ、うんこしたらお尻拭くのと一緒だ MOVE SPACEだ けどマシン室ドアの暗証番号を入れ間違い「あ、あれっ」とすんなり一回で入れない コボラーとはそんな漢の世界
874 名前:デフォルトの名無しさん mailto:sage [2007/11/07(水) 21:58:58 ] >>873 >マッチングの前に〜うんこしたらお尻拭く どちらかというと、「トイレで座る前に便座を拭く」とかの方が良くない? ときどき水滴が...
875 名前:デフォルトの名無しさん mailto:sage [2007/11/07(水) 22:03:14 ] 確かにウンコする前に尻拭いてるって事になるね した後は当然拭いてないんだろうなぁ んで保守契約ぐらいしとけw 壊れたらどーすんだ
876 名前:デフォルトの名無しさん mailto:sage [2007/11/08(木) 16:59:16 ] >>875 >壊れたらどーすんだ メインの媒体はCMTだからw MTはおぢちゃんたちが「過去のデータ資産を〜」って言って残したの(実際はCMTに全部COPYしてるけどね) ほら"007"(ショーンコネリーのね)とか、仮面ライダーのショッカー基地とか… 悪の秘密結社でMTがくるくる回っているが心にのこってるのよw 「あれがコンピューターだ」ってね 結局…CMTとかDATには『萌え』がないんだよw これっって賛同者多いと思うけどなww あ〜ちなみに8インチフロッピーもご健在 髪の毛挟まっていようが、綿埃ついていようが 「ガッチン、ガッチン」読込むあのタフさが『萌え』ww
877 名前:デフォルトの名無しさん mailto:sage [2007/11/08(木) 22:35:38 ] つーか今でもMTのメディアや機器作ってる会社あるのか?
878 名前:デフォルトの名無しさん mailto:sage [2007/11/09(金) 08:23:23 ] >>856 その古いシステムを延々と保守し続ける事が 仕事になるって、ある意味幸せな事だけど…。 10年後もおそらくそれで飯食えるわけだろ? 他の環境なんて、ライブラリやら刷新されて 一から覚え直してプログラミング なんてザラでっせ。 (昨今のWeb系もC++だけじゃどうにもならんからね)
879 名前:デフォルトの名無しさん mailto:sage [2007/11/10(土) 04:53:54 ] >仕事になるって、ある意味幸せな事だけど…。 >10年後もおそらくそれで飯食えるわけだろ? 死なない程度の給料でな。 >他の環境なんて、ライブラリやら刷新されて >一から覚え直してプログラミング なんてザラでっせ。 どこのザラか知らんが、技術職なんかは常に勉強するのが ある意味、普通なんだが。 オブジェクト指向な言語(JavaやC#)の初歩すら理解できん 低脳は存在するから、それはそれで仕方ないが、 自分が理解できないからって上記な理由で身の保身に 走って他者の脚を引っ張るマネするからCOBOLerは 他のエンジニアからバカにされる率が圧倒的に高いんだとオモ。
880 名前:デフォルトの名無しさん [2007/11/10(土) 08:25:08 ] コボルの仕事で金を稼げるかどうかは会社次第なんじゃねぇの 金融子会社でもコボル使わない現場に送られたら・・・ それ以上に、システム会社自体がどれくらい寿命があることやら
881 名前:デフォルトの名無しさん mailto:sage [2007/11/10(土) 08:58:42 ] >>879 おい言葉に気をつけろ。低脳とは何だ。 人をそんな風に言うもんじゃない。 オブジェクト指向は本来非常に特殊で難解な 概念で、ソフトウェア技術に適用することに疑問すら 提唱されているものなんだから、わからなくても おかしくないんだよ。
882 名前:デフォルトの名無しさん mailto:sage [2007/11/10(土) 09:44:04 ] >コボルの仕事で金を稼げるかどうかは会社次第なんじゃねぇの 会社が儲かるのと個人の報酬は別物だけどなー。 ああ、でも単純なプログラマー単価だと不思議とCOBOLはちょい高いよな。
883 名前:デフォルトの名無しさん mailto:sage [2007/11/10(土) 09:56:18 ] >>879 JavaやCができたって所詮デジタル土方じゃないか。
884 名前:デフォルトの名無しさん [2007/11/10(土) 10:02:13 ] オブジェクト指向なんて、別にできたからどうっていうほどの 特殊な思考でもないけどなあ。 そういえばOOCOBOLってやっぱり誰も使ってないの? 俺もOOCOBOLでCOM作って遊んだ程度の経験しかないけどさ。
885 名前:デフォルトの名無しさん mailto:sage [2007/11/10(土) 10:21:15 ] オブジェクト指向はたいしたことなくもないが、 現実問題ユニットテストつーか、単体テストで ファイルの結果をなんでもかんでも16進数のダンプ形式で プリンタに印刷して、鉛筆と定規で縦線引いて、 マーカーで色つけて、って手間ばかりかかるテスト手法を 強制するのがCOBOLerだなー、って感はある。 オブジェクト指向と言うよりかは、現代の開発スタイルから あからさまに取り残されている感がウチの周りではある。 もうちょっと本質的かつ効率的なテストしてほしい。 JavaのxxUnitみたいなユニットテスト→リファクタって概念ないんで、 システムが年々グダグダになっていく。 まあ、Javaでもグダグダになっていくけどサ。
886 名前:デフォルトの名無しさん mailto:sage [2007/11/10(土) 14:02:11 ] >>885 COBOLが駄目な一番の理由はリファクタ出来ない事だよねぇ 現行の仕様を誰も理解してないから、 デグレードが怖くて影響の少なそうな部分を強引に直す んで更にシステムがグダグダになっていく まさに負のスパイラル
887 名前:デフォルトの名無しさん [2007/11/10(土) 17:44:25 ] 月9ドラマ「ガリレオ」最終回、COBOLる(おわる)
888 名前:デフォルトの名無しさん [2007/11/10(土) 17:49:10 ] >>886 考古学的プログラム分析ツール 仕様書のないCOBOLプログラムを分析ツールにかけて、GUIで、シーマンプログラマが一杯飲みながら 愚痴りながら仕様を解説してくれる
889 名前:デフォルトの名無しさん [2007/11/11(日) 04:34:58 ] デー子で働いてる人いたら業務内容kwsk
890 名前:デフォルトの名無しさん [2007/11/11(日) 04:51:22 ] COBOLのコーダーになりたい pc11.2ch.net/test/read.cgi/prog/1194723581/
891 名前:デフォルトの名無しさん [2007/11/11(日) 09:43:13 ] >>890 COBOLだけ学んでもJCL学ばないと意味ないぞ
892 名前:デフォルトの名無しさん mailto:sage [2007/11/11(日) 19:30:12 ] 言語の難易度として COBOLってどれぐらい? 自分は全く触ったことないけど、印象的には SQLぐらいかとか、何の根拠もなく思ってるん だけどどんなもんだろ。 もっと難しい? 難易度の尺度としては、同じ人物が、 簡単なアプリ組めるようになる日数で。 (SQLはアプリ内で要求通りの表作り)
893 名前:デフォルトの名無しさん mailto:sage [2007/11/11(日) 19:51:47 ] バッチ系のファイル更新のみで、同じ人物だとしたら 生産性はSQLが10分とすればCOBOLは3・4時間くらいだろうな。 ただ、現実的にCOBOLerはSQLを覚えない、もしくは 超絶初心者レベル(SELECT * FROM HOGE程度)が 99%くらいなので、こういう比較は意味ないとオモ。 あと、SQLでは画面遷移やらプリンター印刷やらの処理は出来ない(に近い)ので SQL使いは他の言語(JavaやらCやらRubyやら)を覚えなければならないが、 COBOLはそれだけで一通りのアプリが出来なくもないのでSQLとは比較にならないとオモ。 言語の難易度としては気軽に学習とは言いがたいのでそういう意味では高いが 言語仕様的には中レベルじゃね。
894 名前:デフォルトの名無しさん mailto:sage [2007/11/12(月) 00:02:38 ] SQLでどうやってファイル更新するんだろ
895 名前:デフォルトの名無しさん mailto:sage [2007/11/12(月) 06:39:36 ] COBOLerのカキコは相変わらず釣りかマジレスか解らんな・・・
896 名前:デフォルトの名無しさん mailto:sage [2007/11/12(月) 21:50:02 ] >>893 今Accessを勉強しているけど、やはり難しいと思う。 複数のクエリが同時に連動して動く。 これではどこかでクエリを止めて出力を検証するなどの デバッグ手法が使えないし、項目の追加変更が出た時に どこを直すべきかわからなくなる。 やはりコボルで地道にバッチシステムを構築するのが 一番だと思った。
897 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 00:00:55 ] 今いる部署で言語コンバートをしているのだが、 「COBOLは保守要員がいないのでASMにして下さい」 泣いてCOBOLにしてもらいました。ASMクメネ.orz かと思えば、 よそのシステム管理部からCOBOLプログラムの修正が飛んでくるし。 >896 後々を考えると、VBA+SQLで組むのが応用が出来ると思います。
898 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 01:03:22 ] そういえばWinでバッチなシステムを見たことが無い 小規模なシステムならUNIX使うより運用が楽そうで良さそうなんだが
899 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 06:47:44 ] >>896 Accessにナニを求めているか知らんが、 カキコを読む限りはCOBOLの延長でモノを考えているから 泥沼にハマるだけなのでは・・・。 そして、地道なバッチシステムほどメンテしにくいモノはない。 RDB設計の基本の「one fact in one place(1つの事実は1カ所で管理する)」 が出来ていない人間ほど、そういう複雑怪奇な物事の考え方をする。
900 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 09:00:14 ] >>896 複数のクエリが同時に連動して動く って? できないことはないでしょ、みんなやってんだから。 アクセスは組んだことないけど、Winアプリは、 DOSプログラムの様な1本道の処理ではなく、 いわば全て割り込みを引き金にして動くからね。 これはオブジェクト指向とも相性がいい。
901 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 10:50:03 ] >>893 COBOLの仕様も随分と拡張されたものだが、 それでも"やさしい部類"に入るのではないか。 役に立っていない予約語が無闇と多いが。
902 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 12:43:19 ] Cみたいなバイナリベースの型しか頭に無かった俺は 高校でCOBOLやらされてPICを理解するのに数日苦しんだw 桁ベースなんだよな、あれって…
903 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 16:54:52 ] C畑にとっちゃCOMPも理解に苦しむな なんなんだよ、あれ・・・
904 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 21:28:35 ] >>900 > 複数のクエリが同時に連動して動く って? 例えばクエリAの出力をクエリBの入力に指定して… という風にどんどんつなげていくと、 クエリZを実行しただけでクエリAからZまで ぷよぷよの大連鎖みたいにダダーって動く。 これは恐ろしい。下手に動かすとシステムを壊してしまう。 全クエリの相関図を書かないと手を出せない。 その点コボルは一つ一つがロードモジュールとして 明確に独立しているから、非常に扱いやすい。
905 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 22:23:22 ] >>904 もしかしてSQLの実行に非同期コマンドの DoCmd.RunSQL 使ってないか? だったらAccessで(というかVBAで)初心者が必ず犯す失敗のひとつ。 同期コマンドの CurrentDb.Execute 使ってみれ。
906 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 22:33:04 ] >例えばクエリAの出力をクエリBの入力に指定して… >という風にどんどんつなげていくと、 COBOLerが好みそうな糞設計の典型だな。
907 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 00:06:27 ] ばよえ〜〜ん
908 名前:デフォルトの名無しさん [2007/11/14(水) 11:43:02 ] >>906 動かした順番を間違ったときオペレーターが悪いって言い張るアレのことかな
909 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 13:43:28 ] >>906 おまえ知らなかっただろw
910 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 22:22:37 ] 基本的にCOBOLerってシステム設計で基本の「結合度は低く、凝縮度は高く」を 真逆に実装するクセがあるよな。 そのクセ「その点コボルは一つ一つがロードモジュールとして 明確に独立しているから、非常に扱いやすい。」とか勘違いして、 途中のモジュールがコケると後続やら関連JOBが停止して、 あれこれとオペレータが泣かされる。w 普通の設計でクエリの出力をつなげるなんてヴァカ設計しねーっての。
911 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 23:16:40 ] >>910 >途中のモジュールがコケると後続やら関連JOBが停止して、 当たり前じゃないのか? 重要なのは対処して、再実行だけで業務続行が出来るように 設計されていること。 PCなんかじゃ、編集中のファイルがぶっ壊れて 修復不能ってのが当然なんだろ。
912 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 23:26:46 ] >PCなんかじゃ、編集中のファイルがぶっ壊れて >修復不能ってのが当然なんだろ。 釣りがマジレスか知らんがこの認識が正にCOBOLerの真骨頂だと思う。
913 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 23:30:58 ] >重要なのは対処して、再実行だけで業務続行が出来るように >設計されていること。 現実的に、10年以上前のシステムをリファクタ無しでCOBOLerが メンテし続けた、複雑怪奇な状態で「再実行だけで動く」なんてのは かなり稀なケースであり、実際は「あそこのフラグを初期化してから実行」 とか「あのメニューの最初から順にやり直してください」ってケースが ほとんどな点についてw
914 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 23:34:33 ] コボラはまずコボル以外の開発をやってから何か言った方がいい
915 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 00:16:12 ] COBOLしかやったことのない奴なんていねーよ だいたいが複数言語のマルチリンガル
916 名前:デフォルトの名無しさん [2007/11/15(木) 01:12:05 ] そうだなCOBOLer崩れがVBの糞設計を量産しているのはよく知っているよ 500行を超える関数をコーディングしたりしてな
917 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 02:07:24 ] >>916 別に問題無いだろ。意味なくアホみたいに小さな関数大量に作られる 方が苦痛だ。呼び先見たら1行なんてざらだし。 開発量の水増しかよww >>913 だってマジにやったらお金掛かって仕方ないしw >>912 釣りはオマイだろ。MS-Wordのファイルなんか普通に保存して、 二度と開かなくなることが度々あったしな。 こんなレベルの製品で金が取れるのが不思議だ。
918 名前:デフォルトの名無しさん [2007/11/15(木) 04:36:23 ] >>917 COBOLerってプログラムの構造化が何で必要かわかっていないんだ 500所か1000,2000行の関数作って「俺は凄いんだ」って自己満足してるしな スコープって概念は一生理解できないだろうな 俺が知ってる1行の関数作っていた奴もCOBLer崩れだったんだけどね 1000行ぐらいの関数から4,5回呼び出していたよ
919 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 06:03:37 ] >>910 > 普通の設計でクエリの出力をつなげるなんてヴァカ設計しねーっての。 んー俺が勉強不足なのかなあ。 クエリ一つでやれることは一つの処理だけだから、 複数工程のデータ加工を実現するには JCLのステップみたいにクエリをつなげるしかないと思うんだけど。 で、一番最後のクエリを動かすマクロをAccessに登録して 運用者にはそのマクロを起動してもらう。 この手法でいろんなシステム組んじゃってるんだけど マズイのかな。
920 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 06:50:01 ] >釣りはオマイだろ。MS-Wordのファイルなんか普通に保存して、 >二度と開かなくなることが度々あったしな。 Win3.1の時代のネタか故障しているPC&鯖なんじゃねーのか。 今はまず壊れないし、自動保存&作業中にハングしても元ファイルは壊れない 仕組みになっている。 障害率で言うならCOBOLerのシステムの方がよっぽどアベンド率が高い。 自らの保身の為に都市伝説を声高らかに語るなよ。アフォか。
921 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 07:27:52 ] >>919 コミットやロールバックは知ってる?
922 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 07:31:13 ] >>919 じゃ世の中のSQLを内包して動いてるシステムは壊れまくりっすね
923 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 09:22:59 ] >>921 コミット・ロールバックはAccessのマクロからでは使えないって知ってる? >>920 この手法はまずいと思う。 VBAを使えばAccessでもコミット・ロールバックが使えるからそちらの 実装を考えてみては?
924 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 10:50:49 ] 今北わけだが このスレでコボラーと定義されているコボルしか扱えない人達 (恐らく2007年問題とか言われてる中で居なくなる人たちが主) は確かに使い物にならないというか、未だにダム端しかなくても 困らない仕事しかできないのは事実だけど、コボル自体は悪い 言語じゃない。ここでコボルを卑下してるヤツってコボルを実戦 経験してないだろ。解釈がおかしすぎ。 コボルでも普通にSQL扱えるんだから、うまく利用できていない ことがあれば、それはコボルの問題じゃなくて人の問題。 もっともくだらない小競り合いからVBAやら終にはワードの話に なるんじゃ、ここでは肯定派にもいわゆる駄目な人が居るみたい だけどさ。でも、>911の解釈は正しい。 >910は何してる人か知らないけど、エラーは情報を残しておいて 後で処理すれば済む場合と、その場で対処しないとユーザにも 迷惑かけることになる場合があるのはわかるよな?
925 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 13:37:06 ] コボルが悪い言語じゃないって良く聞くフレーズだけど、 どう考えたって言語として最悪だろ それを認めない限り、一歩も前進しないぞ
926 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 13:46:57 ] >>925 だから最悪だってことを説明してみろよ なーんも考えてないくせに「どう考えたって」とか放いてるなよ
927 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 14:03:07 ] 最悪な点なんざ枚挙に暇がねえよ 俺的に一番気に入らないのは、抽象化が出来ないこと
928 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 14:52:42 ] >>920 Word使ったこと無いでしょ。Word2003でも余裕で 死ねるつーの。都市伝説?どこの田舎だよ。 これが現実だっつーの。 Word 文書が破損している場合のトラブルシューティング方法 support.microsoft.com/kb/826864/JA/ >概要 >文書ファイルが壊れていると、プログラムの動作に問題が発生する場合が >あります。この現象は、ファイル内の情報に誤りがあることが原因で発生します。 >文書の破損による損害を防止する最も効果的な方法は、 >文書のバックアップ コピーを作成しておくことです。
929 名前:デフォルトの名無しさん [2007/11/15(木) 17:03:47 ] >>928 数千万のコンピュータで動くソフトと、お前の1台のコンピュータでしか動かさないソフトを比較して嬉しいの?
930 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 17:05:29 ] >>927 それを言うなら「枚挙に遑がねーよ」な ゆとりな抽象的回答過ぎて何の抽象化だか判んねー アセンブリじゃねーんだから、抽象化ぐらいできてるぞ 思考の抽象化もたいがいにしろよ ま、クラスって考え方はコボルにはないけどな 仮にそれが一番の理由として、それで最悪? 少なくとも「俺的」根拠で最悪とは短絡思考もいいところ
931 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 17:08:16 ] コボちゃんご立腹 の巻
932 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 18:23:03 ] COBOL で関数が作れたら良いなぁ。と思ったことはある。 (FORTRANを思い出しながら)
933 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 21:50:55 ] >コボルでも普通にSQL扱えるんだから、うまく利用できていない アレは普通とは言わないと思うし、そういう場合は普通にストアドにする。 そこまでして生産性の低いコボルをムリに使おうとは思わない。
934 名前:デフォルトの名無しさん [2007/11/15(木) 22:07:29 ] >>930 COBOLってよく知らないんだが、クラスを伴わない抽象化って斬新だな abstractやinterfaceを使わずどうやって抽象化するの?
935 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 22:36:49 ] 930の世界ではアセンブラ以外の言語は全て抽象化が可能なんだろう。
936 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 23:23:01 ] このスレで抽象化とか意味不明なことしゃべるなよ。 COBOLは質実剛健・実用第一を旨とする漢の言語。 軽薄な機能なんて要らないのさ。 変数スコープや関数や小文字キーワードなんて 百害あって一利なし。バグの元になるだけ。
937 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 23:25:26 ] いや漢とか…
938 名前:デフォルトの名無しさん [2007/11/15(木) 23:43:27 ] >>936 ただ、不器用で使いづらい言語なだけだろ
939 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 23:45:47 ] COBOLなんてSQLサーバへクエリー投げた結果を形整えて出力するだけでいいんだよ。 PL-SQLの上位みたいなポジション。
940 名前:デフォルトの名無しさん [2007/11/15(木) 23:47:07 ] >変数スコープや関数 いや、これはイルダロ・・・
941 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 23:51:58 ] オブジェクト指向を覚えたての人間が混じっているな interfaceだのabstructだのって。。。
942 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 23:53:45 ] COBOLってRDBすら使わないイメージがあるのだが。
943 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 23:56:02 ] RDB使わずにVSAMやらなにやらだけでやってるところは当然ある。
944 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 23:56:13 ] さすがにRDBは使うよ ファイルの変わりに
945 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 00:01:16 ] >>936 N88-BASICかよ
946 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 00:28:43 ] しかしさCOBOLやっててファイル名がIN01やらIO01とか TENBANはまだいいにしてもCA001→CA999,CB001→CB999とかな カラム名でDB設計されてたらたまらん罠。
947 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 00:51:57 ] 必要なら一覧表を参照すればいい。
948 名前:デフォルトの名無しさん [2007/11/16(金) 01:30:03 ] >>944 レコードイメージをvarchar型とかに平気で突っ込んだりしてるのかな
949 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 01:46:14 ] 俺、汎用機使ってCOBOLで処理しているんだけど、 COBOLってそんなに悪い言語かなあ? この考えが時代遅れか? 例えば100万人分のバッチ処理をやったりする分には まったく不自由して居ないんんだけど。
950 名前:デフォルトの名無しさん [2007/11/16(金) 02:07:49 ] >>949 俺は、COBOLの表面くらいしか知らないし、言語にはそれぞれ 適した分野があると思う。用途さえ間違えなければ。 過不足ないということは大事。 そこをあえて質問してみたいのだけどさ、COBOL以外の言語の この機能があれば、もっと便利なのに!って思うことは、 あります?
951 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 07:08:55 ] >COBOLってそんなに悪い言語かなあ? >この考えが時代遅れか? とりあえず現代においてはそんなにいい言語ではないな。 たとえばCOBOLで実現可能なバッチ処理なんかは SQLで組めば1/10の期間で作成可能だし。 そして強烈な排他制御やらスレッドなプログラミングは 辛すぎる。つかそんなのCOBOLでやらんけどな。 100万人がどーとかはマシンパワーの問題なので言語は関係ない。
952 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 07:47:03 ] >>950 やはり、文字列の解析がし易くなるような、文法上の 基礎が欲しいですね。
953 名前:デフォルトの名無しさん [2007/11/16(金) 11:32:39 ] >>949 地球シミュレータが廃止される、というニュースが報道されてたよね。 汎用機より、クラスタの時代じゃない?
954 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 11:38:12 ] >>934 >930はアセンブリを対照としてあげてるんだから命令というか制御の抽象化を書いているんだと思うよ。 >927がオブジェクト指向言語上の話をしているって前提がどこにもないから抽象化の語意が多岐にわたっちゃっていて、前提条件が無い状態では一概に抽象化といってもデータの抽象化のこととは限らないんだから思考まで抽象化するなってことでしょ。 >930の頑な過ぎのところはどうかと思うが、仕事を頼むなら手戻りがなさそうだから期間は短くなりそうだな。要件定義のワークショップはやたら長そうだけどw それから、俺もCOBOLはすごくいいとは言わないけど悪い言語ではないと思うな。よく枯れていて安定してるし、最近の言語よりも英語ライクだからファイル読んで加工してファイル吐き出すとかの簡単なものならプログラムを知らない人でも読めるしね。 そこにある環境で求められているもの実現することがプログラム言語を扱う者の役割なんだから、過剰に言語をえり好みするのは自分のスキルに自信がないか向上心がないかだね。つまりはCOBOLerと同族ってこと。
955 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 16:44:41 ] やんわり口調でズバリ言ったwww
956 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 20:22:58 ] 普通にCOBOLを評価するなら、極自然に悪い言語だとおもうけどな。 コレ悪くないと評価するならば、他の多くの言語は神レベルだし。w 英語ライクつっても、そのお陰でステップ数は他の言語に比べれば膨らむし 変数スコープの概念がアレなので、プログラムの見通しは悪い。 そしてCOPY句とかでソースがやたら分散してたりすると、ソースの解読が かなりマンドクサイ。 別に昔から動いているシステムでそれの保守の仕事ならそれでいいけど、 新規案件でメインの開発COBOLとかヌカすアフォがいるからなぁ。
957 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 21:33:30 ] おれは、COBOLは「悪い言語」というと、少し表現がキツいと思うが、まぁ嫌いだな。 あまりにも、COBOLばかりやらされ過ぎて「嫌いにさせられた」のかも知れん。 >>956 普通に新規で使ってたぜ。 UNIX上で動いているOracleDBからWebブラウザに表示するデータを抜くのにCOBOL。 途中にJAVAが挟まってるんだけど、直接Oracleに触るのはCOBOL(Pro*COBOL)。 その方が速いからという理由だった。実測値を示された訳じゃないんだが、ほんとに変わるのかなぁ? ほとんどデータを右から左に受け流すだけなんだけど。(一応、規定の電文形式とやらに整形してはいたけど)
958 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 21:43:04 ] それは、たぶん嘘w 一日に1回しか起動しないようなバッチ処理だとCOBOLと言うか OSネイティブコードなアプリの方が速いだろうけど、 トランザクションがドカドカ走る状況になると、servletの方が速い。 と言うか商用のJavaのAP鯖だと、コネクションプーリングやら キャッシュとかがRDBとの関連技術がウマーな感じで働くから。 後はEclipseの様なIDEとJavaやWeb関連の開発&テストツールが 豊富なので、トータルコストで考えるとCOBOLをWeb関連で使うのは ほとんどお勧めしない。
959 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 22:09:20 ] >>954 >よく枯れていて安定してる この「安定」は、言語仕様が大幅に変わることはない。という事を言ってるのかな? (作ったプログラムの安定はプログラマの問題だからな) でもそれって、悪く言えば進歩がない。現状にアグラをかいている。COBOLerの体を表しているとも言える。 あるいはその言語には誰も期待していないことの現れカモ知れん。 せめて関数が自作できて(FORTRANの文関数みたいなのだけでも...) MOVE MYFUNC(ARG1, ARG2) TO A. みたいな書き方が出来れば、使いやすくなるんだけドナ。 ここまで書いた所でググったらCOBOL2002では「利用者定義の関数機能」あるみたいねw
960 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 22:41:44 ] だからProCOBOL+TPモニタ+UNIXが最強だって 埋め込みSQL使ってProC以上の生産性と可読性 TPモニタに乗せればプーリングもキャッシュも自由自在 コンパイルすればシェアードライブラリになるから高速動作 J2EEで実現している機能でこの組み合わせで実現できていないものはないよ だってそもそもAPサーバ自体TPモニタのJava版クローンなんだからサ
961 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 22:52:36 ] >だってそもそもAPサーバ自体TPモニタのJava版クローンなんだからサ 釣りかマジレスか知らんが勘違いもここまでくると感動モノだな。 じゃあ、DB2だったらどうすんだヨ?って言ってみるテスト。
962 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 22:53:30 ] 関数は嫌だなあ。 文と一体化してしまうから、ある意味言語仕様の 拡張をしてるみたいなもんだろ? サブルーチンはサブルーチンらしく、PERFORMか GOTOの配下に置くべきだと思うなあ。
963 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 23:21:55 ] APサーバがTPモニタの機能をそのまま実装しているのは 常識だと思うのだが。。。 コネクションプーリングやライブラリキャッシュなどの 機能は全部TPモニタの思想を受け継いでいるだけであって APサーバ固有の機能ではないし。 だいたいAPサーバもTPモニタもミドルウエアの総称なのに、 なぜDB2という製品名が持ち出されるのかすげー謎。 まさかTPモニタはOracleしか使えないとでも思ってるのか(藁
964 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 23:26:45 ] 963がどんどん哀れになってきました。
965 名前:デフォルトの名無しさん [2007/11/16(金) 23:27:22 ] 完全にスレチだが、アプリケーションサーバが強いベンダーは もともとTPMonitorで稼いでいたところが多いよね。 その頃の思想をアプリケーションサーバに受け継がせている。 IBMはCICS→WebSphere、BEAはTuxedo→WebLogic、 ついでに日立はTP1→TPBroker→Cosminexusなど、
966 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 23:27:58 ] じゃあ、DB2だったらどうすんだヨ?って言ってみるテスト。 じゃあ、DB2だったらどうすんだヨ?って言ってみるテスト。 じゃあ、DB2だったらどうすんだヨ?って言ってみるテスト。 >>961 よ・・・
967 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 23:28:25 ] 自分が世界の中心を思い込みたいだけだろ。放置汁
968 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 23:29:03 ] クローンかどうかは知らんが、960の上5行がCOBOLで実現できるなら Java厨が得意になって語っているメリットってあまりないなあ
969 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 23:37:02 ] つか、COBOLの場合だと宣言部だけで5行以上消費すると思うが。 まあ、○○を使えば、って事いいだすとそんなのなんでもアリになる罠。 VB.NET最強論と大差ない。
970 名前:デフォルトの名無しさん [2007/11/16(金) 23:52:58 ] 言語の話と製品の話とプラットフォームの話がごっちゃになるから 訳分からなくなるんだよ。言語スレで汎用機批判されてもなあって感じ。 だいたいここは対決スレじゃないんだから、次スレでは純粋に 言語についてのみ語りたいなあ。
971 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 08:36:56 ] えっ、次スレあるの? w
972 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 08:52:47 ] 個人的にはCOBOLが安定性云々って汎用機(IMS)が前提にしても怪しいよな。 ウチの職場な感覚だとCOBOLが言語的に枯れているのは事実だろうけど、 10年以上前のシステムを使い続けていて、誰も全仕様を把握してない 状況だから障害のない日が珍しい。って状態だったり。w ぶっちゃけiSeriesにWebSphereの組み合わせで運用が適度に保守している システムの方がCOBOLよりも生産性&保守性&安定性において 全て勝っている。 最大の問題はマイナーOSを使えるエンジニアがエスパー並に少ない事だが。w 様は使いどころと使う人間って結論なんだろうが、ウチは上がアレな性か今の現状は 安定命→汎用機+COBOL→けどシステムグダグダ→よく落ちる どーでもいい情報・分析系→適当なAP+DB鯖+Java→使いやすい→超安定 とかなり皮肉な結果となっている。
973 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 11:16:12 ] メインフレームでTSSからJCL視認・手実行で COBOLアプリを動かす。 これほど簡単で安定した運用環境はこの世に存在しない。
974 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 12:19:20 ] 君だけを見ていた コボルそうな笑顔 初めて見つけた時から 君だけを見ていた ずっと側にいるよ 飾らない心で
975 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 12:21:39 ] COBOLだけを見ていた 寂しげな横顔 初めて見つけた時から COBOLだけを見ていた まっすぐな瞳と 飾らない心で
976 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 13:13:41 ] それにしても相変わらず「普通に・・極自然に」って訳の分からない日本語を 使うヤツが自分の価値観を振りかざすのはなんでなんだ? 自分の嫌いなものは悪というシンプルなルーチンしか持ち合わせてないのか? COBOL擁護派は"一般的"に多くのシステムで稼働を続けているとか "多くの"金融機関の基幹系はCOBOLだとか定型句を言い続けてるだけで、 完全否定派は"個人的に"とか根拠のない"普通に"の後に自分の感想文を 付けているだけなんだよな どうせ両派共に当てはまるようなヤツはプラットフォームの選定や決定にかかわる ような仕事には携わらせて貰えないんだから、自分の好きな言語だけを使えれば 困らない職場にシッポ降ってついて行けばいいじゃん 見苦しい
977 名前:デフォルトの名無しさん [2007/11/17(土) 13:52:32 ] >>976 はいはい、おまえも価値観丸出しなんだけどw 恩をあだで返すタイプだな お世話になってる人の悪口をいう奴。
978 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 14:04:17 ] 価値のない見本が釣れましたww
979 名前:デフォルトの名無しさん [2007/11/17(土) 14:16:46 ] 難しいことを言っても始まらん。あまりに稼働中のシステムが多いから、 「学名に死語であるラテン語を使っていることを変えられない。」 のと同じことじゃないのか? Argol由来の言語はほぼ共通の形式で大差がない。 最後は特殊・実験プログラミング用の言語とCOBOLが残るぐらいだな。
980 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 14:24:27 ] >>977 >976が卑下してるようなタイプの人間に恩を感じてる人がいるなら、君も将来、いやたぶん既に恩を着せてるつもりの奴に見下されてるよ。 ガンバレ せ・ん・ぱ・い♪
981 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 16:12:54 ] うひゃ 釣れまくりだなw
982 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 16:50:15 ] コボルスレのくせに下手な言語スレよりレス伸びてんなw
983 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 18:55:12 ] 言語は終わってるけど俺たちのスレは始まったばかり!
984 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 21:59:19 ] 最初からクライマックスな言語なだけあるなw
985 名前:デフォルトの名無しさん [2007/11/17(土) 22:12:35 ] 次のスレタイはなにかな
986 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 22:57:28 ] オブジェクト指向が行き詰まり C++やJavaが改変の果てにグダグダ言語になって 世界はやがてシンプルなCOBOLへ還る… そんな日がきっと来ると思うんだ。 だからCOBOLの技術を磨き、資料を作って 次代へ継承しようよ。
987 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 23:04:30 ] たまっしぃーのルフーラン
988 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 23:06:47 ] 極論COBOLerがうざいなら存在価値を薄めてやりゃいい。 進化はほぼ止まったような言語なんだから、現状のCOBOLを覚えちまえば COBOLのシステムを抱えている企業でも事足りる。 COBOLerは年寄りが多い分無駄に高給だから需要あるぞ。 もちろん適用業務の知識を持っていることが条件だけどな。 最近の若い奴らって仕様書通りにはどうにか作るけど稼働させる現場のことを 全く勉強しないんだよ。一生プログラマで食ってくつもりなのかね? それがCOBOLerの入口だと気づいてるんかいな?
989 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 23:31:45 ] 使ってる言語の優劣なんて問題じゃないのよ。 経験そのものに価値があるんだから。
990 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 23:35:11 ] プログラマーの経験なんて何の役に立つんだか。 SEやらPMの経験ならともかく。
991 名前:デフォルトの名無しさん mailto:sage [2007/11/18(日) 00:11:54 ] >>990 意味ワカンネ。 プログラマーの経験は次のプログラミングに 役立つに決まってるじゃねえか。 一つ仕事をするたびにそのソースを体に取り込んで 成長する、それがプログラマのあるべき姿だ。
992 名前:デフォルトの名無しさん mailto:sage [2007/11/18(日) 00:42:40 ] とりあえず次スレではCOBOLerの要件定義からはじめようか
993 名前:デフォルトの名無しさん mailto:sage [2007/11/18(日) 00:49:51 ] >>986 黄ばんだドキュメントなら腐るほどあるけど・・・ 次代云々前に今すぐ窓から投げ捨てたい。
994 名前:デフォルトの名無しさん [2007/11/18(日) 00:50:58 ] COBOLのシステムについてはいろいろな意見はあるようだが COBOLerイラネってのは異論が無さそうだな
995 名前:デフォルトの名無しさん [2007/11/18(日) 01:33:36 ] 1000でアベンド発生
996 名前:デフォルトの名無しさん mailto:sage [2007/11/18(日) 07:27:39 ] >一つ仕事をするたびにそのソースを体に取り込んで >成長する、それがプログラマのあるべき姿だ。 COBOLのプログラマを見ていると10年以上 同じ事の繰り返しで10年近く同じデスマやら障害を 繰り返している進歩のない連中が90%ってノリについて。
997 名前:デフォルトの名無しさん [2007/11/18(日) 12:15:08 ] バッチとオンラインの違いはプログラムを見てどのように 判断すればいいのでしょうか? 明日から現場に配属されます・・・