2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

COBOLの現状について教えてください

1 :仕様書無しさん:2006/07/13(木) 17:12:24
知り合いが大手金融会社などのシステム保守を請け負っているとこに内定したらしいんです。
正直COBOLって、昔の言語って感じであまりイメージがよくなかったんですけど

「大手の銀行とか重要機関は全部COBOLだし、COBOLから変更の予定もない。
 若手にはCOBOLは不人気だからCOBOLの担い手が減ってきている。
 COBOLは一番安定してて、需要もあるから、むしろやるならCOBOLだ」

って言われた。
なるほどと思うと同時にホントかな?とも思います。

皆さん、実際のところはどうなんでしょうか?
COBOLは安定優良なんでしょうか?ご意見よろしくお願いします。

2 :なぎさっち ◆Nagi/FmYMM :2006/07/13(木) 17:24:08
>1
言語に依存しない技術を身につければ無問題。



判ったら削除依頼出しとけ。単独質問スレ立てんな。

3 :仕様書無しさん:2006/07/13(木) 22:07:22
手に職つければ…でもオープン系は三十五歳であぼーん。知ってる会社は採用条件コボルのみ。
コボルやってりゃ一生安泰。
でも、俺やりたくない。
だから、今でもフリーター。

4 :仕様書無しさん:2006/07/13(木) 22:22:53
コボルとは、終身雇用を約束する魔法の言語。
やってて良かったーーーー。
コボルでなかったら、家のローンを頭金ナシで35年も
組めないもんね。

5 :仕様書無しさん:2006/07/13(木) 22:26:14
やっときゃよかったかもな

6 :仕様書無しさん:2006/07/13(木) 22:35:59
COBOLなんかやるのは、この業界じゃえたひにんみたいな連中だろ。

7 :仕様書無しさん:2006/07/13(木) 22:54:26
官庁や病院の汎用機のシステムは、ほとんど壊滅したから、
残るは金融のみだね。
でも、でかい会社に雇われていているなら、まだ持つかも。
ただ、客のシステムがリース契約になっているようなら、
リース切れの際にさっくり切られる可能性は高い。

8 :仕様書無しさん:2006/07/14(金) 00:20:22
確かにCOBOLは少ない。
年寄りじゃなくて、若手のね。

若手だったらそこそこ需要あるかもね。

9 :仕様書無しさん:2006/07/14(金) 00:43:09
大企業の社内COBOLerはお役所仕事でおいしい。
毎日定時上がりで、年休100%消化で、35歳年収850万。
やーめられまへんなーーーー!

10 :仕様書無しさん:2006/07/14(金) 01:17:09
くさいいきを得意とする植物系の怪物?










…それはモルボルか

11 :仕様書無しさん:2006/07/14(金) 01:24:49
オチュー

12 :仕様書無しさん:2006/07/15(土) 03:02:13
>>1
銀行同士がくっつくとどうなるか
単純に考えるとシステム維持に必要な要員が2分の1になる
これがどういう事か解ればよろしい

勝ち側に居れば引退後も変な事されると困るから厚遇受けるが
負け側のシステム担当だと厳しいよな年とって様が否応無しに弾き飛ばされる

13 :仕様書無しさん:2006/07/16(日) 03:01:14
>>1
COBOLが安定優良なのは事実。認めたくない香具師もいるみたいだが。

COBOLerが安定優良かどうかは、事情による。勝ち組金融機関の
社員COBOLerなら安定優良かもしれんが、なまじ出来ると人事異動で
慣れないところに飛ばされて壊れるかもしれん。出来ない香具師が
いつまでもぬくぬくできるかはその金融機関次第。

金融機関の外注先だと、金融機関という太い客を捕まえている分、
下手な所よりは安定するが、いつ切られるかは分からない。

14 :仕様書無しさん:2006/07/19(水) 10:30:50
NET COBOLのありさまが現状です。

15 :仕様書無しさん:2006/07/21(金) 00:28:14
なあに、
金融機関勘定系パッケージ全盛の時代は、もうすぐやってくる。

パッケージに乗り換えたとたん、おまえらの大半はクビです。

16 :仕様書無しさん:2006/07/21(金) 02:41:49
20年以上も前からんなふうに言われてるわけだが。


17 :仕様書無しさん:2006/07/22(土) 16:57:52
20年前にあったパッケージは、都銀のシステムをそのまま買ってくるパッケージだけだった。

今は、FlexCubeを筆頭に、システム屋が主となって開発したパッケージがたくさんある。
新規参入銀行は例外なくパッケージを購入している。

18 :仕様書無しさん:2006/07/23(日) 04:56:12
それなら現状働く連中はクビにならず安泰だな。

19 :仕様書無しさん:2006/07/24(月) 21:43:48
地銀でFlexCubeに移行中のところがあるから、動き出せばそれを拡販だ。
FlexCubeの開発部隊は3500人もいるから、正直なところ、太刀打ちできない。

古い勘定系に守られて成長することをやめた連中は、確実にクビになる。

20 :仕様書無しさん:2006/07/29(土) 02:26:16
NetCOBOL(゚∀゚)

21 :仕様書無しさん:2006/08/05(土) 19:19:09
結論

現状安定優良、ただしその安定状態に胡坐かいてると痛い目を見る可能性もあるぞ
ってことでOKなのか?

22 :仕様書無しさん:2006/08/05(土) 19:43:13
安定優良って技術的に枯れているから、システムとして悪いものではないって意味でしょう?
コボラーとしてずっと食っていけるかっていうのとは完全に別問題。
ハードのコストが高いから、リース切れなどの機会に槍玉に挙げられることが多いし、
新規での案件はまず無いし、市場としては確実に縮小しているよ。

社内である程度のポジションにいるおっさんなら
管理職としてダラダラやっていける可能性があるからいいけど、
いまどき若くしてコボラーは危険。

23 :仕様書無しさん:2006/08/06(日) 03:28:34
新生銀行のDBはSQLサーバーらしい。

言語も新しいやつだったような気がする

24 :仕様書無しさん:2006/08/06(日) 18:38:00
負け組みのコボラーになりそだ。(・・・ぐすっ)
吸収合併でなくても、大企業の子会社・下請けはそんなもんだ。
子会社・下請けの分際で汎用機専門ってのは、生き残れないと思われ。





25 :仕様書無しさん:2006/08/06(日) 18:57:45
金融系いけば分かるけどCOBOLはかなり多いよ。
都銀や大手・準大手証券、大手の損保や生保などかなりある。
パッケージはパッケージ側に業務をあわせないとならないから、
結局はなんだかんだトータルコストが嵩むし、自由度も減る。
費用減らなきゃ何の意味も無いので一度試して懲りる所が多い。
あとPL/1→COBOLのリプレースもある。
ただ発注先はまず中国。
日本人でCOBOL覚えておいて間違いなく損は無い。
でも実装とかはほぼやる機会は無い。

26 :仕様書無しさん:2006/08/06(日) 19:32:03
SAPとかってCobolわかんないとわかんないって噂。
たしかにOPEN系業界ではSAPの話ってあまり聞かない。

27 :仕様書無しさん:2006/08/06(日) 19:36:45
某公共料金の計算システムでは、COBOLは現役だぞ。
料金改訂とか単価の変更がある度にCOBOLのソースに手を入れるから、
需要は極めて安定して存在する。


28 :仕様書無しさん:2006/08/06(日) 20:31:38
つーか、それ
単価の変更くらいでソースいじらないといけないっていうのもどうよ

29 :仕様書無しさん:2006/08/06(日) 22:18:31
>>28
それがCOBOL案件が無くならない理由だよ

