【IT】「COBOLは現役バリバリ」、東京海上日動がシステム全面再構築でCOBOLを選んだワケ　開発者向けセミナー「XDev2008」 [08/09/08]

（1/2）

　「COBOLは現役バリバリだ。“COBOLは化石”などと口にするのはITとエンタープライズ
システムが何たるかをわかっていない証拠」。東京海上日動システムズの稲葉茂 取締役
抜本改革推進第1本部長（写真）は“不当な”評価にさらされるCOBOLの評価をこう正した。
稲葉取締役は2008年9月4，5日に開催した開発者向けセミナー「XDev2008」で「基幹系イ
ンフラを支え続けるCOBOL 〜東京海上日動の抜本改革〜」と題して講演した。

　稲葉取締役がこうした熱いエールを送るのには理由がある。東京海上日動火災が25年
ぶりに取り組むシステム全面再構築である「抜本改革」プロジェクトでは，開発言語を多面
的に評価した結果，新システムでもCOBOLをビジネスロジックの開発言語として再び採用
したためだ。2008年5月に，3年7カ月前に着手した第1次フェーズが終了し，自動車保険シ
ステムが新たに生まれ変わった。300億円，3万人月強を投じている。

　抜本改革プロジェクトにおける開発言語の評価軸は，開発技術の動向といった「外部環
境」，同社のスキルや技術文化などの「内部環境」，抜本プロジェクトにおける「プロジェクト
要件」と「システム構造」の四つだ。外部環境で言えば「30年システムに携わっているが，
COBOLは規格として長期間安定し，ビジネスロジックの書きやすさにおいては右に出る言
語はない」と判断したという。

　内部環境を一言で表現するため，稲葉取締役は「開発1年・保守10年」と東京海上日動
内で伝統的に伝わる「戒めの言葉」（稲葉取締役）を引いた。「システムは開発して終わり
ではない，いかにそれを高い効率と信頼性を保って保守していくかが欠かせない」（同）。

　このため同社は部品化とシステム構成のシンプル化に最も重きを置く。「COBOLはそれ
を最も実現しやすいと実証している。なぜなら5つのロジックと10の命令文で当社は30年
間システムを保守できているからだ。実際，新システムでは旧システムから2000本のプロ
グラムを部品として有効活用できた」（同）。言語自体のシンプルさは習得スピードの速さ
につながり，人材育成にも有効だったという。

（>>2 以降に続きます）
―――――――――――――――――――――――――――――――――――――
ソース：日経コンピュータ
http://itpro.nikkeibp.co.jp/article/NEWS/20080906/314277/

写真：東京海上日動システムズの稲葉茂 取締役 抜本改革推進第1本部長
http://itpro.nikkeibp.co.jp/article/NEWS/20080906/314277/ph1.jpg

（2/2）

　プロジェクトの要件では，「プログラミングと単体テストを5カ月で終了しなければいけない
スケジュールを乗り切るには，これまでのノウハウや人材を生かしきらなければならない
と判断した」という。システム全面再構築のため，アーキテクチャ設計や要件定義，テスト
工程に多くの時間を割く必要があった。

　最後の「システム構造」が「COBOL採用のもっとも大きな決め手になった」という。今回
の新しい自動車保険システムは，処理量や信頼性，既存システムとの連携面からメイン
フレームで稼働させ，ソフトウエアのアーキテクチャにはデファクト・スタンダードである
MVCモデルを採用することが当初から決まっていた。「ビューは若手を中心にJavaで，
モデルはベテラン中心にCOBOLで開発していくという分担ができた」（稲葉取締役）。

　「25年の間，システムの利用範囲は外に外にと広がっていった。そのたびに改修を加え，
システムは本館の横に別館を建て増し，それを渡り廊下でつなぐような複雑な構造になっ
た。保険商品も保険料の支払い方法もどんどん増え，それに伴いシステムは複雑さを増
した」という。ビジネス面でこれらをお客様目線で見直し，シンプルにわかりやすくするのが，
今回の抜本改革だ。

　稲葉取締役は「システムが複雑になったのはビジネスが複雑になったため」とぴしゃりと
言う。「システムトラブルの原因を“COBOLを使っているからだ”などと話す人や“COBOLは
化石”などと話している人を見ると，ビジネスに携わる技術者として見識を疑う。COBOLの
将来はまだまだ明るい」と講演を締めた。

（以上）

COBOLしか知らないだけじゃねぇの？

勉強しろよ（笑）

CAFI 自体が COBOL の設計だからなー。
OO だとは言い張ってるが、精々正規化指向というかデータ指向というか。

つうか 2000 年頃に業火に焼かれたのはなかったことになったわけ?ｗ

>>3は逆にCOBOL知ってるのか？
俺はCOBOLもそれ以外もそこそこ知ってるが、>>1の取締役
の主張は、これはこれで見識だと思うよ。

>>3
COBOLだけ知ってりゃシステムできんだったら、一番効率がいい（投資効果が高い）
第一、言語を勉強することが、システム開発の勉強じゃねーだろ

(笑)　>>3

コボラーの仕事を無理矢理捻出してるようにしか見えない
これ以上メンテ要因増えないのにどうするんだよ

>>6
自社内に COBOL 村でも作ってるならともかく、今時 SI で COBOL 開発なんて
要員集まらないから効率悪くて仕方がないんだが。

ところで SI って知ってる?

訂正：「“COBOLは現役バリバリだ”などと口にするのはITとエンタープライズ
システムが何たるかをわかっていない証拠」

今時はWEBアプリで構築してクライアント側の費用を抑えたいもんだと思うんだが、まさかダム端？
いや、COBOLでWEBアプリも作れっけどさ。
定義体を使って、ファイル読み込みと同時に変数化する技以外にCOBOLのアドバンテージが見えん。

世界で稼働してるメインフレームのうち、半数以上が日本にあるんだってさ
それだけ日本と世界の潮流がずれてるってことだと思う

まあＣＯＢＯＬが一番バグ叩き出し易いからな

COBOLなんて、ストアドプロシージャーの寄せ集めみたいな言語じゃない。
設計が頻繁に替わらない様な環境なら良いけど、

スケールメリットを生かして行く、現代の現場じゃ先ず使わないだろう。

>>11
ビジネスロジック側の話だよ。ビジネスロジックだけなら構造化言語で十分。
フレームワーク化可能な範囲が少なくゴリゴリ書く以外に方法がない領域だから。

ここは単に実権握ってるアーキテクトが COBOL 頭なだけだが。

プログラムについてはエクセルのマクロぐらいしかできない俺が言うのもなんだが、

この人の発想は、昔からの日本にある人材囲い込みという考え方が軸になってんだろうな。
プログラマーは自分の会社で育て、最期まで面倒を見ると。
流動性のある社会なんて知らんよ。と

実際のとこ一長一短なんだろうね。
この会社でしか生きられない人材をつくることは害悪かどうか、ということ。
もちろんＣＯＢＯＬがしっかり理解できれば、他の言語も覚えるのは難しくはないのだろうが
現実的に多くのプログラマーはこの会社にしがみつくことになるだろうしね。

いきつくところ奴隷は幸せか。ということなんだろうけど。

この言葉を聴いて顧客はどう思うかな？www

全面再構築する気が無いからＣＯＢＯＬ選んだんだろ

レガシー全部捨てるんなら、ランニングコストの安い分散系システムで作り直すだろ

適材適所だよCOBOLのバッチ処理をACOSで動かすのが一番良い業務もある
何でもかんでも一つの処理系でやろうとするのが間違い

レガシーでロックインしてると、最終的にはメンテや運用コストに跳ね返ってくるから
何も好きこのんで最新技術に飛びついてるわけじゃない

専門学校出て１４年間やってたＰＧ．ＳＥを３４歳で辞めて１０年！

もしかして４４歳になった俺もまたＰＧ．ＳＥ復帰できるのだろうか？

多分社長がコボラーなんやろうな。
エンタープライズを分かってないとか
何も言われてないうちから喧嘩腰である時点で
主観で無理矢理コボルにした負い目の心理が見えるよな

社員は転職力が無くなるからモチベーションダウン。
外注は希少性をたてに値上げ要求

ビジネスロジックなんてその業務に精通してる人が書いた方が
いいものができるということじゃないの

最近のプログラミング技術に精通してても業務がわからない人が
書いたらとんでもないものができるということなんじゃないの？

結局COBOLだけは残るんだろうなあ。
確かに事務計算では、わかりやすいし、効率もいい。
　

まぁ、それはそれでいいんじゃないの？
ずーっと続いてるもんなんでしょ。

>>20
それわかるんだが、リスク評価材料のうちの、「手慣れた言語の効率性」という点の評価が高すぎるんじゃね？
という話。




COBOL：豆腐屋のハチロク
P言語：バットカー（ティム・バートン版）

なんかこんなイメージ。

でかいところで常にビジネスロジックの書き換えがあるところなら
COBOLのほうが、というより昔から使ってる一つのものだけ使用するほうが
効率がいいのは確か

それだけの話

うわぁぁ、わが社の基幹システムもCOBOLだよ。

ずっとNECのでっかいマシン（ACOS)が鎮座してたけど、
2回目のハード更新で、とうとうx86系サーバになってちいさくなった。
相変わらずCOBOLだけど。

COBOLE仕事ください＞＜

コボル
パスカル
フォートラン

言語なんて適材適所なんだし、事務系なんて100年たってもやることは一緒だろ
まぁ、今ならオープン系の環境もあるし、バックエンドとの連携も困らん
しかし、さわりだけでも知ってないと端から選択肢にはいらんわな

いっそADAで設計しろ．

(ﾟ_ﾟ)ポケコンを思い出した。

事務計算でモデルをCOBOLでっつうのは最強じゃろ

いいんじゃないの！
韓国語より・・・・

>>9
それ程度の低い会社だな

開発費に大金を要求するくせに３次４次請けの糞PGに丸投げして
バグだらけのシステムを作るITベンダを選ぶなんて馬鹿馬鹿しいんだろう

COBOLならパソコンしか扱えない素人でもすぐ扱えるようになるし
なにより保守改修が自前でできる
外部委託だと１画面１項目直すのに１００万円とか要求されるｗ
この社長はITの何たるかをよく分かってるな

＞「ビューは若手を中心にJavaで，
＞モデルはベテラン中心にCOBOLで開発していくという分担ができた」（稲葉取締役）。

要するに、年寄り連中が新しい言語を習得できなかっただけだろｗ
今はそういう連中を使って開発すればいいが、１０年後、２０年後はどうするんだ？
市場からＣＯＢＯＬ人材を獲得しようとすると、ものすごくコストがかかることになる。

BASICも使ってあげてくださいｗ

画面はVB、中身はコボルでいいよ別に。
JAVA使ったwebのアプリケーションなんか逆に使いにくくなってる。

新幹線制御をC#でやるという英断を下したJR束という恐ろしい存在も
あるというのに、東京海上ったらまったく…。

>>40
Win端末構成ならそれ最強だな

COBOL懐かしいね。
要はシンプルさと今までの財産が活用できるので、
短期間で開発できるのと、保守がしやすいということか。

そら、COBOL選ぶわな。

コボラーは絶滅危惧種だが、現在のコボラーは生活自体は安泰。

コボラーの友人が言ってたなぁ。

>>38
構造化言語なんて基本がわかればどれも似たようなもんだから、
簿記の資格持った若手を見つけてくる方が重要

別にCOBOLを使ってもいいと思うが、優位性をアピールするのはやりすぎだろう

また、カード型データベースでスパケッティソースに悩むのね。
リレーショナルデータベースを捨てると。

>>47
COBOLでもRDB使えるよ

VisualCOBOLとか売ってるのか？

> これまでのノウハウや人材を生かしきらなければならないと判断した」という

これが全ての理由だね。

>>48
今更、SQL捨てる事なんて出来んだろ。
フレームワークは既に完成してるのに。

グレース・ホッパー女史もあの世で喜んでるよ。

>>49
Visualにする意味がわからん
見やすいデバッグ機能でも欲しいのか？

たぶんソースはCOBOLだか
はきだすのはC+な悪寒

新商品、新サービスを考えられない、
経営サイドの逃げに過ぎない。

既に4次産業は完成し稼動してるんだから。

>>49
ユーザインターフェース部分はJavaで作ったWebアプリなんだろうな

部品化とシンプル化という方針ならＣ言語だろうけど、
プログラマーが反対したんだろうな。

>>41
そーすください＞＜

オブジェクト指向は部品化をしやすいように作られてるのに手続き型言語にこだわる理由は
今までの人材活用と過去の資産活用というところかな

単にC言語とかの新しい言語は、金融系のシステム開発で役に立たない欠陥が多いだけ。

逆に事務系統では、ＣＯＢＯＬべースのシステムが、現役かつ信頼性のあるシステムと言われる。

PERFORM MAE-SHYORI
PERFORM NAKA-SHYORI
PERFORM ATO-SHYORI

昔見たのはこんな感じのばっかだったんだが、今もそうなんかね？

>>60
C++は比較的新しいけどC言語は古いしただの手続き型言語
C++とCをごっちゃにしてる人多いなここ

IT屋の予算消化対策

将来の日本で不足するCOBOLのメンテ要員を
一企業が確保し育て上げる遠大な計画だそうだ

別に選択するなら選択すればいいけど
言い訳がましい口調はﾑｶﾂｸな

なんかCOBOLという言葉にみんな過剰反応している気がするが、
>>1を読む限りは十分すぎるほどの検討をした結果、一番利益が挙がる
選択肢がCOBOLだったという結論なんだろ？
正直、言語なんてシステム別に選択されるものなんだから、経営判断としては
まったくもって不思議ではないと思う。

メンテできる人間がいなくなるとか言われて久しいけど、COBOLぐらいCとか
読める人間なら予備知識無しでも読めるだろ。まったく問題にならない。

15年前すでにCOBOLのおばちゃま、とか言われていたからな。

COBOLって古くね？
今はC、Java、VBだろ

俺　古臭い人間だけどCOBOLは分かりやすいと思う

よく3万人月もリソース集められたな。
こっちはｺﾎﾞﾗｰがいなくてバッチすら一部JAVAで開発しだしてるのに。

現行システムの仕様書も要件定義書も残ってないんだから、
ＰＧＭ解析して新案件組み込むしかない。
だったらcobolでやるしかないよね。

javaとcoboj両方できる人をたった5か月だけ大量に集めて
システム全部新規で作り直すなんてムリなんだから。

それに保険系の業務に精通しているのが大事で、java使えるだけで
自尊心振りかざしてる言語オタクのなんてお呼びじゃないんだよ。

よくわからないからカレーに例えてくれないか？

javaを勧める奴多いが覚えること多すぎて、PG同士でつぶし合うことになる

今後もこの流れ続くだろうな
別にレガシー資産の再利用だろうが基幹業務システムってやる事かわらんから

プログラム２千本を再活用できたと言っているから、
これが１０％だとすると、全体本数は２万本くらいかな。
３００億３万人月を費やしたと、言っているが、これは高すぎる。
１桁ボッタクリにあったようだな。
まさか、社会保険庁に出入りしているベンダーを使ったのかな？
だったら請求書は１桁多くなるな。

プログラミングわからない人にプログラミング言語をマスターさせて
実際にプログラム組めるようにするにはJavaよりもCOBOLの方が楽だよね

コボラー復活！！

後のスカイネットである

COBOLは勘定系
うそくさ

コボル徒が息を吹き返したと聞いて

>>12
世界一メインフレーム使ってるのって米軍じゃないの？

>>1
C言語で経理のプログラムは書きたくねぇなぁ。
経理系はCOBOLでいいんじゃね？

「COBOLでいい」ではなく「COBOLがいい」　これ重要

>>82
Cはないだろ
今はJavaで書くのが主流なんじゃないの？

仕事にあぶれかけの技術者を安く使いたいんですね分かります

携帯と同じく
日本ITのガラパゴス化が進行してるわけね。
IBMがコボルでシステム作ってるの？

団塊の再雇用先ゲットだぜ

今の流行なんて関係なく検討した結果がCOBOLなんだろ。
技術者を何人集められるか、この後どうするかも含めた判断なんだろ？

流行だからとベンダの提案を丸呑みにして、テスト工程のノウハウもなく、
いざ本番で動かんシステムをつかまされる経営者なんかよりよっぽどマシだろ。

で、この会社は配当金払ってるの？

COBOL以降の開発方法論を否定したんだね、
それはそれでありだと思う。

開発言語なんてぶっちゃけ飾り、
問題はどう開発を進めるかだから・・・。

COBOLスレが妙に盛り上がっててﾜﾛﾀ

手書きの方が誠意が伝わると言ってた上司が居たけど

>>88
そんな石橋を叩いて渡る経営者居るわけ無い。

Javaも今の流行というほど新しくもないけどね
こういう分野でJavaが使われるようになって10年くらいたつんじゃないの

ちゃんと動いてるなら良いけど、
新人研修後にフルに配属されてた人間はちょっと可哀想な気もする。

N5200でCOBOL85書いてたｵｻｰﾝPG（現・NEET)が通りますよ･･･orz

過去の資産使っても300億円ってどんだけぼられてるん？

＞「システムトラブルの原因を“COBOLを使っているからだ”などと話す人や“COBOLは
＞化石”などと話している人を見ると，ビジネスに携わる技術者として見識を疑う。COBOLの
＞将来はまだまだ明るい」

（　ﾟдﾟ）

>>9
歌える島

コボラーってCOBOLを否定されていると勘違いすると青筋立ててまくし立てるよね。
別にCOBOLを否定していないのに、すごい剣幕で唾を飛ばしてが成り立てる。
医師会の集まりでおごちとかいう奴を見て引いた。ORCAは絶対に失敗すると確信した。

過去のシステムとの互換性を重視する場合なら、COBOLも否定しない。

でも今から作るなら、最低限オブジェクト指向の言語の方が良いと思うけど…

>>100
そいつ頭おかしい人だからｗ

キーパンチャーも必要ですね

COBRA〜、ふんふんふん　ふ〜ん♪

「IT技術の進歩」で稼ぐビジネスモデルの嘘が

ば　れ　た

最小公倍数をとっただけな気がするが。

どうせ保険屋のシステムに
開発効率なんて問われないもんな。
保険金払い渋りで溜め込んだ金が腐るほどあるからな。

地球人の故郷

2003年出版の書籍『13歳のハローワーク』(村上龍)では「COBOLは過去の言語で、修正できるプログラマは皆死んでしまった」という趣旨の記載がされた。

ｗｗｗｗｗｗｗｗｗｗｗｗ

昔、Wizardryとかで倒したなぁ

win95が出てCOBOLは使わなくなったな。
もうC言語は読めないけどCOBOLとFORTRANならまだできると思う。

COBOLｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ




　

総責任者の頭が固すぎるだけじゃね

読売新聞でコボルちゃんは現役連載中

>>102
おごちさん（漢字がわからないｗ）って評判わるいよね。どうして。

10進使ってでかい数値計算するなら、COBOLとかPL/Iが良いに決まってる
ああしか書けないから保守がしやすいってのも良くわかる
このご時世にCOBOLを選択出来るのは寧ろ頭が柔らかいんだと思うがな

早くMSを超えるOS作れよ

Intelのサイトで次期Fortranコンパイラのベータテストが始まっている。
Fortran2003の規格も結構インプリメントされた。
まだオブジェクト指向の部分は完全ではないが。

誰でも落とせるのでGo！

>>118
それってスパコン用だからな。Larrabeeリリースされたんで、それに合わせたんだろう

他人事だけど.....
ここまで方針を固めてくれりゃあ、やりやすそうだ。

BASICが王様だと思ってる。

COBOLとFORTRANは100年後でも残ってるよ。

まあ、自分で使うシステムを、自分の金で作るなら、
化石のような言語で書いても、いいんじゃね。

ＯＯと言っても、使いこなせている奴なんて何割もいないし。

責任もって人材を育てるなら良いけど
新卒に即戦力を求めたり、実装は外注だったりしないよな？

ＳＥ辞めて８年になるが、当時ですらCOBOLはもう終わると言われてC++で書いたものだが。
そうかそうか。俺の寂びたコボラーとしての技がもう一度逝かせるのかｗ

>>116
＞ああしか書けないから保守がしやすいってのも良くわかる
結局、いまさらCOBOLを選択するって、これに尽きるよな。

この理屈でいけば、インターネットより狼煙のほうが、通信手段として優秀という
理屈も通る。

まあ、経営者が保守的な技術を選択するのはありだが、技術者がこれを支持したら、
技術者として失格だな。

>126
たとえがひでえな
目的を達成するなら効率がいい方を選ぶってだけの話だろ
狼煙だって限定条件下では有効だし

逆になぜＣＯＢＯＬだけ目の敵にするのか。
俺にはそっちの方がわからん。

>>1
…いや、まぁ、ひらがなだけでもしょうせつはかけるよな。
しゅっぱんしゃがきょうようすれば、さっかさんはかくだろうけどさ。

>>127
COBOLだけっつーか、特定の言語にこだわっている技術者がウザイだけ。

システムの要件によって、それぞれ最適な言語があるはずだし、
技術者はその要件に応えて、適切な言語でシステムを構築する義務が
あるはずなのに、それを放棄して特定の言語しか使おうとしない奴が
目の敵にされるんだろ。

別に、東京海上日動が、COBOLでシステムを作るのは勝手だし、
その判断に云々言うつもりはないが、それに乗じて、COBOLをやたらと
持ち上げる奴らがウザイだけ。

常識的に考えれば、例外はあるにせよ、後発の言語の方が優れているのは
間違いないのに。

>>126
しかし最新技術を支持して失敗するプロジェクトの数は半端ない。
年季のいった技術者ならば枯れた技術が一番だという考えも理解できる。

>>130
だから、それは経営者が判断するレベルの話なんだよ。

少なくとも現状に対して何らかの改善を図ったはずの新技術や新言語から目を反らして、
古い技術に固執するのは、技術者として職務に誠実ではない。
特に、ITなんてまだまだ、発展途上の段階なのに。

>>129
＞常識的に考えれば、例外はあるにせよ、後発の言語の方が優れているのは
＞間違いないのに。

さすがにこれはダウトだろｗ

>>131
世間知らずのなんちゃってITコンサル並の言い方だな。
実務経験ある？

