【コボル】COBOL不要論【ただのDSLだよね？】->画像>1枚

COBOLでCOBOL書ける?

まさかの次スレ
前スレの名物困ったちゃん来るかなー

前スレ
【コボル】COBOL不要論【いらない】
http://hibari.2ch.net/test/read.cgi/tech/1248937976/

とりあえず出てた話題とか適当にピックアップ
・コボラーにかかれば基本情報で出てくる正規化をすればバッチ処理はいらないらしいよ。凄いね(繰り返し出た話題
・なにがCOBOLだ。Java+swingなんか冗談だろ、時代はVBだよ。なにせWindows Formsだ。一味違うぜ。HTMLなんかじゃ表現力が足りません。
・んなこたないJS凄いぜいやFlexだドットネットだと喚く方々の登場後うやむやに
・PCサーバと仮想化で全部解決。メインフレームは遺物。

概ねこのあたりから適当に気になったところ突けばCOBOL関係なくても回るスレだったようです

まだ不毛な主張を続けるのかよ。

続けなくていいです

>>1
修士課程の同僚がFに入社したが、COBOLでCOBOLコンパイラ書いてるって泣いてたような

今時ライブラリも使えずプログラマーが自分でロジックを考えないといけない
時代遅れなCOBOLなんてもう要らない。

なに言ってんだお前

ライブラリがあると自分でロジック考えなくていいんだw

>>10
今時ロジックや仕様みたいな下衆な作業はプログラムが組めないゴミSEの仕事だろ。
技術の進歩についていけない老害は黙ってろｗ

そのライブラリは誰が作るんだよ

>>11
ゴミコーダーさん乙
はやくSEになれるといいね

>>13
＞はやくSEになれるといいね

落ちぶれてどうするw

いくらライブラリがあるからって、
SEやPEを介さずに一から十まで自動的に全部システムを構築できるのか？
そういう機能があるのならJavaのこと見直すかな。

SEがコーダーより給料低いとこってあんのかな？
いや、確かに給料問わず昇格して人生落ちぶれたように感じられる奴はまま見るけどなw

大体プログラムが組めないゴミSEがPGより報酬がいい事自体間違っている。

>>17
会社の不満は上司に言えよ。

プログラムが組めないゴミSEがここ監視してんのかな

そもそもよくプログラミングせずSEになれたなそいつ
そいつってコードも読めずに設計してんの？設計じゃなく机上の空論に終わりそうなもんだが、そういう才能でもあんのかね
>>17は気の毒だが

ここの住民はSEを知らんらしい。
SEが設計なんてする分けないだろ。受注活動から人材調達、稼働後の
フォローといった、お前ら対人恐怖症供には出来ない作業を
やるんだよ。
接待ゴルフとかしないだろ。

営業から企画に運用管理まで全部やらせてんのかw
そんなんじゃ最初の肩書きなんてもう飾りになってるんだろうけど
その方は労わってあげたほうがいいと思うw

>>21のところは悲惨だよねw
PMの仕事を全部肩書SEに任せてるんだから…。
SE単価で馬車馬のようにこき使われてるんだろな。

ああ、だから設計をプログラマがやってるのかwww

>>21
プログラマーに必要なスキルは仕様を正確にコード化する技術であって
対人コミュニケーションのスキルなんて全く必要ないと思う。
そもそも他人と関わりたくないからPGの職に就いたのに。

>>24
＞>>21
＞プログラマーに必要なスキルは仕様を正確にコード化する技術であって
＞対人コミュニケーションのスキルなんて全く必要ないと思う。

そのレベルの作業は機械化されていってるけどな。
第一、コード化技術だけで充分なら、ハッカーがプログラマーでもある事の説明が付かないだろ。

>>25
> 第一、コード化技術だけで充分なら、ハッカーがプログラマーでもある事の説明が付かないだろ。
意味不明

>>25の言いたいことがよく分からないけど
少なくてもプログラマにもコミュニケーション能力は必要。
システム設計したSEに質問したり、上司やリーダーに報告とかいろいろある。
システム屋だったら一人だけで仕事なんて無理でしょ。

スレ違い

>>27
別に仕様書通りにきちんと納期までにコーディングするだけだから他人とコミュニケーションを取る必要は無い。
仕様上の矛盾なんてそもそもPGの責任ではないし、知ったことじゃない。
またリーダーへの報告も完了若しくは遅延等の最低限の報告のみでいいと思う。

実際自分も職場で丸一日人と会話をしないことなんてザラだし、むしろ他人と馴れ合うとは好きじゃないからプログラマになった。

君もスレ違いでは
いや現場がCOBOLならいいんだけど

そのスタンスは長持ちせんよ。上はミスを棚に上げて「気付いたんなら相談してくれ舐めてんのか」とか「気付かないとか頭使ってんのかこっちも一杯一杯なんだよ」などと平気で言うぞw

無口にやりすぎると「メール送りましたよね」「見てねえよ口答えすんな」コンボも珍しくないからな
上っ面だけでも仲良くやってると期待

>>30
> 上っ面だけでも仲良くやってると期待
>

コボラーってそういったつまらない人間関係やコミュニケーションばかりに気をまわしているから
肝心プログラミングのレベルが低いんだと思う。
本来プログラマーってPそういった人間関係なんて気にしなくていい職業じゃないの？

>>29
ドライだね～
一番下っ端の立場ならそれでいいのかもしれないけど…

ＳＥと比べたら、プログラマーにコミュニケーション能力はいらないかもね。
お客さんや上司や他のエンジニアとか、交渉事は全部ＳＥに任せてしまえばいいんだから。
でも、プログラマのままだと、給料は増えないし、責任のある仕事も担当させてもらえない。
一生プログラマで生きていく方が大変でしょ。

仮に愛想笑いや上っ面の謝罪で面倒ごと回避できるならいくらでもやるぜ
浮いた時間で肝心のプログラミングレベルの向上に励むもよし、趣味に潰すもよし

でも人間関係のくだらなさは上っ面じゃ回避し切れないのよね

>>33
責任のある仕事って、失敗したら人格レベルまでこき下ろされて、成功したら上の手柄になるって奴の事だろ
願い下げだよ

>>33
そもそも勤続年数に応じて出世しないといけない、という日本固有の古臭い考えたかだそもそも間違っている。

もう少し具体的にCOBOLプログラミングの話ができないものかな。

>>36
出世しなくてもいいけど、給料も増えないぞ。

>>38
報酬は勤続年数に応じて増えないとおかしいだろ。出世しないと給料が増えないって日本ぐらいだろ。
つか常識的に考えて営業やSEなんかよりPGの方が優秀なんだからPGの待遇をもっと改善すべき。

>>37
COBOL自体が劣ってるのはもはや自明であり議論の余地が無い
よって次スレも不要だったのだが立ってしまった以上とにかく埋めようという皆さんの涙ぐましい努力の結果がこの流れなんです
わかってあげてください

最近落ち目で他言語から叩かれまくりのJava
そのJava使いが唯一叩ける相手がCOBOLなんです
哀れだと思うなら叩かれてあげてください

>>40
文字列領域はREC定義で取得するのでよいのだが、
極めて使いやすい文字列処理ライブラリが標準で提供されたら、
COBOLの用途は少しは拡がるものだろうか。

極めた所でCOBOLの上だろ？
まあプアなphpくらいは目指せるんじゃないの

でもなんだかんだで基幹業務系や社会インフラ等、我々の社会で重要なシステムは未だ殆どCOBOLだという現実…。

>>44
いやCOBOLが…、というより他の言語が稼動するフラットフォームがあまりにも脆弱過ぎるのが
いまだにCOBOLをのさばらせている要因だと思う。
特にWindowsServerなんて20年以上昔のメインフレーム以下の安定性・信頼性だからそういった社会インフラ系のシステムを
メインフレーム+COBOLからWindows系に置き換えたら社会全体で中国の高鉄のような事故が多発してヘタすりゃ人類が滅亡しかねないw

まぁ最近はメインフレームからLinuxへのリプレースという話はよく耳にするけど、開発言語は一体何を使っているんだろうね…。

COBOL

>>46
それはない!!
Linuxだと恐らくC++かJAVA若しくはRuby辺りだと思う。

COBOL卒業した人は、何言語やってるの？
Java？VB？

>>48
Prolog

>>49
COBOLを10年やったら移れるのはそれしかないな。

前のスレのSQL正規化の人は、多分月次処理などを実運用中にテーブルをさらに新規に作成し、
ボタン一つで処理するので、そもそもバッチやCRONという概念が無いのだろう。
であるから正規化や、バッチは必要ない、COBOLにWinFORMやHTMLのボタンが無い、と言っているのだろうと解釈した。
普通、正規化と言ったらDBの設計だと思うのだが、この方法はACCESS等では可能なのかもしれないが、
実際どうなのだろうか。

SEとコーダーとテスターの業務って全部一人でやるもんだと思ってたんだけど違うの？
分業してるとこあるの？

漏れはＣＯＢＯＬ→Ｃ→ＪＡＶＡ→Ｃ＋＋

漏れはＣＯＢＯＬ→Ｃ→ＪＡＶＡ→Ｃ＋＋→LabVIEW
だった

まあ、ATMシステムをCOBOL→JAVAに代える勇気はないわな。

科学技術計算もFORTRANがしっかり残ってるし、CやC++よりも
最適化が進んでる。ポインタとか使わないのが標準だから。

>>48
漏れは、C→VB6→COBOL→VB.NET→JAVAだよ

20年後にはJAVAプログラマがコボラの後継者になる予感。

20年かかってその位置づけなら定年まで食ってけそうだな
その頃Rubyとか存在しとるんだろか？

一昔前は「JavaがCOBOLに取って代わる」と言われていたけどCOBOLは未だ健在でJavaが先に消えてしまったな…

金融関連のホストを一掃しないかぎりCOBOLは残ります

>>60
金融系のホストを脆弱なWindowsに置き換えたら毎日のようにトラブルが発生して経済が破綻してしまう!!
((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>61
なんでWindows一択なんだ…。東証みたいにLinuxを使えば?

>>62
LinuxはVBが使えないから論外。

つまりVBといいたい為に書いてるのか。

鯖にVBで何を作るんだ

つか世の中のシステムなんてVB+SQLに十分リプレース可能だろ。
基本情報の例題やプログラミング・SQLの参考書を見れば判ること。

>>66
そうね。パソコンもヤフオクで13000円くらいでノートを落とせばいいし。

C#あるのにVB？

なんでよりにもよってVB

VBはSIerのデフォルトスタンダード

>>68>>69
むしろVBを選択しないのが不思議…。C#なんて実績も無いただのゴミ

>>70
ぷっ

釣りのつもりならまだRubyの方が脈絡あるような
ちょっと何から突っ込んでほしいのか分かりませんが、MS限定ならPowerShellもいいよとかネタ振ってみよう

>>70
おいおい…

>>70
m9（＾Д＾）プギャー

1.0～2.0の頃はC#のほうが断然よかったが
ここ最近はVBも結構頑張ってると思う。2010（4.0）だと、もうそんな大差はない。

いや、厳密にいえば機能的にC#のほうが上のものもあるが、VBと差が出るほどフルにC#を使いこなそうとすると、色々変態チックになりがちなんで
VBのほうがまだ現実路線のような気がしなくもない。

と、最近C#2010,VB2010と続けて、こじんまりとしたシステムを開発してみてそう思った。
まあ前述したとおり、使いこなしている人はC#のほうが魅力的なのかもしれないけど。ふつうに使う分にはC系の構文なのかベーシック構文なのかの違いしかない。

情報システム構築する上でC#で出来てVB.Netで出来ない機能ってある？

普通に使う時こそ記述能力や可読性が大事じゃないの？
なんか君にかかればJavaScriptやPythonも変態チックで済まされそうで怖いな
現実路線どうこうじゃなく、記述能力が低い言語に満足しちゃって井の中の蛙になってるだけかもよ

使いこなせて無いだけかも知れんが
少なくとも開発してて、「ちくしょうC#じゃなきゃだめだー」って頭抱える様な事はなかったよｗ

まあなにがいいたいかっていうと、みんなVBに悪いイメージ持ちすぎなんだよな。
たしかにVB6とドットネットの最初の頃は悪かった。あれは本当に悪かったと思う。
でもVBもアレから進化してんだぜ。COBOLスレで言うこっちゃないと思うがｗ

安心しろ
お前は間違いなくCOBOLスレに相応しい逸材だよ

VB.NETは進化して使いやすくなったが、
結果ちょっと機能の足りないC#になっただけという

ラムダ式とか頑張ってるのは分かるんだけどね
どうせILレベルで一緒の物が出来上がるのなら、素直に書けるC#選ぶな
好みの問題で可能性狭めてどうするのよ

>>79
さすがはVB厨。PHPしか知らん奴と同じ事言って恥ずかしくないのw
もちろんCOBOLしか知らない奴も長年同じ事言ってたのだが、流石に今では通用しない事に気づいて黙るようになった

うえ理論で言ったら負けざるを得ないよな>>VB.NET
おれもC#よりVBのほうが上とは思わないし。

ただまあ、CLIレベルで一緒のものが出来上がるってんなら、COBOL.NETとか、どうなのよっておもうけどな
それはまた別の話か。

>>84
給料変わらなきゃそれで問題ないのさ
情報工学突き詰めたいならこんなスレ煽ってちゃだめよ

もう俺には最近の言語はよう使えん
俺もHaskell本買ってみたけど、ジジイにはろくに理解できんかったわい

実際、PHPで困ったことないよ(^O^)／
VB？うーん、、、f^_^;)

実際VB2010とC#2010を比べて非難してんなら問題ないけど。



両方つかって批判してんの？

ASP.NETを否定する訳じゃないが、むしろなんでVB選定することになったのか聞きたいな
なし崩し的にC系で書けるならC#一択だ、となってしまった所も多いだろう
VB.NETの文法的な良さってなんかある？好みでいい

C系の文法ってそんな優れてますかね

>>88
なんで両方使ってるんです？
うちではドトネトの初期で古いVB開発しかできない人は一斉に切られた

>>91
へえ。なんで？

>>90
JSとかまで含めたら、優れてるというよりもっとも一般的って所でしょう。Macがいくらかっこ良くても、個人用途での実用性を考えたら結局買わないのと一緒。
Cそのもので言えばどこまで行っても高級言語の皮を被ったアセンブラ。だから価値があるってだけで、決して見やすくないしあれなら僕はまだフォーマットした括弧だらけlispの方が好きです。

>>91
Java外注にシフトしました。

identification


俺の事も思いだせこの野郎

C系の構文が見やすいってのも宗教っぽい気がするガの。ほんとかよ

プロだったら言語に依らず、お客さんの要望に答えろって事だ。
新規開発で言語選定が可能なら、
コストや保守のし易さとかユーザーサイドで考えて選定すべきだ。
俺がC++得意だからとか、そういった理由で選んじゃいけない。

どんなに他言語ユーザーが息巻いてても、結局COBOLでもVBでもlispでも家族養えてるのなら問題ない
暇作って勉強くらいはするがね
C#君は食えてるのかね

>>97
C++は喩えにしてもどうかと思う。いくら得意でも、よほどキツくパフォーマンス要求されなきゃ避けるよ
ゲームでさえ緩い部分はスクリプト多用してるんだから

十年以上COBOL後継の本命はJAVAだったのであり、そのJAVAキラーとして
MSが遅ればせながら投入したのがC#。.NETの中で唯一JAVAやCの上に行く
可能性を持っている。そのことを考えれば、今後、VBが事務処理で大展開なんて
ありえない。

>>100
でも結局JavaがCOBOLに取って代わることはなく、COBOLが生き残りJavaは消えちゃったんだよね…。
うちの会社なんて中途半端にJavaに移行してしまったから今大変なことになっている。

他の言語を使えないジジイのために.NETという仕組みがあってだな
COBOLでもVBでもIL吐いてくれる
メンテを誰がするかは知らん

C#使う位ならJava使うよ。

ドットネット開発なら個人的にはbooがいいと思う。誰も使ってないしネームバリューもないけど。
C#が持ち上げられてるのはよーわからん。

COBOLの基幹システムをJavaでリプレースしようってPJにちょっとだけ関わったんだけど
なかなか面白かった。
PJサイドはJavaしか知らない奴が大半、ユーザー（一応システム部門）はCOBOLしか知らない
ので、可変長の文字列？それって何？って感じで実装の話になると全く言葉がかみ合わないの。
まあ運良く途中で抜けられたんだけどそのPJ多分エラいことになったんじゃないかな。

「あのね、悪いんですがクラスとかよくわからないモノ使わないでくれませんか？」
「これJava移植作業なんですけど？」
「あーあー、なんでわっかんないかなー。そりゃねJavaならオブジェクト指向ですか。多分その方が格好いいんでしょうけどね、こんなん俺ら分からないの。そこんとこ分かってる？」
（分かってない事以外わかんねーよ）

つうかPJサイドCOBOL勉強しろよ

>>106
COBOLのリプレースでJAVAなんか採用するからそうなる。
IT業界のデフォルトスタンダードであるVBを使えば幸せになれたのに…。

道具が良くても使い方を知らなきゃただのゴミだわな。
むかし日本が途上国に井戸掘りの機械を買って与えたが、使い方がわからなくてずっと放置されたまんま、あいかわらず飢餓の国があるらしい。

>>108
おまえの発言は釣り臭がひどくてダメです

VBと聞いたら親の仇かのように噛み付く奴がいるね
そしてまたいつものように内容がない

VBは昔のクラサバ移行で痛い目にあってるエンジニアが多いからなあ。旧VBのほうだけど。
一度ついたネガティブなイメージは、なかなかどうしても拭いきれないんでしょう。

大概は↑でも語られてる通り、COBOLとの設計思想の相違からくる無理が祟っての事なんだが

今はその役目（汚れ役）をJavaに譲ったけど
Javaもそのうち（いまでもそうか）戦犯のように語られるんだろうなあ。

COBOLでもVBでもJavaでもいいけど
それしか知らないアホがいるからイメージ悪くなる

>>105-106
それって、Cobolのソースコードをそのまま変換するようなのかな?
Move a to b
なら
なんかのライブラリ.move(a, b);
にするようなとか。

>>108
デフォルトスタンダードって何だよw
変な言葉作るなwww

>>105,>>106
そういう話はよく聞くよな。
ユーザーサイドとPJサイドが別会社だと、
連携が取れなかったり、責任の押し付けあいが起きてデスマ化する。

>>114
プログラムの改変はべたにやって動くかも知れんけど、
MFからCSに移行とかだとデータの変換で死ねる希ガス

移行前の時点で既にデータ不整合だったのを発見してしまって、そこから処理ロジックのミスが10年以上見過ごされていた事を知ってしまった、あの日( T_T)

>>118
深刻なバグでなければ放置なんて、よくあることじゃん。

月次処理すると残高が微妙に変わるだけなんだけどね

請求金額の端数処理とかあきらかにバクってても、直すと怒られたりする。
いままでと金額が変わると取引先側で稟議が必要とやらで大変なことになるとか。
言語リプレースしてもその仕様は引きずって、意図的にバクを再現する必要があったり。

>>119
ドキュメント、何それ？状態だったから、影響範囲が不明なんだよ。
結局、怪しいデータだけ手管理になつた。
一つだけ良かったのは、扱いにくいデータを怪しいデータ扱いして開発の手間を減らせた事。

http://my.chiebukuro.yahoo.co.jp/my/myspace_quedetail.php?writer=song_kawasaki

データの手管理って、
データベースを開いて直接データを操作してるってこと？
それともマスターメンテ画面を作ってそこから操作してるのかな？

コボルで書かれたシステムのデータの一部を統計解析するので
このソース読んでデータの抽出方法を考えてきてくれ
と言われて, トータル5k行くらいのソース渡されたんだが,
いざコードを読もうとすると, 脳みそが拒否反応を起こして
睡魔が襲ってきます

データ定義だけ読めば何とかなるもんですか???

>>125
たかが5000ステップくらいで拒否反応起こすような整理能力の無い脳みそでは
言語関係なくそもそもプログラマーとして向いていないと思う…。

まぁコーダーなら話は別だが…。

5000行なんてたいした事ないけど、
構造化されてないスパゲッティなプログラムだったら死ねる。

>>126
フツー， 他の言語だと1kに満たない行数で書いてあるんだが

5kはJava脳とかだときついかもな。
cでもしmain関数が5000行あったら気が狂うが、
さすがに構造化くらいされてんだろ？

>>129
FORTRANの5kは全然区にならないんだが
つか, FORTRAN屋だよ, 本職は

>>130
# echo 'FORTRANの5kは全然区にならないんだが' | sed '/区/苦/'
つか， java 何かで統計解析やったら日が暮れる

他の言語は、データ定義だけ読めば何とかなるもんなのか…

>>132
ほしいのは, どのファイルのこの部分をどの部分を取り出せば良いかの情報
一つのファイルに収まっていなければ, 他のファイルも同様に再帰的に読んでいけば良い
と思ったんだけど, そうはいかない???

ステップ数の長いプログラムは、面倒であっても紙に印刷してマーカー引いてる。
画面とにらめっこしても埒が明かないよ。

Fortran屋かー。なんかCOBOLやJavaとは対局な業種ってイメージだw
ところで充分目的が定まってるのなら専門の担当者にヒアリングした方が早いと思うぞ。
絡まってるところが皆無だったとしても、見当つけるのが一番早いのはそのコードに関わってた奴なんだし。
Javaでいくら綺麗に組まれてても、細切れファイル追いかけまくる作業は眠いしな

> 専門の担当者にヒアリング

なにぶん, 現在それがいない（システムをメンテするときはコボル屋さん
の会社に出してるらしい)ので, わけのわからない言語(lisp とか ml
とか haskellとか)を趣味でつつき倒してるおれにお鉢が回ってきた

DATA DIVISION, どのファイルに書き出してるかと
調べ始めたんだけど, いつも使ってる言語と違って構文違いすぎ
# おれにはついていけませんwwwWW

つか,
``lock もかけずに同じファイルに書き込んでるみたいなんだけど, これだいじょうぶなの???''
``おれのほしいデータは最終的にどのファイルに集約されるの???''

って, な感じで謎は深まるばかりです

なんか並んでる言語名見る限り、考え得る限りもっとも場違いな人選されたんじゃないですかね。
排他制御はシステムが面倒見てるはずだから気にしなくていいと思うけど、必要なデータがどこかに集約されてるとは期待しない方がいいかも。
初期設計時に想定してない集計だからこそ業務として発生し、依頼されてるのでしょうし。
不得手なら面倒でもフローチャートを書き出したほうが早いかもしれません。

数学屋に事務処理言語のまま渡すってどうなんだ
建築デザイナーに図面とつるはし渡すかのようなシュールさを感じるw

>>138
某リフォーム番組で無理やり資材加工させられる匠みたいたなｗ

コボルでフェラチオソフト作りたいよ。
わかりません

COBOLかー
もう１５年やってないなあ

そんな漏れは今モータ制御で交流理論と機械力学の勉強中
言語はC++が一番好きだけどたまにCOBOLが懐かしく感じる

すべて小文字にするだけで一気にお洒落なデータ指向言語に

COBOLでモータ制御

いまのCOBOLは小文字でもＯＫじゃなかったか。
なんか前に古い汎用機のリプレイスでＯＲＡＣＬＥ移行とかやったけど
変数名を全部ＯＲＡＣＬＥ－ＤＢに合わせてたな。（キャメルケースって奴？）

>>1
>>7
COBOLでCOBOLコンパイラ書いてるという噂は私も聞いた。

世界初のLISPインタープリタは、FORTRANで書かれたそう。

何を何で書いてもいいんじゃない？

フリーのcobolの開発がもうちょっとやる気あれば
PCでcobol使って遊べるのに

そんなに駄目な子なの？

フリーのCOBOLなかったっけ

FreeCOBOL.iNFO～フリーのWindows用COBOLコンパイラまとめ～
http://labs.netbata.com/cobol/

汎用機とシステムのセット販売で大企業の強大なバックアップを受けられることがウリのＣＯＢＯＬで
フリーの実装って需要あんのかね。
まあ学習用か。

プログラム言語云々なんて所詮数ある手段の一つに過ぎないからな…。

>>152
COBOLerを増やしたい、せめて維持したいがための撒き餌かも。

COBOL汎用機から、クラサバにリプレースしたものの、中身はエミュレーターでCOBOLが動いているのを知った時の絶望感は異常。

だって作りなおせないもの

ん？汎用機COBOLをクラサバCOBOLへ移植したんじゃなくて、
サバ(UNIX or Windows)上で汎用機のエミュレータが動いているの？

そして、GUIも
ドロップダウンメニューで選んで送信ボタン
ってのが裏で
画面のこの位置にカーソル持ってきて数字入れてえんたー
って実行されるように出来ているんだろうなあ。

>>158
soretyottotanosisou

>>158
何そのオンラインバッチもどき

COBOL to Javaの自動変換ツールは山のようにあるけど
余り利用されてないのかな？
すくなくとも言語にまつわる問題は一気に解決しそうなんだけど。

>>161
未だに古いシステムをリプレースできてないところは、そもそもシンプルな仕様変更さえ超怖い状況下にあるものばかり
コンバートしてテストして稼働出来るような部品であれば、都合さえつけばとっくにコンバートもシステム移行も終わってると思いますぜ

とある業務系では
if 1989
...10ベージ位の処理
if 1990
以下ry)と延々と、しかもプログラム中に散りばめてあった。