30 :仕様書無しさん:2006/08/07(月) 20:55:56
なあに、COBOLの仕事が来てから覚えても大丈夫。
「COBOL出来るか?」と聞かれたら、「まかせてください。」と答えてから覚えればよい。

COBOLなんてものは、ずぶの素人でも3ヶ月で猫の手くらいなら使えるようになる言語だ。
ましてや、すでに別の言語での実績があれば、ちょっとだけ文法覚えればいいだけだよ。
新しい概念なんて、全く出てこないから。

31 :仕様書無しさん:2006/08/07(月) 22:31:13
まぁ>>30のいうことには一理あるな。簡単で単純な言語だ。
メインフレームが絡むとちょいだりーけど。
仕事は一応安定して供給されるよ。税制改正、法改正があれば立派な大規模プロジェクトだよ。
古いソースで中身がぐちゃぐちゃだからちょっとした改修でも手間がかかる。
新規案件も一応あるんじゃないかなぁ。バッチはCOBOL以外で作ったことないな。

32 :仕様書無しさん:2006/08/07(月) 23:06:41
COBOLって桁数をいちいち決めなきゃいけないので
桁数増えた場合の修正がめんどくさい

33 :仕様書無しさん:2006/08/07(月) 23:33:48
桁数をちゃんと決められるのが、金の計算では有利になると思う。

> 桁数増えた場合の修正がめんどくさい
仕事が増えていい感じじゃねぇか。
ホームレスになるよりかはマシ。

34 :仕様書無しさん:2006/08/08(火) 01:43:15
外資系金融機関もCOBOLなの?
それともCとか使ってたりするん?

35 :仕様書無しさん:2006/08/08(火) 02:31:47
日本ほどCOBOL一色じゃない。
勘定系に限れば、PL/Iもあるし、Modula-2もある。
ただ、勘定系といっても日本ほど多機能じゃなくごく単純なものだ。

外資系のシステムは、日本人が情報系と考えている分野にほとんどの開発リソースを投入しており、
日本はまさにその分野で遅れている。

第3次オンラインで育った団塊世代が一掃されないと、
勘定系にしか目が向かない現状を打破することは不可能である。

36 :仕様書無しさん:2006/08/08(火) 23:38:43
>>35
それは無理だろ、役所がいろいろな事を複雑に難しくする事で自分達の仕事を減らさない様にしてる国だからな
企業の仕組みが簡単になると色々都合が悪いみたいだよ

37 :仕様書無しさん:2006/08/10(木) 00:09:23
>>36
金融行政はアメリカの方が難解である。
日本の金融行政でも力を入れているのは、情報系システムで対応すべき分野だ。

勘定系にインプリメントしなきゃならない制度や法令上の制約は、
ほとんどパラメータで対応できている内容であり、
根本的な変化など、あまりありません。

38 :仕様書無しさん:2006/08/10(木) 03:20:30
ぶっちゃけ帳票にあんなに凝らなきゃ
日本は遅れなかったとは思う。
その分ヨソに力使ってればなぁ

39 :仕様書無しさん:2006/08/10(木) 22:22:10
>>38
この上なく激しく首がちぎれるくらい同意

40 :仕様書無しさん:2006/08/11(金) 01:01:18
>>38
その言葉、俺の上司どもに言ってやってくれ。