>129
>システムの要件によって、それぞれ最適な言語があるはずだし、
だから経理系においてはＣＯＢＯＬがそうなんでしょ？

>常識的に考えれば、例外はあるにせよ、後発の言語の方が優れているのは
>間違いないのに。
それを否定する気はないが、そもそも
ＣＯＢＯＬより効率のいい後継言語ってあるの？
なんでもできる言語が求められてるわけじゃなし、
正直、現在のプログラム手法が使えないってだけで
毛嫌いしてるようにしか見えないんだが。

COBOLの運用実績が高いってのは聞いたことあるな

昔はドキュメントがしっかりつくられていたから、ＣＯＢＯＬの方が資料が沢山あったのだろう。
なまじJavaなんかで作っても、ドキュメントをつくらない連中ばかりだと継続性が途切れる。
元の資料＋ソースの出力による解析でなんとかなるけど、無駄が多いのは確かだ。

>>129
常識的に考えれば、一番使われている言語の方が優れているのは間違いない。

簡単なのは間違いではないのだが、インターフェースの設計に難があるからなあ。
実際には、オッサンがプロジェクトリーダーでそれしか知らないというあたりだと思うが。

>>133
もうこの手の、ぬるま湯現場にいる奴らの遠吠えなら、もう聞き飽きたけどな。

>>136
それって、COBOLだからJavaだからってより、システムの規模や複雑さ、納期の方が
原因だと思うけどな。
今の規模のシステムを、全部ドキュメントに起こすとなったら、そもそもコストに
見合わねーだろ。

COBOLの価値知らん無知が騒いでるスレだな

俺はJavaとCしかまともに使いこなせないし、
もはや今は口だけコンサルだけど
10進計算専用アーキテクチャ上のCOBOLや
並列計算用のFORTRANの強みは認めてるぜ

>>139
なんだ
素人か
ｗ

懐かしい…。
20年近く前、入社前の宿題がコボちゃんだったなぁ。文系の自分は大変だった…。

>>115
おご“し”じゃなかったっけ。
どうしてもなにも、性格的なもんでしょ。ハッカー的気むずかしさというのか。

>>131
非常にいい視点だと思う。
COBOLから何を改善しようとして今の言語への移行が進んだを
考えてみるべき。
この移行は言語自体の生産性のためではなく、ダウンサイジング、
オープンシステムという流れの中で起こったもの。
このあたりを考慮すればCOBOLがまだ現役でいけるという判断は
十分ありだと俺は思うよ。

ＣＯＢＯＬの最大の利点は入出力に強いこと（かしらん？）
でも、現行Ｗｉｎｄｏｕｓサーバーのファイル管理では、ブロッキングが
出来ない（違ってたらゴメン）ので、ここら辺が問題だわな。

CユーザーがC++を否定する心境に共通するよな、狭い例えだけど

そりゃCは流れの通り作っていけばいいから、
なにも考えずに組めて楽だけどさ

>>142
ぷ。勝手にそう思っとけよ。

まあ、次々と新技術を取り入れて、より良いものを作ろうとするより、
みんなが知っている技術だけで、作れるシステムだけ作ろうという、
スタンスもアリだって言うのは、俺もわかるよ。

俺も、上のような現場で、同期を鬱で亡くしてるからな。

でも、下のようなスタンスは、あくまで妥協のスタンスであって、
それが正義のように唱える奴らがウザイだけだ。お前のようにな。
まあ、お前と現場で会うことは絶対ないだろうから、どうでもいいけど。

>>145
インターフェースの設計を除けば、勘定系には向いてるよ。

>>148
無駄な長文書くな。下記のだけで十分だろ

新技術は、現場を救う（笑）

社内にCOBOL技術者抱えてて、ちゃんと面倒見れるなら別に構わないんじゃないの？
最新技術が常に最良という回答ではないし、調査しての選択なら問題ないでしょ。

俺はＣＯＢＯＬ−Ｓしかできません・・・・orz

>>148
>次々と新技術を取り入れて、より良いものを作ろうとするより
最新技術だとより良いものだという思い込みが理解できん。
COBOLerにイジメられた過去でもあるのか？
勘定的過ぎるぞ？

>>153
別に、COBOL で動いてるシステムも、ソースコードも否定する気はないが、
本気でそう思ってるなら、もうオタクと話すことは何も無いわ。

「写真なんて誰が撮っても同じだろ」と思っている奴に、写真の技術の話を
しても意味が無いのと同じようなもんだしな。

>>151
鯖との連動性と、インターフェース設計。セキュリティ関係の組み込み。

この辺がクリアできると踏んでるなら、それほど奇妙な選択でもない。
ただ、ここがクリアできないから言語が移行していったわけで……。

>>150
７割くらいは混乱に陥れているように思えるがね

コボルってパソコンでも動くの？

>>155
それらの問題点は、決してクリアできないってわけでもないでしょ。
何らかのクリアにするツールなり何なりの方策があったんじゃないの？

>>154
なんだ説明できないのか。
だから周りから妄想って言われるんじゃねーの？ｗ

COBOLで何から何まで業務システムを作る時代は既に終わってるが、
だからと言って、COBOLを全面的に既に終わった言語と考えるのは間違い

この東京海上みたく、ビューやコントローラはJavaで、
モデルをCOBOLという戦略は有りだと思うぜ

JavaアーキテクトでCOBOL分かってる奴がいるのが必須条件だな

メンバメイコボルスミ11

>>157
http://www.microfocus.co.jp/

その他フリー物も探せばあり。

もちろんLinuxにもある。

>>158
鯖との連動性はCPUの計算タイミングとかそういうレベルの話なので、
COBOLだとややきつい。ハード的な対処がいる。

セキュリティは、しーぷらぷらとの組み合わせで何とかできるかな。
インターフェースは……。
まあ最低限のものは出来るから、使う人間の方のオペレーター教育の問題かもしれない。

>>146
一番良いのは、桁を明に意識させる所かな。
あと、ポインタやオブジェクトが無い(解放漏れが無いとも言うか？)所。


制御系のアプリケーションは書けないが、事務処理アプリケーションなら必要十分

用途に応じて使い分けるが一番。JavaやCでないと出来ないことをCOBOLでやる必要は無い。

>>160
オッサンにJavaを教え込むのか、
若手にCOBOLを教え込むのか。

そこが問題だ。
まあ、コボルとフォートランは情報工学系の高校、高専、大学で
今でもやってるから最低限の知識のある奴らは多いが。
本当に単位が取れたらそれでいいって教え方らしいからなあ。

おまいら、つっこむとこ間違えてるよ
COBOLにつっこんじゃだめ
ここが一番の問題だよ

>>　プロジェクトの要件では，「プログラミングと単体テストを5カ月で終了しなければいけない
>>スケジュールを乗り切るには，これまでのノウハウや人材を生かしきらなければならないと判断した」
>>という。

>>システム全面再構築のため，アーキテクチャ設計や要件定義，テスト
>>工程に多くの時間を割く必要があった。

COBOLから、OlacleやSQL ServerとかのＤＢにアクセスするADO、ODBCあるの？

>>165
>>2を見れば、
「ビューは若手を中心にJavaで，モデルはベテラン中心にCOBOLで開発していくという分担ができた」
とあるから、うまく棲み分けできてるんじゃないのかな。

>>166
よくあるデスマだろ。
人数を駆り集めようとしたけど集まらないので、老齢にさしかかったPGに頼るしかなかったという。

>>165
当然、ビューを設計する奴がモデル側の仕組みを理解すべき
おっさんは黙ってCOBOLで作ってれば良い

>>168
設計の段階から、両者の意見調整をする人間が居るんだよ。
上手く調整がいかないと、結局いつものデスマになる。

>>162
ありがとう。

実際、事務処理のところ、つまりファイル開いて加工して閉じるようなところは
全部コボルにしたら楽かな。

画面周りは大変だったからそこは　HTMLでやれば最強

コボルでもフォートランでもパスカルでもアセンブラでも何でもいいから
東京海上日動は頻発するシステムの不具合をさっさと直せや
代理店はデバッカーじゃねえぞ！

頭の片隅に
「コボル　アルゴル　フォートラン〜」と浮かぶんだが　アルゴルなんて言語有ったっけ?

UFJのシステム移行にかなりJavaや勘定系の人間が集中してるから、
東京海上日動のシステム開発に人が集まらなかったってオチだと思うんだがなあ。

それでオッサンPGを駆り集めてみたけど「COBOLしかできません」
しょうがないから、その状況で何とかするためにコンサルが知恵を出したんだろ。

ＪＣＬなつかしい、いまどき古いだろ。
ＶＢ６で十分作れるｗ

>>171
プログラマ全員が、インターフェースを意識しなきゃならんような開発にはしないだろ普通。

ルールを作って、プログラマに従わせる。
ルール作るものが、Java、Cobolに精通してればいいんじゃないの？

ALGOL？スペル忘れた

すみわけってやつだな。

新光のプロジェクトに参加した人間ならばわかる
このプロジェクトは神

>>177
学生か、現場を知らないコンサルかなんかかな？
言ってる事はその通りなんだが、それが通用しないのが現場なんだよねえ。

結局、両者の意思疎通が上手くいかなくて板ばさみになる人間が出るんだよ。
で、そのポジションの人間は基本的にスキルが高くて、人間性も良いヤツだから、
そいつが関係のない仕事に忙殺されるようになって開発スケジュール全体がきしんでいく。

というのが、だいたいのパターン。
だから、プロジェクトリーダーとかみんなやりたがらない。

つまり、,netでＣＯＢＯＬが動くようになれば良いんじゃね？

>>181
問題点が違うと思うんだけどなぁ。

>>165で
>>オッサンにJavaを教え込むのか、
>>若手にCOBOLを教え込むのか。

っとあったから、COBOL、Javaやる人間全員に、両者のスキルは求められていない
ってことを言いたかったんだけど、うまく伝わらなかったみたいだね。

なんか、このプロジェクトを随分と否定したいみたいだけど、恨みでもあるの？

はっけょぉ〜い　コボッタ!

やりたいことができて、信頼性があり、メンテがそこそこできればどれでもよいかと。
そういう意味では、Javaは失格。
仕様は変わるし、安定性が足りない。

>>183
うーん。やっぱり現場をあまり知らないみたいだね。

COBOL系のオッサンPGって、本当にCOBOLしかできないから
他の言語で開発中のモジュールとの連動性を考慮した設計を依頼しても
それが実現できないので勝手に作るんだよ。
で、設計の方を変えさせようとしてくる。

こぼらーのPGって課長以上で部長に手が届くぐらいの位置の年代だから、
力関係の問題でそっちの意見がおし通ったりするんですよ。

大手のコンサルが大好きな製造業的な工程管理が通用しないのね。
管理工学系の知識であれこれ言われても、現場の理屈は違いますよってヤツだ。