>>163
>if 1989
なにこれ？

あんま想像したくないけど、まさか西暦別で処理書いてんの？ｗ
流石に遺産コードにしても担当者生きてたら怒鳴り付けたいレベルですなあ

>>163
ソースコード変換以前の問題の事例ですねわかります

こんなの、javaに変換できたところで……。

年度・法律が変わると、帳票の指定様式が整合性無視で変わるという、涙物。
しかも、年度によっては複数年度過去まで遡って累計が必須。
唯一の救いは、過去に出した計算結果は絶対に変えてはいけないので、補正分データを追加すれば良かった事ぐらいかなw

一般的コボラ程度の涙ぐましさですね。
もちろん担当者様を揶揄しているわけではありますん

最後に関わったＮ系、その手の笑い話状態のプログラム減ってた気がする
遺産の重さに負けず、頑張って書き換えてる人はいるみたいだな

何で一つのプログラムにいろんな処理を無理やり突っ込む作り方をするのかな。
処理を細かく分けれて組み合わせて作れば、メンテの負担も減るのに…。
すごく腹が立つ。

COBOL85 のコンパイラ書いてみようと思ってるんだが、
COBOL85 って LALR(1) じゃ解析できないよね？

>>171
このスレでLLだのLRだのが分かる香具師が何人いるやら…

