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

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

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

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

「大手の銀行とか重要機関は全部COBOLだし、COBOLから変更の予定もない。
 若手にはCOBOLは不人気だからCOBOLの担い手が減ってきている。
 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.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)