>>184
【審議中】
　　　 ∧,,∧　 ∧,,∧
　∧ (´・ω・) (・ω・｀) ∧∧
(　´・ω)　Ｕ) ( つと ﾉ(ω・｀ )
｜　Ｕ (　　´・) (・｀　　)　と ﾉ
　ｕ-ｕ （l 　　 ) (　　　ﾉu-ｕ
　　　　 `ｕ-ｕ'.　`ｕ-u'

エンタはWeb、Direct系。
工場の装置制御はＣ言語かPLCラダー。
汎用機の事務はCobolだろｗ

あきらかにメンテ大変だからｗ
中心人物が50以上のひとなんだろうなあ

>>186
>>COBOL系のオッサンPGって、本当にCOBOLしかできないから
>>他の言語で開発中のモジュールとの連動性を考慮した設計を依頼しても
>>それが実現できないので勝手に作るんだよ。

こういうのは、Javaを教え込んだところで、勝手なことするだろうよ。

要員に求められる、言語のスキルの問題と違うんじゃないの？

皮肉でもなんでもなく 純粋に「なつかしい」

(ﾟ_ﾟ)HyperTalkを思い出した。

走ってるシステム、企業で半ば仕組み化したものはＣＯＢＯＬで走り続けてる。
そういう意味では現役バリバリだけど、
全面再構築で今ＣＯＢＯＬを選択したのは、結局人材不足によるところが多いだろう。
ＣＯＢＯＬしか使えねぇジジィなんて山ほど居て、
帳簿をめくる管理職もインターフェース変わると使えまシェン。見たいな。人材不足なんだよ。

COBOLにせよJavaにせよ、バカの作ったsourceは所詮バカ。
同じシステムの中で3種類の閏年チェックがあり、おまけに全部バグっている某社のシステムは勘弁して欲しい…orz

>>194
これが究極だな。
馬鹿が多過ぎる。

http://video.google.com/videoplay?docid=-1396473546552842629&hl=ja
成長の代償　中国

システム再構築にコボルを選んだということが
ニュースになってしまうこと自体、コボルが
現役バリバリではないということを端的に示している。

10年とか20年見据えてシステム作ってるなら文句いわないけど、実際どうなんだろうね

ハードの保守契約の問題もあるから、あまり古い言語は使うべきではない。

日本語プログラム言語「なでしこ」に一票！

有り体にコボラーは火事場泥棒だがたまに焼死することもあるので注意。

へー、COBOLまだ使ってるんだ
これ、マシンに使われてる感じがしてイヤだったな
だから、AlgolとFortranと若干のアセンブラしか使ったことなかったな
大昔の話だけど

1を読むとCOBOLでいいんじゃね
うまくいってるのに外部のものが、それはおかしいなんて余計なお世話でしょ

それに外注によるトラブル排除という観点でも良いんじゃないでしょうか
どんなに良い言語でも保険商品とその管理方法を知らないと、それも大問題ですからね

\n忘れて、Coreダンプ作ったら怒られるぞｗ

会社Ａが１月〜６月までに上げた収益は６００万円
７月〜１２月に上げた収益は４００万円

会社Ａが挙げた収益、ひと月の平均を示すプログラムを

COBOL　Ｃ言語　ＪＡＶA　

それぞれで、示せ　そして決着をつけろ

>>174
ALGOLは、PASCALのお父さん。
FORTRANに駆除されたけど、PASCALとCが仕返しした。

いっそのこと、ＬＩＳＰで勘定系システムを組む兵は、出てこないのだろうか…

おれはいまでもN88BASIC

2chって低レベルSEしかいないんだよなぁ・・・・・
ホストの世界じゃCOBOLはまだまだ主役だよ。
PL/1からCOBOLに移行中のシステムも多い。
つか、分散環境の総コスト高が判明して、むしろホストへの回帰現象がおきてる。
ホストの中で、DB関連の処理をまとめてCOBOLで処理して、ゲストOS内でWeb処理して外部に発信・・・なんてケースはざら。

分散=安価って言葉は見識の低い証明だよー

人をバカにしたがる奴ばかり

間違いじゃないけど言語自体の進化が期待できないのが敬遠され始めた原因のはずだぞ。
安定性だけ求めるんだったら新しい言語なんてでてこないよ。

言語の設計からコンパイラの開発まで含めてずっとやっていくなら別にいいけど。

COBOLはDATA DIVISIONがひどすぎると思うが・・・

言語なんて２０年以上前からぜんぜん進歩してないからな〜
せいぜい「カキの種」が「わさび味」になったぐらいだな

>>209
仮想化もその流れの一端のような気がする。

COBOLは事務屋さんがちょちょいと自分の仕事を片付けるには
なかなか良く出来た言語だと思う
それが通信とかのシステム部分にも手を出そうとするからおかしくなるわけで

>>209
POL/1とか知ってるヤツ、日立だろ。
ASPENで、南砂の日経平均のバッチやってだろｗ

汎用機系のＰＬはあまり死なないけど、オープン系のＰＬは良く死ぬな
ＯＯだと変更に強いとかいうけど、何故かデスマーチが多い不思議
同期がどんどん倒れていった。設計が悪いんだろうけどね。

という漏れはAS/400でILE RPG
これ最強

若干ｽﾚﾁの気もするんですが、ヘタレLinuxerとしてお訊きしたいのですけど
PerlやらPHP、bsh、cshあたりの開発経験しかない場合、COBOLを
勉強したかったらTinyCOBOLとかopenCOBOLに手を出しておけばいいのでしょうか？

んでもロジックの部分は記述がめがっさカンタンそうで、むしろJCLとかCICSとか
ハードウェアリソースの管理の仕方こそじつはCOBOL開発の精髄の気が
するのですが、・・・やっぱ現場で覚えるしかないのでしょうか？

保守要員は最後まで飼い殺せよ。
間違っても世間に逃がすなよ。
COBOLマンセーは否定しないが自分の庭だけでやれよ。

変なのが外に出てくると迷惑なんだよ（´・ω・`）

日本企業東芝死亡確認！！！！！！！！！！！



SamsungによるSanDisk買収検討の背景、株価はこの1年で1/3以下に

韓国Samsung Electronics Co.，Ltd.が米SanDisk Corp.の買収を検討している件（Tech-On!記事1）
について，韓国のメディアが「Samsung社はJPMorgan Chase & Co.を引き受け会社に選定して
SanDisk社と交渉準備中」と報じている。このことから，
今回の買収交渉は今後，比較的短期間に決まる可能性もありそうだ。

業界内では最近，SanDisk社の買収にHDD大手の
米Seagate Technology LLCが興味を持っているといった噂が流れていた。
SanDiskの買収レースでは，Samsung社が頭一歩抜け出したかたちだ。
http://www.nikkeibp.co.jp/news/flash/584083.html

>>218
ホストのシステム開発とCOBOLを混同してるぞ。

Unix上のCOBOLは普通にシェルで動かせるし。
Cで読んだデータをCOBOLにパイプで送り込むなんてのもやった事がある
（緊急回避でやっただけであまりやりたくなかったが）

JCLは完全に機種（ホストつーかOS）依存だしCICSにいたっては
「IBMの環境」でしかない。

COBOLの強みは運用に入ってからさ！
デバッグの時間はJavaの1/5。　バグを発見してすぐにコード修正して、システム再立ち上げ完了まで
わずかに5分！！
システム復旧まで2分20秒・・・　こいつは速い！！

なんにしても20年以上も前に設計された言語だとは思えないよ！！
設計思想が一歩も二歩も先進した言語だ
今の時代になってようやく他の言語が肩を並べはじめたってわけさ

>>221
ﾚｽ�dです

> ホストのシステム開発とCOBOLを混同してるぞ
ああああ、そうかもですorz

> Cで読んだデータをCOBOLにパイプで送り込むなんてのもやった事がある
mjsk

> JCLは完全に機種（ホストつーかOS）依存だしCICSにいたっては
「IBMの環境」でしかない。

把握しました。現場で機械の取説なりレガシーソース見ろってことですねorz
ま、言語仕様だけ（仮想かもですけど）鯖でも立てて勉強してみます

ﾉｼ

使用実績＋過去の資産流用に重点を置いたってとこか？

>>167
SQL Serverは知らないが、
COBOLから、Olacleなら、Pro*COBOLを使う。
ADOやODBCは使う必要がない。

オッサンホイホイスレｗｗｗ
ここは伸びるｗ

企業のシステム障害が社会に及ぼす影響が
でかくなってるからなあ。
安定運用のために枯れた言語を選ぶのは正論。
Javaはいつまで経ってもバージョンアップが終わらないし
ドットネットフレームワークも同様。

>>223
COBOLの勉強だけなら、TinyCOBOLとかopenCOBOLで実行してみるだけでできるよ。
COBOLも機種依存するところがあるから、実戦では「組んだことがある」程度の経験にしかならないけどね。

他の言語をやってれば、COBOLなんて難しくはないよ。
誰でも組めるように設計されているんだから。

>>227
進化の過程ですから、たまの障害も我慢してください

って訳にはいかんからね・・・

つーか、COBOLで挫折した奴なんて存在するの？
もし存在したとして、そんなのは何やらせてもダメだろ

COBOLというよりDB／DCで挫折する人は多いだろうね。

>>216
釣られないぞｗ
昔、ExcelできないけどPOLはできます、って言ってるのがいたな

将来にわたってCOBOL使いを確保できるかどうかがまず疑問

>>233
確保も何も、普通のエンジニアならすぐ使えるようになる
現在も使ってる奴とか、経験者を募集しようとすると大変なだけ

>>233
あと２０年はなんとかなるだろうよ

>>233
教育する環境があるなら大丈夫でしょ。

>>222

信じられない･･･
開発効率ははJavaのほうがずっと上だった･･･

柔軟性と保守性は別だ･･･ましてこの現場では並のスキルは通用しない･･･

死の無限ループ（デス・マーチ）だったな

>>209
高レベルＳＥがこんな時間にここにいるわけないだろｗｗｗ

>>237
そんな日本語で仕様書くからデスマになるんだよｗ

ベーシックインタプリタで開発よろ

スペースアドベンチャーCOBOL

今って COBOL2002 for .NET Framework なんてのもあるのか。
俺がCOBOLをやっていたときとは違うと思っていたが、ソースを見たがあんま変わってないな。

１０年くらい前は俺もコボラーだったが……
周りから将来性が無い無い言われて、結局転職してしまった。
それでも俺はCOBOLが良くできた言語だと今でも思ってる。

>>217
AS/400ってユーザー数多いの？

いくら騒いでもITブームはもう無い。
諦めろ。

>>244
最近は新規が減ってるけど、10年とか20年以上前に導入したユーザーがけっこういる

次の全面再構築では人が集まらなさそうだな

>>222
ヲイ、それ使ってるエリアって地獄って言われてないか？
確かリーダーはサキって言ったな。

>>222
＞20年以上も前に設計された言語

COBOL の第１版は1960年。だから48年前。
（設計は1950年代）

もともと大型コンピューター用のプログラミング言語として作られた。
しかも、２進数で計算を行うことで発生する“誤差”を極力抑えることが重要だった。
（お金の計算をするのに“誤差”が出たりしたら大問題だからね。）

そしてその後のコンピューターの発展にともなって
COBOL は何度も改訂されて現在に至っている。

>>247
次の全面再構築の頃には、Java(笑)とかってありえない
って時代かもしれんから心配しなくて良い

>>222
たしかソルジャーは2名以外全員死亡。
生き残った1名も記憶喪失になってるだろ。

そんなデスマーチかかわりたくねぇ。

>>247
古代言語解読のエキスパートになっておけば高収入

>>244
結構いるよ。
中小企業とか大企業の部門サーバーが多いから目立たないけどね。
システムが安定しすぎで新規案件が少ないのが玉にきずｗ

COBOLは事務計算に特化してるのがミソ。
１つの言語で何でもやろうとするより、
多数のツールを組み合わせたほうが開発効率が良くバグも少ない。
Javaの品質と持続性の怪しげなフレームワークなんかより
COBOLを積極的に選びたいね

実際にこれで食ってる友人居るな

学生時代を思い出した。

たしか、「テンパイ　ロン　メンツ　出た　ディビジョン」という麻雀用語を覚える必要があったはずだ。

昔汎用系ＰＧ／ＳＥで１０年、その後フリータ（肉体労働）１０年、今求職中の４０過ぎのオヤジですけど、
ＣＯＢＯＬ（つーか汎用系）の仕事もらえますか？　深夜のオペレータとかでもいいです。時給１５００あればおんの字です。。

事務処理言語としてＣＯＢＯＬはよく出来た言語。
自然言語に近いせいもある。
システム開発時の哲学を無視した保守側の近視眼的改修が事態を悪化させただけ。
例え改修範囲が拡がり、時間が掛かったとしてもその哲学を維持すれば
結局は長寿命となりコストも安価。
保守に大所高所の見地で判断できる有能な人材を置かないことが問題。
システムは成果だけでなく、プロセス、ノウハウも資産なのに、
近年の使い捨て感覚で仕事するヤツは残念だが、明日はわが身だよ。

>>257
ttp://www.google.co.jp/search?hl=ja&q=COBOL%E3%80%80%E6%B1%82%E4%BA%BA&lr=

誰でもつつけるってのは大きなアドバンテージになると思う。

おまえらが何を言ってるのかさっぱりわからない

>>9
>ところで SI って知ってる?

知らん

COBOLのおばちゃま。

システムを丸ごと発注してオーダーメイドの作るって見直されてるだろ
既存のもの使うと端末は何でも良くなるしアップデートも簡単だけど
機密保持がややこしくなる
警察や自衛隊の情報漏れってシャレになってないし
金のかけられる企業は避けるだろ

>>263
http://ja.wikipedia.org/wiki/%E3%82%B0%E3%83%AC%E3%83%BC%E3%82%B9%E3%83%BB%E3%83%9B%E3%83%83%E3%83%91%E3%83%BC

COBOLは化石

COBOLが消える時はJAVAも一緒に消えるよ

>>259　いや現場の意見としてどうかなぁと思って。実際こんなオヤジが面接に来たとして採用しますかね？

バッチの事務処理をCOBOLより効率的に作れる言語は無いだろ。

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

最近のＩＴ屋はメインフレーム上でJavaで開発する気満々ですね。

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

>>270
厳しいよな。逆にcobolだったら最速で動かすことができる。
本当の最速はアセンブラだけど。

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

一言抜けてました。最近のＩＴ屋は天才過ぎます。

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

アセンブラが最速っていつの時代だよ。
今は高級言語の方が速いぞ。

>>273
最適化の話？ランタイムライブラリーの話？
まあどっちでも同じだけど。最速はアセンブラ。

>なぜなら5つのロジックと10の命令文で
これってなんなの?

田中角栄の五つの大切十の反省を思い出した。

結局、代理店がカスだと意味がない

>>275
想像だけど。これくらいの規模を運用しているところは
プログラムの雛形が最初からあって、そこに仕様書通りの
ロジックを埋めていくだけというのが結構あるので、
単純なシーケンス処理や比較処理用の雛形などが全部で
5つということじゃないかな。

例外処理なんかは最初から雛形に組み込まれているから、
そこは命令文にカウントしないで、SQL文なんかを対象に
PGは10の命令をこなせれば、開発を進めていけると。

>>271
ID見てみろwww

(ﾟ_ﾟ)CASLを思い出した。

>>278
光栄です(><;

>>280
残業がんばって。

ハンドアセンブルとコンパイラのどっちが速くて最適化できるかって話だろ？
いまどきはコンパイラのほうがはるかに優秀だ

>>282
そうだな

>>282
まあ全部アセンブラとか全部高級言語っていうならコンパイラのほうが結果的に
速いな。ある再利用可能なボトルネックロジックのみをチューニングするなら、
コンパイラの最適化オプションいじって試行錯誤するより、さくっと書いたほうが
速くてメンテしやすいものができるけど。

ルイージを画面の右から左へ走り抜けるのに
ファミリーベッシックで６時間かかった折れは勝ち組

COBOLってプログラミング教育用の言語じゃんｗｗｗ

せめてC(++,#)かJava使えよｗｗｗ

プログラミング言語選びなんて個人の趣味。

でもシステム開発でCOBOLはありえないけどね

>>286
子供は黙ってろ

>>287
場合によってはね
特にフロントシステムは、そうだろうね。

毒米を食べて毎日通勤電車でチンされているサラリーマン

やっぱり電子レンジ？：電車の中では携帯電話をＯＦＦにしろとイスラエルが勧告
http://hobby11.2ch.net/test/read.cgi/engei/1209083035/180

化石脳の中では現役バリバリなんですね。分かります。

>>265
スゲー！！最初のバクは本物の虫だったんだｗｗ

Fの小型汎用機入れたらCOBOLで書かれた花札、マージャン、競馬ゲームが付いてきた。

関わってる全てのSEやPGが優秀で空気読めるなら言語なんて
なんでもいいと思うけど、規模が大きくなると新卒なのに実務3年とか
平気で突っ込んでくるSIいるから、個人の技量の影響が少ない
古い言語のほうが適してるのかもしれないね。

ウチは十数年前の基幹システムそのままリプレース繰り返して使ってるから
いまだにcobolだよｗｗ
サブシステムのオープン系はVBだけど全部外注まかせｗｗｗ

まあ日本の会社は300万ステップのCOBOLソース全捨てする勇気のあるところがないからな

リッチ言語は確かにできることの幅が大きいけど、その分各プログラム，プログラマーの
癖、長所、短所が出やすいからなぁ。
そう言う意味では言語自治が簡単な分、構造解析と管理がしやすいって言うのは悪い
事じゃないと思うけどね。

>>294>>297
後任者がソース読みやすいってのも長く使われる言語の特徴なのかもな。
Cとかわけのわからんコード書こうと思えばいくらでもかけるし
Cはfor(i=10;i--;i>0)｛｝これでもコンパイル通っちゃうところが怖い

>>296
捨てて新システムボロボロになった失敗事例が多いからでは？

300億で3万人月強って、いったいどんだけケチっとんねん！
と、通りすがりのシステムアナリストがつぶやいてみるテスト。

>>265
えー　コボルの由来って、そういうものだったのか。
素で勉強になった。ありがとう。

構造体や共用体が目で見てわかるし、N次元配列もCOBOLならすんなり理解出来た。
学習用としてはかなり良いと思うな。

>>265
すげーｗｗｗ

>>86
> 日本ITのガラパゴス化が進行してるわけね。

「ガラパゴス化」なんて、ガラパゴス諸島について高校生程度の
知識があれば、恥ずかしくて到底口にできないセリフだよ。
無知蒙昧なコンサルに踊らされていますな。

>300億円，3万人月
う〜ん、ま、無尽蔵に金がかけられるならどうでもｲﾝｼﾞｬﾈ？

>>304
ガラパゴス諸島についての高校生程度の知識ってなんだ？
俺は独自進化っていう意味合いでしか言ってないんだけど。

FORTRANも現役バリバリだし、COBOLも古さという意味では驚かないな
でもFORTRAN使いは大学の研究室で毎年コンスタントに生まれるけど
COBOL使いは今後減る一方だろ。大丈夫か？

運用開始してからのコストと安定性考えたら
IT気取ってるスパゲッティ屋にボロシステム押し付けられるより
100倍いいだろう
構造化で充分なシステムなら、こういう割り切りもありだと思う

COBOL自体は実績あるとしてもオープン系でCOBOL使ったシステムは実績あるの？

「独自進化」なんて生物学用語、あったっけな？

>>298
昔はコーディング基準でそういう変な記述をしないよう指導・教育して、
たとえ書いても、ソース・レビューではじいていたもんだ(遠い目

手間かかったが、品質維持やメンテ考えたら結局お得だった

COBOLの人がCOBOLに引き篭もるのは問題ないんだ。
ただな、COBOLな人がSEとかになって設計始めるとDBにすごいアレなテーブル名とかカラム名が出来るんだ。
マジ勘弁してくださいお願いします。

>>312
先に命名基準くらい作っとけよ

>>313
そのCOBOLな人が命名基準作っちゃうんじゃね？

COBOLが現役なのはいいんだけど
やりたい、20代、30代って存在するのか

人の確保をどうすんだろうね

>>313
コーディング規約はガッチガチに縛られてるのに
(何故かC#で古のハンガリアン記法採用…MSがダメって言ってたよね…)
何故かDBとかは放置でカオスな世界なんだよなうちの会社。
ﾜｹﾜｶﾝﾈ。

>>315
業務命令じゃないの？
東京海上なら安泰だし、悪くない選択じゃないかな。

>>315
一番の問題はそこなんだよな

なんとか仕事増やそうといらん技術を詰め込んでるイメージは確かにある
COBOLで済むならそれでいいじゃない

>>308
だよな。この考え方はありだよ。
大切なのは言語よりもメンテ性。スパゲティは見たくない。

それにCOBOLなら早いしいいんじゃね？
javaとかは処理が重いから結構嫌われてた覚えあるな。

N88-BASIC(86)は現役ブリバリ

オブジェクト指向はダメってことか？

>>316
さっさと基準のドラフトでもこさえて提案汁
放置してたら結局自分にとばっちりがくるだけだ（来てるか？ｗ

新卒でコボラーになってしまったorz
将来を悲観して毎日ため息しか出んわなあ
JAVAやPHPでガリガリ書きたい・・・

>>322
適材適所。

>>317　>>318
そうだ、刑務所で教える言語はCOBOLでいいんじゃね
社会復帰した時、同世代ばっかりだしハッピーじゃないかな

>>321
教育用には、今でも最適だと思う

>>1
いわゆる金融系はPL/I・COBOLで問題無いよ
ただ、保守しやすいようにやればな。
DBでFILLER足りないとかが無ければ基本的に問題は無いでしょう。
人員も若手をどうするんだ？
COBOLやれる若手いるの？

正しく動いているシステムは美しい

お前らの会話、さっぱり理解できんｗ

なんか悔しい

>328
コボちゃん

>>307
FORTRANがバリバリというのは微妙だなあ。
77→90で現代的プログラムについてこれなかった難民をかなり生んだし。
Fortranの最近の規格ではOOとかもできる見たいだけど、
今更Fortran2003覚えるくらいならC++かJava覚えるよ。

intel Fortranのベンチマークでもintel C++にだいぶ差をあけられていて
スパコンいじるんじゃなかったらFortran不要だなあ。

>>328
＞ソフトウエアのアーキテクチャにはデファクト・スタンダードである
＞MVCモデルを採用することが当初から決まっていた。「ビューは若手を
＞中心にJavaで，モデルはベテラン中心にCOBOLで開発していくという
＞分担ができた」

とあるから、モデル部分のメンテ人員はそんなに必要ないだろう
不足分に新人投入するにしても大した数じゃない
開発部隊のベテランをあと７、８年も使えば効率よかろう

その後はまた時流にあわせて全面再構築が選択肢に入ってくるだろうし

>>332
かれこれ１０年前の話だが
俺の研究室では新人はFortranをCに書き直すのを黙々とさせられた
懐かしいな〜

＞300億円，3万人月強を投じている。

数字だけ見ると、数だけ無駄にかけてる感じなんだが、
3万人の中で継続的にやってるやつは少数なんだろうな。

抜本システムとかいって連休とかにシステム更新してたと思ったら
COBOLだったのかよｗ

>>332
お前無知だな
学術系ではFortranはCよりもメジャー

>>327
グローバル変数だらけだしIF THENを複数行書くのにGOTOとかつかわんといけないしでだめだろう

ひさしぶりに「２ちゃんに来たなぁ・・・」って感じ（良い意味で）

１人月100万だが、下請けはいくら抜かれてるんだろうか。

誰か「ビジネスロジックの書きやすさ」ってどういう意味か説明してくれ。

業務系システムは「設計(仕様)」が全てだから実際に開発する
SEとかPGがCOBOLが得意で、流用できる資産が多いんだったら
生産性を考えてCOBOLを選ぶのは一つの選択肢だと思うけど、
プレス発表で「開発言語」を語るなんて、社内でも相当批判を
浴びたんだろうな。

その程度の器の人間が「ITとエンタープライズシステムの何たるか」
を語るとは、、、

COBOL使いの漏れさまが来ましたよ
団塊世代が無茶苦茶なシステムをつぎはぎつぎはぎつくっている
ゴミシステムを置き換えるうちに、なんか必然で覚えた

COBOLも嫌いじゃないぜ・・・

これってメインフレーム使わないといけないからCobolになったってこと？

COBOLのコードは無駄過ぎる

>>324
自分の時間に好きなことやればいい。
COBOLは少なくともPHPよりも将来性がある。
Javaは二十年後残ってるかね?

>>324
Javaはもう成熟しちゃってるから、今はPythonやRubyが面白いんでないの？

environment DIVISIONとかなつかしいのお

えっ？！
桜も、寿司も、侍も、日本刀も、剣道も、柔道も、相撲も、合気道も、華道も、茶道も、熊本城も、浮世絵も、歌舞伎も、能楽も、神社建築も、万葉集も
全部韓国・朝鮮文化なの？　
世界中に嘘を広げる韓国人！
弱小民族韓国人の凄まじい劣等感による愛国民族教育の結果がこれだ！！

韓国起源説
http://ja.wikipedia.org/wiki/%E9%9F%93%E5%9B%BD%E8%B5%B7%E6%BA%90%E8%AA%AC

ここはCobolファン結構多いなw

俺は開発者の立場から言いたいけど、Cobolのシステムなんか全く面白くないだろ？
Ajaxとか使って楽しいアプリ作りたいよ。堅牢性とか分かるけどさ。

あと、これってWebアプリなのかね。ビューはJava、ってSwingのこと？

COBOL世代がシステムの更新にRubyを採用したら・・・なんてことを妄想してみちゃったり

>>350
面白いかどうかで仕事選べるのか、恵まれてるな。

>>350
こういうのでビューっていったら、基幹システムとやりとりを行うCGIやらJSPやらをさすんじゃねーの？

>>350
お前みたいなクズ開発者を排除するのにも役立っているようだｗ

新しい言語を次々習得して…なんてやってる暇あったら
簿記でも社労士でも、なんでもいいからまっとうな資格とって
こんな業界はなれたほうがいいよ
特に20代後半。方向転換するなら今のうち。

楽しいとか面白いシステムなんて聞いたことも見たことも無いな。

苦しい、きつい、勘弁しての3Kだ

>>341
複雑な処理が苦手なので、難しいことができない。
とかいう意味では。

>>344
今は、UNIXでもパソコンでもあるみたいだよ。
3回位しか使ったことが無いので詳しくは知らないが。

>>352
まぁそうかもね。俺は「アプリケーションサーバーって何？」って時代から
J2EEのシステムやってた。

今は.Net案件が多いなぁ。だけどRubyとかでパパッと作っちゃうとかやって
みたいね。楽しいのが一番だろ。

>>353
Webアプリなの？ふーん。

>>354
簿記（笑）。社労士（笑）。それ、まっとうな資格って言わないから。

>>356
昔からあるよ
N5200で走らせていたなんてごく普通だったよ。

>>341
単純に業務フローは今でもフローチャートやその類似でかかれることが多くて、
ＵＭＬはエンドユーザでも知ってる人が少ないということではないのかと・・・

>>326
一つだけ問題がある。
「COBOL→ほぼ100％金融系で使用」

泥棒に、金庫番させるようなもの…ってのが比喩でなくて、そのまんま。ｗ

しまった俺、釣りに反応したのかorz

>>357
＞俺は「アプリケーションサーバーって何？」って時代から
＞J2EEのシステムやってた。
自慢するほどのもんじゃないね

簿記も社労士もシステムバカより潰しが利く
その上でシステムも知っているとなったら、欲しがるところはある

COBOLは残るんじゃないか。
Javaは微妙。まあ今やメインフレームでも動くけど
　

>>356
PCでもCobol動くのは知ってるけどさ、メインフレーム使わないといけなかったから
Cobolになったのかねぇ。

思うんだけど、Cobolって汎用言語じゃないと思うんだけど。Javaとかと比較しちゃ
ダメなんじゃないのかな。DSLっていうか、業務アプリ向けのコマンドツールだしょ。

だからここでいくら騒いでもこの会社にお前らが納品する機会なんてないんだから
安心して別のスレ行けってｗ

>>362
あはは。自慢じゃなくて、恵まれてたって言ってるわけ。なかなか新しいこと
できるチャンスが常にあるわけじゃないからさ。

っていうか、君学生？

プログラミング言語のそれぞれの特徴を理解していれば、
趣味ではなく適材適所で選べる。
趣味で選ぶのは無知な素人だけ。

枯れた技術の垂直思考

人的資産の安全かつ有効な活用方法の側面もあるだろうな。

相変わらず言語に振り回されてる人たちホイホイですね。

そうだなぁ・・・語畜と名付けよう。

COBOLが現役ばりばりなのは否定しないが、選ぶメリットって何がある？

>>367
だからさ、Cobolってのはコマンドツールだよ。JavaとかCとか、その手の汎用言語と
同列に並べるのは間違いだよな。

この手のものをJavaとかで作るなら、まずJavaでそういう言語を構築する必要がある。
フォーマットはXML形式とかでもいいしさ。そうすりゃ、きまったコマンドだけ知ってれば
誰が書いても同じコードが生成される、ってわけ。

>>371
現行システムと業務を知ってる人材をそのまま利用できる。

>>177
　最新のコボルだとオブジェクトも扱えるから、インターフェイス込みで開発できるぞ。

ほしゅ

>>337
数値計算のプログラミングしたことないだろ？wwww
Fortranしか使えんヤツが多いだけ。使いたくないけど、研究室のボスがC/C++分らんから、
みたいな理由がほとんどだ。あと分野によっては過去のコードが生き残っていて、
一から書き直すのが面倒臭いから我慢してFORTRAN使っている。

スパコン以外の開発環境優先度はC>Fortranという現実には気づいた方がいいと思うぞ。
C.B.EとかCUDAとか大体最初はCサポートから。

>>364
> DSLっていうか、業務アプリ向けのコマンドツールだしょ。

いや、だから、それしか出来ないという理由でCOBOLにしたんでしょう。

それ以外のことは、COBOL屋以外の人がカバーして、
COBOL屋さんは、事務計算部分だけを作成するということで。

>>376
f2c

>>377
思ったんだけどさ、Cobolみたいなの知ってるだけで飯食えた時代って
ある意味うらやましいよなw。

>>379
開発案件ごろごろしてて、情報化といって惜しみなく投資する企業多かったし。
ただ、今では、業務知識込みじゃないとCOBOLの需要は少ないみたいね。

>379
しかし、メーカー製のエディタとかライブラリ管理とかが使いにくく機能が未熟で単純手作業とか多かったぞ。

>>380>>381
いや、だけどそれは量的な問題でしょ？つまり最初にちょっと勉強すれば、あとは
頑張るだけ、って時代だったんだね。

今じゃそれは完全に通用しないもんなぁ。

ウィルスに感染しなくて済むかもｗ

C++よりJavaの方が優れているし、
JavaよりC#の方が優れている。
これからはC#。
プログラム言語を勉強したい人はC#を勉強しなさい。

変更のきかない固定長VSAM、NDB
死んでいるのか生きているのか分からない大量のプログラム
３０年前のGOTO文オンパレードのプログラム。。。
ホストを使っているところはどこもこんな感じじゃないかな？

プログラミング言語だけで食えると思ってるのは専門学校の学生か？

このニュースについて言えば、COBOLで構築したことを自慢してるというのが
一番理解できない。勝手にCOBOLでやってりゃいいのにさ。誰もそんなものに
関心なんか無いってのw

これが、独自開発した関数型言語で超並列処理を実現し、信じがたいパフォーマンス
を達成、とかだったら大いに自慢できる。

「なぜなら5つのロジックと10の命令文で当社は30年間システムを保守できているからだ。」

って誰に向かって自慢してるのwwwwww

プラットフォームとしては探せばアリモノがみつかるJavaのほうが良いかと。

test

>>385
巨大なGOTO文の塊でも正常に動作するなら無問題。
塊をばらそうなどと思ってはいけないｗ

>>382
オブジェクト指向ブレーク前は、CでもCOBOLでも3ヶ月ぐらい研修受けてOJT。

今は最初に覚えること多くて大変そうだよね。

>>382
まぁね、発想や手法をを変える必要はなかったね。
帳票を作るだけでけっこうな金もらえた。

>>385
レコードがいっぱいになった後に項目を追加するだけで大事だった。
単純な力仕事。

いくらスペースシャトルがロシアの鉛筆を馬鹿にしても
シャトルが爆発事故繰り返してて、鉛筆で用が足りてれば
鉛筆のほうが生き残るのさ

GOTO文とかグローバル変数必須とか、もうそれだけでどうして真っ当な
プログラムが書けるのか想像もできないよw

>>394
（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

どうせ作るのはＯＳでもなければミドルウェアでもない
馬鹿でも出来る低付加価値な残りカスですけど

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

ｶｽ言語　こぼる

>>391>>392
そうそう。今はさ、逆に知識ってそんなに重要じゃない。自分で調査できるか、
問題を段取りよく解決していけるか。

いいプログラマが少ないわけだねぇ。

>>387を読んで思った。
COBOLには並列コンパイラとかないのか？
ﾌｫﾄﾗﾝにはあるみたいだが。
需要あるんじゃないか？

COBOLってよくネタにされるけど、何がおかしいの(´・ω・`)？
C/C++みたいなのしか知らない僕に教えて！

言語なんかなんでもいいと思うのだが。
ミドルウェアはどうなってるんだ？
ＩＭＳｏｒＣＩＣＳ？
ＩＭＳ−ＤＢorＤＢ２？
そっちのほうが気になるけどな。


フロントエンド(画面とか)は、ＣＯＢＯＬじゃかったるいから
ＪＡＶＡｏｒドットネットなんだろうし。

>>398
GOTO文とグローバル変数必須の言語で並列処理ってw