>>171
コンパイラに使う言語に関心がある。
COBOL用じゃないけど、最近見たのは、Haskellで書いたやつ。

Cobolはすべてが言語仕様に入ってくるから大変だと思うけど。

同じ語で別の意味持ってたり、省略可能な項目も結構あるから字句解析も構文解析も面倒な予感

それでもC++よりは、まあ。

スレチなのだがＣＯＢＯＬで２０年ホスト系で働いてた隣のおっちゃんが、パッケージ化されてきたからクビになった。っていってたんだけど。どういう意味？

http://www.amazon.co.jp/dp/4274211312

>>178 これ、新刊だね。

コボルとはコロボックルの略である

むしろコボルト

コボルでラムダ関数みたいなことはどうやればいいの？

>>182
やめとけ

思い返すとCOBOLについては一切身銭を切ったことがないけど、
困ることが何もなかったのは色々と考えさせられますな。
最近の流行の言語は機能は豊富だけど、学習コストが高すぎるのよね。
IDEや入力補助がないとコードを書きあげられないのはどうなのかしら。

いや、最近の言語でもIDEなしでコード書けるし、
むしろコボルってIDEとか入力補助ないような非効率な開発を
まだ続けてるんだという驚き。

スレタイの「ただのDSL」呼ばわりが改めて沁みる問答だ

