353 :
仕様書無しさん:04/03/13 22:29
日本の病院と同じだよな。
多すぎるんだよ。ソフトハウスが
354 :
仕様書無しさん:04/03/13 22:43
技術の進歩は当然だが、
新しい技術 = ユーザーにとって役に立つ技術
とは限らない点がポイント。
COBOLや汎用機は数十年現役だが、技術的に新しく優秀だが消えたOSや言語は無数。
355 :
仕様書無しさん:04/03/13 22:54
「新しい技術で作りました!」と言って、その技術が5年後に消えてれば、
無くのは保守できないユーザー。デファクトのメリデメは再認識しよう。
356 :
仕様書無しさん:04/03/13 23:01
357 :
仕様書無しさん:04/03/14 00:25
Cで作るかCOBOLで作るかはユーザー数による。
薄利多売で行くのなら、COBOLなんかで作ることは出来ない。
COBOLerでは汎用的な物なんて作れないんだから、パッケージといってもせいぜい数ユーザー程度のものだけ。
コンシューマー向けや、ビジネス用でも一般的に知られているようなものでCOBOLなんて聞いたこと無い。
要するにCOBOLが使えるのは以下の条件を満たす場合のみ。
(1)ユーザー数が少ない
(2)業務アプリで低レベルな制御が不要なもの
但し、上の条件さえ満たしていれば、COBOLを採用することにより以下のメリットがある。
(1)確保した要員がDQNばかりでもなんとかなる。
(2)確保した要員が夜逃げしても、空いた穴はすぐに埋めることが出来る。
(3)人月商売なので、「品質って何ですか?」という方針が可能。
(4)発注側もDQNが多いので、DQNを送り込りんでも金になる。
>要するにCOBOLが使えるのは以下の条件を満たす場合のみ。
>(1)ユーザー数が少ない
>(2)業務アプリで低レベルな制御が不要なもの
たとえば、どんな業種だ?
データベースは、oracleとか、つかうの?
バッチ処理は、ストアドでかくの?
画面は、VBがつくりやすいね
じゃあコボルはどこで、つかうの??
359 :
仕様書無しさん:04/03/14 00:43
バカ晒し上げ
>>354 普及度の点で勝る古い技術を、扱い易さで勝る新しい技術が駆逐していった例。
CP/M → MS-DOS → Windows
漏れの予想する未来。
COBOL → Java
今さらだけど、「13歳のハローワーク」って書いたのは村上龍じゃん。
なんか、最近、経済関係の本を出しまくっているらしいが、、
「2000年問題でインド人が・・・」の話をここで聞いて、
やっぱダメじゃんと思った。
362 :
仕様書無しさん:04/03/14 08:20
>>357 実態は逆だよ。
(1)COBOLユーザーは昔からの大手に多い
(2)COBOLは業務記述言語だから、制御は最初から別言語で書いてる(ASMとか)
小さい処理ならCで手軽に書いていい。
が、巨大なシステム(1000ユーザーとか)は、その開発・保守に適した言語を選ぶ。
富士通の作った銀行システムなんて、業務は全部COBOLだし。
363 :
仕様書無しさん:04/03/14 10:23
>>357 薄利多売とか出すなや。(w
そもそもCOBOLは、その会社だけのために作られるプログラムばっかりだ。
ユーザー数で言語を決める?んなわけねー(w
穴埋め簡単?2007年問題なんていわれる問題がおきるんだ?(ww
364 :
仕様書無しさん:04/03/14 22:12
「xxxx年問題」なんてのは需要掘り起こしを目的とした煽りにすぎない。
>>364 じゃあ、2000年対応で修正したソースの数々はなに?
366 :
仕様書無しさん:04/03/14 22:26
明日起こるかもしれない問題だな。この2007年問題と呼ばれているものは。
その会社の定年退職者の状況次第。
規模が小さければ引継ぎができる。
大規模となると、たぶん退職後にアルバイトできてもらうことになるだろう・・・。
仕様がわからねーもんどーにもならんよ
>>364 >じゃあ、2000年対応で修正したソースの数々はなに?
需要の掘り起こし
368 :
仕様書無しさん:04/03/14 23:01
不安を煽って物を売りつけるなんて霊感商法と一緒じゃん。
子供相手に話しても時間の無駄
370 :
仕様書無しさん:04/03/16 00:08
最近はオープン系COBOLが本格的に広まって、技術者不足らしい。
要因は
・若者はVB, C/C++, Java, Perl とかに集中して、COBOLが手薄になった
・Fとかが汎用機・オフコンCOBOLの移行に本腰を入れだした
・MicroFocus COBOLが日本で整備されて数年、実績が広まってきた
・「最新」に振り回されたユーザーが、「事務計算に集中できるCOBOL」を再評価しだした
・若者はVB, C/C++, Java, Perl とかに集中して、COBOLが手薄になった
→いまさらCOBOLやれって言われたら暴動がおきるw
・Fとかが汎用機・オフコンCOBOLの移行に本腰を入れだした
→「Fとかが」だけでお腹一杯。
・MicroFocus COBOLが日本で整備されて数年、実績が広まってきた
→どの程度w
・「最新」に振り回されたユーザーが、「事務計算に集中できるCOBOL」を再評価しだした
→すでにその頃の「最新」は「標準」になっている。
>最近は・オフコンCOBOLの移行が本格的に広まって、技術者不足らしい。
はー??
オフコンハードのリース切れによる、
オフコンCOBOLの移行の需要はとっくに
ピークを過ぎたはずだが??
でいまは、やっぱりインチキCOBOLオープンシステムは、
OSのサービスパッにクを当てると、動作保障しない等
の問題から、本格オープンシステムへの移行がふえているが
田舎ではそうなの??
373 :
仕様書無しさん:04/03/16 01:08
世の中にはCOBOLでwebプログラミングをしている人もいます。
「お疲れさん」としかいいようがない・・・。
今時、ENVIRONMENT SECTION だってよ。
頼むから、大文字で書くのやめてくれよ。
変数がグローバルなのか定数なのかローカルなのかわかんねぇじゃねえかよ。
銀行システムも今は Javaで開発し、オブジェクト嗜好により
かなり、工数削減し、品質も向上してる
>373
COBOLのソースをまだ見る機会があるのか
不幸だな
COBOLでweb???????
おれも、聞いたことは、あるが本当につかってるとこが
あるんだ
377 :
仕様書無しさん:04/03/16 10:02
>>373 ENVIRONMENT SECTIONって釣りか?
ENVIRONMENT DIVISIONだろ?
COBOLプログラマをやっている。本命のJavaプログラマに配属されなかった瞬間即決した。
カッコイイ、マジで。そして有名。名前を出すとみんな知ってる、マジで。ちょっと
感動。しかもCOBOLなのに漢字が使えるので分かりやすくて良い。COBOLはオープン系が弱いと
言われてるけど個人的には優れていると思う。Javaと比べればそりゃちょっとは違うかもし
れないけど、そんなに大差はないって富士通の社員も言ってたし、それは間違いないと思う。
ただ再帰とかあるとちょっと怖いね。COBOLなのに処理が動かないし。
処理速度にかんしては多分COBOLもJavaも変わらないでしょ。Javaをつかったことないから
知らないけどオブジェクト指向が使えるかどうかでそんなに変わったらアホ臭くてだれもCOBOLな
んて使わないでしょ。個人的にはCOBOLでも十分にセキュリティに強い。
嘘かと思われるかも知れないけど富士通からCOBOL.netの案内が届いた。つまりはあの
富士通ですらCOBOLには一目置いていると言うわけで、それだけでも個人的には大満足です。
380 :
仕様書無しさん:04/03/17 22:49
>>378 たしかに言われる通り。
恐怖というか、殺意すら覚えます。
あの例題の内容では、普通は使わないであろうと思われるシェルスクリプトでCGIを書いたとしても、
COBOLより簡単に書けてしまうあたりが、COBOLの恐ろしさを物語っている。
>>378 こうしてみると、行数稼ぐには最適の言語であることがよく分かりますな。
あとコボラーオヤジがソースを紙出力する習性は、狭い画面でこんなの弄っていたから
身に付いたんでしょうな。
こぼらって自分を客観的に見ることってできんのだろうか?
主観的にマンセーしてる奴しかみたことない気がする。
383 :
仕様書無しさん:04/03/18 21:37
>>381 それがCOBOLの利点じゃん。マジで。
A = (B + C) * D みたいな単純な計算でも、多くの場合は数行で書く。
バカ長い代わり、税制変更とかでも、どの1行を直すか(追加するか)、
スキルが低くても明確にわかる。
極論すると、英文に近いから、仕様書がそのままソースになったような感じ。
CやJavaは1行以内でスマートに書けるが、標準化しても個人差が出やすいし、
他への誤影響を出しやすい。
当然、C/Java PGから見るとCOBOLは非効率なバカに見えるが、
COBOLの作られた目的は、もともとシンプル標記では無いのだ。
>バカ長い代わり、税制変更とかでも、どの1行を直すか(追加するか)、
>スキルが低くても明確にわかる。
しかし同じコードをコピペで増やしていくから、変更箇所の調査にかかる工数は結局(以下略
しかもコボラーのオサーン達はgrepすら(以下略
385 :
仕様書無しさん:04/03/19 02:44
>>384 メインフレームにはgrepなど無いし使う必要もない。
ISPFでほとんどの事はできるのだよ。
これだからUNIX厨は(w
>英文に近いから、仕様書がそのままソースになったような感じ。
その時点で日本人にはダメダメのようなw。一時期はやった日本語でCOBOLって
まだやってるんですかね。
日本人のCOBOLプログラマーは皆死んでいるので
このスレにはインド人しかいないというのは本当ですか?
388 :
仕様書無しさん:04/03/19 08:19
インド人の中の人にCOBOLプログラマーなどいない。
またかれらは形から入る人なのでデスマーチなどしない。
389 :
仕様書無しさん:04/03/20 15:14
>>387 大ウソだよ。村上龍はインタビューする相手を間違えたな。
>>384 ISPFだとGREPに近い事ができますが何か?
390 :
仕様書無しさん:04/03/20 15:15
日本人の中にCOBOLプログラマーなど痛い。
また彼らは宴会から入る人なので、日産マーチで運転などしない。(飲酒運転厳禁)
391 :
仕様書無しさん:04/03/20 18:25
>>389 ろくに汎用機を使ったこともないやつにマジレスするな。
Win(DOS)のFATやNTFS、UNIXのiノードしかファイルシステムを知らず、
区分編成ファイルや多重索引ファイルなどは言葉すら知らんのだろうから。
コンピュータシステムには様々な用途とスタイルがあることを知らん厨房なの
さ。
392 :
仕様書無しさん:04/03/20 18:32
COBOLerの人口が多いのは、他の言語を覚えられないから・・・プッ!
うちの会社おれ以外全員コボラ。確かにシェアNo.1だ。
おれがCで作ってると「COBOLもC言語だよな、はっはっは」と
昭和ギャグを飛ばされる。
余談だが、ゲームや翻訳ソフトやDVDプレイヤーを
違法コピーして客のPCにインストしている。
コボラは著作権を知らない。
3/31で退職予定。
素人って厚顔無恥
>391
面倒なのはDBかVSAMにしちゃうしそれ以外は大体只のSAMなので、
正直ISAMとかもういらないんじゃないかと思う。
PDSはまだ要るけど。
>>385,389,391
ええISPFなんて知りませんとも。
新人の頃目立で汎用機に関わったけど、周りのオサーン立ちは皆80x25のコンソール画面で
ASPENとかいうエディタ使って地道に人力調査してましたから。
まー自分のスキルの高さを誇示するなり、漏れを蔑むなり好きにして下さい。
漏れが
>>384で言いたかったのは、
>>383へ
「スキルの低いCOBOLerは、変更要求に応えるのに工数掛けまくってるじゃねーか」
って事ですから。
397 :
仕様書無しさん:04/03/21 14:09
>>395 普通はVSAMとSAM(FB/VB/U)とPDSだけありゃ足りる。
398 :
仕様書無しさん:04/03/21 14:12
>>396 汎用機の人は、viやgrep見て驚く
オープンの人はISPFやPDSやSO/SI見て驚く
ところでCOBOLerが工数かけるのは、技術の問題つーより、
管理の問題(ちょっとした変更も、官僚的に膨大な手続きと文書化する)だと思うね。
無駄なようだが関係者が多いシステムでは、必要。
>無駄なようだが関係者が多いシステムでは、必要。
本当に必要なものはどれかは、あまり検討されてないような所も多いけどね。
>>397 もちょっと自分の「普通」を高度にしましょう。
401 :
仕様書無しさん:04/03/21 20:06
>>399 それは言える。
当時は必要でも、今は陳腐化した文書や手順が、官僚的にただ残ってる職場は多い。
>400 そういうつまらないところだけ高度にしてもねぇ