ＣＯＢＯＬ・・フォートラン・・・・四十年ほど前の電算機学校では

花盛り・・・。ｗｗ

自分は最近の技術をやってからメインフレームをやっているけど、
メインフレーム特有のCUIも悪くないなと思った。ある程度なれたユーザーにとっては
GUIよりも速く操作できることが多い。変に誰でも使えるような画面にするよりも作業性が高いんだよね。
ただし、複雑なシステムではCUIではきついかもしれないが。

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

ＣＯＢＯＬはどちらかというとＵＮＩＸのシェルスクリプトに近いですね。
メインフレームにはコマンドプロシジャというのがありますが
その別途高機能拡張版見たいな感じ
ＪａｖａとかＣはどちらかというとシェルスクリプトのコマンドの中身を
作成するような言語

　比べる事自体ナンセンスですよ。最近のＩＴ屋は天才度がますます上がっていますね

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

>>398
>COBOLには並列コンパイラとかないのか？

メインフレームを触ったことがない人でつね。
z/osの主記憶上には、10,000以上のlinuxが稼動できるんですよ。
並列コンパイラとか、必要ないし。

>>405
Linuxを10000稼働できると、GOTO文＋グローバル変数必須の言語で
並列処理が記述可能なのか？

結局は何も知らない2chと言うことで終わりそう。
いつもそうだもの。

>>1に書いてあるじゃんか。既存資産の流用がし易いんだよ
でかい会社ほど小回りが効かないし、1から作るリスクを考えるとCOBOLはアリなんだよ
若い技術者からしたら、そんな化石みたいなもの勉強したくないってなるんだろうけど
企業側からすれば、言語なんて最先端だろうが最後尾だろうが、まともに動きゃどっちでもいいんだよ
むしろ開発手法が確立されてない新しい言語で実験台にされるのはまっぴらなんじゃないか？
勿論多くの企業は最先端の事やりたがるけどさ

最近じゃ人手も少ないし、そもそも会社が覚えさせないよなCOBOLなんて
だからCOBOLの開発メンバーなんておっさんばっかり
でもあのおっさん達は、他は何もできなくても一生メシ食って行けるんだ

10進数を扱うならCOBOLのほうがラクかな
Cで扱おうとすると…

>>401
おまいは、物理的な実装に制約がなければ、自由にコーディングするような、お花畑的人間なんですか？

現在、IBMのCOBOLはHLL/WBというケースツールを使用してコーディングするようになっている。
まずは、データ分析をしてデータ構造を定義して、データ辞書を構築する。
ここで偉そうにご自説を述べている人なら、オラシルやデータベーススペシャリストぐらい
取っているだろうから、わかるとは思うが。

しかし、グローバル関数などという、大まかなお約束を持ち出す馬鹿にはわからんとはおもうが。

おまいはかなり痛い奴だ。

>>408
シェルよりずっと低機能な言語で飯食えるってのがうらやまし過ぎるw

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

どうでもいいのは言語だけでなく、低付加価値生産ソフトそのもの
ＯＳもミドルウェアもかけないなら
コリアンやチャイニーズやインディアンと
肩並べて仲良く喧嘩してください。

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

>>398
COBOLは、繰り返し処理をほとんどやらないんじゃなかったっけ？
読んで、書いてを繰り返す程度では、並列しても意味なさそうだが。

>>399
Cの開発者が、VBの開発者をネタにするようなもん。

>406
単純なデータ処理が主なので、プロセス間で同期とかする必要がない。
プログラムを10000個同時に動かせばいいってことじゃないかな。

なあ、どう考えても目先のことしか考えていない選択なんだな。。。。

COBOLは現役だということは認めるけど、メンテ考えてんのかね？

しらねーぞ。。

>>410
ケースツールw

物理的実装に制約が無い場合、並列処理では限られた範囲での実装しか現実的じゃ
ないよ。複雑になったら怖くてできない。

だからGoogleなんかは独自で並列処理用の関数型言語使ってるんだろ？

知り合いがCOBOLコードからJavaコードにコンバートするツール
を売っている会社にいたが、、、そういう方向性はないのかね？
昔先輩に聞いたが、やっぱり安定性では
COBOL>>>>>>>>>>>>>>>>>Javaなのかね？

>>406
おまいは本当に馬鹿だな。

javaと言う言語には、確かにgoto文はない。
しかし、javaVMが実際に実行するマシン語はブランチ命令
(おまいが言うところのgoto)ですよ。

>>411

目的が違うものを比べてどうすんの？

スクリプト未満の言語（笑）
それに何十年も携わる（失笑）
オブジェクト思考が何の事だかわからない（爆笑）
そんな奴がプロジェクトマネージャー（日本死亡）

>>417
そもそもJavaはこういうシステム向けじゃない。

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

そもそもＪａｖａとかＣは本当の意味での真の理系ＰＧしか触っちゃいけない言語
今の天才的な日本のプログラマーにはＣＯＢＯＬで十分です。

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

関係ないが、COBOLほどフローチャートが似合う言語はないなw

フローチャートをバカにしてるわけじゃないんだが、最近の自称SEさん(笑)ときたら、日本語にもなっていないような文章だらけの設計書持ってきやがるし、当然できたsourceはグチャグチャだし。

いやぁ、俺も、ネット証券のシステム開発したときに
UNIXサーバ上でCOBOLコーディングしてアプリ作成するとは思わなかっただよ。
Cでコーディングすると思ってたんだよ、配属された時は。
でも、まぁ、簡単といえば簡単だったし、
コーディング期間を短く＆難易度の低さ
でCOBOLにしたんだってさ。

>>416
言語に物理的ば制約がなければ、なぜ運用に制約がないと思うんだい？
ゆとりさん。

馬鹿だな。

ミドルやＯＳ側でコントロールしてるんだが、なぜそれが理解できない？

>>418
なんでマシン語の話になるわけ？COBOLはマシン語並に低級言語だけど、
シェルより遥に自由度が無い言語だ、凄いだろ、って言いたいわけ？w

>>417
別に、あえてJavaを使う必要はないんじゃないの？

適材適所ということか
メンテ要員の調達とかどうするんだろ？
>>1読む限りではすげ自信ありそうだけど

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

ＣＯＢＯＬは削られたてカットされたダイヤのようなもの
ＪＡＶＡは原石のようなもの

ＣＯＢＯＬを馬鹿にしてる時点でＰＧとしての天才度がわかるのはありがたいところです

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

COBOLかわいいよCOBOL

>>430
それは全面的に認める。
PascalやFortranも可愛がってくれ。

>>414

制御はDB/DCがやるんだよ。
COBOL言語の外。

オープンだとCOBOLランタイムやらRDBやらなんやらが。

兎も角、事務ロジック以外は書くな、という言語と思っても良い。

>>426
> COBOLはマシン語並に低級言語

COBOLは「高級言語」に分類されるはずだが、はて？

>>425
おい、運用の話してないだろw。Cobolについて話してるんだろうが。

普通の発想は、並列処理は危険がいっぱいだから、どうしても並列処理で複雑怪奇な
ことやりたい場合には物理的制約をもたせる方向を考えるんだよ。

君は運用でそれを回避するのか？w

JAVA（笑）
C++のパクリ（失笑）
パクリ以前に実は劣化コピー（爆笑）
手続き型（死亡）

>>417
昔から良くある、アホ新人ネタで、プログラミング実習の時に
「先生！このＣＯＢＯＬバグがあります！」ってネタがある。

ＣＯＢＯＬだと新人がアホで済むんだけどＪＡＶＡだと・・・

そろそろ目森二五六の登場か？

>>431
ベクトル演算したいならFORTRAN。
いま、最初にコーディングするならPascal。
トップダウン的に官僚的なうんざりするようなシステム構築をするならCOBOL
万が一xpやラップやUMLに理解があるお客さんのシステムが構築できるならjava
お客に復讐したいなら.net

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

ＣＯＢＯＬでの開発＝ＣＯＢＯＬ言語＋ベースに完成度の高いフレームワーク
　ＣＯＢＯＬ言語は完成度の高いフレームワークをカスタマイズする言語

ＪＡＶＡでの開発＝ＪＡＶＡ言語（＋イマイチなフレームワーク）
　ＪＡＶＡのフレームワークは完成度が低いだから大変　

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

>>436
JAVAは言語制約がゆるゆるだしねぇ。

>>404

きもいな。
所詮、投資対効果なのに。学問やってる訳じゃないよ。

このニュース海外に持っていった時の反応が気になる

他の国ってどうしてるんだろうな
特にアメリカでCOBOLってどんな扱いなんだろう

>>423
大正解ｗ
日本語書き過ぎだよな最近の設計書って。フロー書けば済むだろって言いたくなる

>>434
>普通の発想は、並列処理は危険がいっぱいだから、どうしても並列処理で複雑怪奇な
>ことやりたい場合には物理的制約をもたせる方向を考えるんだよ。

危険がないように運用します。それができるのですが、なんか質問ある？

>>17
どうも思わんだろ。普通の客は。

>>443
フローなんか書く必要ないだろ。

ごめん。設計書書いたこと無い。ソースに注釈は書くけど。

>>442
ＩＢＭの米国のサイト読んだことないでしょ。

ロシアのソユーズなんて４０年くらい基本設計変わってなくていまだに飛んでるけど
最も信頼性の高いロケットだという声があるくらいだ
システムの世界にもそろそろ「枯れた技術」が出てくる時代じゃないか？

変数宣言で疲れ果ててしまえ！

最初が肝心ＷＷ

>>444
おれさ、間違ってたよ。お前が言ってる並列処理ってのは、Cobolの言語的には
そもそも無いってことなんだな。

並列処理とは、DBのトランザクション機能だったり、人力だったりするということだな。
話しているレベル違ってたよ。

言語なんてどうでもいい。
バグまでいっしょに出荷すんじゃねーよ、この糞ソフト屋！
んで、バグ取で残業代もらってじゃねーよ、サビ残して穴埋めろ滓ども。
（営業職　３２歳）

>>420
オブジェクト思考はさすがに分からんなｗ

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

ＪＡＶＡでの開発も完成度の高いフレームワークが存在すれば
ＣＯＢＯＬ開発のような簡単なものになります。

ＣＯＢＯＬ命令＝ＪＡＶＡフレームワークのＡＰＩ

ＯＳやミドルウェア書いた事の無い人ような天才ＰＧさんには理解していただくのは
無理だとわかってます。

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

>>438
概ね同意。
ただ、お客からしっぺ返しが痛そうだ。。。

.net死ね。

このスレの住人なら知っていますね、あの糞開発ツールのことを

・自分のプログラムのバグなのかコンパイラのバグなのかわからない
・他の仕事に応用できない糞開発ツールの独自世界を必死に学習している
・テキストエディタで書いたほうが効率的なのに糞UIツールを懸命に使っている

糞だけど、政治的な理由で無理やり使わされているんですよね。
もう、あんな厨の作った糞ツールを我慢して使うのはやめましょう。

・糞開発ツールを部下に押し付ける上司の命令は無視しましょう。
　上司は糞開発ツールが使われる実績を作ることであの会社のごきげんをとっているのです。
・あの糞開発ツール提供会社には「おたくの糞開発ツールは話にならない」と突き放しましょう。
　バグレポートなどしてはいけません。改善要求などもってのほかです。
　あの会社はあなたたちのことをテスター/モルモットとしか思っていません。
・あの会議で「糞開発ツールを使ったら生産性がxx％アップしました」
　なんて話が出たら力強く机を叩き、会議室を出ましょう。
　あの人たちは糞開発ツールをマンセーすることで立場を確保しているのです。

糞な開発ツールを糞だと言える、そんな当たり前の環境をみんなの力で取り戻しましょう。

この会社の方針でCOBOLに決めて、うまく行ったってなら、それでOKと思うんだけどなぁ。

なんで、言語にこだわるのかな？

開発期間短くて、抱えてる技術者も活用できてるから、素晴らしいことでないかい？

>>454

それは事実だが。実際問題ないだろうが。
ほんとにきもいな。

>>451
そそ。言語にはない。
ミドルに実装されてるのよ。

もうさ、言語なんかどうでもいいでしょ。
ミドルに実装するか、言語に実装するかの違い。

画面とか、インターフェースに近づくと最新の言語じゃないとめんどくさくなるんだけど、
ビジネスロジックやＤＢ周りは言語はあんまり関係ないんだよね。

>>457
OKだけどさ、公に出てきて自慢するなよ、ってことだねw

>>443
だよなw
俺、某SIer(笑)から普通の会社に転職して情報システム部門にいるんだけど、最近仕事してる自称SE様(笑)たちときたら、嫌がらせのような大量の設計書とクソみたいなソース持ってきやがるんだよ。

無駄な資料作らなくていいから、まともな設計書とちゃんと動くソース持ってこい、と最近いじめ中。

Javaはいいよなちゃんとした開発環境があって。
ABAPとか悲惨の一言だぞ。
COBOLにはJava並みのIDEあるのかね？

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

キモイ？キチガイの間違いですよ。私、ジョーカーは少なくとも
この国ではキチガイです。では。

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

>>457

今の会社の体制で考えればそうだろう。しかし10年先を見ているかな？
会社の機関システムなら不精をせずに、きちんとコーディングするべきだ。

もちろん。COBOLでもコーディング規約を作って皆がきちんと守れば、
問題ない可能性もあるが。。。

それでも、ちょっと言語仕様が古過ぎやしないか？と、

そう思っている人が面白おかしく叩いているんだな。

おれなんかcobolよりもさらに絶滅種のpl/iを知ってるから、当面安泰だぜ

>>463

きも。

やってることは、旧システムの大規模保守だから言語も変えないのは構わないが、
それを”抜本的改革”と呼んでることが腹立たしいんだよ。

>>462
>COBOLにはJava並みのIDEあるのかね？

つ　http://www-06.ibm.com/jp/domino02/NewAIS/aisextr.nsf/ByLetterNo/RTL08007?OpenDocument&ExpandSection=1

>>483

> お客に復讐したいなら.net

わろたｗ

>>459
いや、言語に実装されてないってのは質的な違いだから。

>>469

うわぁ

438の間違いだ、、orz

>>468
なんか凄いの出てきたｗ
マジであるのがCOBOLクオリティーだな。
さすが枯れているだけのことはある。

JAVAで作ってシステムメチャクチャになるより
マシだろ

COBOLコンソーシアム
http://www.cobol.gr.jp/

>>464
技術者的には、現役COBOLerは、40代後半あたりだから、退職しないから大丈夫。
ハードサポートは、どこのハード知らんけど、メーカー潰れない限り問題ないでしょ。

Javaも10年先どのように変化するかわからないわけだし。
言語仕様は、古くから変わってないほうが、いいんじゃないかな。

>>468
( ゜д゜) ポカーン

(つд⊂)ゴシゴシ

(;゜д゜)

(つд⊂)ゴシゴシ
　_, ._
(;゜ Д゜) …?!

COBOLは新規では使いたくないだろ。ｊｋ…
COBOL信奉する奴は開発したことあるのか？
（確かにいい面もたくさんあるが、新規ではありえない）

まず、COBOLというだけで金のかかる開発環境を用意しなくちゃならん。
Javaならライセンスなんぞ気にしなくてもいいし、
偽装請負の人間のPCにさっさとEclipseと一緒にインスコさせればいい。
加えて、Javaの方がコードがスリムになる。
COBOLなんざSQLのStoredProcedure以下のコード視認性の悪さ、
加えてユニットテストも行えない、RDBとの親和性が悪い（Javaよりも）、
開発人材も*COBOLしかできない*という妙齢の給与だけ食うスペシフィカリスト（笑）を
つれてこないといかん。

たしかにCOBOLにもいい面があるが、わざわざ選ぶかというと、次元の違う話。
正直ビジネスロジックだってCOBOLで書きたくねえよ。そっちのがバグあるんじゃねえの？
仮にバグがより少ないとして、開発期間やら圧縮できんだろうが。

目的の仕様を満たすんなら、枯れた技術が運用的にはいい罠。
この辺は個人向けＰＣや、中小顧客向けシステム組んだ程度の人には判り辛いだろうね。
仮想化＆Javaは、基幹にはまだ１０年はかかるかー。

Javaと比較してJavaはスパゲッティとか言うのはおかしいだろ。

JavaやCはスパゲッティにすることが可能だが、Cobolはそもそもスパゲッティに
することができないんだ。それだけ制約がある言語で、これはJavaとかと同列に
比較する言語じゃないよ。

基本的にJavaなどの開発では、Cobol並の単純作業までAPIを落としていく本来の
プログラマと、できあがったCobol並にシンプルなAPIを使ってライン作業する
単純労働者にわけるべきなんだね。

>>475
いや、後進のCOBOLerを育成してる会社もあるぞ。
俺が見たことがある一番若いCOBOLerは20代後半だったw

>>461
俺も似たような感じだｗまあまたベンダーだけどさ
そうだよな。最近の設計やってる奴って、何だか小難しい用語使って、物量だけで仕事したような気になってるのよ
設計書ってのは客に理解してもらって、検収をもらうものって事がわかってないんじゃないかと思うよ
技術者が「仕様です」って言い張ったり、バグ探すために作ってるんじゃないんだっての

で、作ってる方も理解できてないから変なものが出来上がるｗ

>>477

COBOLが高く感じる程の開発規模では確かにCOBOLは使わないほうが良い。
と思う。

システムを新しくするならコボル資産はすべて捨てたほうがいい。
中途半端にフロントだけwebアプリとかにすると、そいつとの連携に保守工数がかかる。
しかも大抵cobol側がボトルネックになるからフロントも中途半端になる。

>>482
いや、高くなくとも、どんどん開発をアウトソースして
末端の人間を把握しない凶悪SIerスタイルでは使えないよってこと。
ま、大概ライセンス踏み倒すんだろうが。

でも現実ビジネスロジックだけ書くわけじゃないから、
そういう面をとっても処理を抽象化しづらいCOBOLは扱いたくねえんだよな。
一開発者としては。COBOL使ってどうのっていうマゾヒストによる
マスゲームやりたいんなら勝手にやっててくださいって感じだが。

おっさん馬鹿にするばかりだが、
お前らもおっさんになるんだろ。

その前に自殺するからいいのか。

COBOLもJavaもいつかは消えるが、
Cは永遠！！

>>486
ブー！
不正解。
COBOLもJavaもCも消えません。

>>475
そんなもんなのかねぇ。人材の活用という意味ではそれが解なんだろうねぇ。

ああ、Javaはどうなんだろうねぇ。
結局C/C++最強な気がするんだよねぇ。こういうシステムって。
言語理解できる人材がいねぇ！！！となるかもしれんが。

>>485
俺はパンチカード時代からの現役プログラマと昔Java開発で一緒に働いたけど、
すっげー出来る人だった。

人によるんじゃないか？CobolみたいなDOSコマンドレベルの弄んでるだけで
何もしないようなのは首つるしかないんでないの？

>>487
VBはいつ消えますか？

ＣＯＢＯＬ！ＣＯＢＯＬ！

自分が前にいた某大手メーカーも、ＣＯＢＯＬが基幹にあったから
捨てられずにいた。しかも、それ分かるのは、外注さんぐらいだったのに
切っていったから、どうやって保守してるのか。時々思出す。

>>482
同意。
cobol換算100ＭStep以下のシステムでは、COBOLを導入するメリットはないよね。
鯖が増えるし、フロントエンドの開発要員とビジネスロジックの開発要員を
別々に用意するのがアフォらしい。
めんどくさいけど、javaとか使っておいたほうが。

>>484
たぶん作ってるシステムの種類が違う。。。

スレをさらっと読んだが、PL/I使いが何人か生き残っていて、嬉しかったお！

>>488
C、特にC++は業務ロジックとかには低レベル過ぎるだろ。確かに今後も低レベルな
領域では生き残ること間違いないが。やっぱりOS記述言語なんじゃないの？あとは
組み込みとかさ。

>>490
あと50年ぐらいは余裕でどこかで働いている。

>>493
そうだね。

たしかにcobolを扱っていると、マスゲームをしている気分になるよ。
1000人以上が同一システムを開発している状態って、わかる人のほうがすくないだろう。

>>495
そういうわけで、そういう領域でほそぼそと食ってます。
いいよ。組み込みは。ハードと対話できるのがいいね。

最近は>>484みたいなカスSIerが現場無視で適当な仕事すっから
客の偉い人が把握できるように古いシステムの単純リプレースが存外多い。
ボッタのベンダから偽装請負の担当者引っこ抜いて、後は自分らでやりますと。
やっぱ自分の手元で運用する分には枯れたのが良いと。

あんまお客さん舐めてると足元すくわれるよ。
結局金出してるのは客なんだし。

ってもデータセンタ系は仮想化避けられんけどね。

ＣＯＢＯＬに落とせないようなシステムは作るなってこった。

>>493
どうなんでしょ。
結構>>1に似た空気の案件でもJavaだったよ（旧COBOLからのリプレース）。

>>495
C++は分かってる人が使えば低レベルなりに、高い抽象度を提供しますよ。
ま、分かってないCレベルでしか使わない人が8割ですが。

>>481
> 設計書ってのは客に理解してもらって、検収をもらうものって事がわかってないんじゃないかと思うよ

だよね。ほんと、こういうSEさんが増えたような気がする。

設計書って、さらには下流の方に流すための指示書だったりするわけなんだから、シンプルかつ明確に書けばマトモなモノもできるのに。

>>494
このスレに、REXX使いの方はいらっしゃいませんか。

俺だけかよ。。。