41 :仕様書無しさん:2006/08/15(火) 23:39:19
製造系で多くのシステム構築をし、その経験を認められ
現在某大手で金融のパッケージの作成の上流工程からの業務を行っているものです。
金融系を相手にしている某大手は
「新しいシステム」「勘定系からの脱皮」「Windowsへの展開」
好き勝手言ってます。
「やっぱ最新の技術はJAVAだろう。どんなハードウェアでも動くし!」
ってことでJAVA採用(JAVAってどういう言語だと思ってるんだろ。。。)
「でもJAVAってバッチ処理できるの?」
「ぃゃ、バッチ処理はCOBOLだろう?」
ってアホな意見でCOBOLも採用(汗

で、わたくしの書いた設計見て技術責任者が
「ねぇ!これってファイル2回開かない?! 負荷どうなるのよ?!」

ちなみに製造業で古い技術をいつまでも使う事や技術的知識が無いまま
プログラミング設計をすると「欠陥品」を作り「リコール」発生の原因となります。
製造業界では上記で書いたような「おかしい」発言をする技術者には
ビシッっと言うのが正しい対応です。

で、

ビシッ と言うと

次の日から「しったか」と言われだもれ相手に(略


これがCOBOL金融業界の全て(w

でもこの逆境に勝てた人はかなりおいしい思いできまっせ

42 :仕様書無しさん:2006/08/15(火) 23:44:35
>>41
同じ事を東大卒の新入りが言うと、「さすがだ」に評価が変わります。
つまり、あなたが悪いのではなく、あなたの学歴が悪いのです。
それが、金融業界です。

43 :仕様書無しさん:2006/08/16(水) 00:06:49
金融業界って、天然記念物がいっぱいいるね


44 :仕様書無しさん:2006/08/16(水) 07:25:17
それが金融業界というもの

45 :仕様書無しさん:2006/08/16(水) 20:36:18
金融業界といえば、何故かフロントエンドPHP+バックエンドJavaという
摩訶不思議なシステムがあちこちにあるとか。。。

46 :仕様書無しさん:2006/08/16(水) 23:25:37
>>45
それ金融じゃなくてカードとか証券の方の話じゃないの?
金融とは名ばかりのバッタ物

47 :41:2006/08/16(水) 23:35:14
>>42
なんだかどこも同じ思考回路なんですね(w
すごく納得してしまう意見です。

本題のCOBOLという言語について…

COBOLは汎用機で帳票出力したりするのには最適な言語だと思う。
「Windowsで動く帳票出力システムを2日で作ってね〜」とCOBOLERに言われて作ったが
「これ、汎用機+COBOLで作った帳票プログラムより性能わるいじゃん!」
とCOBOLERに激怒されました。で、COBOLで出力した帳票を見て思いました。
帳票出力に関してはCOBOL様には勝てません。

金融業界とそれ取り巻く技術者は「帳票」に対してすごい思い入れがあります。
帳票出力は「処理結果のプリント出力」というごく一部の機能ではありますが
COBOLERは「帳票出力以外の処理は何か良い(便利な)パッケージで処理させればいいじゃん」
という思考なので結局COBOLで帳票を出力する技術=技術力
という書式が金融業界では成り立ちます。

つまり金融業界でがんばるにはCOBOLスキル必須です。

48 :41:2006/08/16(水) 23:41:57
ただ、
「いくらなんでも帳票(COBOL)ばかりに執着しててもねぇ」って考えを
都市銀と第一地銀では持っているようです。
都市銀や第一地銀と中の良いIT系大手数社にはCOBOLからの脱皮案は何かないか
というやりとりがぽつぽつとあるようですが
IT系大手にはCOBOLERが大量にいるのでそう簡単には動けないようです。
(理想と現実ってやつですね。)
それでもって銀行側が出す案が
新しい技術っていえばJAVAっしょ!!!JAVAにしましょ!!(なぜか都市銀も地銀もそういうw)
なのでCOBOL+JAVAというスキルが今の金融には喜ばれますよ。

49 :仕様書無しさん:2006/08/16(水) 23:44:06
ペーパーレス

50 :仕様書無しさん:2006/08/18(金) 00:54:22
>>47
同じプログラムのパラメータ変えるだけで、
PDF, Excel, web, プリンタと出力先が切り替わるところ見せれば、
60%の汎用機野郎はぐうの音も出なくなる。

そんでもって残り30%は、その意味するところが理解できず、

残りの10%は、「そんなもの、オーバーレイ切替ただけだろ」と勝手解釈した上で逆ギレ。

51 :仕様書無しさん:2006/08/18(金) 07:46:27
帳票ツールの時点でソート順の切り替えが出来るって事が理解できない汎用機野郎はいるな
ソートはツール使わなきゃダメって思想らしい

52 :47:2006/08/18(金) 23:07:07
>残りの10%は、「そんなもの、オーバーレイ切替ただけだろ」と勝手解釈した上で逆ギレ。
ん〜 私の職場では10%じゃなくて100%かな。

「これさ、エクセルじゃなくてPDFとかビットマップでも出力できるようにしておいて〜」
って言われて2日かけてコーディングしたら
「パラメータ変えるだけで2日使うの?!君本当にプログラマー?!」
って説教された(w

完全オリジナルなソフトウェアなのでそんな便利なパラメータはございません(汗


53 :47:2006/08/18(金) 23:10:08
そんなCOBOLERとしている仕事の内容は
「テキストファイルのデータをOracleに登録する」
という内容の仕事。
まだ実現はしていないけど今までにおよそ120人月くらい消費しました(w

「SQL*Loader使えば一日で終わりますよ〜」と言いたいが
言ったら100%追い出される(w

54 :仕様書無しさん:2006/08/19(土) 00:03:45
SQL Loderなぞ、子供のおもちゃ。
120人月も浪費するのなら、PowerCenter使え。
1000万円ぽっちであれだけの機能が使える。

55 :仕様書無しさん:2006/08/19(土) 02:52:49
COBOLage

56 :仕様書無しさん:2006/08/23(水) 11:35:00
>>1に言うとすれば(もういるかどうかわからんが)
COBOLERになれるならなっとけ、ただしCOBOLと平行してjava勉強しとけ、イザという時少し有利だ
ってことか

57 :仕様書無しさん:2006/08/23(水) 23:36:31
>>56
COBOLer達の聖地金融業では
COBOLは古い!Javaだ!
という流れが全銀協 第一地銀協でできているようなので
その意見は正しいかもしれません。

けど、古〜いCOBOLERが出世して技術責任者になっていて
自分の技術をいつまでも肯定したいがためにCOBOLを支持するのが現状。
実際はCOBOLじゃぁ無理な要求をCOBOLerと友好関係にある金融業界がしてきている。

VBやCOBOLのように「だれにでも簡単に取得できる技術」で食うのはつらい時代となりましたね。

ちなみにこのスレで意見している人のCOBOLERとそうでない人の見分け方は
全角英数っす(w

58 :仕様書無しさん:2006/09/01(金) 01:05:51
朕は、全COBOLerの総意に基いて、新COBOL国建設の礎が、定まるに至つたことを、
深くよろこび、COBOL国憲法の改正を裁可し、ここにこれを公布せしめる。

プログラマ国憲法

前文

 COBOL国民は、恒久の言語存続を念願し、プログラマ相互の関係を支配する
崇高な言語を深く自覚するのであつて、オープン系の波から逃れようとする
COBOLerの信義を信頼して、われらの安全と生存を保持しようと決意した。
われらは、COBOLer人口を維持し、BasicとJavaとC++とPerl、
UNIXとWINDOWSを地上から永遠に除去しようと努めてゐるCOBOL社会において、
名誉ある地位を占めたいと思ふ。
われらは、全世界のCOBOLerが、ひとしく失業と金欠から免かれ、
平和のうちに生存する権利を有することを確認する。

 われらは、いづれの言語も、COBOLよりも普及してはならないのであつて、
COBOLer道徳の法則は、他言語の普及の芽を摘むことであり、
この法則に従ふことは、COBOLerの主権を維持し、
COBOL知識の陳腐化を阻止しようとするCOBOLerの責務であると信ずる。

 COBOL国民は、国家の名誉にかけ、全力をあげてこの崇高な理想と目的を
達成することを誓ふ。

59 :仕様書無しさん:2006/09/01(金) 01:07:13
第1条
全リソースは万世一系のCOBOL、これを統治する

第2条
COBOLは神聖にして侵すべからず

第3条
COBOLはCPU、記憶装置、出力装置、通信制御装置を統帥する

第4条
臣民たるオペレータは法律の定める所によりテープ交換及び用紙交換の義務を有す


60 :仕様書無しさん:2006/09/01(金) 01:08:47
第9条
COBOL国民は、メインフレームとオフコンを基調とするCOBOL85による統一を
誠実に希求し、業務ロジック記述の発動たるプログラミング言語に、
C++, Java, Perl, Basic, PHPの行使は、業務処理を解決する手段としては、
永久にこれを放棄する。

 前項の目的を達するため、UNIX, Windowsの環境は、これを保持しない。
COBOL以外のコンパイラは、これを認めない。


61 :仕様書無しさん:2006/09/01(金) 01:16:46
明治憲法と昭和憲法が混ざってる

62 :仕様書無しさん:2006/09/02(土) 11:45:58
COBOLってプログラム組んでても楽しくないんだよな。
ほとんどの仕事が他人が作ったグチャグチャになったソースを修正することだしorz
帳票関係はさすがにCOBOLはスゲーと思うけど、それだけだからな。
COBOLで.netとか出てきて、かなり無理してるのが滑稽orz

63 :仕様書無しさん:2006/09/05(火) 03:52:37
COBOLは可読性が高くてすばらしい。
Javaみたいな無駄に肥大化して手に負えなくなるようなヘタレ言語とはわけが違う。

64 :仕様書無しさん:2006/09/05(火) 08:21:43
Javaの無駄な肥大化について、一例でも挙げて見ろやww

65 :仕様書無しさん:2006/09/05(火) 16:38:09
ほれ、自分で探せ。
ttp://www.google.co.jp/search?hl=ja&q=Java+%E8%82%A5%E5%A4%A7%E5%8C%96&lr=

66 :仕様書無しさん:2006/09/06(水) 00:36:37
>>63
COBOLの可読性って、きれいなソースだけだろ。
修正しまくってドキュメントがまったくないソースなんて見れたもんじゃねーぞ。

67 :仕様書無しさん:2006/09/06(水) 23:16:56
>>59 & 60
COBOL使いと仕事する前の自分なら
「あぁ また2chプログラマのCOBOLerたたきかよ(w」
と言うが
COBOLerと仕事をした今の自分から言わせてもらうと
「大正解〜」
と言う。

68 :仕様書無しさん:2006/09/07(木) 01:16:42
>>63
肥大化してるのは言語仕様じゃなくて要素技術の話だ。
んなもん、使わなきゃいいだけだろ。

つか、JavaとCOBOLでまったく同じことを実装したら
Javaの方が間違いなく可読性高いソースにしあがるぞ。

69 :仕様書無しさん:2006/09/07(木) 05:28:09
それはありえないな。


70 :仕様書無しさん:2006/09/07(木) 21:05:31
常識的な使い方の範囲でだが、
一般的に、COBOLで記述可能なら、JavaよりもCOBOLの方が可読性が高い。

問題なのは、COBOLの硬直的な仕様のため、記述できる範囲が限られているということだ。

71 :仕様書無しさん:2006/09/07(木) 22:08:05
COBOLの可読性のおかげで
基本情報に合格できました

72 :仕様書無しさん:2006/09/07(木) 23:54:23
素人でもある程度の文意を汲み取ることができるってのがCOBOLの可読性
短い時間で多くの情報を得ることについては、COBOLの記述性は他の言語よりかなり劣るよ

73 :仕様書無しさん:2006/09/08(金) 01:18:03
ようするに、素人でもわかる程度のプログラムしか書けないから、COBOLは可読性が高いということだな。

つまり、書籍に例えると、全部ひらがなで書かれた書物ということだ。

全部ひらがなで記述すれば、小学1年生でも夏目漱石や川端康成を読むことは可能だ。
しかし、大人が読むにはちとつらい。

結論づけると、COBOLはお子ちゃま用言語ってことですな。

74 :仕様書無しさん:2006/09/08(金) 01:29:23
出口はあちらです

75 :仕様書無しさん:2006/09/08(金) 02:26:58
>>73
高級言語とはそういうことなんだよ。
この低脳め。

76 :仕様書無しさん:2006/09/08(金) 06:20:28
COBOLの場合、複雑なアルゴリズムなんてありえないからな

77 :仕様書無しさん:2006/09/08(金) 20:49:22
>>75
JavaもCもC++も、高級言語なんだよ。
この低脳め。

78 :仕様書無しさん:2006/09/08(金) 21:55:44
>>76
go toであっちこっち跳ぶ奴見た事無いんだろう?

79 :仕様書無しさん:2006/09/09(土) 03:03:21
>>77
高級言語の意味をわかってるかテストしてやろう。
COBOLはC/C++よりも高級である。
これは真か偽か?

80 :仕様書無しさん:2006/09/09(土) 03:22:03
>>79
俺は>>77じゃないけど、プログラミング言語の高級度で
いえば、C言語よりCOBOLの方が上だろうな。
プログラミング言語の仕様がアプリケーション等、業務目的
のために策定され洗練されているし、キーワードが人間の
言語(英語)に近い。

C言語は高級アセンブラ言語に近いんジャマイカ?

C++はパラダイム肥大化で、ややプログラミング言語学者や
技術者の自慰嗜好要素が含まれている。
ISOうんぬんで品質管理の認定を受けても、実際のコードは
各自でC言語以上にバラバラなスタイルなので、これで認定?
ドキュメントだけの統一で大丈夫か? とも感じる。

81 :仕様書無しさん:2006/09/09(土) 15:02:22
高級アプリ言語と高級アセンブラ、どっちがより高級かてのは、
甘いメロンと甘い桃、どっちがより甘いか、て比べてるようなもんでは。

82 :仕様書無しさん:2006/09/10(日) 18:07:29
>>78
構造体もない。
ポインタもない。
再帰も使えない。

そんな言語で扱えるアルゴリズムなんてたかが知れてるんだよ。

83 :仕様書無しさん:2006/09/10(日) 18:17:49
ぷ。
言語に機能がないとアルゴリズム使えないんだって。

84 :仕様書無しさん:2006/09/10(日) 18:21:43
ま、所詮COBOLerにアルゴリズムの話など通じるわけはないわなw

85 :仕様書無しさん:2006/09/10(日) 18:34:57
>>82
そりゃCOBOLは事務処理言語だし・・・
構造体はレコードだけでも十分。
参照やポインタの概念は無くても困らない。
定型の事務処理に再帰の有効性はまず無い。

機能的にはSQL+αで十分でしょ。

86 :仕様書無しさん:2006/09/10(日) 18:37:24
まぁ、気の毒だとは思うよ。よりによってCOBOLだもんなぁ。
コントロールブレークだのマッチングだのといった単純なアルゴリズムしか扱えない環境じゃねぇ。

87 :仕様書無しさん:2006/09/10(日) 21:45:48
使用目的を考えずにアルゴリズムがどうこう言う奴はただの馬鹿だ。

88 :仕様書無しさん:2006/09/10(日) 21:48:56
アルゴリズムを語れないプログラマなぞ馬鹿以下だ

89 :仕様書無しさん:2006/09/11(月) 18:06:03
アルゴリズム体操はできるぜ

90 :仕様書無しさん:2006/09/13(水) 15:24:36
COBOLerを目指す若人がいるというのか、珍しいな
単純に労働条件で比べれば、まだまだ発展中の言語(代表例はjavaか)の使い手に比べて安定してるだろうな
なんせ、仕事のメインは開発ではなく保守だから
うまくいけばPGに付き物の残業地獄から逃れられるぞ





うまくいけば、な

91 :仕様書無しさん:2006/09/13(水) 18:41:33
>>90
逆にプログラミングや先端技術、コンピュータサイエンス
などに魅力を感じたらCOBOLer失格とも言えるな。

COBOL言語 仕事用!

92 :仕様書無しさん:2006/09/13(水) 18:53:10
>>90
うまくいかない場合ってのはどんな場合があるのだ?

と、内情をまったく知らない俺が聞いてみる……単純に職なしになるのか?

93 :仕様書無しさん:2006/09/13(水) 19:04:03
そういう案件が続けばって話だろ。
ある日突然ユーザー企業が目覚めなければ、だ。

94 :仕様書無しさん:2006/09/18(月) 21:56:01
まあ、2,3年コボラーやってたけど
デスマーチとは無縁の、マッタリした職場だったな
おっさんたちの開発時の武勇伝が色々聞けた

95 :仕様書無しさん:2006/09/24(日) 16:17:19
Cocolの開発環境でお薦めのものってあります?


96 :仕様書無しさん:2006/10/01(日) 23:37:42
>おっさんたちの開発時の武勇伝が色々聞けた

どんな話かしらんけど、「完全徹夜は当たり前」とかそんな話ばっかりじゃねーだろーな?
前転職活動で回ってて、「完全徹夜は当然対応できるよね?」とか聞かれて、このジジイ、阿呆とちゃうか?と
思ったよ、俺は。

97 :仕様書無しさん:2006/10/08(日) 00:11:38
WEB COBOLなるものがあると聞いたのですが、COBOLerに未来はありますか?

98 :仕様書無しさん:2006/10/08(日) 06:00:40
大昔から動いてるCOBOLのシステムは紙しか残ってない昭和の仕様書
だったり本番環境にLMがあるのみでソースがないなど新システムに
以降するのも大変ってのも多いな

99 :仕様書無しさん:2006/10/08(日) 16:17:30
職業プログラマとして先行きを考えなければならないのは
LISPerとPL/Ierくらいじゃネーの?

100 :仕様書無しさん:2006/10/08(日) 20:34:05
>99
コボラー乙

101 :仕様書無しさん:2006/10/08(日) 20:35:56
うらやましいのか?

102 :仕様書無しさん:2006/10/08(日) 20:36:53
うはwwwそういうことにしておくよwww

103 :仕様書無しさん:2006/10/10(火) 02:09:58
プログラマーの残業時間は一般職種に比べて5割増しらしいけどな、実数も感覚も
……労働時間でいえばCOBORerはプログラマーであってプログラマーではないのか

104 :仕様書無しさん:2006/10/10(火) 02:29:28
新しい言葉を発明する仕事は、マじゃねーだろ。

105 :仕様書無しさん:2006/10/10(火) 14:28:59
読み方はコボーになるか……

てか特にプログラマになろうという意思はなかったのに
就職活動中にたまたま受けたらたまたま採用されてなんとなくプログラマなったりしたら悲劇だ


106 :仕様書無しさん:2006/10/25(水) 23:34:45
>>105
それ俺

107 :仕様書無しさん:2006/10/28(土) 19:55:08
>>99
Lisperなめんなw
奴らの平均レベルは押しなべて高い。

108 :仕様書無しさん:2006/10/29(日) 17:58:10
>>107
基礎にLISPが染みついてる香具師はそうかもしれんが
>>107みたいにLISP使えますレベルじゃぁ…

109 :仕様書無しさん:2006/10/29(日) 18:08:37
>>108
句読点も使えず、アンカーも冗長。
お前はたいしたマじゃ無さそうだなw

110 :仕様書無しさん:2006/10/29(日) 18:09:59
コボラでしょ。

111 :仕様書無しさん:2006/10/31(火) 14:56:27
そういえばCOBOLとNETCOBOLって何が違うんだ
オブジェクト指向にでもなったのか?

112 :仕様書無しさん:2006/10/31(火) 20:10:43
コボルがオブジェクト指向に対応するとかどうとか聞いたことが確かにあるな。
どうなったのかしらんが。

コボルは知ってて損はないな。いまだに新規案件のバッチはコボルで作ることも多いし。
コボルしかできないってのは問題だが。
超簡単な言語だし覚えて損はないと思われ。

113 :仕様書無しさん:2006/10/31(火) 20:56:27
COBOL85しか知らないんだけどさ、最近のCOBOLって動的配列は出来るの?

114 :仕様書無しさん:2006/10/31(火) 23:03:36
>>113
何そのかっこいい言葉?

115 :仕様書無しさん:2006/11/01(水) 00:19:13
できるんじゃねーの?

116 :仕様書無しさん:2006/11/01(水) 01:59:27
COBOLって再帰できないんだ・・・。
再帰に向いている処理をする際かえって面倒じゃないのか?

117 :仕様書無しさん:2006/11/01(水) 02:49:42
とりあえず今のところ再帰処理はしてないな

118 :仕様書無しさん:2006/11/02(木) 00:18:36
富士通の新人研修でコーディングシートを貰ったよ!
あと、あのテンプレートというやつ。

119 :仕様書無しさん:2006/11/02(木) 23:11:05
>>116
どんな言語であったとしても、たとえローカル変数が使えないとしても、
スタックをエミュレートすれば再帰処理は可能だ。

120 :仕様書無しさん:2006/11/03(金) 14:23:29
俺はCOBOLで再帰処理を書いたことがある。
古いCOBOLは全部グローバルな変数なので、
スタック用の配列とスタックポインタの変数を作り、
PERFORMを呼び出す前にサブルーチン内の変数と実行している場所をスタックに積み上げ、
GOTOで自分のサブルーチン自身の先頭に飛んだ。
抜けるときはスタックから変数と戻るべき場所を取得し、戻る。

これにより、ツリーを辿る処理に深さの制限が無くなった。(もちろんスタック容量の範囲内)

121 :仕様書無しさん:2006/11/03(金) 14:54:10
>>120
それは、オナニーに近いプログラムだ。
そこまでできるなら、さっさとCOBOLを捨てて別の道に進んだほうがいいと思うぞ。

122 :仕様書無しさん:2006/11/03(金) 19:38:44
>>121
職場でオナニー 3ヌキ目
http://pc8.2ch.net/test/read.cgi/prog/1054634685/


123 :仕様書無しさん:2006/11/04(土) 06:54:40
>>120
どんな業務で必要としたのか、そっちのほうに興味がある。

>PERFORMを呼び出す前にサブルーチン内の変数と実行している場所をスタックに積み上げ、
>GOTOで自分のサブルーチン自身の先頭に飛んだ。
>抜けるときはスタックから変数と戻るべき場所を取得し、戻る。
ここ読んでるとアセンブラでやることをCOBOLで実現してるみたいでおかしい、いや面白い。


124 :仕様書無しさん:2006/11/04(土) 20:40:37
>>123
元来PGという人種はヒマになると凝りだすからな。
まぁ、現実にはアレな輩も多数含まれるわけだが。

125 :仕様書無しさん:2006/11/04(土) 23:15:02
>>120 のやり方をオナニーとは思わんなあ。
実際、良く知られた技法だし、再帰ができる言語でも、サブルーチン呼びだしの
オーバヘッドが大きい時に、チューニングの一種としてやることが稀にあるよ。
木を辿るようなアルゴリズムは再帰で考えた方が楽だから、もし俺が>>120
立場だったとしても同じことをしたと思う。

まあ、そういう処理をCOBOLで書かざるを得なかったのは、不幸だし、さっさと
別の道に進むべきというのは同意。(w

126 :仕様書無しさん:2006/11/04(土) 23:37:44
>>125
スタックをエミュレートする時点で、すでにコスト高いと思うけど・・・・

127 :仕様書無しさん:2006/11/05(日) 17:29:30
>>125
俺の会社じゃ、俺以外にスタックの意味がわかるヤツがいなかった。
これって普通ですか?

128 :仕様書無しさん:2006/11/05(日) 18:53:04
その会社のプログラマーの平均年齢とレベルによるんだろうなぁ。
20代の人間はシラネーんじゃねーか?

129 :仕様書無しさん:2006/11/05(日) 19:52:25
学歴にもよるな。
スタック、キュー、ハッシュくらいは教養レベルのデータ構造だろ。

130 :仕様書無しさん:2006/11/05(日) 20:17:53
>>127
普通は誰一人として知らない。
お前が一人だけでも知っているから、普通じゃない。


131 :仕様書無しさん:2006/11/05(日) 23:05:10
スタックとキューは自前で知らなくてもそれなりのプログラム作れるようになったからな

132 :仕様書無しさん:2006/11/05(日) 23:20:25
まあ、現状、知ってたからってだから何ができるんだって感じではある
いい時代なのか情けない時代なのかよくわからんな

133 :仕様書無しさん:2006/11/05(日) 23:30:22
>>132
COBOLerにとっては、40年前からスタックとキューは必要ありませんでした。

134 :仕様書無しさん:2006/11/06(月) 22:58:08
COBOLプログラムには歴史が詰まってんだよ。
この間、ソースを見てたら1972年とか書いてあってよ
なんか涙が出てきたな。

135 :仕様書無しさん:2006/11/06(月) 23:06:26
COBOLプログラムには歴史が詰まってんだよ。
この間、ソースを見てたら慶應元年とか書いてあってよ
なんか涙が出てきたな。



136 :仕様書無しさん:2006/11/06(月) 23:09:19
COBOLプログラムには歴史が詰まってんだよ。
この間、ソースを見てたら2006年とか書いてあってよ
なんか涙が出てきたな。

137 :仕様書無しさん:2006/11/06(月) 23:10:29
次は江戸時代初期の頃か?

138 :仕様書無しさん:2006/11/06(月) 23:11:10
COBOLプログラムには歴史が詰まってんだよ。
この間、ソースを見てたら神武天皇即位対応とか書いてあってよ
なんか涙が出てきたな。



139 :仕様書無しさん:2006/11/07(火) 00:57:47
あー
ウチは昭和で動いてるんですよ
って言ってた所、まだ動いてるのかなぁ・・81年か
さすがに3桁になったら修整するんだろうか?

140 :仕様書無しさん:2006/11/07(火) 01:51:37
>>139
それまで会社が存続しているかどうか・・・

141 :仕様書無しさん:2006/11/07(火) 02:02:58
コボラーって
COBOLERでいいの?
COBOLORじゃあるまいか?

142 :仕様書無しさん:2006/11/07(火) 03:28:23
>>141
ホントはCOGBOLLA
中生代に繁栄した

143 :仕様書無しさん:2006/11/07(火) 11:27:56
>>141
コボラってかくと可愛いよ。

144 :仕様書無しさん:2006/11/07(火) 20:40:32
ゴジラ対コボラー

145 :仕様書無しさん:2006/11/07(火) 22:17:38
コボラvsゴジラ

146 :仕様書無しさん:2006/11/07(火) 23:21:34
コボラvsメカコボラ(コードジェネレータ)

147 :仕様書無しさん:2006/11/07(火) 23:22:10
ガメラVSコボラ

148 :仕様書無しさん:2006/11/08(水) 00:09:31
http://pc.2ch.net/test/read.cgi/prog/1029933440/

149 :仕様書無しさん:2006/11/09(木) 04:44:32
コボラーが合体して、古代生物コボラになります。

150 :仕様書無しさん:2006/11/09(木) 09:22:37
コボル簡単だし大体が保守だから開発と違って
楽な気がする
いきなり廃止なんてありえないし移行は現状不可能だから
やってて損はないな

151 :仕様書無しさん:2006/11/09(木) 12:03:33
保守の方が大変

152 :仕様書無しさん:2006/11/09(木) 13:48:13
ドライバとかいうテンプレ集ってどこで手に入れたらいいんですか?

153 :仕様書無しさん:2006/11/09(木) 15:09:07
来年からSEとなる者なんですが、4月に受ける基本情報試験の言語をどれにしようか迷っています。
文型なもので簡単といわれているCOBOLかCASLUにしようと思っているのですが、やはり実務で使えるCOBOLの方がいいでしょうか?
ご意見お願いします。

154 :153:2006/11/09(木) 16:00:14
それとも需要の多いJavaにした方がいいのか・・・ものすごく悩みます。

155 :仕様書無しさん:2006/11/09(木) 16:43:21
>>153
何も知らずにコボルコボルと言ってると、ほんとにコボラになっちゃうぞ。
素直にCかJavaにしときなさい。

#問題はJavaの方が随分簡単だった気がする。

156 :仕様書無しさん:2006/11/09(木) 21:44:20
>>153
受かるのなら、何を選択しても良い。
言語問題などにこだわるな。

言語問題を全部落としてでも、他の問題の正解率を上げた方が効率的。


157 :仕様書無しさん:2006/11/09(木) 22:08:23
オープン系はやめた方がいいよ。

基幹系の方が将来性あるからね。

COBOLの方が将来性あるよ。

158 :仕様書無しさん:2006/11/10(金) 01:13:47
あと40年仕事があれば何でもいいよ

159 :仕様書無しさん:2006/11/11(土) 18:38:09
あと40年もCOBOLの仕事を受注し続けるには、かなりの営業力が必要だ。

正直、最近のCOBOL案件は少ない。
メインフレームのCOBOL案件を発注するのは大手企業だけだ。
受注さえすればウハウハだが、大手SIではないところが受注するのは至難の業。

オフコンのCOBOL案件はあるが、
オフコンでCOBOLシステムを残している企業は本業が苦しいので新システムに刷新する金がない企業だけだ。
当然、おいしい仕事は残っていない。

160 :仕様書無しさん:2006/11/11(土) 23:37:31
ホスト系はCOBOL、FORTRANとまったく違った文法、適用分野だったが、オープン系はJavaにしろ.NETにしろ、みんな同じような感じになってきたな。
組み込み系になると違ってくるけど、業務系ならJava、.net、Ruby、PHP、もうなんでもいんじゃね?

161 :仕様書無しさん:2006/11/11(土) 23:59:55
>>160
Ruby、PHP入れるあたりがダメっすよ。おぢさん。
受け売りも程々にね。

162 :仕様書無しさん:2006/11/12(日) 00:52:46
>>161
Rubyの仕事は無いが、PHPの仕事はたくさんある。
残念なことにPHPの仕事はケチくさい仕事ばかりだが。

163 :仕様書無しさん:2006/11/12(日) 00:55:11
>>162
残念ながらPHPは「なんでもいい」と言うほど洗練されてない。
気の利いたフレームワークを作る前にまず名前空間を実装して欲しい。
まるでVB6のようだ。

164 :仕様書無しさん:2006/11/13(月) 00:04:40
PHPでフレームワークを作ろうという考えが間違っている。

PHPはPerlと同じで、使い捨てのプログラムを作るもの。

Perlと違うところは、
PerlにはCPANのような巨大なライブラリがあるが、
PHPにはそのようなものがない。

165 :仕様書無しさん:2006/11/14(火) 01:35:46
COBOLがなぜこんなに話題になるのかね?
COBOLを使うところは言語なんてどうでもいいのよ
単なる道具だから。プログラマも単なる道具。
システム部門の人間は経営陣に雑誌に出てるような
言葉を使っていかにも仕事をしていますってポーズを
とりたいのよ。それだけ。それだけ。それだけ。

166 :仕様書無しさん:2006/11/16(木) 13:37:31
>165
話題になるんじゃなくて
関係者が無理矢理話題にしようとしてるだけ

167 :仕様書無しさん:2006/11/17(金) 07:48:47
>>165
そういう事に関するスレに来て何言ってんの?池沼?

168 :仕様書無しさん:2006/11/17(金) 08:13:46
ところで、大手の保守を請け負ってればある程度いいんじゃねぇの?って話だが
COBOL使ってる大手ってどこがあるんだ?省庁とか金融とか……あとは新聞社なんかもそうか?

169 :仕様書無しさん:2006/11/17(金) 12:10:56
帳票大好きなところだろ

170 :仕様書無しさん:2006/11/17(金) 19:58:26
自動車会社のT社系列でも使ってるだろ

171 :仕様書無しさん:2006/11/17(金) 23:36:30
>>168
官公庁と金融関係が大きなマーケットだ。
上記2つの市場は、コスト意識が甘いので、ぼったくりOK

歴史のある製造業の会社には、生産系のシステムでメインフレームが残っている。
しかし、製造業はコスト意識が高いため、あまり利益が出ない。

中小企業のオフコンもCOBOLだが、
いまだにオープン系にリプレースできていない中小企業は、はっきりいって危ない。
もともと利幅が少ない上に、倒産したら未収金が回収できないぞ。

172 :仕様書無しさん:2006/11/19(日) 23:08:55
いくら金払いがよくても、個人請け負いなんてありえない所だし、ぼったくってるのは大手SIかメーカーだしな。

173 :仕様書無しさん:2006/12/02(土) 11:28:22
某携帯電話会社のDやAやWもCOBOL

174 :仕様書無しさん:2006/12/07(木) 20:06:39
>>173
Sは?

175 :仕様書無しさん:2006/12/08(金) 08:00:11
ぶっちゃけCOBOLとPL1を扱っててあと何年くらいもちそうなんだ?
俺にはそのあたりの未来予想図がみえてこない

176 :仕様書無しさん:2006/12/08(金) 08:24:06
>>175
そんな「宮大工やっててあと何年建築業界でもつかな?」
みたいな話されてもな・・・

177 :仕様書無しさん:2006/12/08(金) 08:30:35
宮大工って。。。
そこまで技術のいる仕事じゃないし
単価だって高くないだろ。。。

178 :仕様書無しさん:2006/12/08(金) 18:34:01
古さに対して貴重と陳腐の区別がついてないことはわかった

179 :仕様書無しさん:2006/12/14(木) 23:39:45
宮大工は新しく作ったりするけど、COBOLだと新しく作ることないもんな

180 :仕様書無しさん:2006/12/17(日) 12:02:37
業界全体なことはともかく、個人としては>>56がいいのか?
定時に帰れて休みもしっかりあるシステム保守系COBOLer羨ましい(´・ω・)

181 :仕様書無しさん:2006/12/17(日) 12:04:26
>>180
は?

182 :仕様書無しさん:2006/12/17(日) 13:54:46
>>180
とりあえず定時上がりが羨ましいってことはわかった

183 :仕様書無しさん:2006/12/19(火) 19:35:43
文系学部卒で、初級シスアドの資格は持ってます。
このたび、システム関係の部署に異動になりました。
COBOLを使う職場らしいので、事前にさわりだけでも勉強しておきたいのですが
詳しい方がいらっしゃいましたら、以下の点を教えていただけると幸いです。


1.基本情報技術者試験(COBOL選択)の勉強は午前・午後の知識とも役に立つのか
2.同試験のCOBOLの試験範囲だけで、実務を一通りこなすことは可能か?
  また不可能であれば、どのような勉強を追加していけばよいか。
3.試験用のCOBOL参考書は、実務でも役に立つのか。

無知で申し訳ありませんが、よろしくお願いします。

なお、COBOLの参考書は
「らくらく突破 COBOL」を使う予定です。
この本の評判などもお分かりの方がいらっしゃいましたら教えていただけると幸いです。

184 :仕様書無しさん:2006/12/19(火) 20:05:33
試験は受けていないし、これからも受ける予定はないが、、、

会社ごとの規約っつーもんがあるからそれに慣れる必要がある。
んでその規約を無視したソースもごまんとある(特に昔のとか) w

後、あったりまえだが、JCLも覚えないと話にならん。まぁ先輩諸氏に教えてもらえるだろうが。

185 :仕様書無しさん:2006/12/22(金) 03:15:27
俺ほとんど素人だからよくわからんが
結局COBOLerって絶滅危惧種ってことなのか?

186 :仕様書無しさん:2006/12/22(金) 06:38:00
早く絶滅して欲しいとは思うが、危惧するほど少ないとも思えんなぁ。
ただDQN率は圧倒的に高いと思うが。

187 :仕様書無しさん:2006/12/27(水) 23:02:15
>>183
心配する必要はありません。
そんな試験など通る必要もありません。

だれにでも出来る簡単な仕事ですから。

188 :仕様書無しさん:2006/12/27(水) 23:36:37
COBOLでもCでも、要は結果を得るための流れと
そのキーワードが何をする命令なのかを理解すればOKさ
目的が2つの数字の合計を出力であれば
流れとして2つの数字を入力して合計して出力する事が頭に描けて、
プログラム組む時に加算だからADDを使えればいい

189 :仕様書無しさん:2006/12/28(木) 00:11:49
全部グローバル変数で、しかもメインループや変数宣言が色んなファイルに散らばってて
どこにあるかたどり辛いのがCOBOL

190 :仕様書無しさん:2006/12/28(木) 00:48:44
>>189
全部グローバル変数ってバカじゃねえの?
モージュールの中だけの話だ。ローカルだよ。
他モジュールとのグローバル宣言も出来るが滅多に使わない。
>メインループや変数宣言が色んなファイルに散らばってて
それはコピーライブラリの事か?
じゃあC++なんかもっとひどいが。
いっぱいINCLUDEしなきゃいけないしな。

191 :仕様書無しさん:2006/12/28(木) 01:58:33
>>187
言語が何で書かれていようと、システム自体が易しくなるわけないだろう。
お前、アホか?

192 :仕様書無しさん:2006/12/28(木) 20:45:23
>>190
その「モジュールの中だけ」というのは一般的な言語ではスタティック変数と言われている。
もちろんローカル変数ではなく、分類的にはグローバル変数に準ずるものである。


193 :仕様書無しさん:2006/12/28(木) 22:02:46 ?2BP(1011)
COBOL の static に宣言した変数は global になるんかい?
この説明だと global > static > local って順の変数があるのかと思う。
COBOL ってこういう言語なのか?


194 :無なさん:2006/12/29(金) 16:01:58
グレース・ホッパーとグラスホッパーは似ている。

195 :仕様書無しさん:2006/12/29(金) 21:50:17
アクセルホッパー

196 :仕様書無しさん:2006/12/29(金) 23:43:16
キックホッパー

197 :仕様書無しさん:2006/12/29(金) 23:45:34
デニス・ホッパー

198 :仕様書無しさん:2006/12/30(土) 01:43:57
チリ・ペッパー

199 :仕様書無しさん:2006/12/30(土) 02:28:31
>>192
スコープの話とスタティックの話一緒にすんなよ…

>>193
Cで言うところのローカル変数(関数が呼ばれたときにスタックに取られる
=毎回値が変わる(プラットフォームのメモリ管理の方式にもよるが)、
関数内からしか見えない変数)がなくて、ファイルスコープのスタティック
変数しかないってことだよ。

200 :仕様書無しさん:2007/01/05(金) 21:44:41



試験、試験って、おいら中学2年で基本、取得したよ。






201 :仕様書無しさん:2007/01/09(火) 23:12:52
とりあえず、
MOVE
しておきなさい。
ちなみに、COBOLなんて入社時研修以来接していません。
(現34歳)


202 :仕様書無しさん:2007/01/12(金) 02:02:43
>>201
同じく。配属1ヶ月までは触れたかな。

203 :仕様書無しさん:2007/01/13(土) 17:48:45
>>2
その事をなかなか理解できなと申すか、知らない人がお聞きになっているのですから
おやさしくね^^


って相当遅レス

204 :仕様書無しさん:2007/01/14(日) 12:08:02
現状はCOBOLを別のオープン系言語に変えようとしている流れはあるけど、
正直現実(数百万ステップ〜数千万ステップ)を度外視しているスケジュール(数ヶ月〜1、2年程度)で
立案されているから、思ったようにうまくいかないのが現状。

また、このオープン系言語へのリプレースで人が集まらないという状況も続いている。

特に、COBOLをJava等に変更しようとしているプロジェクトとかは相当苦労しているらしい。

205 :仕様書無しさん:2007/01/14(日) 19:52:04
解らなくもない話だけど、スケジュールの問題は言語に関係ないし、
オープン系の人材不足しているとか言われても、
出来る人間は常に不足しているのは当たり前だと思うが。

特にCOBOLをJavaに変更するプロジェクトって
苦労するって、単にCOBOLerがドキュメント作ってない、もしくは未整備
だったってオチだと思うが。

移行系のプロジェクトでデスマになる原因は見当違いの移行計画も
あるが、前担当者が相当にアフォだとそれはそれで苦労する。特にCOBOLerだと。

Javaだと苦労しない訳でもないが、まあコレは分析ツールやドキュメント生成ツールが
豊富にあったりするけど、COBOLだと資料が紙ベースだったりするからなぁ。

206 :仕様書無しさん:2007/01/14(日) 22:51:31
>資料が紙ベースだったりするからなぁ。


それも全然修正とかされていないものだったりするのが普通 w

207 :仕様書無しさん:2007/01/15(月) 00:27:17
>>205
>COBOLだと資料が紙ベースだったりするからなぁ。

それも言語に関係ないし。

208 :仕様書無しさん:2007/01/15(月) 00:38:50
つうかCOBOL程度だったらドキュメントなくても
ソース解析で充分だろ。


英語読めない香具師か?

209 :仕様書無しさん:2007/01/15(月) 00:40:54
>>208
メガネがないと見えない

210 :仕様書無しさん:2007/01/15(月) 01:17:44
>つうかCOBOL程度だったらドキュメントなくても
>ソース解析で充分だろ。

こういう発言を堂々言う辺りCOBOLerが嫌われてるんだろうなぁ。

211 :仕様書無しさん:2007/01/15(月) 01:23:57
>>207
さすがにJavaだと資料等は電子媒体がメインだと思うが・・・。
Javadocでマニュアルとか、CVSでバージョン管理とか
クラスの相関図なんかはツールで自動生成&メンテなんだが・・・。

別にJavaでも紙ベースでやりたきゃやればいいけど、やってる案件は
現実に見たことはない。


そしてCOBOLだと紙ベースが標準だったりするが。
ご丁寧にコンパイルリストも印刷して綴って保管してたりするし。
アレが役にたったケースなんか10年に一度あるかないかだろうなぁ。

212 :仕様書無しさん:2007/01/15(月) 01:30:37
「動いてるソースが一番正しい」って言う奴は、大抵「正しい仕様」を理解していなような。
よく調べてみると仕様書もソースも間違っていることも珍しくないし。

こういう「常識」が罷り通っている現場って、「正しい仕様」をユーザーも含めて誰も
把握していないことが多い気がしてる。
結局調査対象の数だけ「仕様」が存在するとかね。(w

213 :仕様書無しさん:2007/01/15(月) 06:04:13
>>210
激しく、激しく同意!!



214 :仕様書無しさん:2007/01/15(月) 19:27:17
>>208
お前、アレだろ 「プログラマは徹夜して当たり前」と思ってるクチだろ?

215 :仕様書無しさん:2007/01/15(月) 19:56:07
>>205
>Javaだと苦労しない訳でもないが、まあコレは分析ツールやドキュメント生成ツールが
>豊富にあったりするけど、COBOLだと資料が紙ベースだったりするからなぁ。

ドキュメント自動生成ツールの類なら、COBOLも豊富にあるが。

結局なにも分かってないJava厨の戯言か?

216 :仕様書無しさん:2007/01/15(月) 21:57:32
結局、おまいらにはプロ意識がないってことだ。

全く、なんとか切りたいよこんなやつら。

217 :仕様書無しさん:2007/01/15(月) 22:13:43
>ドキュメント自動生成ツールの類なら、COBOLも豊富にあるが。

IBMのIMSデータベースをいじくるホストシステムなんかで
COBOLにそんな豊富なツールがあったようにはとても思えんのだが。

218 :仕様書無しさん:2007/01/15(月) 22:19:31
>ドキュメント自動生成ツールの類なら、COBOLも豊富にあるが。
だったら何で紙ベースのドキュメントばっかりなのかご説明を〜♪

219 :仕様書無しさん:2007/01/15(月) 22:27:06
COBOLのドキュメント自動生成は明らかにJavaに比べれば明らかにダメダメの域にあると思うが。
最新のZ/OS辺りのだといいのかもしれんが・・・。

i5/OSくらいでRPG系のドキュメント自動生成は、なんとか我慢できなくもない
レベルだとは思うが、アレも結局は紙ベースに落ち着く作りだしなぁ。

220 :仕様書無しさん:2007/01/15(月) 22:41:51
>>だったら何で紙ベースのドキュメントばっかりなのかご説明を〜♪
紙で出さないと客から金もらえないから

221 :仕様書無しさん:2007/01/15(月) 22:48:33
コーダーには解らん世界だな。

222 :仕様書無しさん:2007/01/25(木) 22:31:44
COBOLには作る喜びが感じられなかった。
あんなにツマらん言語も珍しい(´・ω・`)

223 :仕様書無しさん:2007/01/26(金) 21:06:50
それはある意味完成(?)された言語の姿なのかもしれんな。

しかし、個人的にはCOBOLがつまらんというよりかはCOBOLを使う
案件はお客の顔が見えん、と言うかCOBOLの案件だとプログラマーって
社内にヒッキー状態で、美味しいところは営業がもっていくオチだからだと思うが。

他の言語だとCOBOLよりかは開発がプレゼンしたり、顧客のところに言って
生の声を聞く機会が多いけど・・・。

224 :仕様書無しさん:2007/01/26(金) 22:01:33
金融系って基本的に残業多くてブラックなんだよな・・・・。
正直、cobolやるよりも、そっちの方が問題だ。

225 :仕様書無しさん:2007/01/26(金) 22:12:10
別に金融系に限るんじゃなくて、営業がアフォな見積もりだしたり、
開発のマネージャーが精神論だしてきたりする職場がデスマになるだけだろう。

漏れも一応金融系だが、デスマは回避している。
確かに言語はCOBOLじゃねーけど(w

226 :仕様書無しさん:2007/01/28(日) 17:28:13
もうコボルやんのやだー。
Cやったほうがつぶしがききそうだしなー。

227 :仕様書無しさん:2007/01/28(日) 18:34:30
時代が変わって
最近はC使いが叩かれるようになってきますた。
かつてのコボラーのように。
いわく
・年寄り
・Cだけやってりゃいいと勘違いしてる
・つぶしがきかない
・オブジェクト指向がわからない
etc, etc. …

228 :仕様書無しさん:2007/01/28(日) 22:10:58
こぼら度チェック 〜 文字入力編

・いつでもどこでも大文字。小文字の出る幕はない。
・やっぱ日本人はカナ入力に限る。
・全角記号、全角英数字、半角カタカナを多用する。
・「ti」と書いて「ち」と読むのが世界の常識。

229 :仕様書無しさん:2007/01/28(日) 22:25:47
C++の連中でもJavaの連中でもCOBOLは簡単に習得できる。
1ヶ月後にはゴリゴリ書くことができる。
しかし、3年と続かない。モチベーションが維持できないからだ。

Cでゴリゴリ書くのは、簡単には習得できない。
言語のことよりもコンピュータのアーキテクチャを学ぶのが簡単ではない。
なにより、ちんたらポインタばかり使うのうぜったいよ。

Perlでゴリゴリ書くのは、簡単には習得できない。
あの暗号めいた正規表現や、暗黙の約束事が多すぎて、独自の世界観について行けない。

アセンブラも簡単ではない。
というか、あんなものは石器時代の産物だ。
お前はクロマニョン人ですか?

そんなわけで、おいらはC++プログラマ。
正直、社内SEになってVBAでもするのが勝ち組だと思い始めた30歳。


230 :仕様書無しさん:2007/01/28(日) 23:05:45
Cはポインタがあるからある意味、楽な印象あるけどなー。
まー、***hogeなんてポインタ使うのがウザいってのは解らんでもないが。

アセンブラは言語自体は簡単だろ。使いこなすのとは別レベルだろうが。

勝ち組って言うとビミョーだけど、社内SE(?)でネットワーク管理とかノーツサーバーを
ダラダラと面倒みるのが最強な気ガス。

と言うかプログラマって職業自体が負け組

231 :仕様書無しさん:2007/01/28(日) 23:38:36
Notesサーバは独自過ぎて、構築凄い大変だった。
開発となるとなおさらだろうな。
小さいところでダラダラ面倒みるのは楽かもね。
しかし潰しがきかないか?

232 :仕様書無しさん:2007/01/29(月) 00:06:39
>>230
そらあ昔のCICSなCPUの話だろ。
昔のRISC系ですら、とたんに難しくなる。

ていうか最近のCPUだと、
パイプラインを乱さずに、分岐予測やキャッシュフォールトまで考えて組むなんて無理だ。

VLIWなCPUだと事情はさらに複雑になって、
凡人がアセンブラで組むなどほぼ不可能だ。
言語が簡単だとか難しいといような領域を超えている。
人間がオプティマイザになれるかっつーの。


233 :仕様書無しさん:2007/01/29(月) 00:16:06
アセンブラの件は組み込み系な世界じゃねーのか?

CELLのOSをアセンブラでヤレと言われたら死亡するだろう。
とは言えC言語とかでコンパイルしたとしても、あの辺りでドライバやらカーネル
いじくりだすと、マシンコードは読むとは思うが。

55 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)