で最近のPGがよく口にする「関数が無いから組めません(ｷﾘｯ」となるわけですねｗ

まぁ最近の開発はGUI部品を貼り付けてクラスや関数をスクラッチして作成する簡単なお仕事だからな。
ちゃんとコードが書けるPGなんてPG全体で1割いるかどうかだからな・・・。

cobolもideあるけど只厨にはハードルが高すぎるな

>>186
趣味で(興味本位で)COBOLを触ろうなんて奴は、めったにいないから無問題

というか、COBOLでオプソなんて、ORCAくらいしか思いつかないけど、
他にもあるのかな？

>>187
まるで、コボラーなら「関数が無いから組めません(ｷﾘｯ」ってならないと
言ってるみたいだ。

昔いたコボルの現場で日付の論理チェックのサブルーチンで「日付チェックのクラスが無いから出来ないです！」といって
バンザイしてたC++プログラマなら見たことあるよ。

>>191
そういう人間をCOBOLの現場に連れてくるなよ w

「負数の数を含む剰余」ってどう定義されていますか?
処理系間で互換性はありますか?

かつては金融機関の勘定系（基幹系）システムは全部COBOLで動いていた。

設計思想が古かったり、2000年問題の主役の一人だったりで>>1みたいに嫌っているプログラマー多し。
だが、COBOLが愛される最大の理由は信頼性だろ
バグ1個で億単位の損害が出る分野には枯れた技術や枯れた言語が一番
こういうのだとバグが少ない（はず）
埃かぶったWindows3.0とかが取引先で現役とかザラですし
クレジットカードのシステム全部COBOLで動いてるらしいぞ

COBOLがダメな理由がない限り使い続けるほうがいいに決まってる。

最新の～～だったらこんなこともあんなこともできてー
ってたいていは必要の無い機能だし。
COBOLerとかいって笑う人多いけど、おまえら3000万口座で24時間365日絶対に止まってはいけないし
計算を間違えてはいけないシステム設計したことあんのかよ。

東京海上日動の新システムはCOBOLを採用
http://itpro.nikkeibp.co.jp/article/NEWS/20080906/314277/
COBOLこそスピード経営に必要 BY ジャパネットたかた
http://itpro.nikkeibp.co.jp/article/COLUMN/20100319/345984/

>>194

COBOLが嫌いな理由、コーディングしても楽しくない、ライブラリが充実していないので全てコードを自分で書かないといけない。
あとステップ数が異常に多くてコードが難解。

> COBOLerとかいって笑う人多いけど、おまえら3000万口座で24時間365日絶対に止まってはいけないし
> 計算を間違えてはいけないシステム設計したことあんのかよ。

なんで24時間365日絶対止まってはいけないの？OSのアップデートなどでWindowsを定期的に再起動するでしょ？
コボラーの常識ではアップデートなしの危険な状態で運用するのが当たり前なのw

普通は止まってはいけないシステムを設計するより止まっても支障ないような設計にするのが当たり前なのに・・・。

しかし言語が作られて何十年も経ってるのに、
未だにライブラリが揃ってないというのはどういうことか。

>>194
人間が作る以上、バグを無くす事なんて不可能だし
たとえプログラムにバグがなくてもOS側の問題でトラブルが発生するんだから365日無停止のシステムなんて構築不可能。

確かにCOBOLは計算一つ行うために延々と定義みたいな処理を何十行も繰り返さないといけないというヤバイ言語だな

だがコイツなら0.1を正確に表すことができるから
新人でも浮動小数点使って誤差出す初歩的なポカをやらなくて済むじゃん。
銭の計算は１０億で１円の誤差でもアウトだから。

1/3=?

>>197
バグ1個で万とか億とかの銭が大量に動いたりしたんじゃ、ヤバすぎるだろｗｗｗ

お前らそろそろVISUAL COBOLについて語ろうぜ

> 銭の計算は１０億で１円の誤差でもアウトだから。
なんでなんだろうね。商取引も相対誤差ε以下は許容するとかなって
いるといいのに。

>>200
そもそもバグなんてプログラマの責任じゃなく設計者の責任だろ

>>202
いや、今でも誤差は許容してるんじゃない？
１０進で何桁未満は切り捨てor四捨五入みたいなように決めておいて。

本当にあるこんな話

A「私、金融系のシステムリプレースやってるんです」
B「へえ～、COBOLからJavaに置き換えるのですか？」
A「いいえ逆です。JavaからCOBOLに置き換えるんです」
B「えっ？？？？」
A「Javaから、COBOLです」
B「(ﾟДﾟ)ﾊｧ?」

この業界に長くいると時々出くわすね
技術力はあるんだけど
「お金の計算をするシステム組んだことないんじゃないの？」
って人

>>206
そりゃそうだ。君が世間を知らなすぎるだけ。

>>206
最近はCPUって何？OSって何？とか言い出す人間がプログラムを組む時代だからな。

スーパーでも24時間営業の店とかあってNCRのノンストップ・コンピュータ(HP社に吸収されたタンデム社のOEM品？)を使ってるよね

>>204
いや、そういうんじゃなくて小数点７桁の数値を単純に数百万回加算しても誤差が出ないという話では？
初期のパソコンによく使われたZ-80とBasicの組合せでは0.001を単純に1000回足しても1に為らずに0.997とか0.999になってしまうものだった

確かi386とBasicの組合せ(OSはMS-DOS)でも出たような記憶があるんだよなあ
勿論1000回ぐらいじゃ出ないんだけど・・・

今、Excel2000のマクロで0.0001をFor～Next文で一万回足したら…orz

>>210>>212
0.1 を 1 万回足してもなかなか 1,000 ちょうどにはなってくれない場合がある。
コンピュータが 2 進数で動いていることの証拠なのだが、金融の世界ではかなり困ったことになる。

2進演算では、小数点以下の丸め誤差が発生してしまうためだ。

金融業界は怖いぞ～、この業界では超巨大な銭を扱っていて、
さまざまな金融商品を数十兆円単位で取引しているが・・・
0.1％の誤差があるだけであっという間に数百億円単位の損害を叩き出す大惨事になるというとんでもない世界
だから金融業界ではBCD演算が必須

COBOLは言語の仕様でBCD演算をサポートしているから銭の勘定では他の追随を許さない安定性がある。
他の言語でもできないというワケではないが、初めからついてる奴と、後付けの差は大きい。
要するに「そろばんや電卓での処理」をそのままプログラムに落とし込めるから金融系では確実に使える

蛇足だが、MSX（大昔の8ビットパソコン）にもBCD演算機能が存在する

BCD演算って他の言語でもライブラリとかで使えなかったっけ？

>>214
有るだろうけど(Excelだと通貨型)つまりは意識してデータの型を宣言しなければいけないという事

>>214
有っても確か演算処理が非常に遅かったはず・・・

パフォは一番悪いとかなんとか

>>216
COBOL使うようなマシンなら、CPUがBCD演算をサポートしてるんじゃない？

何か勘違いな部分もあるようなんで…
COBOLは言語の仕様で固定小数点演算(Binaryだと浮動小数点演算より高速だが有効桁が小さい)
扱える形式
Binary
BCD(pacdデシマル)
ゾーンデシマル(文字型数字)
何れでも小数点ありの変数として計算可

何か勘違いな部分もあるんで
COBOLは言語の仕様で固定小数点演算(Binaryだと浮動小数点演算より高速だが有効桁が小さい)
扱える形式
Binary
BCD(pacdデシマル)
ゾーンデシマル(文字型数字)
何れでも小数点ありの変数として計算可

ありゃ、二度書きしちまった^ ^;
小数点の位置を固定するので、ある意味integerとして計算できる

COBOL以外でBCDを高速で扱えるのはPL/1くらいか。

先ほども云ったようにコンパイル時に計算対象の変数、数値を解析して小数点位置を決めうちし計算するのでBinaryであっても0.1を１万回加算しても誤差がでる事がない

PL/I、俺自身は使った事無いけど使われなくなってしまったのは惜しいと思う。IBM、パソコン用にだしてくれないかなあ(格安で…)今出たらCOBOLもJavaが殆ど消え去りそうな気もするけど

システム構築、工程品質管理、その後の保守をする立場でいえば、COBOLは色々な面で有難いし、不要とは思わない

比較的まとまった規模の案件であれば、他言語併用でCOBOLはいまだに現役だし、これからも事務処理系や大量のデータを取り扱う分野で生き残ると思う
新規案件が減っている感じもしない

ちなみに、レベルの低いJava書きを排除するために、Java案件でも、人員資格にCOBOL必須と入れている

プログラマーにとっては、面白みはないが、毛嫌るす言語では無いと思うのが、個人的な意見
異論は認める

20年以上前にCOBOLを使っていて不満だった事
・ローカル変数が使えない(全てDATA DivisionのWORKING…で定義)
・構造体の拡張が出来ない・テーブルの動的拡張が出来ない

これくらいかな？
後はPL/Iの総称名が使えればなあとオンライン処理の時に思ったくらいかな

最後の部分は機種依存による制約にしか過ぎないのかな？
SDLC、HDLC等プロトコル手順毎にメーカー提供のサブルーチン名が異なっておりリンク時に静的結合しかできなかったんでため息をこぼすしかなかった

COBOL の区粗なところ
大量のデータをライブに扱えない
１ 日 n00GiB から nTiB 増えるデータは扱えない

>>224
金融業界や保険業界だと、Web製作すらCOBOL採用する暴挙をやらかすからなあ。

ＢＯＣＯＬぞ！

>>227
あまり問題無い気もするが、>>227の想定ってどんな状況なんだろうか？

まあ、どうしても無理なら、必要な所はC++とか、Javaで書けばいいだけじゃねぇ？

>>228
GUIがJavaで、裏はCOBOLってやつかな？
それならお互いの特性を使い合えるから、程度にもよるが、有りだと思う

ALL COBOLなら、ある意味、COBOLに掛ける情熱に尊敬する

>>230
C++やJavaは言語としてはいいけれどそれらを走らせるプラットホームが脆弱過ぎるのが困る・・。

>>228
NetCOBOL？

>>225
全く同じ不満を持っていたw
俺だけじゃなかったんだ

>>227 論理的な区切りが出来ないイメージデータ？

機種依存の部分でレコード長が32KB制限あるのはきつかったなあ(WORKING内の各テーブル等…)
リアルタイム集計やCAFISみたいにアプリレベルに近い部分で非同期処理があると、もうね…

>>227
COBOLだとどういう問題があるのですか？

>GUIがJava
そこももうどうかと思うなぁいまどき…

誰か不定長レコード(可変長じゃなくて)のファイル扱ったことある人いる？
俺あれだけは何に使うのか解らんかった(^ ^;

>>223
PL/IはIBMのメインフレームで使用されている言語だね。
COBOLとFORTRANとALGOLから当時としてはいいとこどりをして作られたが
マシンリソースを大量に必要となるため、ＩＢＭのメインフレーム以外では普及はしなかった
日本では三菱東京UFJ銀行、みずほ信託銀行など多数が使っている。
>>231
キャッシュカードやクレジットカードのポイント設定とか与信管理などをするWebサイトだったら
モロに勘定系システムだからCOBOLで動いていてもおかしくない

どうやら安田火災海上保険（現:損保ジャパン）は、自動車保険のインターネット見積りサイトは保険料の見積もりをする部分がCOBOLで動いているらしい。
↓がCOBOLで動くWebサイト（実は、コレはCOBOLで動く！！）
http://www.sompo-japan.co.jp/kinsurance/automobile/onestep/index.html

>>236
今のCOBOLは可変長出力ができるし、他の言語と
特別差はない。ポストスクリプトファイル出力なんか
だってするし。

>>238
そりゃ誰でも使ってるよ、LMなんかは不定長ファイルじゃないか。

Webというかhtmlファイルの大枠はCOBOLで書いて、
複雑な処理は別マシンでCOBOLがバッチ出力したファイルを
Prologで読み取らせて処理させ、JSファイルに出力させて置く、
というのは見たことがある。
問い合わせにリアルタイムでというのは無理そうだった。

>>242
バックエンドのバッチ部分はCOBOLで・・というのはわかるけど、htmlの出力部分をわざわざCOBOLで組む理由がわからん。

なんかコボルのシステムってエリアの領域が足りなくなって
計算おかしくなったりするのおおいイメージだったんだけど！
たとえば簡単にいうと、エリアに3文字しか入らないのに、
1200+300を計算すると、500になるとか。そういうバグ大杉。
まあ僕じゃなくてコボル40年のジジイが作ったやつだけどね！！

>>244
そりゃ桁あふれすれゃ不正な数値になるのは当たり前だろ・・。int型の変数に32768以上の数値をぶち込むのと同じ事

いまどきintが16bitなのか…

245は40代

桁あふれによるバクを発生させるなんてビギナーレベルの初歩的なミスだろ

いや桁あふれたらエラー吐けよコボルはそんなこともできないのか？

COBOLの場合、BCDだから演算とformattingが一体化してるんだっけ?
だとすると、
"1"500 (3桁) <- 1200(4桁) + 300(3桁)
という演算をやっているので、コンパイル時にわーにんぐが出てもよさそう
なものだいが。

>>241
機種によって違うのか
俺の使っていたマシンは固定長だったな
ソースライブラリは可変長(ヘッダー部にLength付きで扱い方はデルファイと同じ？)だったし
プリントファイルが不定長なんだろうけど入力側として使ったことがない
銀行の勘定系だと全銀オンラインがプリントイメージなので有るんだろうけど

>>249
ADD、SUBSTRACT、MULTI…、DIVIDには確かあったはず(ON SIZE ERRORの構文の後に命令)最もよほどの事が無い限り省略していたなあ
COMPUTE命令、MOVE(項目転送)命令にはないねえ

>>250
BCD、文字型数字で計算できるといってもコンパイル時にバイナリーに変換して計算、そしてOUT側の形式再変換したりが普通じゃなかったかな

>>243
順序が逆なんじゃないかな。元々COBOLで組まれていて、
対応できないというか、メインフレームでは危険な部分が
生じて例えばUNIXのシステムを追加した。
不整合な部分をJS出力で誤魔化した。

>>253
IF文の多いCOBOLと
IF文が消え去るPrologは
相性がいいよね。

>>254
COBOLからPrologプログラマへの転向は簡単かも知れないけど・・

よっしゃこれからProlog勉強する

Prologって仕事あるの？
何も勉強しないよりかはマシだけど
仕事無くて結局コボラー続けちゃうんじゃないの？

>>257
メインフレームでは無理だろう。
UNIX/Linux/OSX上では実は結構ある。

私の知る限りの話だが、年配の管理者に、この案件は
関数型言語でやりたいと申し出てもほとんど拒否されるが
Prologでというとすんなり通る。この言語不思議な地位にある。

>>258
＞UNIX/Linux/OSX上では実は結構ある。

Windowsで走らない時点で終わっていると思う。

>>254-260
貴様等、まとめてPrologスレへ逝け！w

>>260
古くからメインフレームのバックで動いてる環境という意味。
今やAndroidやMacの時代で今更Windowsなんて使わないだろう。

>>262
＞今やAndroidやMacの時代で今更Windowsなんて使わないだろう。

いいえ、世の中ほとんどがWindowsです。

日本のシェア1月
OSシェア
Windows 7：37.37%
Windows XP：27.51%
Windows Vista：18.71%
MacOS：6.64%
Android：4.00%
iPhone：2.88%
Windows 2000：0.27%
Linux：0.05%
Windows ME：0.09%

>>263
だから、現時点では Windows 7:37.37 OSX が多分12-3%
つまり 3 : 1
目を覆うばかりのWindowsの凋落ということだろう。

>>263
Linuxがゴミ過ぎてワロタ

最近じゃメインフレームもWindowsのエミュ上で走らせるのが常識なのに…

>>265
twitter利用者でのシェアは数%あるそうだから、そう単純ではない。

Windowsと併用してる人がだろ。

>>266
お前どっかのスレに居た人だな？ｗ

そういえば、あのスレ落ちていたな

はい、ソース。

Windows上で稼動するメインフレーム
http://wsmgr.jp.brothersoft.com/screenshot-50450.html

えーっ。VMwareか何かでOS/390なんかも動くの？

>>271
だからそれメインフレームじゃなくて端末だってば、まだ解らないの？ｗ

>>273
あ、>>266にエミュって書いてあるねw ごめん。
だけど、3270エミュレータならN88-BASICの時代からあるよ。

>>274
いや3270のエミュなら昔からあるだろう、そりゃ。
ただ件の彼は残念ながらずっと「『メインフレーム』をWindows上で稼働させるのが普通」
って言っちゃってるんだよ…

「端末はWWWで言うブラウザみたいなものだぞ、お前は2chの鯖がWindowsで動いてると思ってるのか？」
と指摘したら「鯖もWindowsに決まってる」と言いきっちゃったマジメに痛い子

>>271は荒らし
別スレで同じようなやり取り幾度も繰り返してる。

コボラーにコンピュータの常識が通用しない事がよくわかりましたｗ

>>277
そう思っていいから、Windowsと暮らしてなさい。

コボルか、何もかも懐かしい

>>278
今の世の中、ITの世界はむしろWindowsじゃないと成り立たないんじゃないの?

>>280
スマホがパソコン出荷を上回り、そのOSの50%以上がAndroid。
さらに、Macのシェアが世界的には15%に日本でも10%を超える。
Linuxは欧州の都市の公的コンピュータを席巻して、UNIXの
サーバーとしてのシェアも一定水準を確保。以上のことから
言えることは、UNIX系OSの大反撃が起きているということ。

コボラーに未来は無いと言われ続けて20年
どっこい生きてる基幹システムの中

保守要員としてならあと20年は戦える

基幹システムが壊れないといいね

>>283
基幹システムが壊れるってどういう意味だ？

まさか基幹システムがPCやサーバーみたいな固有のH/Wだと思っているのか・・・

壊れないは変か？
cobolで処理できない状況にならなきゃいいけどね

COBOLが優秀というよりCOBOL以外の言語が走るプラットフォーム、
特にWindowsが脆弱過ぎて基幹システムの運用に耐えられないだけなんだけどね。

>>283
そうだね。基幹システムで不具合が出たら、あっという間に億単位の損害ｗｗｗｗ

基幹システムがCOBOL以外のモノに移る可能性は常にある。
50代の技術者が定年までしがみつくには最適かもしれないが
2,30代の技術者が食ってくにはキツイ。

ホストでLinux, java,oracleが動く時代だぜ。
某銀行も保守はともかく新規でCOBOLを採用することはないと断言してるし。

Oracleって、メインフレーム上で動くの？
間接的な連携はできるらしいけど。

分散処理が出来るようになったからね
データベースだと、どこで管理するとかになってくるんじゃねえの
クラウドっていうのもその流れの一つでしょ

ホスト上でDB管理することで高い信頼性を維持してるのに
わざわざ信頼性の低いサーバーに分散とか意味わからないとか思ったけど
別システムのデータを直接引っ張ってこれるって意味なら、アリだな。

でも今時のPGみたいにパッチワークのようにコピペでしてコードを書く人間にはCOBOLは辛いかもね

>>290
現在はホストと言えばWindowsを指すのだが？

東京証券取引所の基幹システムとして稼動するWindows
http://itpro.nikkeibp.co.jp/article/NEWS/20090609/331590/?SS=imgview&FD=-654674548

HPCでもダントツのパフォーマンスをたたき出すWindows
http://cloud.watch.impress.co.jp/docs/interview/20101224_416025.html

Windows上で稼動するメインフレーム
http://wsmgr.jp.brothersoft.com/screenshot-50450.html

Linuxより57倍速いWindows!!
http://www.elecom.co.jp/business/pickup/nas/201102/index.html


一方Linuxは…
Linux Daily Topics：2011年9月2日　Kernel.orgがトロイの木馬の侵入被害に｜gihyo.jp … 技術評論社
http://gihyo.jp/admin/clip/01/linux_dt/201109/02

Linux カーネルの基盤サイトがクラッキングの被害に - japan.internet.com
http://japan.internet.com/webtech/20110902/2.html

Linux Daily Topics：2011年9月15日　狙われるLinux… 今度はLinux Foundationが標的に｜gihyo.jp … 技術評論社
http://gihyo.jp/admin/clip/01/linux_dt/201109/15

【経済】 東証でシステム障害　２４１銘柄の売買一時停止
http://uni.2ch.net/test/read.cgi/newsplus/1328146640/l50

これが噂のwindowsさんか…納得

ホストの意味も理解できないようでは・・・ 贔屓の引き倒しになりそう

>>294はLinuxスレで暴れているアンチだよ。通称ダダダ。
たしか勤め先のサーバーがWindowsから全てLinuxに置き換えられて
Linuxについていけない>>294はリストラされたとか。

故にLinuxが憎くて憎くてしょうがないらしい・・・

コボラーってもしかして昔ながらのホストマシン(笑)が未だに稼動していると信じているんだw

Windows全盛の今の時代でメインフレームすらWindowsで稼動している現代でまさにオカルト的な発想だわｗ

これじゃあリストラされても止むなし(^ω^)

>>299
確かにｗ
コボラーは技術が20年以上遅れているからどんどんリストラされている。

これは失笑ものだな

ダ「メインフレームは現在Windows上で動いている、証拠の画像だ」
住民「いやそれ、ただの端末だから…」
ダ「端末がWindowsならメインフレームもWindowsだろう」
住民「えーとな、メインフレームはWebサーバ、端末はブラウザみたいなもんなんだよ、例えば2chはWindowsから見れるだろう？」
ダ「2chの鯖もWindowsだろう？」
住民「いやBSDだが」
ダ「違う、Windows鯖だから見れるんだ」
住民（駄目だコイツ）

アンドロイド端末からＰＣを操作出来る→ＰＣのＯＳはアンドロイドだ間違いない(ｷﾘｯ)
こうですか(笑)

COBOL資産の他言語移行が進まないのは、
銀行や証券・生保など金融機関の勘定系システムで多く利用されているため
スケジュールと人員面で移行が困難なせいもあると思います。

特に金利計算なんかは100％ブラックボックスと化していて下手にいじると収集がつかなくなったりして。

「今でもCOBOLで問題なく動いているものを、
危険なリスクを背負ってまで他言語へ移行する理由もない」

・・・と経営層は判断するでしょうし。


バッチ処理に強いとか言われるけど、日本語環境ではいまだに全角／半角文字の混在処理が苦手だったり、
GOTO文使いまくって簡単にスパゲッティコードになったりするのはいい加減勘弁して欲しいです。

でもまだ当分現役なんだろうな・・・

例えば住宅ローンの場合は最長35年あるわけで、1970～1980年代のシステムがそっくりそのまま残っていて
そのままCOBOLで運用されてても不思議ではないです。ただ、今後積極的に使われることは少なくなってくるでしょう。

過去10年分のデータ食わして同じ結果になりました、みたいなテストができりゃ良いんだけどねえ
無理ゲーすぐる

未だにCOBOLが使われているのは他の言語やプラットフォームについていけない老害ばかりだからだろ。

VBとSQLで何百倍も低コストで何千倍も早いシステムが構築できる・・・。
COBOLが得意というバッチ処理でもCOBOLで何時間もかかる処理がSQLだと数秒で処理でる。

あれ辺だなあ、漏れがCOBOLやってた頃ふつうにＲＤＢ使ってたけどなあ

COBOLをやると落ちCOBOL

・・30年前のダジャレより

F通でもRDBⅡというのがありましたで（って今もあるんだろけど w

講師に聞いた事があるけどCOBOLのバッチ処理って何時間もかかるんだよね？
だから夜間しか処理出来ないとか。

WindowsのPCとSQLだと簡単なマクロで数秒て処理出来るのに・・

Windows爆速厨にデータ量を調べようとした形跡がないのが気になる

あるんだぞCOBOLしか知らんプログラマーが全文検索を
text optionとかないRDBでやろうとして検索対象を不定長stringの項目に放り込んで
オンライン検索に1画面5分かかりましたとかすごいことをやっている例が

チューニング頼まれて見てみると5分間Disk I/Oが100%張り付きww
聞いてみると「VSAMが使えないんでこうやるしかないかと思って…」

システム開発したこと無い奴のダメな営業トークみたいだな。
ユーザーも開発者もみんな不幸にされちまう。

流行るかどうかは微妙なとこだがNoSQLという流れもあるんだな。

>WindowsのPCとSQLだと簡単なマクロで数秒て処理出来るのに・・


これは実際に同じデータを与えて検証した上で言ってる事？

>>310
> 講師に聞いた事があるけどCOBOLのバッチ処理って何時間もかかるんだよね？
> WindowsのPCとSQLだと簡単なマクロで数秒て処理出来るのに・・

WindowsPCで数秒な処理ならメインフレームでは一瞬だよ
それに応答速度という点では、IMSなどの階層型データベースはRDBよりも高速だよ

>>310
問題はWindowsが1年間無停止とか出来ない事にある。

>>316
今時Windowsてわメインフレームが走る時代にWindowsが不安定とか一体何時の話だよｗｗ

東京証券取引所の基幹システムとして稼動するWindows
http://itpro.nikkeibp.co.jp/article/NEWS/20090609/331590/?SS=imgview&FD=-654674548

HPCでもダントツのパフォーマンスをたたき出すWindows
http://cloud.watch.impress.co.jp/docs/interview/20101224_416025.html

Windows上で稼動するメインフレーム
http://wsmgr.jp.brothersoft.com/screenshot-50450.html

Linuxより57倍速いWindows!!
http://www.elecom.co.jp/business/pickup/nas/201102/index.html


一方Linuxは…
Linux Daily Topics：2011年9月2日　Kernel.orgがトロイの木馬の侵入被害に｜gihyo.jp … 技術評論社
http://gihyo.jp/admin/clip/01/linux_dt/201109/02

Linux カーネルの基盤サイトがクラッキングの被害に - japan.internet.com
http://japan.internet.com/webtech/20110902/2.html

Linux Daily Topics：2011年9月15日　狙われるLinux… 今度はLinux Foundationが標的に｜gihyo.jp … 技術評論社
http://gihyo.jp/admin/clip/01/linux_dt/201109/15

【経済】 東証でシステム障害　２４１銘柄の売買一時停止
http://uni.2ch.net/test/read.cgi/newsplus/1328146640/l50

老害コボラーといい、UNIX/Linux使いといい、古臭いコンピュータを使い続けると脳味噌も腐るんだなｗ

お前は本当に馬鹿だな。
東証は取引時間帯以外ならシステム止められるじゃん。

>>318 ←ウインドウズしか使えないアホ発見ｗｗｗ

それはちょっと前どこかで見た池沼コピペ君だからいじらないように

>>317
その東証が去年末に大事故起こしてますよね。
ハードに精通せず、OS語るだけの3流エンジニアしかいないという事。

>>322
> その東証が去年末に大事故起こしてますよね。
LinuxみたいなフリーフェアOSを使うからそんな事故が起こる。
Windowsを採用していれば事故は起こらなかったはず・・・。

社保庁の消えた年金問題もCOBOLが原因だったらいしいねｗ

年金問題はコンピュータの問題
http://www.nikkeibp.co.jp/style/biz/column/tahara/070705_18th/index.html

今時基幹システムにWindowsシステムを採用しないのはもはや罪だよな・・・

全く使用するメリットが見出せないLinux

・安定性・信頼性
　Linux
　フリーソフトであるLinuxの安定性・信頼性はハッキリ言って問題外。
　1日連続で稼動させることすら困難。

　Windows
　いまやWindowsの安定性・信頼性はメインフレーム(汎用機)をも凌ぐ。
　世界中のメインフレームが全てWindowsServerに置き換わったのがその証拠。

・脆弱性
　Linux()
　Linuxで稼動している世界中のサーバーがクラックされまくっている。
　シェアが全くないLinuxはウイルス対策ソフトも皆無。

　Windows
　デフォルトスタンダードOSとしてあらゆる攻撃を受けてきたWindowsはいまや世界で一番強固なOSとなった。
　豊富なウイルス対策ソフトもさりながら、カーネルの構造的に絶対に外部からクラックされることが無いOSとなった。

コスト
　Linux
　フリーソフトなのでOSは無料。
　しかし上記内容により安定稼動させるのはほぼ不可能。
　またサポートが存在しないため自前で何とかするしかなくかえってコスト高となる。

　Windows
　OSは無料ではないが従来のメインフレームのOSと比較すると安価。
　もともと安定性に優れたOSであるため、誰にでも安定稼動させることが容易である。
　サポート面もマイクロソフトを始め、各ベンダーが完璧なサポートを行える体制となっている。
　またコンピュータOSとしてほぼ100%のシェアを誇っているので情報が豊富である。

Windows上でCOBOLシステム動かしてるぜ！

何年後か、MSが4-5年前のGMになることは必定だしな。
IBMだってあれだけ苦しんだんだから。

全然話が変わるんだが、昔何処かのサイトで「人類最後のコボラー」みたいな話を読んだ記憶があるのだけど、誰か知らないかな？

亀ネタだけど、Rubyが国際規格として承認されたね

主にCOBOLが未だ死なない理由は・・・
・夜間処理等、定時で動くバッチシステムとしては比較的軽量。
UNIXサーバのシェルとの相性も悪くない。
・半世紀前からあるようなホスト現役の所とか、誤差がダメ！ゼッタイな金融機関等々、
大幅システム再構築を嫌がる所では重宝される。

いくらなんでも中小企業でメインフレーム(オフコン) + COBOLを現役で使用しているところは随分減ったと思うけど
民間の金融機関（特に保険）や社会インフラ系（鉄道・電気・水道・ガス）、各省庁ののバックエンドなどの
案件で扱ってる言語は、今でもCOBOLが入ってるメインフレームが大絶賛稼働中だよ。
ウォール街やTOPIXにて毎日取り引きされている何十億ドルもの株、債券、オプションなどもCOBOLを使ってるところが多い
ただそういったところでも一般ユーザーが目にするフロントエンド系は殆どオープン系だったりするから
エンドユーザーが稼動しているCOBOLを実際に目にすることは皆無だろうね。

一番問題なのはスパゲティコード化してる事。もはや解読不能。　
継ぎ接ぎだらけなのにさらに言語自体を理解してるやつがいなくてブラックボックス化なのに使うことは止められない
現在正常に動いているシステムがあったら、ソースは絶対いじるなってのはどこの業界も同じ。

IDENTIFICATION DIVISION.
PROGRAM-ID. AD3410SB.
AUTHOR. ASNN.
INSTALLATION. SYSTEM PROG.
DATE-WRITTEN. 2011.10.10.

システムまるごと捨てる思いがないと、COBOLは無くならないよ
最新言語に置き換えることは可能だけど、現行の再現は一部困難

トップがシステムごとCOBOL捨てます！って宣言しないとダメだねｗ

リライト案件もあるんだけど現行保障をしなきゃいかんてことで
COBOL設計をそのままJavaに置き換えただけの「見た目だけJava」が横行していたり。

なんというかCOBOLは死んでも精神は死んでないというか、はよ死んでくれというか。

企業の基幹システムなんざ今も昔も思想は大して変わらんからな…
変える必要が無いものをリスクを負ってまでわざわざ他の言語に変える必要な無いという事じゃね？

COBOLがいかんのじゃなくて、COBOL脳がいかんのだと思う

優秀なCOBOL脳はいまでも優秀、もう現場にはいないけどｗ
ダメなCOBOL脳は昔からダメ、そしていまでも現場に残ってるｗ

アルゴリズム（死語？ｗ）を理解してない奴ばっかり！

まあたしかにCOBOLみたいに書きたいんだったらCOBOLでいいじゃん
とJavaで１クラス１メソッドプログラムを見てそう思った。

この時期になんとか内定をもらったんですが、その会社はCOBOLが中心のようなんです
COBOLには将来性がないらしいですが、そんなに深刻なんですか？
あと、まったくのど素人なんですが、やっていけるものなんですかねえ

つべこべ言わずに勉強しろ

技術に興味を持って普段から色々と勉強してればそんな酷いことにはならないけど
COBOL「しか」できないようだと将来的に辛いだろうな。

>>339
今更の亀レスだが、、、
COBOLそのものはそんなに難しくはない
JCLやらなんやら覚える必要は勿論あるけど。

それ以上に難しいのが業務ロジック
なんでこんな処理をここでやる？ってのは業務を知らんと判らん

後、家では他の言語を勉強しとけ
C,Java etc

>>342
COBOL以外の言語に慣れた奴にとってはとても難しいと思うぞ

業務ロジックに関しては他の言語でもやってることじゃん

で、 「業務ロジックは俺に任せとけ!!!」な、 SEとかって日本固有の
馬鹿な職業ができる、と…

本屋でCOBOLの本を立ち読みしたことあるけど、コードを5行くらい読んだだけで
つらくなって棚に戻した

CやJavaに慣れちゃった者には、あれを受け入れることは生理的に難しい
Lispとかのほうがよっぽど受け入れやすいのではないかな

C/C++のバッチ処理とCOBOLのバッチ処理はどっちが早いですか？ 理由もお答え下さい。

誰も答えられないのかぁ？

設計の話じゃなくて早さの話になる言語はクソだし廃れる。

>>339
あのねえ。仕事は言語で覚えるより、仕事の内容で選んだ方がいいよ。

COBOLの会社は大抵は特定派遣の客先常駐で、自社に机がない所ばっかだから、そういうのでメンタルやられて、鬱病になる奴が多いよ。

なるべく自社内で開発してる会社を選んだ方がいいと思うよ。あとメンタルについてもキッチリとフォローしてくれる所。

>>1
30年近くも前だけど、COBOLで書いたPROLOGというのは
見たことがあるから、単なるDSLではないね。

それを言い出すと elisp あたりは COBOL よりハルカに柔軟に
どんな言語の処理系でも実装できる
でも elisp は emacs 専用の DSL だ

>>345
そもそも処理系もそれを動かすCPUや周辺機器すらもバッチ処理に特化した環境でやるCOBOLでしょ
Cはそれに特化した言語でもなければ、動かすマシンもそれに特化してるワケじゃない

COBOLプログラムをJAVAに移植するためのライブラリってある？

age

COBOL批判してる人も経営側になったら批判できんとおもうが。
現行COBOLから移行なんてすさまじいリスク。

早く古いシステムを排除しよっぜ

オープン系の基盤が未だに脆弱過ぎる現状ではCOBOLを駆逐するのはなかなか難しいんじゃない？
SoftBankですら基幹部分は未だにCOBOLで稼働しているし…

早くCOBOLに代わるものを作りたい

COBOLから他の言語へのコンバーターとか

変換で構造やロジックが失われるようなコンバーターはダメ

C++11で書いてみるか

cobol to javaコンバータがあるよ。

変換後のソースなぞ見たくもないけど

>>359
蟻がとう

>>360
あと、Cへのコンバータもあるよ。
オープンソースで。

でも、それって変換率99%とかって奴じゃないの？

GNU CobolはCへのトランスレータだよね。
http://sourceforge.net/projects/open-cobol/

変換率100%ではなく必要なのは補償率100%

小保ラーのみなさんこんにちわ

笹井なことにこだわんな

COBOLの面白さは、後にメンテする者が、いかにメンテし易い様に作るか、に尽きるな。

グローバル変数しかないところを、シンボル名の工夫でローカル変数的な扱いだと知らせる。
COPY句使えば継承もどきもできるが、読解牲が極端に悪くなるんでやらない。
SECTIONをモジュールと見なし、その中で機能を完結させる。

よーするに、
入力－編集－出力が一目で分かるような制御構造をこさえ、
SECTIONモジュール強度とかSECTIONモジュール結合度とか、SECTION間での基本的なところをキチンとさせたプログラムを書くのは、
自己満足でも楽しい。

後で読んだ人が「すげ～」って言うプログラムは、
概ね高度なテクニックよりも、
何をやりたいのかやろうとしてるのかが一発で分かる＝実装思想の一貫性が読み取れる
じゃないかと思ってる。

他の言語でも同じでないの？
　

>>367
メンテしやすいPGを心がけてる。

http://jobinjapan.jp/job-listing/keyword-cobol.html

COBOLの代替技術をまとめてくれ。

>>370
COBOLにローカル変数とスコープの概念を導入すれば、ほぼ一通りの物は書ける。

パックトBCDってもう古臭い技術だよな？ 4ビットで10進一桁なんてやらないっしょ？

あげ

なるほど。IEEE754-2008使えばいいんだ。

IEEE754-2008が使えるから、COBOLは要らない。ファイナルアンサー？

>>371
COBOL85からローカル変数はあるしCOBOL97にはクラスの概念もあるんじゃなかったかの？

>>376
そう、以前の記憶で最近のCOBOLはローカル変数導入したはずとgoogle先生に尋ねたんだが
どうにも見当たらなかったのさ。

COBOL2002さんはいつになったらオブジェクト指向言語として活躍するのかな…

うちのシステム、COBOLからCOBOLに移行

◆COBOL　は　はじまった　ばかり　だ

◆COBOL　は　はじ、　まった　ばか　りーだー

【社会】損保ジャパンがCOBOL一掃を決断･2ch.net
http://daily.　2ch.net/test/read.cgi/newsplus/1444867000/

かなC

みずほ銀行はCOBOLで楽天銀行はjavaか？
それにしても東芝を330円で200万円分買ってしまったぞ
どうしてくれんだ？訴訟するか

売れ
200円まで待て

ハローワーク求人128,214件の平均月給197,300円～268,000円
その中からCOBOLの求人486件の平均月給251,800円～432,000円
https://goo.gl/E3yXUJ

今更、ワイにはなりたくないですよ
とかいう後輩がおるんや
おかしいやろ

まずこのスレ見てCOBOLのありがたさを
学んで俺に追いつけよと指導してやったわ

メインプログラムはCOBOLやとわからんやつわ
ゆとりやでw

>>384
楽天はwebサイトプログラマがJavaで実装だろうな

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

EEQX7

PQY

>>384
みずほはJavaでシステム移行
Javaライセンス料発生(三菱UFJも同様)
メガバンクは何とかなるが中小金融でJavaに移行した所はこれから経営が難しくなる
Javaライセンス化前にシステム移行した所は負け組

JavaEEはライセンス対象外だったっけ？

んな訳無いでしょ

ライセンス逃れたいならOpenJDK(OracleJDK)で半年毎に自分達で修正、ビルド、テスト、リリースする場合のみOK

>>394
OpenJDKでも完全にOSSじゃなくてオラクル管理下なのよね
オラクルがOK出さないとフリーとしてソースが使えないと言う事実

とりあえず金融機関システムはりそなのシステムが現状、最適解だろうな
それをCOBOL→Java移行を推進したSierがおかしかった

http://d.hatena.ne.jp/ryoasai/touch/20101202/1291295077

既存のJavaフレームワークがダメだと言うオチ

>>396
Linuxサーバー(or Windowsサーバー)
SQL Server(PostgreSQL or MariaDBでもOK)
バッチはCOBOL(Open or MF-COBOL or NETCOBOL)
UIはMF-COBOLでもC#でもVBでもJavaでもスクリプト言語系でもOK

要は金額計算部分をCOBOL外部モジュールにしてしまえば良い

https://review-of-my-life.blogspot.com/2017/10/COBOL-JOB.html?m=1
COBOLで転職活動したら

https://mobile.twitter.com/tsuchie88
それ以上に最近目立っているのは、メインフレームからAS/400へのマイグレーションだ。
AS/400はCOBOLもサポートしているので、中小規模のメインフレームから移行する例が多い。移行に際して、DBをRDB化する必要があるが、既存のアプリケーションを生かせるという点で強みがある。
https://twitter.com/5chan_nel (5ch newer account)

某銀行
銀行側「なぜこんなバグが見つけられなかったの？」
開発会社「作業人数不足です」
銀行側「募集かけろよ！」
開発会社「もう市場にCOBOLのエンジニアはいません」
銀行側「育成しろよ！新入社員いるべ？」
開発会社「え！？いや… https://t.co/lhv1QKyaDu 👀
Rock54: Caution(BBR-MD5:b73a9cd27f0065c395082e3925dacf01)

彼はCOBOLで書かれた業務システム（コード行100000行と言ってた。正気か。）を今年度までにJavaで書き換える案件をやってるらしい。
ほんとは一気にAWSへ移行予定だったが、無理なのでまずはコードベースをJavaにしようとい… https://t.co/LKHi6OYOBx 👀
Rock54: Caution(BBR-MD5:b73a9cd27f0065c395082e3925dacf01)

>>402
Amazon web serviceがJava限定ならアレだが
https://toris.io/2016/12/cobolambda-a-serverless-cobol-on-aws-lambda/
COBOLでも動くからね

金融系システムの請負やってる所は新人にCOBOL習得させろ、と言われるらしい
結局COBOLは捨てられない

で結局数値計算が他言語だと上手くいかない理由はなんなの？
特別に計算クラス作ってもだめなの？

>>405
コードレベルでは結果が予想出来ない
他の言語は最終テストまでしないと出てくる計算結果が分からない

https://github.com/katahiromz/anticobol

今、COBOLからC++への移植キットを一生懸命作ってるとこ。アイデア&Pull Request募集中。

>>407
COBOL→C++?
そんなのどこに需要あんの?
COBOL→C#とかVB.NETの方が需要有るだろ

今時C++ってギャグなのか

>>407
ちょっと見てみたけど字句解析とかから自力で全部やろうとしてる感じ？
yacc & lex みたいな既存のものを使うことも検討してはどうだろう

>>410
需要が無いマイグレーション用ツール作るのはな
(少なくとも日本では)
JavaへのマイグレーションはSierが腐るほど出してるからな
やっぱり日本ではVB.NETあたり狙うのが賢い
http://www.triview-innovation.com/as400/archives/09.html
AS/400のサポート切れ迫ってるから需要有る

https://www.tairax.com/entry/COBOL/No-young-engineer
COBOLに若者を担当させるな、ねえ
でも資産は残るから誰かがやらねばならん
VB資産も同様
つまらない、とか仕事上は無関係

COBOL,VBはスキルアップ出来ないから若いプログラマがやりたくないってただの甘え
そういうプログラマはJava,C#でデスマーチに参加してれば良い

COBOL不要どころか


AWSにおいてRubyサポートして、いろんな言語がLambdaでって、COBOLも対応するぞい

日本ではオフコン&COBOLはレガシーみたいな風潮があるけど
IBMについていけば全然そんなことないという

>>415
NEC,富士通などの日本メーカーの場合だよな、レガシィ扱い

アメリカは日本以上に未だCOBOLに依存しているしな

オフコンなんて言葉久々に聞いたな
日本メーカーは全部撤退したんだっけ？

IBMぐらいだな、頑張ってるの
NEC、富士通、日立全て既存サポートだけ残ってる

https://www.tairax.com/entry/Three-reasons-for-asserting-that-a-company-that-makes-a-new-graduate-engineer-do-COBOL-is-a-black-company

こういう事、断定するから
COBOLのプログラマが増えない

同意出来る部分もあるが、まー個人の鬱憤晴らしだな
としか読めなかった
COBOLしかやりません。
もしくは
Javaしかやりません。
って会社なんて有るわけ無い
そんな会社あったら潰れるわ

若い社員にソンタクしてJava,.NET以外させないとかね
そういうソフトウェアハウスはその内潰れる

勤労統計問題の原因は「COBOLプログラムのバグ」 - アゴラ
http://agora-web.jp/archives/2036852.html

>>423
単に官庁のチェック体制の問題
それをCOBOLのせいにしてる

>>423
あるツイート
勤労統計問題の原因は「COBOLプログラムのバグ」??agora-web.jp/archives/20368…いや、こんなのをCOBOLのせいにされても。。。

言語は関係ねえ。

COBOLだと高齢者しか読めない、ってあたりが筆者の思い込みで嘘の部分だなぁ
若くたってちゃんと読めるぞ？簡略化されすぎた記号みたいな言語じゃないんだから

JavaやC#、C++が読み易いと思ってるんかね?

https://mobile.twitter.com/h_okumura/status/1088982028828069888
厚生省統計システム
COBOL,FORTRAN,C,VB,Perl,Java etc
言語統一すらしていない
https://twitter.com/5chan_nel (5ch newer account)

FORTRANもGO TO強制される古いやつでなけらそれほど読みにくくはないっつうか
逆数書け忘れてる事を読み取れない言語って、その中には無いような

>>430
無い
だから、単にCOBOLにアレルギー有る担当者に任せた結果だろうね

COBOLを名前だけしか知らないやつほど
”無条件に悪として叩ける対象"みたいな認識してるからなぁ

"グローバル変数は絶対悪"病患者とか
"オブジェクト指向にしさえすれば古臭い言語よりは必ず生産性が向上する"教信者とか
ようは宗教なのよね、彼らは”そういうものと信じていると”信仰を告白してるだけ

COBOLって1本が短いイメージあるよな
他の言語でいうクラスが、COBOL1本のような
時々気が狂ったか？てくらいの化け物もあるけど

設計次第だよ
1万ステップ、てのが銀行系では存在する

cobolってパンチカードで作ってるイメージだったわ。。

情報処理試験から消失か
これも時代の流れ
でも過去の資産は消えない

昔居た会社で、COBOLで作られた大小2000を超えるモジュールで成り立ってたシステムを、今風に置き換えるのに見積もりしたら10億円だったな……。

こういうツイート見るにつけ強制的に言語移行するのが正解とは思えない

同期に聞いて驚愕したんだけど、新卒で入った元弊社では新人研修の言語がJavaからCOBOLに変わるかもしれないらしいです

Java教えてもメンテ要員にしかならんからな
それならCOBOLと同じ
VB.NETでも教えて貰う方がなんぼかマシ

「COBOLを取り巻く環境の中、損害保険料率算出機構は既存システムの刷新時にプログラムをCOBOLに集約し、COBOL資産の保守に力を入れている。
あえてCOBOL資産を生かした事情を説明しよう」業務アプリに最適な言語は今もCOBOLなのか、ある組織の決断を基に考える??tech.nikkeibp.co.jp/atcl/nxt/colum…

あるツイート

COBOLからjavaへの変換用ツールのプロジェクトで失敗という例があるのか。。。

そりゃwater fall言語からオブジェクト志向言語への移行なんぞ、元から無理

ウォーターフォール・・・言語（爆笑）

根っこはwater fallスタート
今はOpenCOBOL出てるけど基本は変わらんわな

https://type.jp/et/feature/9767

COBOLの問題は言語よりシステムマネージメント体制

コーディングシート（紙）でコードレビューする文化は、好きだぞ

Oracle DBとUnix、COBOLの案件で、DB更新が固定長ファイルで落としてから、夜間バッチ処理を幾度も経て、最終的にdelete * とInsert Intoで全件総とっかえする、という案件だったらあった。現行通り、という要求定義しかされていないプロジェクトで、炎上して破綻した。

なんでdeleteとinsert発行すんの?
バックアップ取ってtruncateしてSQLロードしたら速いだろ

https://mobile.twitter.com/nikkeibpITpro/status/1139303373491113989

どういうことなの… "DB2も廃止し、SQLとDB2で行っていた入出力処理をCOBOLとCSVで代替することにした。

リアルタイム処理じゃなくてバッチ処理だからな
CSV(テキストファイル)読んで集計して帳票印刷して、テーブル再作成するならメインフレームのメソッドと同じ
そりゃSQLをRDBに投げて結果取得してチマチマリアルタイム更新するより速いわな
https://twitter.com/5chan_nel (5ch newer account)

http://www.nurs.or.jp/~ogochan/essay/archives/5033

NEC IDL2→IBM COBOL移行
するくらいならNECでもCOBOL用意されてるやろ?
この企業は何をしたいのか?

https://mainichi.jp/articles/20190624/k00/00m/020/227000c

COBOLからJavaに移行してもリストラだってよ
何やってるか分からんな
そもそもJava移行プロジェクトで金使い過ぎて経営圧迫されたからじゃないの?

https://type.jp/et/feature/9767

COBOL問題の根底

「高齢者しか分からない特殊な言語」というような発言がありましたが、これはなかなかパワーワードであるなと思いました。

今はバリバリ現役のJavaやC#でコーディングされたプログラムも、10年後はどうなるか分かりません

大事なのは、システムマネジメント体制のデザインです。

適切なシステム運用開発のマネジメントをしなければ、どんなシステムも不良債権化します。日本はシステムの運用開発を丸投げにしがちなので、この問題が非常に大きくなりやすい企業がたくさん存在しています。

ITなしではどの企業も経営ができないにもかかわらず、経営トップにはテクノロジー指南役が付いていなかったり、そもそもIT部門の責任者の中にエンジニアのバックグラウンドを持つ人がゼロだったりするわけです。

>>449の損保ジャパンがその例

あるツイート

COBOLからC#に変換する場合の方針については先日そういう案件を手作業で対応したので虚無の精神状態の中から浮かぶモノは在ったし実験的な実装も追加してみたりしたので気が向いたら手を付ける

COBOL→Java
の代わりにC#へ移行か
.NETへ移行するならNET COBOLとか有ると思うが

NETCOBOLは富士通限定か
まだMF-COBOLの方がマルチプラットホームだからマシか

あるツイート

未だに基幹システムにCOBOLを正式採用してるような会社は基本的に変化を嫌うので、
海外のイケイケのベンダーが10億円未満でモダンなアーキテクチャを提案しても見向きもせずに国内古典SIerに100億円以上払ってCOBOLの基幹システムを保守しながら続投させるという話を聞いて戦慄している


OpenCOBOLに移行しつつ有るの知らないんだな

https://tech.nikkeibp.co.jp/it/atcl/column/17/091500378/092000005/
Javaに移行してライセンス払ってれば世話無い

Javaのライセンス料なんてメインフレームやオフコンの維持費と比べたらゴミみたいなもんだし
OSやDBのライセンス料と比べても安いもんだ

>>455
そうでも無い
コア単位徴収だし

>>455
繋がってるクライアント端末も関係するしね

あるツイート

弊猫も最近は「IBM以外のメインフレームってなくなっていくんだろうな」という気はしてるんだけど、COBOLがなくなるかっていうとあんまそういう気はしてないし、
ましてやよその会社や組織の言語が何で開発されてるかって、Javaで置き換えろとか余計なお世話じゃないかと思ったりする。


COBOLで動くレガシィシステム有った所で誰にも迷惑かからん
VBもね

>>453
銀行のように不具合を絶対出せない会社が多いのだから
予算10分の1で新しい物を作れるとしても、実績がないシステムは採用できんわな
10年くらい1度も不具合を出さずに安定稼働して、やっと検討されるかもしれない
ウインドウズPCみたくフリーズしますたｗリセットｗｗｗとはいかんのだよ

>>459
銀行でもユニシス系の様にWindowsサーバー使ってる所も有るけど
週一回は再起動してるみたいだけどね

https://r.nikkei.com/article/DGXMZO48430390Z00C19A8TCR000
COBOLに罪は無い
TISがCOBOL→Javaに移行させた事によってメインフレームの維持が悪だと言うイメージが出来上がった
実際、移行して発生したのはJDK更新ホリックとライセンスホリック
COBOLをオープン化したり、AWSへCOBOLのまま移行するなら、オープン化と言う意味では問題無し

あるツイート

とすると絶滅が危惧されるのはCOBOL技術者じゃなくてCOBOLシステムをメンテナンスする予算なのでは

メンテ予算するならオープンCOBOLに移行すれば良い
それだけの話

【悲報】底辺IT土方僕、他社がCOBOLからJAVAへ移行したシステム(旧仕様書破棄済)を再COBOL化するプロジェクトにアサインされる
http://2chb.net/r/news4vip/1566005326/

https://programmingch.com/1165/

COBOL→Java→COBOLねえ
しかもドキュメント破棄済みとか
そもそもCOBOL→Javaが間違い、と答え出てるだろ

↑
AWSでCOBOLからクラウド化出来る事になって戻すって言い始めたみたいね
だからJavaに移行すんなって

ドキュメントが無くてソースしかないシステムを
コード読んで仕様書作成から始めるなんて、わしの若い頃はよくあった
>>463はただの甘え

今、Javaに移行した結果の弊害出てるからな(ライセンス他)
COBOL使い続けてた会社が結果、
勝ち組だったと言う事

若者にCOBOL教育が必要か
不要と思った若者は自分から退社するから問題無い
結果としてCOBOLの技術者の補充はされない

あるツイート

メインフレームでは現役で塩漬けにされてることが多いな。 ただ、これからの若者が時間かけて覚える必要はないよね。 どうせ大規模改修とかないからCOBOL使える老人でも運用で飼い殺しとけば良い。

若い技術者に期待するだけ無駄
覚える気が無い

あるツイート

本当の害悪はCOBOLではなく、メインフレームだと思います。たとえソースがCOBOLのままだったとしてもメインフレームでなくなるだけでもだいぶ救われるかと

結局、こういう事

メーンフレームがなくなると救われる
あまりにも意味不明すぎる

メインフレームのハード→PCサーバーに移行、と言う意味かと

それで救われるというのがわけわからん

維持費が救われる、と言う事でしょ

あるツイート

首都圏でのソフトウェア開発系フリーランスエンジニアの平均年収を見てみます。経験やスキルの高低により数倍の開きがありますが、平均としては概ね会社員よりは高い傾向にあるようです。鮏OBOL：　 636万円 VBA： 636万円 VB： 660万円 VC++ ： 720万円

Oracleに付いて来たPro*COBOLで、UNIXサーバーに移行した、とか2000年近辺は有ったと思うが、、
メインフレーム→UNIXサーバーへのリホストが一般的で無かったので広まらなかったな
今はOracleライセンスがウザイのでPro*COBOLを使う機会がほとんど無くなった
Pro*COBOLでMy SQLへの接続は出来るみたいだが
他のDBには無理みたい

https://mohritaroh.hateblo.jp/entry/2019/09/14/203000

みずほ銀行はフルスクラッチで勘定系システムを再構築
(しかもメインフレームのままCOBOLで)

そこまでやるならCOBOLで統合するまでにしてリホスト(Linuxサーバ化)するだけの方が安くついたと思われる

>>476
Linuxみたいなフリーウェアなんて不安定すぎて業務システムじゃ使えないと思う
業務用で使うならWindowsくらい信頼性が高くないとだめ

ちょっと待った！
Windowsの信頼性が、どうだって？
｢それはもしかしてギャグのつもりで言ってるのか？｣
知らんけどｗ

>>478
Linuxより信頼性が高いと言う意味じゃね？

>>477
Windowsサーバーの金融系システムは旧ユニシス系の一部地銀だけだよ

>>479
まさか
LinuxサーバーはWindowsサーバーの同等以上だよ

>>476
勘定系はCOBOLメインフレーム残して
周辺はJavaでレッドハットエンタープライズだとよ
ライセンスかかるシステム更改するからそら何千億円も予算かかるわな

COBOLプログラマ、みずほ銀行案件から解放されて大勢あぶれてるらしいが、、
そもそもニーズの方が多いからね

>>483
お前らアメリカで出番だぞ
https://gigazine.net/amp/20200406-unemployment-benefits-cobol?__twitter_impression=true

【米国】「COBOLの使い手急募」新型コロナの影響で　
http://2chb.net/r/newsplus/1586162983/

こういうのって何でアップデートしないで
古いプログラムで管理してんの？
COBOLじゃないと出来ないことなの？

アメリカの知事さん困っているよ

>>486
COBOLがどうとかじゃなくて、
1. 当時の手法でやってるため、複雑怪奇なコードが何千万行もある。
2. 当時の考え方のやつが指揮をしてるため、改善案に対してことごとく動いてるから改善するなと圧力をかける

この２つでアップデートが実質不可能になってる

そんなの無視してC言語で作り直したバージョンどこかに作らせればいいのに

>>489
無理。「俺は長年コボラー共を指揮してきた。俺の決定以外は何も認めん」
この一言で終わり

>>489
ワロタ
Cで作り直すくらいなら自社でCOBOLプログラマーを育成し続けたほうが1000倍効率的

日本では珍しくないコボラーも他国では妖精さんクラスか >>484-485

そういうことをいわないように

COBOLって具体的にどういう部分で使われてんの

>>494
古くからある大手企業の基幹システムの殆どは未だはCOBOLがフツーに稼働してるよ

30年前「COBOLはもう時代遅れ」
今現在「COBOLはもう時代遅れ」
30年後「COBOLはもう時代遅れ」
COBOL「ボクノ テイネンハ イツ？」

現実にはIBMがあるかぎり常に最前線なんだよなぁ
規格も更新されつづけてるし

金融機関じゃほぼCOBOLらしいけど
計算の処理や管理ってそんなに他の言語で作り直すの面倒なのか

作り直しても得るものが何もないからじゃないか？
パフォーマンスは低下する、機能は旧システムより劣化する、
止まったときの事は何も考慮されてない、作り直しの課程でバグを量産する

若い人は最新の言語で作り直せば、古くてダメな言語が足を引っ張ってた部分を全部解決
みたいに幻想抱いてるけどさ、そもそもダメな言語でもなんでもないっていう

アメリカじゃ時代遅れすぎて使えるやつボランティア募集するくらいダメな言語じゃん

COBOL依存度は日本よりアメリカの方が高いぞ

>>499
COBOLの問題
1. 汎用機+ベンダー依存だからめっちゃ高コスト
2. 再利用性が低い言語仕様なのでコピペ量産+変更に対して脆弱

レガシーシステム以外でCOBOLが使われないのは主に2の理由

コストは汎用機脱却で10分の1になるケースとかざらにある
ただハード・OS・言語・ミドルウェアのすべてが統合管理できる事の価値を理解してない会社は移行後に痛い目見る

再利用性なんて幻想だぞ、特にJava
やろうとすればするほど泥沼にはまる

汎用機だから高コストはちょっとわからんなぁ
高品質なサポート受けられるし、信頼性高いし、トータルでは安上がりなんじゃ？

ソース継ぎ足しすぎて同じ動作するものを他の言語で作ったら余計複雑化するからもうCOBOL使うしか無いってだけ？

プログラム数やステップ数は多いけど
1つ1つのプログラム自体はそんなに複雑なものじゃない

移行しない一番の理由は事なかれ主義
COBOLを使い続けてるところの大半は
前例主義でリスクを取りたがらない文化が染み付いてる

コボルって名前がそもそもムカつく

【コロナ】政府や金融機関のシステムが失業者のアクセスでパンク→使われていたプログラム言語がCOBOLで対応できるエンジニアなし
http://2chb.net/r/newsplus/1586959302/

多分、対応できないのは
「えっ、コンピュータって大体WindowsやMacやLinuxと同じ感覚で使えるものじゃないんですか？」
って部分でCOBOLじゃなさそう

そもそも重要な部分に使われてる言語ならボランティアで募集してるのが頭おかしい
普通に高給で募集しろよ

COBOLで作ってても既存のオンラインプログラムをスケールさせるのに
わざわざ新しくCOBOLプログラマーを雇う必要はないよね

それにWebをCOBOLで作ってるとも思えないから
発注側が中身を何も理解してないだけのように見える

COBOL=高コスト
はOpenCOBOLで解決出来る

ﾁﾝｹなプライドばかりがいっちょ前な、使えない中高年SE

ってイメージがつきまとうかと(゜ω゜)

ﾁﾝｹなプライドばかりがいっちょ前な、使えない若手SE
に書き換えるとあっというまにWeb系に当てはまるという

結局、本質はいっしょなんだな、これがヽ(゜Д゜)ノ

GOTOキャンペーンでもCOBOLは大活躍です！

>>505
COBOLプログラムの置き換えはかなりお金かかるのよ
数百億円単位平気でいくから
コードを書いた古いプログラマはもうおらず
暗号と化したコードの解読から…

ソースが残っているといいよね

汎用機時代はPL/IやFortrunで中間処理してCOBOLで印刷というシステムが多かったのに、なんでCOBOLだけソフトウェアクライシス何だろうと考えた

俺が新人だった90年代初めでさえCOBOLプログラマの減少は問題になってたと思い出したわ

我々の武器は３つ
COBOL、PL/I、RPG、それとREXX

みずほ銀行で障害
2/28が日曜日の場合のバグかな
それかうるう年計算ミスか

タイミング的にうるう年の計算ミスだろうね

DSLなら必要だろう、よく出来てる
新たなCOBOLを再発明してどうなる

>>不要論
最近COBOLの案件多いよ
オープンCOBOLに組み換えするパターンとJavaに置き換えるパターンに分かれてる

>>523
>>オープンCOBOL
ほとんどNetCOBOLだね
NetCOBOLは制限事項が多い
GnuCOBOLって見かけ無いな

りそなはMF-COBOL
LinuxでSQL Server

固定長レコード特化なcobolのロジックを汎用言語に移植したらとても残念な事になると思う…得にjavaとか向かんでしょ
だからとて新規に固定長レコード特化な言語作ったらキーワード違うだけのcobolにしかならんでしょ

Identification Division