目的と手段がわからなくなってるんだよ（´・ω・`）

>>498
組み込みは一度体験してみたい。一度だけでいい。二度はやりたくないw

>>503
おまいは、ほんとにそれだけで食ってるのかとｗｗｗ

ビジネスロジックなんてものはホスト筆頭のレガシーボックスの中で手続き型設計で組めれば十分だけどな。
だが損保みたいに商品対応要件や会社統合・委託販売・規約改定・金融庁のわがまま対応その他もろもろが
毎年、というか毎月出てくるようなところこそさっさと捨てるべきだろう。都度 COBOL の条件分岐で対応して
5 年で部外者メンテ不能、なんて事まだ繰り返すのかと。

まぁ 「保守やってます! COBOL でやってます! COBOL 最強ｳｯﾋｮｰ!」 とか、>>1 は何を意味不明な力説しとる
のか知らんけど。そりゃ保守だから現行言語でやって当たり前じゃろう。わざわざこんな場で言うのは、
「何で COBOL なんかつかってんの?」 という内外上下からの圧力が発生してるんだろう。

糖蜜UFJの機関って、あれはCobol？11万人月とかニュースになってたやつ。

たとえば　兆単位の金利計算をやれといわれたら
当然COBOL。
全部グローバル変数でGOTO文のみの文法だろうと
ファイル単位で管理してマシンパワーでゴリゴリ押すのが
COBOL流。
シリコンドライブとか当然使う。

>>502
その辺はSIerの仕事じゃね？
同じ客でも検収するのに要求してくる内容違ってくるし。

馬鹿みたいに厚い設計書持ってくるSEはアレだけど
個人的にはSIerが調整とかサボってるパターンが多いかと。

ID:rO3xyE1E
こいつ大規模なシステムを構築したことないな。
世間にはいろんなヤツが飯食ってることを知り、
マネージメント出来る立場になってから書き込みな。

>>488

ちゃんと扱えれば、C/C++/C#あたりは最強と思うよ。ちゃんと扱えればね。
もう、なんかね。偶然動いているだけのコードが普通にうようよしてるよ。
そのポインタ、そこで開放してるって！え？コンパイラのバグだからコンパイラを直せって？って感じ。

>>495

あと、制御系（ミドルとかフレームワーク）には使うと思う。
あとCOBOLコンパイラもC系で作ると思う。

>>508
PL/Iじゃないの？

>>505
いいぞ組み込みは！

なんつーか。My fair lady ?
自分好みに仕立て上げたシステムが動くときは、絶頂するぞｗ

わたしもおもしろい仕事してみたい（´・ω・`）

>>514
がんがれ。死ぬなよ。
http://s03.2log.net/home/programmer/archives/blog38.html

生きて帰ってくれ。

三菱ｕｆｊのホストはPL/Iが大半

>>509
COBOLの金利計算の強みって何？？

まぁ　日本のＩＴ業界自体が向こう20年ぐらいは駄目だろうから
どうでもいいっていうのはあるな

基本は全て輸入品

やっぱりＰＬ／１だなｗ
で、JAVAとかは固定小数点データって簡単に使えるの？

シリコンテープドライブ 笑
>>509

>>520
BigDecimal使えばいいでしょ。
ま、特別な扱い方があるならあれをラップするメソッド用意してもいいね。

>>514
職人の世界って感じはするよね。ただ、一旦リリースしたら取り返しがつきにくいとか、
普通の工業製品に近い感じが自分にはできないって思っちゃうな。

>>511
まぁ、大きくても数億かなぁ。だけどやりたくもないしね。大きいのは個人の裁量なんか
全く関係ないし、軍隊的だし詰まらんよ。

無知が多すぎてﾜﾛﾀ
現場にいる人は分かるとおもうが、実際cobolの稼動数が半端じゃない
結構優れてるところもあるしな。
というか、東京海上日動の話はともかく現状cobolで動いてる
大規模システム新構築しようとしたら何億掛かるんだよって話だよな。

>>511

そいつは、もしかすると大規模の科学技術計算屋さんかもよ。
ビジネスロジック中心の大規模システム屋さんは、逆に通用しないよ。

>>520
10進数演算特化したかったら、java.math.Bigなんちゃら。

C系は、普通は浮動小数点じゃないの？

ゼニ、カネの計算にはＣＯＢＯＬがテキトー

安定性を最優先した場合、適材適所ってとても重要

複数ある選択肢で何を選ぶかってだけだよな。

>>523

あ。ごめん。エスパー失敗。
数億か、じゃぁCOBOLには縁はないね。
というか、大きいプロジェクトは個人の仕事量ではどうにも出来ない。。

>>524
だけど、Webベースにしたい、そうなるとJavaや.Netか、ってなってリプレイス
パターンがここ10年ぐらいのトレンドだろ？

運用コストはWebのほうがかからないしさ。

>>518
ないでそ。
Javaでそういう関数を作ればそっちのほうが使えるよ。
ＣＯＢＯＬの日付関数の貧弱には驚かされるよ。本当にうんざり。

ＣＯＢＯＬの言語仕様には強みなんかないよ。
ＣＯＢＯＬの強みはそういう「なにかができる」と言うものじゃなくて、
ミドルとかＯＳとか運用とかを含めたもろもろのものですよ。

>>451
よくわからないが、お前の話し相手は
運用って言葉をシステムの運用と言う意味では使ってない気がする
Cobol言語による製造工程の管理って意味で使ってるように見える
まともなITエンジニアが運用って言葉をそんな使い方するとは思えないけどｗ

>>520
扱えます。が、価格系を Java や他言語にリプレースしようとしても精度が合わないから無理! と
いうのが客を煙に巻くベンダーの常套句。真意を問いただせば、既存設計によっては浮動小数点
経由で演算やらかしてるところもあるからという話。

言語は絶対性能でなくて、必要充分な機能と安定性が全て。
客の視点で物事を見られない奴ぁ、長生きできんよ。

>>514
最近の組み込みは怪しげなミドルウェアのお陰で…
小物物件ならいいかもね。大きめな奴はとりあえず逃げとけ。

>>531
問題はその関数の信頼度。

>>522
ありがと。勉強になった。
もうIT業界には行きたくないが

>>511
>ID:rO3xyE1E

組み込みをやったこともない奴が言語を語るとはwww

>>531
ですよね〜

>>535
COBOLよりよっぽど信頼性あると思う。Fortranには負けるだろうｗ
使う側としても金融計算メソッド作ったらJUnitで問題ないか通すでしょ。

>>538

物事知らないにもほどがある。。

COBOL使いは年寄りが多いし希少価値もあるんで実は金かかる。
根本的にシステムを見直すのが普通なんだけど金に余裕があるから
悪いが金をドブに捨てられるんだろうな。
といっても、保険屋は金回りがいいんですね。

こんな無駄金を使うことに疑問を感じない
東京海上系列の保険は今後避けます。

>>539
じゃあ信頼度とかいまさらな話題を振るあなたはJava使ったことありますか？
もちろんFortranも知ってて逝ってますよね。
正直プロプライエタリ環境で独自拡張オンパレードのほうが
よっぽど信頼できないですわ。Javaなら元のライブラリから開発者が
ソースコード見放題で、いろんなところで使われているしチェックも厳しいもんですが。

>>538
>>COBOLよりよっぽど信頼性あると思う。

えー、さすがにそれはないでしょ。
メインフレームはハードで10進数演算サポートじゃなかったっけ？

金扱ってるんだから。
もとめられる信頼性のレベルが違うよ。

新生銀行はWindowsだけど、Cobolなの？

>>516
あひゃひゃひゃひゃ。こりゃひでぇ。途中で吐き気がしてきた。

ほそぼそと食っているといったとおり、ほぼ始から最後まで一人で起してる。
こういうのとは無縁だな。。。つーか俺なら上司殴ってやめる。

まあ、脱線しまくり。

COBOLは現役バリバリはいいとしてだ。
手続き型言語は、勘弁してくれ。
マジに自分で書いたコードも半年あれば忘れるわ。
そんなもんで大規模システム構築は、生理的に受け付けない。。。。
いや、愚痴だよ。気にするな。

>>544
Java
シンプレクスがJavaで作り上げた自慢のシステム。

さすがに会社名は言えないが、Windowsサーバの上でCOBOLのビジネスロジック走らせている会社はあるぞw

>>1
伝説のコボラーと呼ばれた男だけど呼んだ？

IDL

関数の信頼性って言語関係なくね?
テストの手抜きを言語機能(制約)でカバーとかいう発想?

>>538
いくらjunitを通すからといって、COBOLであればベンダから提供されているであろうライブラリを自力で実装し直すと言うの？
私もjava好きで、えこひいきしたいが流石にそれはない。ナンセンス過ぎる自信過剰さだね。

>>548
植田まさしｻﾝでつか？

旧システムから2000本流用できたって言うんだから、古いＣＯＢＯＬでも
長い年月掛けてビジネスロジックを関数化できてるんだろうな。

ま、最近の東証のグダグダ振りを見ると、新しい開発環境ばかりが良いとも
思えない。シンプルイズベストと主張したい気持ちも少しは分かるけどね。

>>541

また。きもいのが。

COBOLもJavaもFortranもPascalもCもC++もVBも、もろもろ使えますよ。
もう覚えてないけど、えっとN-BASICもZ80もぴゅーたも使えたぞ。
C#はまだやってない、てか暇がない。VLIEWは流石に組めないぞ。頭が変になるぞ。

> 正直プロプライエタリ環境で独自拡張オンパレードのほうが
> よっぽど信頼できないですわ。Javaなら元のライブラリから開発者が
> ソースコード見放題で、いろんなところで使われているしチェックも厳しいもんですが。

なんだよ。お前の気分の問題かよ。COBOLの信頼性が低いのは。

>>553
東証の問題を起こしている部分の開発環境って何使っているの？

まぁ、俺が後ん十年後に死んでも余裕で生き残ってる。それがＣＯＢＯＬ。

>>485
なんか俺のドッペルゲンガーがいる・・・・

>>553
東証もCOBOLでしょ？違ったらごめんね。

ttp://allabout.co.jp/career/corporateit/closeup/CU20051204A/index.htm

>>556
Pure Lisp で書けば、COBOLよりも長生きかも知れんよ。
基本関数が5つしかないから移植も楽だ。

まぁ、半分冗談だが。

>>468

> 本製品は、日本国内のみの発表です。
> 本製品は、日本国内のみの発表です。
> 本製品は、日本国内のみの発表です。

ちょっと泣いた。

>>537
>1を読み返せ。
総合的観点からの発言をしてるんだろ。
やっぱ、言語おたくは視点が狭いからため息が出ちゃうよ。

>>540
イージーで短絡的発言。
システムは大事な資産。選定基準は多角的な観点、
　「早い、安い」なんて牛丼屋発想で決められるものじゃあないんだよ。

たぶん主意を分かってくれないのだろうけどね。

>>547
それ面白いw。

今Cobolで最も安上がりな環境ってWindows？

>>547
ホスト系のCOBOLを動かすソフトなんて、たくさんあるだろ？
ホストリプレースの１つの手法じゃねぇの。

まぁ、本質は、COBOLどうのこうのじゃなくて、
データをどう持ちまわすかだと思うが。。

ビジネスロジックなんて、ぶっちゃけPHPだろうが、Javaだろうが、ノボルだろうが、
うごきゃなんでもいい。
でも、DBはそうはいかんからな。

>>562
いや普通にあるよ。特に某F社関連とかなら。

>>561
プログラムという製品が人件費の塊である以上
多くの場合において「早ければ安い」。

単価の高い老いぼれが時間をかけて書いたプログラムが
そこまでコスト対効果があるのかってことさ。
宮大工や人間国宝に法隆寺や東照宮を作らせる余裕があるのは
呑気なものだってこと。

>>564
ちなみに某F社関連のCOBOLランタイムはサーバライセンスなんで、えらく高くつくw

ハードウェアは日進月歩で色んな技術もすぐ廃れるけどさ、言語ってしぶといよな。

結局Cobolもそういうモノなんだろうね。どこまでもしがみつこうっていう。だけど、抽象化が
できないってのは、発展性が無いってことだからなぁ。

>>564,566
なあ、某つける意味あるか？

>>565
外注プログラマなら、それは当てはまるかもね。
社内お抱えだと、業務知識、既存システムに精通している点を考えると、
老いぼれでも無駄とまではいえないと思うけど。

>>655
NetCOBOL だっけ? プロジェクトで一部開発部隊が使ってた。

>>566
中毒患者はいくら高くても麻薬を買うのと同じだよ。
麻薬中毒患者が周囲からいくら説得されても
バイニンから麻薬の素晴らしさを啓蒙されてしまうからきりが無い。

プログラムとか全く知らないけど、JAVAは新しくCOBOLは古い
ゆえにCOBOLなんかありえない、
と思ってる上司にCOBOLの良さを説明したいのですが良い例えを教えて下さい

ガンダムとかそんな例えはいらんｗ

cobolをおきかえる何かを用意するより
cobolを使える奴隷を作ったほうが安いって話でしょ。

>>565 信頼性が重要な物だと、検査や試験の時間もね。

システムが複雑になればなるほど試験点数(工数)がうなぎ上り。

運用しながら修正掛けられる製品と運用中に修正なんて基本的にとんでもないって製品
考え方も作り方も何が重要なのかもわかれるよなぁ。

ケーブルの向こうで何使ってようが別に気にはならんが
エミュ仕込んでまで端末でCOBOLるシステム構築は勘弁してほしい。

>>574
保険や証券のプログラムが「永遠のベータ」では困るからなぁｗ

>>565
プレハブや掘っ立て小屋しか作ってない人間には判らん世界があるのですよ。
上流噛んで痛い目にあると早ければ安いなんて口が裂けても言えん罠。
走りながら直す部類の考えじゃ金融基幹なんて無理ぽ。

>>568
日常会話でも某がつけばおｋだから
意味は充分以上にある。

どうせウィンドウズサーバー2008(笑)とDELL(笑)機で動かすんだから
コボルでもCでも変わらない罠。システム以前にOSが先に落ちる。

>>572
反面教師として素晴らしい功績を残した。

COBOLが素晴らしい言語であれば、その場に安住して
C言語の登場はおろか、Javaなんて存在しなかったはずだ。
また、潰れちゃったけどDECやhpやSunが登場する機会を与えた。

COBOLは最低ゆえに大きな功績を残した。

>>565
だから短絡的なんだよ。
システムは設計しっぱなしか？
プログラムは書きっぱなしか？時代変化に適応させる改修があるんだろ？
無垢で若く安価で有能な君だけが対応するの？
改修するためには、既存のシステムを調査してから改修プログラムを特定させるんじゃぁないの？
そのプロセス全ても維持管理のコストなのよ。

素朴な疑問なんだけどさ、「IT土方」って言葉あるだろ？

土方って俺はやったことないんだけど、彼らはちょっと見習いとかやれば、
あとは大きな仕事内容の変化なしでずっとやってけるのかな。で、年功で
現場監督とかなったりとか。

IT土方って違うよな。変わっちゃうだろ？だけど、コボラー達はずっと変わらずに
やってきてるってことなのか？

>>581
COBOLの素晴らしさを説くことで永遠に変わらずに生きていける。
信者やジャンキーが引退するか鬼籍に入るまでは食っていける。

>>578
>どうせウィンドウズサーバー2008(笑)とDELL(笑)機で動かすんだから
>コボルでもCでも変わらない罠。システム以前にOSが先に落ちる。

至言だwwwww

要は他に使い道のないコボラー窓際オヤジどもの有効利用だよ。
いま再利用とかエコとか流行ってるだろ？それだよ。

>>581
どこか大手のシステム一部の専属状態になってしまえば結構大丈夫みたいよ。
部署部門全体で COBOL 村作る金はなくても、専属の数人分は絶対になくならない。
都銀や保険屋のシステムなんてのは馬鹿みたいに多種多様なもんがぶら下がってるから
自分のシステムが消えても一人二人程度なら別のどこかに入り込める。

ここは設計が比較的しっかりしてたんだろうなあ。
大抵は設計が現状に合わなくなったのまで「時代遅れの言語」のせいにされて
全システム一新→プロジェクト巨大化→デスマとかなるもんだけど。

>>586
上の連中ってのは内部でどんだけ火吹いてても、
外部には良いことしか言わないぞ。

システムにとってブラックボックス部分が多い (あるいは増える)
というのは望ましくないんだけどな。

担当者に何があろうともソースコードを見ればなんとかなる
というのが比較的望ましいわけだけれどね。
そのために、コーディング規約などがある。

ブラックボックス化したシステムでは
システムが人質になっているようなものさ。

「俺様をクビにしたらシステムが落ちるぜ、ｹｹｹ」
まぁせいぜい、金正日にせっせと貢いでください。

>>586
東京会場のシステム構成図 (俯瞰図?) とか見たことないでしょ。
昔の雑誌 INTERNET の巻末に乗ってた IX 中心のネットワーク図みたいになってるよ。
ノードはそれぞれ「村」ね。村ごとに会社もプロトコルも言語も環境も無茶苦茶。

A software engineer, hardware engineer, and departmental manager were
on their way to a meeting in Switzerland. They were driving down a steep
mountain road when suddenly the brakes failed. The car careened out of control,
bouncing off guardrails until it miraculously ground to a scraping halt
along the mountainside. The occupants of the car were unhurt, but they had
a problem. They were stuck halfway down the mountain in a car with no brakes.

"I know," said the manager. "Let's have a meeting, propose a Vision, formulate
a Mission Statement, define some Goals, and through a process of continuous
improvement, find a solution to the Critical Problems and we'll be on our way."

"No," said the hardware engineer. "I've got my Swiss army knife with me.
I can strip down the car's braking system, isolate the fault, fix it, and
we'll be on our way."

"Wait," said the software engineer. "Before we do anything, shouldn't we
push the car back to the top of the mountain and see if it happens again?"
http://www.the-jokes.com/jviewer.php?clavech=99&cat=info&cla=tcla&sort=calif&id=Search&row=0&chquery=97+335+1194+193+91+94+95+98+617+96+99+93+388+100+90+92+735+89+585+667+561+1208

>>588
ソースファイルをロクに管理せずに、dllファイルだけを後生大事に版管理してる.netのシステムがですね。いや何でもない。

昨日、東京海上日動火災のシステム開発したんです。東京海上日動火災の基幹システム。
そしたらなんか、言語を比較したとかいって、COBOLで作るとか書いてあるんです。
で、よく見たらなんか評価軸とか書いてあって、開発１年保守１０年とか書いてあるんです。
もうね、アホかと。馬鹿かと。
お前らな、書きやすさ如きで３０年前のCOBOLとか採用してんじゃねーよ、ボケが。
COBOLだよ、ｺﾎﾞﾙ。
なんかロジック５個しかないし。COBOLの将来は明るいか。おめでてーな。
よーしまたCOBOLで再構築しちゃうぞー、とか言ってるの。もう見てらんない。
お前らな、コンサル投入するから、アーキテクチャ設計イチからやり直せと。
システム開発ってのはな、もっと現場で議論すべきなんだよ。
外注のSEといつ喧嘩が始まってもおかしくない、
いつ納期ズレるかバックレるか、そんな雰囲気がいいんじゃねーか。経営層は、すっこんでろ。
で、やっと設計終わったかと思ったら、ビューは若手中心にJavaで、とか言ってるんです。
そこでまたぶち切れですよ。
あのな、ビジネスロジックはコボルで！なんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、ビジネスロジックはコボルで！、だ。
お前は本当に抜本改革したいのかと問いたい。問い詰めたい。小１時間問い詰めたい。
お前、COBOLでって言いたいだけちゃうんかと。
言語通の俺から言わせてもらえば今、プログラマの間での最新流行はやっぱり、
Ada言語、これだね。
AdaとC言語でRPC使って分散開発。これが通の組み方。
Ada95ってのは国防総省が作った。そん代わりC++とのインターフェースはできない。これ。
で、それにオブジェクト指向つかって設計。これ最強。
しかしこれを作ると次から誰も保守できないという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前らド素人は、業務パッケージでも導入してなさいってこった。

>>579
Vertor の違いをそうやって誤魔化すのはどうなんだろうな。

C言語を事務用に使う、という意図は最初はないはずだぜ。

>>590
確かに、COBOLのエミュレーターはスイスナイフ並みに機能が多いよな。
実際はあまり役に立たない機能があるけどな、
ああもちろんスイスナイフのことさ。

定年までいるのなら
いい会社なのかもしれんな

笑ってしまった
レガシーを改修する度胸のない連中の言い草か
大昔はシステムは10年で変えろと言われていたのに

紙を後生大事に扱っている連中とかわらんね

>>579

目的が違うよ？

>>596

システムと言語の区別もつかないのか。。

>>597

下手な例え。。

COBOL adapter for XXXとかSOAとかあるので好きなだけコボル使うよろし

うわ！！！
ここはＩＴ土方ホイホイスレだなｗｗｗ

少しは夢を持っていたからこの業界に来たはず
死んだ言語をありがたがるのは技術者としておかしい
残存者利益狙いなら結構

COBOLみたいな簡単な言語だったらサルでも使いこなせるはずだよな。

最近は、COBOLも出来ないサル以下の奴が多いけど。

>>592

何故そこでAda。ｗｗ

>>604
海上というくらいだから、米海軍のシステムに同期させるんじゃね？

はっきり言うが、言語なんかどうでもいい。
要は「安定していて保守性に優れているシステム」が「良いシステム」だ。

どうせ綴りも書けない、くだらねえカタカナ使って客をだます前に
まともな設計してきやがれ、バカSIer。
客にバグ見つけられてる場合じゃねえだろw

>>606
同意。
なんで言語にこだわるのかわからんわ。

これからはSarSがナウいです

>>602

なんでCOBOLだけしか組めない技術者になろうとするんだよ。

>>607
言語特性が保守性に直結するから。

>>608

それ、重症急性呼吸器症候群。

>>607
もちろん>>1はゲンゴの話が主題って訳じゃあないけれど、
ゲンゴの話しかできない人も居るんだから勘弁してあげて。

一人くらい歌ったか？

や〜っふぉ〜　♪
フォートランランラン　♪
やっふぉ　フォートランランラン♪
やっふぉ　フォートーランランラン　♪
やっふぉっふぉ　♪
　

新しい技術を持ち上げるのはいいが、少し雲行きが悪くなると真っ先に逃げ出すのが・・・

>>610

直結はしない。でも言いたいことは半分だけ分かる。

>>614
意外に客が指名してくることもあるんだぜ？
「これからはｘｘｘだ！！！！！」って日経ちょめちょめに書いてあったんだと。

>>610
ソースコード読みにくいとかそういう類なんだろうな。

＞3年7カ月前に着手した第1次フェーズが終了し，自動車保険システムが新たに生まれ変わった。300億円，3万人月強を投じている。

一か月を単位としてのべ3万人ということか？　3万/43か月＝700人

300億円/43か月＝7億/月　、　/700人＝100万円/人・月　で実際まあそこそこ的か。


しかしなあ。どんだけの業務処理内容があるのか知らんが、
千人弱で4年もかかる単一会社特化の事務処理系ソフトなんておかしいとしか思えんが。

天才ないし超秀才PG10人＋秀才PG50人　くらい呼んできて、C++あたりでさっさとつくらせりゃ
1年以内に終わる悪寒。補助的作業を除けば半年かもしれない。
各人に年棒５千万とかやっても費用も1/10ですんだり。もちろん保守も楽っ楽。

Java、Java言ってるバカに限ってさ、ソース見ると
swich文でbreakが書いてなかったり、ひどいバカになるとdefaultも書いてない奴がいるんだよw

こんなバカな奴ら信用できるかよ。

こういう奴らに限って「我々はプロですからお客様はソースなど見なくても…」とか言いやがるんだよ。

一回死ねば良い。

>>619
>swich文
switch文だね、失礼。

>>618
その間仕様が一度も変更してないと考えるほうがおかしいと思えんか？

>>616
そういう人、確かにいるね。
だから大切な者に取り組むときは新しい物好きは信用しない。
どうでもいいことや使い捨てのはやりものしかやらせない。

あのさ、今思ったんだけど、CobolMLとか作ってさ、XMLにCobol書いちゃうわけ。

これどう？

あとはJavaだろうとCだろうと好きな言語でインタプリタ書けばいい。
既存コードのコンバートもJavaに移すのは大変そうだけど、XMLへ
移行するのは簡単。

で、定義された「部品」とやらを使って、Javaで抽象化、マクロもかけちゃう。

>>618
これまた巨大な釣り針ですね。

枯れたものだし悪くない選択だろう
基幹部分をきっちりつくっときゃ他は別にどんな言語でもいいべ

>>618

> 千人弱で4年もかかる単一会社特化の事務処理系ソフトなんておかしいとしか思えんが。

おかしくない。例外処理の塊。
あと規模が大きくなると生産性がどうしてもおちる。

> 天才ないし超秀才PG10人＋秀才PG50人

いねーよ。

>>619
C言語でも起きる現象は全く同じ。
(だから、switch文は避けている)
同じことをプログラマー板で言ってみてはいかがか？

COBOLについてコメントできるような知識はないけど、
「あとから建て増しにつぐ建て増しでシステムを肥大化させる
という作り方のせいで破綻する。という設計と保守と運用上の
問題を、開発言語のせいにしちゃいかん」という点は同意。

>>618の人気にｼﾞｪﾗｼｰw

典型的中二病ﾀﾞﾛ

>>619
> swich文でbreakが書いてなかったり

これはC言語の欠点をJavaがそのまま引き継いじゃったんだな。
落下が正しいケースなんか滅多にないんだから、break不要な構文にすべきだった。

>>623
かなりズレるけど、こんな愉快な製品が世の中にある。
ttp://hitachisoft.jp/products/COBOLScript/

コボラーは決まったことやってればいいから、当然毎日定時退社なんだよね。

>>623
なんでXMLにする必要があるのかな？

>>619
お怒りごもっともだけど、そういう形式的な問題については、
納品のときの受け入れ条件で、「これこれのコーディング規約に
合致していること」という条項を付け加えて、テストにパス
しなかったら受け入れないだけでいいのでは？　チェッカーで
自動的に検査できる話。

>>633

新技術で既存システムをリプレースしたいから？

>>619
>>630

breakを書かないことで簡潔にかける処理もあるのだから、言語のせいにしちゃいかん。

>>631
これを受ければ富士通内定間違いなし！
http://www2.knowledgewing.com/course/cd?c=UBL97L

>>631
これはダメだろ。これってコボルをJavaScriptの代わりにしようってのでしょ？w

逆でさ、Cobolなんか単純な言語なんだから色んな環境でインタプリタ用意すれば
いいだけだと思うんだよね。XMLベースとかで書けば、ツール類もそろってるし、
コンバートだって簡単だし、最近の言語だったら扱いが容易。

>>633
XMLはデータ構造はっきりさせるし、Javaとか最近の言語なら全て自由に扱える
ライブラリあるじゃない。XMLスキーマ定義しておけば言語仕様を定型にすることも
テキストファイル一つで済むしさ。

>>623
それなんてPHP?

XML でコーディングする言語なんて狂気の沙汰。
コンパイラの構文解析を楽にするためにそこまでする必要性がない。
ポトペタツールで作るだけの手書き前提なしというならともかく。

開発したのはシステム子会社だから、
人月計算で親会社に大きめに見積を出して、
長期間引き延ばせば、その分儲かるってこっちゃな。

東京海上日動の基幹システムだったら、わざわざ実績のない新しい技術を取り込む必要なんてないよな｡
安定して日々の業務が行える堅牢なシステムがあればそれでいいんだから、COBOLで十分だろ。

付加的な情報システムだったら落ちても影響少ないから、実績ない新しい手段でトライして泥沼にはまっても影響少ないけどね｡

googleもコボルで書くのかね

>>639
＞XMLスキーマ定義しておけば言語仕様を定型にすることも
＞テキストファイル一つで済むしさ。

・・・たぶん、これを読んでも重度のコボラーは理解できないと思う

ララベルことわざ日記：人を見て法を説け

COBOLは化石じゃなくて、シーラカンス。生きた化石。

進化を止めた言語。じわじわと数を減らしつづけるが、いつまでも生きつづける。
もう海を支配することもない。

Ｃ　こそが至高・・・と思いたい。

しょもないｺﾎﾞﾗｰのおっさんへの嫉妬むき出しのﾍﾀﾚ大杉

だったら自分で提案して構築しろって

もしかしてCOBOLを文法の無いフリーテキストだと思ってる…いや、そんな訳無いよな…じゃあなんで…。

全面改修する予算がないから一部は使い回しただけだろ

>>641
Cobolのよいところは、単純なコマンドで決まったプログラムしか書けないって
ことなんだろ？そして今までの実績もあるんだと。

だったらXML形式とかでコンバートしちゃえば、コボラーの資産使えるし今まで
どおりの機械作業ができるよ。

で、本当にアプリケーションとしてコアな部分は普通の汎用言語、JavaとかCとか
で書けばいい。

デカいシステムを作る時は枯れた技術のほうがいいよな。

東京海上日動ｵﾜﾀ
炎上炎上ｗｗｗｗｗｗｗｗｗｗｗ

扱ってる物件の大きさと経験の差が、これだけ如実に現れるスレも珍しい。

干からびとる。

>>651
>>で、本当にアプリケーションとしてコアな部分は普通の汎用言語、JavaとかCとか
>>で書けばいい。

言語にメリットなんかないんじゃねぇの？

メインフレームにC言語ってバカだと思われるよ。

>>652

でもCOBOLは読みづらいんだよな。
やたらと長い似たような日本語変数が多くて。
使い捨てのループ変数すら長い。先頭にｗが付いてるからワーク用というのは分かるんだけど。

>>643
枯れた業務モデルが実装済みなら、それがCOBOLだろうと何だろうと再利用しない手はないよね。

>>652
はげどう。
新しい技術は使い捨てできるところで実験的に使うのが吉。

要は、外注がダメすぎるんだろうな。
上の連中がダメだからもう全然ダメだと良く愚痴ってるじゃないかお前ら。

>>651
ビジネスロジック記述用の標準言語が欲しいならわざわざ COBOL じゃなくて
強度に規格化した単純構造の手続き型言語を開発した方が早い。
コピー句やら REDEFINE やら READ/WRITE 型設計手法やら COBOL 特有の
特性を持ち込む必要は無い。

データ・事務処理くらいならCOBOLでいいんじゃない？
商業高校がCOBOL教えてITドカタ量産してくれるし

http://itpro.nikkeibp.co.jp/free/ITPro/NEWS/20041026/151724/

こんなんあるんだ

>>661
つBPEL

cobol一筋で年収700万です
休出・残業がないのでまぁいい方だろうなと感謝してます

>>663
何でそこで PHPｗ

>>656
まぁC言語はまずいかw。Javaでいいと思うよ。VMあればプラットフォーム選べるしさ。

Cobolは抽象化とかそういう概念無いから捨てていくのがいいと思うよ。時間の無駄。
だけど資産を使いたいってのならJava経由で使うのがいい。変なCobol.Netみたいな
の作るんだったら、C#でCobol資産を使えるインタプリタなりインターフェースなりを
用意するのがいいだろ。

>>666
コンパイルやビルドしなくていいからねｗ
デバッグらくちん

>>667
寝言は寝てから言ってくれ｡

>>667
JavaVMがあれば、OS関係ないなんてのは幻想。
現実は、VMごとにちょこちょこ違うし、OSの文字コード違いやら
ファイルパス区切り文字の違いやらで、オーバーヘッド多し。
かといって、、メインフレームJava上で開発するわけにもいかんしなｗ
おまけに、Javaのバージョンてコロコロ変わるでしょ？
誰がサポートしてくれんのさ。
Java使ってもロクなことない。

やっぱ、関数もそろってるC言語が一番システム開発に向いてるでしょ。

>>664
ビジネスプロセスとビジネスロジックは全く別物なわけだが…

>>663
もう潰れた。
ttp://www.itmedia.co.jp/enterprise/articles/0712/10/news091.html

どいつもこいつも記事読んでねえな。

この記事のポイントは

>「システムは開発して終わりではない，いかにそれを高い効率と信頼性を保って保守していくかが欠かせない」

であって、COBOL云々じゃないだろ。

これだから、IT土方は困る。

実装する人間からすると、Cobolみたいな言語はメタプログラミングができないから
絶対にメイン言語にはしたくない。基本的には与えられた環境の幅に依存するわけでしょ？
便利なツールとか、なんだとか。

だから実装者が自ら対象プログラムを抽象化し、より合理的に実装するという裁量が
全く働かない、まさしく土方作業になってしまう。

別に俺は東京海上の保険に入っていないから、彼らが何をやろうと自由だ。
その負担で潰れようが保険金の不払いが起きようが関係ない。
ただひとつ言えるのは、中国といった「後進国」もふくめて
新しいビジネスを新しいシステムで進めつつあるということ。
結局、競争力が無くなって公的資金の投入だという話になれば
自民党だろうが民主党だろうが選挙では容赦しないってこと。

>>673
いやだから、その目的達成のためにCOBOLかいｗ
と、話が繰り返す。

>>667
メインフレームの開発やってから発言したほうが、身の為だよ。

>>670
すまん、最後の一行は何だ？w。釣りか。

ID:8mYNMNyAは下流の下流しか任されてないか
脳内ＰＧなんだろうな(´･ω･`)ｶﾜｲｿｽ。

>>670
もうちょっと知識付けてから書き込んだほうが良くね?

>>672
あれｗ

>>673
読めてないのはおまえだ、バカもの。
COBOLだから記事になったんだろーが。
いかに云々なのは、システムなら当然。
それを、COBOLでやった（ここの住人は、COBOLでするか（ﾌﾟｹﾗ））
のが主旨なんじゃねーか。
ど素人はすっこんでろ。

>>674
で、ちょっとプログラミングかじると、すぐメタ言語持ち出したがるが、
気持ちはわからんでもないが、現場ではメタ言語なぞ、クソの焼くにも
たちゃしない。大事なのは変更管理と試験。

COBOLみたいなBASICより簡単な言語も理解できない初心者が面白くってつい

>>674
>だから実装者が自ら対象プログラムを抽象化し、より合理的に実装するという裁量が

私、この一文で君とは絶対仕事したくないとおもた。いやね私の第六感がびんびんと危険をね。

>>670
無知だな
赤くしてやるよ
晒し

>>674

うぜー

相手しているシステムの領域が全然違うことに永久に気がつけない自分に気がつくには無理か？

>>678
いや、圧倒的に、C言語＞＞＞＞じゃば系はこんぷでしょ？

Javaでシステム作ったら負けかなと思ってる。

>>680
オレ、ジャヴァもCも資格持ってるんですけど何か。

>>681
> たちゃしない。大事なのは変更管理と試験。

そりゃ大変だねw。だけどダメなコードは試験に入ってから膨大なコストかかるんだけどね。

>>684
じゃあ、環境の違い吸収する魔法のツールと、
メジャーバージョン間の完全互換とるツールくれよｗ

おまえ、なんかいい方法しってんの？

猛省を求む。

>>685
＞相手しているシステムの領域が全然違うことに永久に気がつけない自分に気がつくには無理か？

ガラパゴス島の珍獣^h^hの人々には失礼な発言でしたね、俺の発言じゃないけど。

>>687
おまえは、システム開発がなんたるかを、全くわかっていない。

＞ダメなコードは試験に入ってから膨大なコストかかるんだけどね

そんなことは、開　発　し　て　る　全　員　が　分　か　っ　て　い　る

けど、分かっていながら、そうしなきゃいけないのが現場なんだよ。

>>686
> オレ、ジャヴァもCも資格持ってるんですけど何か。

資格じゃなくて経験で言わないとこの次のレスあたりでバカにされてると思う。

どうでもいいが、ここに書き込んでるシステム関係者の皆様は
デスマとは無縁な方々でつか？

>>686
>オレ、ジャヴァもCも資格持ってるんですけど何か。
恥ずかしいからんなｺﾄ書くなwww

>>661
>ビジネスロジック記述用の標準言語が欲しいならわざわざ COBOL じゃなくて
>強度に規格化した単純構造の手続き型言語を開発した方が早い。

そういう言語を新規に開発するくらいなら XML で書けばよいのでは？
というのが >>651 氏の言いたいことであると思われ。

>コピー句やら REDEFINE やら READ/WRITE 型設計手法やら COBOL 特有の
>特性を持ち込む必要は無い。

膨大なCOBOL資産を活用するのが目的であれば、COBOL特有の特性を
持ち込むのは良いアイデアであると思う。

ただし >>651 氏の根本的な勘違いは、「COBOLは単純なコマンドで決まった
プログラムしか書けない」のだから「XML形式とかでコンバートしちゃえば」と
短絡的に発想している点。いくら単純といっても COBOL はロジックを記述する
プログラミング言語。対して XML はデータ(or 文書)を記述するための
マークアップ言語。記述のレベルが違うから単純作業的なコンバートはできない。

>>691
>>693
うるせぇよ。おまえら、じゃあなんか資格持ってるのかよ。
オレの資格よりすげぇんだろうな。

695 名刺は切らしておりまして New! 2008/09/09(火) 01:05:47 ID:TyYURaTS
>>691
>>693
うるせぇよ。おまえら、じゃあなんか資格持ってるのかよ。
オレの資格よりすげぇんだろうな。

>>692
瞬間的なデスマはあるけど、
テストで逃げ場の無い未完成の証拠を見せて
リリースそのものを止めたり責任者を更迭させたりで
最悪の事態は避けている。

デスマな現場真っ最中だけど、おいらは開発側じゃないから観察して楽しんでる。

>>695
お前面白すぎｗ
とっととハロワ行って実務磨いてこい

>>695

ｸﾏｰ

ここでレスしてる奴ってホストの開発やったことあんの？
見たことも触ったこともないのに、やたら非難してないか？

>>690
現場っていうか、そりゃ管理が悪いんじゃないか？システム開発で不具合を出さないコツは

1.ソースを書かない
2.ソースをできるだけ書かせない
3.ソースを書かせるが、10人が10人同じソースになるようにする。

この順番で行っていく。Cobolってのは3が守れる言語なんだろ？だから人気なんじゃないの。

>>699
おまえと違って正社員だからなｗ
まぁその時点で勝ち組なわけだが。

しかも、すげぇでかいプロジェクトやってるからな。
忙しくておまえらと遊んでる余裕とかねぇんだよ。

月65万の契約（手取り）って安いの？

まあ、かかわりたくないよね

>>695
なんか釣り臭プンプンなのでレスするの止めますね。悪しからず。

なんつーか「ガラパゴス携帯VSあいふぉーん」みたいなもんだな。

「あいふぉーんなら新しい世界が広がりまくりんぐ！日本の携帯？ｗｗｗナニソレｗｗｗガラパゴス乙ｗｗｗ」
「ごちゃごちゃ言う前にまっとうな日本語入力積め！キャリアのデフォルトメールで着信表示ぐらいしろ！そもそも電波の掴みが弱いって携帯として終わってるだろ！」
みたいなもんで話がかみ合うわけが無い。

>>694
> プログラミング言語。対して XML はデータ(or 文書)を記述するための
> マークアップ言語。記述のレベルが違うから単純作業的なコンバートはできない。

そんなことないよ。XMLで普通にプログラミング言語を表現できるよ。君の理論だと
Lisp系は全部プログラミング言語じゃないってわけ？

>>689

ほんと。うぜー。

COBOLがプログラミング言語として汎用性があるとも、優れているともまったく思ってねーよ。
言語うんちく結構だが、それでは投資は得られないことを知れ。
巣に戻ってろ。

>>703
ここで遊んでる暇があるなら仕事しろよw

>>695
この業界、資格より実績とコネと年収が全てじゃない？
とっかかりは資格があったほうが有利だけど、後はどのプロジェクトを
完遂させて、そのときにきちんと「実力と実績に基づいた」コネ作れてるかだし。

デスマを一緒に乗り切った連中なら、まぁ信用できるしな。

>>692
デスマになりそうになったら、早めに営業交えて客に相談するのが一番。
最初からデスマ折込済みのプロジェクトは全力で逃げる。

こんな糞スレがにぎわっているとは、COBOLがっばってんなー。

FORTRANもしつこくはびこってるよ。社会保険庁でもがんばってるようだしｗ

書き捨てのスクリプト言語と、数十年にわたって使われる大型のプログラムは、
世界観が違うから常に話がかみ合わないなｗ

>>702
なんだ？学生ふぜいか？
全くわかってないね、現場を知らないっつーのは、
不幸なのか幸せなのか、、、
１なんてヤツは１時間でクビだ
２なんてヤツは、給料半額。
３なんてできるわけがない
現場では、とにかく書きまくる！ソースを書いて書いて
すぐコンパイル、試験！そのままチェックアウト。
これを迅速に進めなきゃ、プロジェクトが前に進まない。
納期遅れたらどうすんのさ？
ちょっと考えたら分かるだろうが。
コボルでやろうが、Javaでやろうが、そのへんは一緒。

ID:TyYURaTS がちょっとかわいい件。

>>702
まあ、でも現状１，２はオブジェクト型の方が優秀だってのを
皆理解してるんじゃないか？

で、出入り口さえしっかりしていれば、３も一応満たせるぞ。

まあ、中身がスパゲッティな可能性は否定できないが、
そこはテストテストテストオオオオオ！

>>709
自社でやるよもう、と思わせる事があったんだろーな。散々。
納期の年単位の延長や仕様満たさないのは当たり前ってSEのスレにいっぱい書いてあった。

>>710
おまえらの発言があんまりレベル低いから
見てらんなかっただけ。
その合間にも、仕様書２つも作ったからな。
ソース見ながら仕様書作成。自分で自分が怖いよ（笑）

>>709
こちらからもお願いしたいものです。

「あんたらは巣から出ないでくれ」

とね。
あんたらが娑婆にでてくると。
何よりも新卒はおろか、まともな人材が集まらないので。

>>713
結合ﾃｽﾄでﾊﾞｸﾞ噴出して死にそうだな｡

>>717
>ソース見ながら仕様書作成。自分で自分が怖いよ（笑）
即刻、首きるな、こういう奴w
仕様書くらい客に見せてからモノ作れよw

>>707
まあ技術的な潮流を踏まえて>>1を見れば「視野狭すぎ、日本の業務システム開発終わってる」んだろうけど、
一日本企業の経営方針としてみれば無駄なし効果ありのワザあり経営なんだろうね。難しいね。

>>704
なんともいえない

>>715
外注に負かした時点で、３なんて到底ムリ。
かってにロジック実装していきやがるからな。
動けばなんでもいいと思ってるフシがある。

オブシコでやっても限界はあるぜ。
結局、コーダーがオブシコ完全に理解してないと、
ちょっと難しいロジックになったら、すぐに構造化しやがるからな。
意味不明なクラスがわんさかでてくる。
だったら、もう１クラスでいいから、全部実装してくれと思う。
テストロジック作るの大変だよ。

Z80でハンドアセンブルなら分かるが、COBOLは知らん。

やっぱり、ID:TyYURaTS がかわいい。
よちよち。おちっこでちゅか？

>>711
だよなこの業界では資格なんてなんの役にもたたない
自分は実績で年収８００万円だ

Javaの資格とったところでCommonsやらのライブラリや
Hibenatet等のO/Rマッピングライブラリなんか使いこなせないし
ましてやGOFのデザインパターンを用いたアーキテクトの構築なんかできないだろ

>>724
Z80ぐらいなら脳内変換で直書がデフォw

>>719
結合試験では、ちゃんとバグ曲線にのっかる。不思議なことにｗｗｗ
なぜなら、ホントに出たバグは、単体レベルと勝手に分類して、カウントしないからｗｗｗ

>>720
おまえ、、まさか、仕様書つくってからソース書いてるとか思ってる？
だとしたら、おめでたいにもほどがあるぞｗｗｗｗｗｗｗｗｗ
だったら、あんな短納期で納品できるわけなかろうがｗｗｗｗｗ
最後だけ帳尻あえばいいんだから、ドキュメント作成なんて最も最後だっつーのｗｗｗ

>>713
> なんだ？学生ふぜいか？

いや、君が学生に見えるけどw

10人が10人全くレベル違うコード書かれたら怖いだろ。実力、実績ある人間に
裁量が発生するコア部分を記述させ、あとは定型の反復機械作業にすべき。

Cobolはそういう機械作業言語だってことだな。だから皆が使いたがる。だけど
資産利用はともかく、これをメインにして新規開発なんかおかしいよ。今は
昔と違ってJavaなんか使って、Cobolレベルの言語のインタプリタなんか書けちゃう
んだからさ。

ID:TyYURaTS の人気にﾏｼﾞ嫉妬♪


この巨大ﾌﾟﾛｼﾞｪｸﾄの後は任せたw

>>674
>実装する人間からすると、Cobolみたいな言語はメタプログラミングができないから
>絶対にメイン言語にはしたくない。

では、本質的なメタプログラミングが可能なプログラミング言語とやらを答えてくれ。自分の知る限りでは Lisp/Prolog/FP系しか思いつかない。
Java や Ruby の「中途半端な」メタプログラミング機能は、
開発体制が個人や数人で開発であれば効果的かもしれないが、
数百人で開発するようなシステムでは混乱をまねくだけの代物だと思う。

>>728
だから糞みたいなソースを納品してきやがる訳ですね、わかりますw

>>701
ホストがハード設計思想から運用ノウハウ含めて堅牢なデータストアであることは
ホスト開発したことなくても大手のシステム開発携わった事ある奴なら理解してん
じゃないの。COBOL/COBOLer を揶揄したいのが大半で、リアルに知らないとか
少数だと思うけど。

池沼ばっかだな。

>>723
それなんてデスマーチ一歩手前？

外注するにしても、メイン部分は自分でコーディングするなあ。
経験上、最悪の事態は防げる。

>>728
＞最後だけ帳尻あえばいいんだから、ドキュメント作成なんて最も最後だっつーのｗｗｗ

まるで、F社員のようなことを言いますね・・・

>>733
そっか、COBOLを卑下したいだけなら、話すだけ無駄だね。
ありがとね。

>>736
>まるで、F社員のようなこと
F社員wwwww
あそこにだけは二度と発注したくないわw

>>729
おまえ、、ホントに働いた経験あるのか！？まじで。
おまえは、外注の恐ろしさを知らんようだな。
今最新流行の食品偽装と全く同じだぞｗｗｗｗｗｗｗｗｗ

１０人外注頼んでみろ、死ぬほどばらばらの人材が
１０人くるんだぞ。
プログラムオタから、パソコン初心者、いきなり学習本広げるやつ。。
１０人が１０人、まじ全くレベルの違うコード書いてきやがりますがなにかｗｗｗ
ちなみに、実力ある人間も来るには来ますが、最初の１週間で
タコ要員と交代しやがるからなｗｗｗ
覚悟しとけｗ

というわけで、おまえは全く社会を分かってない件に１票。

>>723
んなこたーねーよ。外注に作らせてもレビューはちゃんとするし、
チェックリスト満たしてないのは付き返すぞ。

金融系に転職したオレとしては、IT系はマゾ集団としか思えない

>>732
まぁ、クソみたいな発注金額なんで、妥当でしょｗｗｗｗｗｗ
文句ある？ｗｗｗｗ
マシな品質ほしかったら、ちゃんとスケジュールとコスト計算してねｗ

>>731
Rubyは雑さがあると思うけど、
JavaやC# は汎関数は仕様として取り入れているよ。
あんた、本当に最近の言語やっているの？

> Java や Ruby の「中途半端な」メタプログラミング機能は、
> 開発体制が個人や数人で開発であれば効果的かもしれないが、
> 数百人で開発するようなシステムでは混乱をまねくだけの代物だと思う。

言語の性質でシステムの開発をかたるのはどうかと
Javaなんて特に大規模開発可能なフレームワークを必ず選定または作成してから
製造に入るものだし

>>739
＞１０人外注頼んでみろ、死ぬほどばらばらの人材が
＞１０人くるんだぞ。

あなたの会社が舐められているんです。よ、派遣元からもね

TyYURaTSはFも怪しいが、Nと言う可能性もあるｗ

あそこもいい加減マジキチ

>>735
なんだ？その趣味みたいなプロジェクトは。ある意味うらやましい。
そんなヒマあったら、１個でも多く実装するしかない。
>>740
まぁ残念な話、チェックするのも害虫なわけですよ。

>>746
俺は CSK の孫か曾孫請けに一票入れとく

>>742
>マシな品質ほしかったら、ちゃんとスケジュールとコスト計算してねｗ
そうだねw
バカみたいな単価ふっかける割にできがわるいなら、中国人でも雇うことにするよwww

>>746
ところで、まともなとこなんてあんの？

>>745
んなことた分かってるよ。こっちも氏ねといわんばかりに値切ってるからな。。
でもそうでもしないとマージンでない。マージンどころか、累積赤字が。。

>>750
まともなひとたちはまじでいそがしいのでねているとおもう
おれもふくめてまともじゃない

今東京海上のトータルアシスト入ってるんだけど、
ソニー損保に変えたいんだけど
手続きはソニーが全部やってくれんの？

>>749
単価にはリスク込みだよ、バカヤロー
単価値切るのはやめれ、こっちも貴重な人材つっこんでるんだからな
それ以上やるんだったら、こっちもDQN人材と交代すっからな

このスレは「目的と手段を混同しない」という
初心を思い返す意味では価値があるね。

後は、客の視点で物を見て・考えられるようになれよ。
泥臭い職種なんだから。

>>746
Nはちゃんと書くが、客や現場が読むことをこれっぽっちも考えてないw

>>754
よろしい。
では、君のところの子請け・孫請けと直接契約するよwww

>>743
>>731の言ってるのは、言語内言語とか独自文法とか定義できるような
本格的なメタプログラミングの事だと思いますよ。

でもそんなの業務システム開発に使うかなあ…。

>>756
キミのような大企業じゃ、契約相手がちっちゃすぎて、
稟議とおらないに１票ｗｗｗｗｗｗ
せいぜい、リベート受け取ったとか五回されないようにがんばれよｗ

>>754
　　　　　　　　　　　　　　　　　　　　　　＿＿＿＿　　　　､ミ川川川彡
　　　　　　　　　　　　　　　　　　　　／:::::::::::::::::::::::::""'''-ミ　　　　　　　彡
　　　　　　　　　　　　　　　　　　　//, -‐―､:::::::::::::::::::::三　　ギ 　そ 　三
　　　　　　　　　　　　＿＿_　 　 巛/　　　　＼::::::::::::::::三.　　ャ 　れ 　三
　　　　　　　　＿-=三三三ミミ､.//!　　　　 　 ｌ､:::::::::::::三　　グ 　は 　三
　　　　　=＝三＝￣　　　　　　《|ll|ﾆヽ　l∠三,,`＼＼::三　　で 　 　 　 三
　　　　　　　 /　 　 　 　 　 　 　 |||"''》 ''"└┴‐`　`ヽ三 　　言　 ひ 　三
　　　　 　 　 !　　　　　　　 　 　 　| /　　　　　　　　　 三 　　っ　　ょ 　三
　　　　　　　|‐-､:::､∠三"`　　　　| ヽ=　　　　　U　 　三.　　て 　 っ 　三
　　　　　　　|"''》 ''"└┴` 　 　 　 | ゝ―-　　　　　 　 三　　る　　と　 三
　　　　　　　| /　　　　　　　　　　　ヽ　""　 　 　 　 ,.　三 　 の 　 し　 三
　　　　　 　 | ヽ= 　 ､　　　　U　　　 lヽ､＿__,,,...-‐''" 　三 　 か　 て　 三
.　　　　　 　 | ゝ―-'′　 　 　 　 　 | 　|::::::::::::＿,,,...-‐'"三　 !?　　　　三
　 　 　 　 　 ヽ　""　 　 　 　 ,.　 　 | |￣￣￣　　　　　　彡　　　　　　ミ
　　　　　　　　ヽ､＿__,,,...-‐''"　 ,,..-'''~　　　　　　　 　 　　 彡川川川ミ
　　　　　　　　　　厂|　　厂‐'''~　　　　　　〇
　　　　　　　　|￣＼|　／

>>751
どの会社の方？
今までの書き込み見てると、絶対に関わりたくないんで、ぜひ教えてください｡

>>747
趣味いうなｗ

つーか、外注の投げ方が悪いんじゃねーか？

>>718

真剣にうぜーよ。言語厨。

COBOLじゃない開発なんていくらでもあるだろ。
そっちの仕事をうけとけば、人材集めに関係ねーだろ。

>>731
> 数百人で開発するようなシステムでは混乱をまねくだけの代物だと思う。

そんなことないだろ？実際にそうしてるプロジェクト多い、というかそうしないと
怖いだろ。大規模ほど。

そりゃLispと比較したら敵わないけどさ、XMLに定型のコードを書かせたりする
ことで成果物の出来不出来をかなり減圧できる。

>>758
はいはい。
明日お客様がぶちきれないように、ちゃんとソースから仕様書起こす仕事に戻りなさいwww

>>760
まぁ、今回は引き分けってことにしといてやるよｗｗｗ

>>761
小規模で、ゼッタイ赤字にさせない自信があるなら、
なにやってもええんちゃう？
投げ方が悪い感は否めない。しかし、時間がないので
どうしても製造最優先になってしまうがな。。
納期が諸悪の巨根源だろう。

>>754

単価交渉に応じんなよ。
どんだけ自転車操業。

ID:TyYURaTSの話はリアル過ぎて嫌。

>>764
いちいちうるさいやつだな。
オレは、ソース書きながら仕様書の根幹を書いてあるから、楽勝だっつの。
まぁおかげで、コーディングスピードが常人と同じくらいまで下がってしまうんだがｗ
明日、コメントにおまえの悪口書いておいてやるよｗ

>>708
確かに XML でロジックはプログラミングできる。XML は極めて単純な言語だから。
でもそれって COBOL の構文を XML で再コーディングしただけのものにすぎない。
それに何の意味がある？自分には見いだせない。

XML はコーディングよりも抽象度の高い局面で利用されるものだと思う。
たとえば XML化に意味があるのは仕様書。

>>765
＞まぁ、今回は引き分けってことにしといてやるよｗｗｗ

幼児向けのアニメ以外で、ここまで香ばしい定型句を使う人も珍しい。
ローゼン閣下の治世になれば人間国宝にしてもらえるな。

上質なシステムを作るには上質な開発者がいる。
が、上質な開発者は火消しに使われるから集まる事は無い。

つまり、そういう事だ。

>>765
せめてどこの開発業界かだけでも言い残して去ってくれ。
まぁ銀行・保険系は金融庁の監査とかあるから君みたいなところは使えないと思うが。

>>766
背に原は変えられない。ホントに。自転車操業ってわけでもないが、
時期案件とかチラつかされたら、一発で撃沈。受けざるをえない。
そういうのまじでやめてくれ。毎回真剣勝負させてくれよ。
生かさず殺さずが一番ひどいと思う。

>>767
全部事実だから仕方ない。
結局、アプリ開発なんて偽装ばっかだよな。。
米はバレて、なんでITはバレねーんだろーな。
きっと、ITで人は死なないからだろーな。。（中の人は除いて）

>>768
>明日、コメントにおまえの悪口書いておいてやるよｗ
楽しみにしてるよw
俺のことは「お客様」、てめえのことは「土方」でよろしく。
ちゃんと2ちゃんで遊んでたって書いとけよwww

しっかし、ID:TyYURaTS、マジ面白すぎw

>>768

えっと。「だから値切られるんだよ！」と一言言っておく。

>>772
業界？幅広くやってるよｗ　いろいろとｗｗ
結局、業務知識ないから、どこでもやってけるんだよね。。悪いクセだ。
まぁ、今度請け負ったらお手柔らかに頼むよｗ
ちゃんと払うもん払ってくれたら、ちゃんと作るからさ。
追加請求には応じてやってくれ。

>>765

うーん。ノウハウ溜まってない感あり。

新人に投げる仕事は赤覚悟。
そのかわり自分の仕事は効率よく稼ぐぞ。

無茶な納期には先回りしろ。「最低限ここまでできます。」って。

>>776
俺は客の立場だが、単価値切る会社って大概品質が悪い会社なんだよなw
小さい会社でも品質よければ単価上げてるし。

つうか、俺自体も元はSIer(笑)だったんだが。
やっぱ客が楽だわw

学校ではCOBOL中心の授業でした
Cがよかったなぁ・・・。

>>773
＞時期案件とかチラつかされたら、一発で撃沈。受けざるをえない。

日々の仕事をきちんとやるから、次期案件がある。
これは同意してくれるよね？

＞毎回真剣勝負させてくれよ。

泣ける

>>774
客もにちゃんでクダ巻いてたって書き添えておくんでよろしくｗｗｗ
>>776
ハァ？こっちは納期必死で突貫工事してんだよ。
値切られる筋合いはないが。

ﾋﾞｼﾞﾈｽNews板でTopってどういうわけだ？

>>769
Cobolのコンバートは、単に資産を使いたいならそうしたらいいんじゃないか？ってこと。

だけど、Cobol.Netだとか、Cobolでブラウザスクリプトとか、そういうのは勘弁してほしいわけ。
あくまでもJavaなどの言語経由で、手軽に扱えるようにしたい。

コボルはスクリプト言語レベルの仕様だと思うから、XMLフォーマットになってれば別に
大した構文解析なんかしないでも扱えるでしょ？

>>783

いや。だから。「値切られる筋合いに早く気づいて、抜け出しな。」と言っている。

>>778
おまえ、、俺らを頃すきかｗ
「最低限ここまでできます。」⇒０．１秒後⇒「あそ。じゃ、次から頼まないからいいよ。これで。」
どうしてくれるんですか？

>>779
大企業ほど値切る摩訶不思議さｗ

>>781
ううん、ぜんぜん同意できない。一番安いとこのみ、次期案件があるの。
わかった？

>>783
>客もにちゃんでクダ巻いてたって書き添えておくんでよろしくｗｗｗ
頼んだぞw
さて、まったく関係ない客がそのコメント読んでどう思うかだなwww

ID:TyYURaTS に少し同情してきた。

>>786
ホントは何もかも気づいてるんだよ。。なにがダメかを。。
だけど、、ひょっとして次案件だったらどうにかなるかも、今までの赤字も
埋められるかも、と思われるとこがひどい。
受注がなくなるっつーことは、収入が途絶えるっつーことだからな。
つらいときほど、逆に先の先を見てしまう。それがダメなことも分かっているんだが。。

仕事として作るプログラマは死ぬほど退屈だろうけど、COBOLは悪くないと思うよ。
むしろJavaが余計だな。ベテランしか基幹のCOBOL書けないんじゃ不味かろうに。

>>787
＞ううん、ぜんぜん同意できない。一番安いとこのみ、次期案件があるの。
＞わかった？

俺もよくわからん、安物買いの銭失い.と言うが
東京証券取引所のブランドイメージは金銭的にはいくらになるんだろうかね？

>>787

いやだから、契約段階でだなｗ　もういいや。
多分もっと効率化できるね。君のところは。。

意外と ID:TyYURaTS に同感するｗ

>>777
うちは単価そこそこ高いし、こちら側の仕様変更・不手際なら追加請求も応じるし、
研究調査・製品評価・某大手インチキコンサル/アーキテクトとのリアルバトル大会
(こちら側のエロい人の支援部隊) とかあるから楽しいよ。

>>788
本とに書くわけねーだろ　ばか！Base64で暗号化して書いとくわｗ

>>789
そういう大企業も、結局社員の給料はさして高くもなく、（漏れらから見たら
とんでもねー高額だが）結局同じ業界で価格競争にあけくれ、、
そのしわ寄せが俺らにきて、薄給だとロクにモノも買えず。。
もうね、誰が悪いんだか、わけがわからん

>>785
>コボルはスクリプト言語レベルの仕様だと思うから、XMLフォーマットになってれば別に
>大した構文解析なんかしないでも扱えるでしょ？

フォーマットを担保するためのXSLTを作るのにも構文解析が必要ですよ。ていうか自分で作る気ですか。
あと、仕様だと思うから、って何ですか、思うから、って。


それはそれとして、>>769は仕様書をXMLにしてどうするつもりなのか聞きたいな。

>>795
＞もうね、誰が悪いんだか、わけがわからん

おそらく、あんたの書き込みも
あんたのギャラを下げる要因になっていると思うぞ。

ID:TyYURaTSが個人請けか会社かは知らんが
適当に来る仕事喰い散らかしてるっぽいね
この業界、何でも出来るは、何も出来ないに等しくて
これだけは他に負けない的に突出してるほうが長生きできるよ。

つーか、客を躾けるのも仕事のうち。

>>792
客が何考えてるかはさっぱりわからん。
でも、今さえよけりゃいいのは確か。
今、ここでコストカット！外注も単価さげさげ！
どうにもならんね。。

>>793
そうだよなぁ。最初が悪いんだろうなぁ。
でも、確信犯的にやられると、受けちゃうよね。。
最初は景気いい話だったんだがな。。

まぁ、結局、世の中は食うか食われるかってことか。

>>795

えとね。価格競争の元凶といえなくもないJava,C/C++。

>>796
>フォーマットを担保するためのXSLT
失礼、スキーマの間違いでした。眠いよ。

>>795
お前が悪いんだよ。
とりあえず、一生懸命やってるのにとか他人のせいにすんのやめろ。
金を稼ぐのがビジネスだ。駆け引きも仕事のうち。

資格もあって実力あるんだろ？それならいくらでも道はあるだろうし、そういう判断もあるぞ。

>>795
>Base64で暗号化して書いとくわｗ
ちっ、口だけ番長かよw

さて、俺はそろそろ寝るが、 ID: TyYURaTS に一言だけ言っておこう。
いやなら客になれ。世の中は180度変わるぞ。
まあ、死なない程度にがんばってくれい。

>>796
> フォーマットを担保するためのXSLTを作るのにも構文解析が必要ですよ。ていうか自分で作る気ですか。

必要だけど、別にデラックスなものじゃあない。あと、俺は実装しないw

>>798
食い散らかしてねーよ！
価格だけでしか判断しない客をしつけるのはムリ。
価格一番安く、品質一番高く。
>>800
分かってますがな。。

まあいいや、仕様書があと２０個あるんですが、
寝ながら書くことにします。

またな！

>>795
>>Base64で暗号化して書いとくわ
Base64は暗号化とはいわんだろ。

>>803
冗談だったのに。。MD５で暗号化しときます。これでいい？
そうだな。まぁ同胞を救い出してから、脱出するとするわ。

>>805
が、がんがれ？

ブランドを確立できなかった企業は、
ダンピングしか道は無いということか、哀れだな。

この業界、買い叩かれてる奴はとことんだなw

>>805
なんか涙出てきた
無理すんなよ、言っても無駄とは思うが

>>808
>>811
うお！最高にありがとう。
まさかにちゃんではげまさされるとは。。
死なないようにがんばるぜ。

敵の兵隊が戻ってきたので、にちゃん落ちます。またな。

>>804
そうでしたか、ちょっと安心しましたｗ

やるならCOBOLソースを直接Javaなりに食わせた方が早いと私は思うけどな。
仮にもソースファイルなんだからさ。

でも実務で使えるものでって言うと…想像したくないｗ

>>785
XMLフォーマットにした COBOL の「コード」を Java で何するの？
確かに Java でCOBOL の言語処理系を書けば「コード」を手軽に扱えるけど、
それに何の意味があるの？結局、COBOL の知識が前提になると思うが。

COBOL が出力した「データ」を Java で手軽に扱いたいから、「データ」の
フォーマットを XML で統一すべきという主張なら理解できるのだけれど。

正味、ID:TyYURaTSは今年度一杯がせいぜいだろうな。
コスト最優先の客でも丸め込む方法あるのにね。
南無ー。

>>815
だな。
まあ、取り返しのつかない状態になる前にに脱出できればいいが…。

>>815
継続的に仕事を任せてくれるなら。。。とか。。。
納期前倒しできたら。。。とか。。。。契約内容でもにょもにょ。。。

やべぇ・・・・いい加減寝ないと今日起きれないぜｗ

ああ。おやすみ。

ＣＯＢＯＬ。。。
誰が書いてもあまり酷いのはないってのは利点かもしれない。。。

>>1-2
察するに、色々手を出してみたが、COBOLから置き換え
できなくてグタグタなしすてむになってそうだね。
もっと勉強して下さい。

>>796
常識的な事だとは思うが、仕様書が XML になれば、機能(ビジネスロジック) -->
実装(モジュール) --> コード の三者に関する一貫した設計リポジトリが
実現できる可能性がある。数百人規模の開発体制と長期間の保守・維持を考えれば
絶対に必要な環境だと思う。当然、バックエンドは XML データベースになる。
死語かもしれないが「ソフトウェアCALS」の世界。

>694
XSL ゴリゴリ書いたことある奴なら分かると思うが、XML はフローを記述するのには向いていない。
XML をコードに適用するメリットなんて構文木の解析が楽になる程度の事。

一方でビジネスロジック用の手続き型言語なんて条件分岐と繰り返し文、それにサブルーチンコールと、
利便性のために switch 文、for 文などがあれば十分だから、単純かつ厳格に規格化した言語構文を
定義してやれば XML 使うメリットなんてないという話。仕様書からコードを自動生成なんて誰もが思いつき
失敗した事を考えてるなら別だけど。

あーでもビジネスロジックみたいな単なる単純フローの塊なら何とかそれもできそうな気がするなー。

CORBAでええやん。

>822
みんな同じこと考えて失敗してきた歴史ってのは常識のうちに入らないのか。
数百人規模で仕事するなら普通専門チーム付けてシステム組むだろ？
でもプログラマーは自分が片手間に工夫すればOKとか思っちゃうんだよな、なぜか。

>>810
そこで笑うかな
只の頭でっかちちゃんか

昔月間エンターにこんな４コママンガがあった

ゲンゴロウ「俺はゲンゴロウ、北斗の拳のゲンゴロウだ」
ゲンゴロウ「フォオオオオオトラン」

敵「なんだてめぇは」

ゲンゴロウ「あたぁっ」BASIC！！
ゲンゴロウ「あたたたたた」LISP！、LISP！、LISP！

敵「へっなんともねぇぜ」
ゲンゴロウ「おまえはもう死んでいる」

敵「うわぁぁぁ　コ、ボ、ル」

COBOLは化石

>>823
確かにビジネスロジック用のコーディング言語は、単純かつ厳格な構文を定義すれば
いいでしょうね。そして、そのコードをXML化するプリプロセッサを用意できれば、
ビジネスロジック記述文書の再利用が可能になるのではないかと考えます。

>>823
昔ちょっと使ってたジェネレータにDF-COBOLってのがある。
今はなき旭化成情報システムが開発した。

これ、フローチャート記述＋処理はCOBOLみたいな言語で、フローチャート
部分は、SORTだMARGEだMATCHINGだってのが用意されている。処理部分なんて
計算式と条件分岐と代入くらいしかないから、見ればサルでもわかる。

展開後のCOBOLソースはバカでかくて、オーバーヘッドはでかいし、プリコン
バイルに偉く時間がかかるけど、それでもバッチ処理のプログラムの生産性は
異常なほど高かった。関数も自分でいくつか追加したけど、マニュアル用意
しておけば、簡単に標準化できる。

ソース見れば処理がわかるので、ドキュメントを作らなくなるという問題が
あったけど、ま、そんなに問題になる事はなかった。逆に、普通のCOBOLなら
メンテの都合で分割したくなるところを、全部一つのプログラムにまとめて
しまって、可読性が増す一方で、やたらとでかいプログラムになりやすくて
そっちに難儀した。

ぶっちゃけ、今のCPU能力なら、あれくらい重いジェネレータでも問題ないの
ではないかと思う。

かたやYPSやらなにやら、やたらと汎用性を高めた標準言語も触った事がある
が、作法がやたらと煩くて生産性を著しく落とすだけだった。

JAVAやC系は出所のしれないライブラリを広域に分散して使用され次回のシステム切り替えで泣きを見ること必至

>>825

確かに >>822 の目的は、(失敗の歴史を経てきた)CASEシステムと同じです。
ただ、これまでのCASEシステムは、あまりにも帳票的というか、印刷物として
出力することに特化しており、それがユーザ(PG)に受け入れられなかった理由では
なかったのかと考えています。それが現在のWeb(ハイパーテキストシステム)のように、
リンクで「ビジネスオブジェクト-->モジュール-->コード」を辿ることが
できるようになれば、皆が利用したくなるのではないかと思います。そして、そのような
システムを実現するには、バックエンドとしてのXMLが必須ではないかと。

ま、また同じ失敗の繰り返しとなる可能性はあるのですけどね ....

COBOLは構造化プログラムに向かないだろ。
メインフレームなんて化石ですよ。
富士通のメインフレームで使ってたけど、COBOLは糞だと思った。

>>833
> 富士通のメインフレームで使ってたけど、COBOLは糞だと思った。
俺もあんまり触ったことないけど、構造化されてたような・・・

>>833
COBOL以前に富士通のメインフレームがクソだからw

そろそろマ板の保守に帰れよ

>>304
ガラパゴス化って本当に馬鹿な単語だよな

今は他社に吸収された某社の広報誌の
「ハイテック575」というコーナーの

「〜涙コボル」(全文と俳号は忘れた)

を思い出す。

>>834
こぼらの知能が追いつかないので、ないのと同じですね。

値切りに応じる所ってそんだけ人あまってるってこと？
うちの所だとまったく人が足りてないから、
値切りは全部つっぱねてるけどな

>>834
COBOL自体は、構造化されている。
でも、何故か、COBOLプログラマーの中には、長ったらしいコードを平気で書く奴が居る。

>>840
ITヤクザと呼ぶにふさわしい連中が居てな、それはもう信じられない追い込みをかけてくるんだ。

>>842
IT屋は人売って何ぼだからな。
マネージャは奴隷のケツ叩いて働かせてなんぼ。

いまどきCOBOLは、コードをプリントアウトしてデバッグするんだぜ……

COBOLer がソース 2 つプリントアウトして、重ねて透かした時は笑ったな。
diff 使えよおっさんｗ

>>841
自分専属の仕事にする（＝他人に理解させないようにする）為に
自分理論で複雑化してPGをくみ上げるんだよ。
囲い込みみたいなもんだ。

他人に仕事を奪われたくないだろ？
だから誰にも触られないように、ブラックボックスを作るのさ。

ついでに時限爆弾も用意しておく。
自分しかそれは解除できないように仕組んでおくんだよ。
顧客から契約切られても放置しておくとシステムがダウンする。
自己防衛対策って事。

>>846
「ほら、契約解除するからそうなる」って暗黙の脅しなんだよ。
どのベンダーに頼んでも同じような仕掛けを作るから
顧客は言われるがまま報酬を支払うしかない。

これが、ベンダーロックの正体。
どのベンダーに頼んでも似たような思想でシステムを組むから
堂々巡りになる。

自分の居場所は自分の実力で作れって事。

今の技術者はそういった自己防衛力（＝創作・工夫）が
無いから買い叩かれる。

言われるがまま誰にでも理解できる金太郎飴のような奴が
量産されてるからちっとも技術が発展しない。

工夫も無ければ、創作も無い。
テンプレに書かれたマスを埋めるだけのボンクラが増えてるんだよ。

ハード屋が凄い勢いで進化してるのに
ソフト屋が昔の方法や理解するのが面倒だから
逃げてばかりいるのも問題なんだよ。

新しい機能をハードに組み込んでもそれを使いもしない。
理由は組み込むのがメンドクサイから、理解するのが面倒だから。

日本のIT産業は負け犬なんだよ。

コボルは、業務ロジックを小分けにしてコンポーネントを作るには神。
これらのコンポーネントを同期非同期で呼び出して美しく動かすのは一種の快感。
コボル以外で金勘定するなんて、バカのやること。

コボちゃんが来たぞー

C、C++、C#は、プラットフォームに依存しすぎる。
移植が難しすぎる。

CPUやGPUに組み込まれてる機能は無視？
何の為にハードの機能を向上してるの？

８色しか表示出来なかったGPUが２０年の進化を遂げ
３Dのグラフィカルな表記がこれだけ簡単に利用できるのに
利用されないのはどうして？

言語の問題に逃げるのは辞めたら？
言語シェア競争はもう終わってるんだよ。

３Dを駆使したフロントエンド表現の競争が
世界競争のトレンドなのに言語がどうとかアホなのか？

もう、呆れて物が言えんわ。

>>852
お前がアホだ

>>852
おまいはゲームの事しか頭にないから駄目なんだ。

保険屋は大人しく約款の改正でも書いておけよ。

>>852
（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）


日本のＰＧたちは天才過ぎるのですよ。
そんな程度の低い事はやりたくても出来ないんですよ。
最近はますます天才度が上がってます。
そんな彼らにはＣＯＢＯＬこそ最適のツールですよ。
ＪａｖａやＣなんか使わせたのが間違いです。
天才には使いこなすのは無理なんです。だからＣＯＢＯＬ復権です。

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

手段が目的だから。

世界に売れもしない物に金かけてもしょうがない。
村社会日本の悪癖だな。
「ぼくちんはCOBOL知ってます」って今更何言ってんの？
バッファはもう必要ない事が証明されてるのに。

世界標準の競争で負けたから
穴蔵に逃げる情けない日本人技術者集団。

(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)

日本標準。。。ＩＴ業界にはあふれすぎていますね。
日本のＰＧは天才過ぎますから


ハライタイ

(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)

生活保護でも受けとけよ。じゃまだっての。
COBOLで組みなおすぐらいなら紙とペンまで戻せ。

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

でも日本人はＪａｖａもＣもまともに扱えない
天才ばかりだからしょうがないですよ。
三輪車しか乗れない天災にバイク与えてもしょうがありません。
天才とはそういう扱いにくいものです。ククク　アッハハハハハ

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

利権が問題なら竹島で好きなだけ暴れて来いよ。
今更、言語競争で遊んでる余裕あるのか？
サービス競争が主流になってるのに。

そんなにCOBOLが好きなら、
ワープアと会社ニート集めて別会社作って
その中で遊んでれば良いだろ。

誰も相手にしないけど。

>>851
ところがけっこうCOBOLは処理系依存なんだぜ。

一人の男の好みで、大企業の未来を左右させてしまうのか

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

ますます天才度が上がっているようで。
そのサービス競争をコリアンやチャイニーズとインディアンと
やっている天才は言う事が違います。さすがです

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

業務を人ありきの昔に戻したいんだろ。
保険なんてリスク回避の条件とパフォーマンスしか見てねーよ。

顔見て営業説明受ける時間があるなら寝てるわ。

COBOLは現役というかずっと使っていくことはできるだろうな。

でもCOBOLを使う人がドンドン現役じゃなくなってくる。
問題はここなんだけどな・・・。

COBOLって大学とかのカリキュラムに入ってんの？

>>846
>自分専属の仕事にする（＝他人に理解させないようにする）為に
>自分理論で複雑化してPGをくみ上げるんだよ。
>囲い込みみたいなもんだ。

組んだ奴は、自分でも、そのコードを理解できないと思う。

そいつが作ったプログラムが上手くいかないから、簡単な修正を頼んだら、元のソースと全然変わっているんだぜ。
どこを直したか全然解んないの。

>863

確かにそうだよね。
COBOLのCは、commonのはずなのに、全然互換性ないの。

効率とかは犬に食わせろ。

ＣＯＢＯＬでできる奴をＣＯＢＯＬ以外でやっても
デスマーチになるだけ。

現状動いてるんだからニートに半年勉強させてCOBOL
覚えさせて保守させたほうがいいじゃん。

MF-COBOL
MIFES
PervasiveSQL
F-BASIC86
iii
Excel

個人事業主だが、これだけで１０年使えてる
アマチュアが使うならいい言語と思うがな

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

コリアンやチャイニーズやインディアンとサービス競争する天才には
ＣＯＢＯＬがお似合いです。
もっともＯＳやミドルウェアやゲーム等、天才様にやらせるのは
もったいない高度な分野はＪａｖａやＣ＋＋が必要ですけどね

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

以下
PROCEDURE DIVISION.

(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)

>>896　天才様の発想に難癖をつけるのはナンセンスですよ。

(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)

COBOLには触れる機会が無かった

化石なんだから掘ればいくらでも出てくるんです。

おーいてめぇら。

色々ばらすんじゃねぇよ＃

銀行系のシステム会社に入社しがんばってCOBOLを習得したけど
５年ほどまえCOBOLに未来はないと先輩に諭されて転職したorz

>>872
何故わざわざ競争するのか、意味分からん

５０才後半

ＰＬ１、ＣＯＢＯＬ、ＦＯＲＴＲＡＮ、ＡＢＭアセンブラー
全部できるがＣ，ＪＡＶＡできない
銀行オンラインメンテナンスしていた。
いまはホテルの従業員になった。夜間駆けつけないので幸せ。

COBOL叩きをしている皆様は、COBOLerの方が
年収が高いという現実に興味はないようですね。

>>503
\CONT HOGE01 GO

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

やあ皆、アフラトキシンしてるかい？
体重1kgあたり致死量は0.0006mgさ！すぐには死なない毒でつらいだろうけど
がんばって毎日１日３回主食のご飯でかかさず取ろうな！
100%肝臓癌になって苦しみぬいて吐血する日々をエンジョイできるぜ！
脳衰省公認のブランド工業米がアフラトキシン豊富でオススメだぜ！
ブランド工業米は脳衰省から三笠フーズ＋その他１６社しか入手できない希少品だが
あきらめるなよ！米業界の最新鋭テクノロジー、ブレンド技術で
君の食卓へきっとインしてるぜ！

【悪質食品詐欺】最強毒（アフラトキシン）の深刻さ
http://jp.youtube.com/watch?v=NFytk-odCXI

ならパン（小麦）を食うって、ウヒヒ
　
１個１５０円の菓子パンに農水天下りニート税５０円が
　http://jp.youtube.com/watch?v=ZfRS9C6hoeQ

（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）（笑）

>>210

亀だけど禿同。
ざっと読んでやっぱPG・SEってこんなのばっかりだなと思った。

自分の知ってる技術や分野から
相手の知らない技術や分野を以下に罵倒するか・・・
そこでしか自分を守れない香具師大杉。

逆のことされると途端に精神的引きこもりになりやがる。

Ｃが最強。異論は認めない。

>>880
それだけできるなら C 自体は全く難しくないかと
難しいというかめんどくさいのは言語じゃなくて環境依存の API 回り

>>210,884

お前らは此処がどこだと思ってるんだ。

親切な人と議論したいなら、それぞれのフォーラムで。

ここは2chだぜぇ？

>>887

おお、海賊様、ここは海軍刑務所ではありませんよ。

fjに比べれば2chなんてぬるま湯

>>878
COBOLに未来はないと言われ続けて10年は軽く経ってるｗ

COBOLなんてInternetTechと関係ないじゃん。

50歳代60歳近くのCOBOLerもいるし
歳食っても食いっぱぐれもなくやれるから細く長くやりたい人はいいんじゃね。

いい取引先をもっているならな

>>890
プログラマー定年３０歳とか言われながらも５０歳で現役だったりするorz

>>869
> 組んだ奴は、自分でも、そのコードを理解できないと思う。
いるいる、こういう奴w

そういや昔、「〇〇の値が××だったら何をする」みたいな単純条件分岐するような仕様を出したら、

IF 〇〇 NOT = △△ …

みたいな否定条件の条件分岐を書いてきて「テストが間に合いません」だの抜かしくさったCOBOLerオヤジがいたよw

即刻クビにしたけどw

いつまでたってもBASIC(Beginner's All purpose Symbolic Instruction Code)。
　　
COBOLと同類の手続き型言語に無理やりオブジェクト指向と構造化をぶち込んだクソ言語。

>>880
CよりもＡＢＭアセンブラーの方が難易度は高いと思うよ。

つか言語なんてどうでもいいだろｗ
肝心なのは「ビジネスロジック」を如何にロジカルにまとめられるか。

>>894
おまいの説明力にも問題あり。
自分で自分をクビにできないのが残念だなwww

>>896
難度の問題じゃあないと思われます。日本語は出来ても英語がダメな人なんてザラでしょ？

>>897
つまり、「頭が悪くて言語の違いが分かりません」ってことねw

>>897

おいおい。そのロジカルにまとめるのは言語だぞｗ

>>894
その例がどうだったかは別として
最近の論理否定を避ける傾向は行き過ぎだと思う。
論理演算できない人が増えているから仕方ないのかもしれないが
否定で書いた方がすっきりするコードまで変えてる気がする。

>>1の東京海上のシステムがどんなのか知らないし、COBOLも詳しく知らないけど、
夜間バッチとかはCOBOLでもいいと思うが、画面系はどうするつもりなんだろう？
COBOLといったら、ホストの真っ黒画面のイメージしか無い。
やっぱり、ホストエミュレータ？
もしかしたら、今どきのCOBOLの画面系って違うのかな？
HTMLを自動生成出来るとか…。

>>902
VB.NETで

If (A Is B) = False Then ...

なんてコードをよく見る。いや冗談じゃなく。

>>902
>>869 の例えとして>>894 がふさわしいとは思えないが、それは、おいといて、
COBOLプログラマは、論理思考は苦手だと思う。
とりあえず、文法が解れは組めるせいなのかもしれないが、下手くそな組み方しているやつが多い感じがする。

COBOL「も」バリバリに出来る人ならいいが、
こういう事言うのは大抵、COBOL「しか」出来ないダメおやじ。

東海上は場所がネック

>>903

>>1に
> 「ビューは若手を中心にJavaで， モデルはベテラン中心にCOBOLで開発していくという分担ができた」
って書いてありますがな。

画面はJSPかSwing、もしかしたらSWT辺りで作ってるんじゃないのかね。

>>908
ありゃ、すんません。

COBOLerには当たった試しがないので
COBOLerには偏見を持っている

>>881
年功序列だからでしょ。
これから大卒で入社して同じギャラで働かせてくれるなら喜んでやるよ。
耄碌しかけた中年三人分くらいの仕事はできると思う。
体力の具合によってはEclipseのプラグインやクロスコンパイラを
作ってもいいくらいだ。
ただし、その場合浮いた分のギャラは全部よこせ。

>>911
クロスコンパイラと言うよりは、クロス逆コンパイラか

>>903
事務のおねーちゃんに言わせると、マウスであちこち触らなければ
ならない画面より、タブでパコパコ飛ばしながらテンキーで数字を
打ち込むだけの画面の方が楽で仕事がはかどるそうです。

奴ら、A4数枚程度の良く使う顧客コード・商品コードくらいなら
暗記どころか指が覚えているからな。なかなか侮れないぞ。

>>911
> 体力の具合によってはEclipseのプラグインやクロスコンパイラを
> 作ってもいいくらいだ。
EclipsePluginは随分前からあるよ、作るんだったら恥ずかしくないもん作ってね｡

色々言語をやった挙句、否定の比較演算子が、NOT =なのか、<>なのか!=なのか
使っている最中に訳がわからなくなってますが、やっぱり事務処理ならCOBOLが
最強だと思う。オセロゲーム造るんならJAVAかC++だけど。要するにこれは優劣
じゃなくて、向き不向きなんだよ。

伝票処理の延長線上に事務処理があるという事実は、どんなに時代が進んでも
変わらないと思うぞ。

>>910
まぁ、その、な。
オブジェクト指向言語は触らせたらいけない。
徹底的に再教育しないと、酷い目にあう。

>>911
とはいえ、事実メンテナンスできる人は減っていて、
その割にはCOBOL資産は意外としぶとく残っている。
ということは今後も希少価値が上がりうるし、高くても不思議ではない。

つまり…発注者側にCOBOL関係者がいるのか??
もしくは過去データの消失を恐れてか??

>>913
> タブでパコパコ飛ばしながら
ホスト上がりのSEならエンター（リターン）キーを選ぶところ。

これも意見が分かれそうだ。

業務こなす画面にGUIはいらないだろ、

随分前に業務用画面を全てWEB化なんて流れがあったけど最近一向に聞かないな

>>919
GUIが要る/要らないは想定する業務によるんじゃないの？

WEB化の話題を最近聞かないのは選択肢の一つとしてアタリマエの存在になったから、だと思うけどな。

>>918
>ホスト上がりのSEならエンター（リターン）キーを選ぶところ。
Enterっつうか、復改キーかな？　懐かしい。

第３次オンライン育ちのお局様と、クラサバ育ちのアラフォー(笑)や
スイーツ(笑)世代でtabかenterかは分かれそうな気がするが、
いずれにせよ、定型事務処理は>>913の言うように原始的なGUIが
好まれるよね。

確かに俺自身もマウス嫌いだしなあ。

事務のおねえちゃんも、ハッカーも、CUIでコマンド打ち込む感覚で
使える画面の方が使いやすいんだよね。

>>916
2000年問題のときに既にCOBOLerの単価が高かったので
COBOLerを先生にして新卒にCOBOL仕込んだって話を友人（仕込まれた側）から聞いたなぁ…
その世代でももう30過ぎか…

>>921
VB（てかWindowsクライアントの出始めの頃）で
「エンターで項目移動させろ！」
とクライアントに要求されて泣いたのは俺だけで無いはずだｗ
あ、もちろんSHIFT＋エンターで逆順だ。

「キーボードのエンターの上かテンキーの上辺りにTABつけてくれれば解決するのに・・・」
と思ったもんだ。

COBOLは画面の制御が苦手で、オンラインで全画面を操作する
プログラムが増えるに従い、操作性の悪さから急速に廃れたよな。

>>922
事務処理の画面でも、入力項目が100以上あってTAB移動しても遅くて、
結局マウス使った方が早いじゃんな画面がですね…いやなんでもない。

お前らゲームでもやってUIってやつを学んで来てください。おながいします。

ＣＯＢＯＬのプログラマー時代

いきなり２０００枚以上のコーディングさせられ鑽孔カードを機械に掛けるのが苦労だった
金利計算のプログラムだった

>>924
俺は名古屋方面の某社の業務システムのweb化で「エンターで…」をやられたよw

「今までと同じ操作性を担保するのは必須要件」とか言いやがってさw

結局やんなかったけどね。

>>924
キーマップ変えちゃえ。
そのアプリにフォーカスはいったら切り替えるの。

>>926
>事務処理の画面でも、入力項目が100以上あって

いったい何を入れるんだよ、その画面wwwww

金利計算とか一括処理はコボルが一番得意とするところ

購買とかの古参の労務者は古いインターフェースに
こだわるんだよね。こっちのほうが早いとか。

結局、某ビジネス機のエミュレーターの上で動かしていたような気が。
大昔のことだけど。そういった人間を飼っていることによるコストが
製品に上乗せされるという泣ける状況になる。

>>930
売上伝票だったかな。項目が一画面に収まりきらなくなったら代わりにボタンが増えだしたよ。
押したらサブ画面が開くやつな。そこで俺は数えるのを止めたね。

顧客はこんな画面使いこなせるんですかって聞いた事もあったかな。返事は返ってこなかったけど。

>>933
それ、画面設計からしてダメダメだなw
まあよく見かけるけど。

一画面に収まりきらなくなったら、自動スクロールするように
プログラムするのが常道だろ

噂に聞いたのだが、
いや決してそんなことあるわけがないと俺も思っているのだが、
まぁ、その、なんだ、ここで聞いてみたいと思ったんだ。

とあるCOBOL処理系ではでWinアプリが書けると聞いたのだが、マジ？
んなわけねーよなｗｗｗｗｗｗｗわりぃ最近仕事が忙しくてちょっと
パラノイアきてんだよね〜

というか、売上伝票ごときに100個の入力欄がいるとは思えない。

システム化される以前の手書き伝票を１枚起こす度に100個の項目を書込んでいたなら仕方がないが
そんなのは普通あり得んわな。

>>935
まあ、客の頭の程度にもよるけど、一画面に収まらなくなったら
入力項目を分類して複数画面にして入力の生産性とシステム自体の
レスポンスを上げる、という考え方もあるんだが。

>>929
記憶があやふやだが確かそれだけだとうまくいかなかったような。
どうやって逃げたんだったかなぁ？

あともう一つクライアントによく言われた悪魔の言葉
「エクセルみたいにしてよ！」
だったらエクセル使ってください・・・
さすがに最近はどっちも聞かなくなったなぁ。

>>936
普通に作れるが？
http://www.coboler.com/ima01.htm

>>936
１5年前ならマイクロフォーカスと言う外国の会社のコボルのOEM製品が
日立とか東芝のＰＣに採用されてたよ，ＭＳ-ＤＯＳだけど
WINDOWS版もあるんじゃない

>>938
項目の利用頻度も含めて、商品体系を見直しとほうがいいのだけれど
一介のSEごときがそんな提案を下手にして
先方の怒りを買って上司にチクッたりでもしたら
下手すると一生出世の道が断たれるからな。
会社や上司にもよるだろうけど。

レガシーシステムを後生大事にしている会社は本気で
脳内お花畑が少なくないし。

>>937
そりゃ画面一枚＝紙一枚に対応している訳じゃないからね。
そもそも紙一枚で済むような売上情報＋αなら100項目とかなるわけないでしょ。
まあ、それを差し引いても酷い設計だったけどね。

プログラムなんてぜんぜん組まない銀行員融資担当の僕でつが
CとC++とJavaとVBAならつかえまつよ

＞売上伝票ごときに100個の入力

売上伝票でないけど、あったよ
ドッカンと１億円くらいの入金があって
これで売掛金明細の消し込みをする仕様のプログラム