【IT】世界は60年前の言語で動いている。米コロナ失業申請がクラッシュ、COBOLの古兵が大忙し
■ このスレッドは過去ログ倉庫に格納されています
コロナでギークが一番驚いたのがこのニュース。
失業給付金の申請者が史上最悪の1680万人に達して全米で業務システムがクラッシュ！ 化石のプログラミング言語COBOLを操る古参プログラマーが現場の最前線に駆り出され、｢こんなこともあるんだな…｣、｢コロナって計り知れないな…｣とIT業界を驚嘆させています。
絶滅すると言われ続けて60年
COBOLは1959年、インターネットが生まれる遥か以前のメインフレーム時代に生まれたコンピュータ言語です。大学で教わるようなものではなく、使いこなせるのは現場で覚えた生き残りの人たちだけ。完全自動処理ではなく、手動で実行する処理も多く、早くから｢死にゆく言語｣と言われてきました。
早くから、というか、開発の翌年には開発チーム自身が｢そんなに長続きしないだろう｣と冗談でCOBOLの墓石（写真）をつくっていたほどなのですが、これがなかなか廃れなくて、今だに｢銀行システムの43％、対面取引の80％、ATMの95％｣（Reuters）はCOBOLなんですね。
アメリカではCOBOL使いのおじいちゃんたちが集まって立ち上げた｢COBOL Cowboys｣というコンサルタント企業まであって（社内では50代が｢若手社員｣）、レア過ぎる人材としてプレミアムプライスでサービスを提供しています。ここによると｢フォーチュン500の大企業の9割はいまだにCOBOLが走るシステムを使っている｣んだそうですよ？ ひゃー…。
なぜいまだにCOBOL？
本当になんで？って思ってしまいますけど、金融、官公庁の業務システムは365日24時間のミッションクリティカルな業務を扱う巨大組織なので、よっぽど悪いところがないと置き換えられないんですね。
それに、COBOLからJAVAへの移行には膨大な手間と費用もかかります。たとえば2012年に移行したオーストラリア・コモンウェルス銀行の場合、5年の歳月と10億豪ドル（約680億円）もの費用がかかりました。
それなんかはまだいいほうで、英TSB銀行は買収時に脱COBOLしたら、何日も業務停止となって3億3000万ポンド（約444億円）の事業損失を出してしまったうえに、システムのメルトダウンに乗じた詐欺の餌食となって、そちらでも4910万ポンド（約66億円）もの被害を出してしまい、カスタマーからの苦情が204,000件集まって、その対応用の新規採用で1億2200万ポンド（約164億円）、顧客補償で1億2500万ポンド（約168億円）のマイナスとなって頭取が辞任。今も完全には立ち直っていません。
そういうのを聞くと恐ろしく恐ろしくて迂闊に移行できない気持ちもよくわかりますよね…。
2兆ドルの景気対策で盛大にクラッシュ
以下ソース
https://www.gizmodo.jp/2020/04/an-old-computer-system-is-keeping.html 俺はMZ-80BのS-BASICを使いこなして一部機械語も使っていたけれどどこにも需要はない。
もう忘れたけど。 １０年ぐらい前かな。
マイグレーションするのに、組み込まれたアセンブラ対応で
相当引っ張りだこだったらしい。単価も良くて。
今はもう落ち着いたと思ったけど、需要はまだあるのか・・・ コボラーの俺
52歳のくそじじいでも
転職先見つかったよ
新入社員研修で
コボルは一生物です
なんて言ってたが
ホントだったw また「養老会」のスレが立ってしまった。
ｂｙ 元こぼらー
５０だけど、もう、おれはいいよ…。
あんなに残業する日々では体がもたない。
脳も衰えたわ。 >>1
既存のシステムを更新しようとするからだよ、馬鹿だな
ベンチャー企業に新しい銀行システムを作らせて完成したら完全子会社化すばいいだけ
既存のIT会社よりも数段レベル高い人材多いから安上がりなんだけどね
既得権益者の老害には理解できないからみずほみたいになる 平時にデータ構造が近いXMLにコンバートしてゴニョゴニョしておけば 日本もあちこちで稼動中ｗ
わたしがやったのもｗｗｗ >>14
長年に渡る契約・法律・商慣習が組み込まれてるから新たに作るって訳にはいかない
そんな業務ノウハウのない新興企業には入り込む隙も無いわ >>4
cobolって簡単に言えばcとsqlがドッキングしたような言語なんだな。
んでsql的な部分をsqlに任せてJavaだのc#だのにま …任せた方が後々メンテナンス性良いんだが、Javaもsqlも割とgdgdだったから今でもcobolコーダーは世界中どこでも需要ある。 >>8
60年前のプログラムだよ
ハッカーでも８０歳以上でないと攻略不可能 >>1
『べーしっ君』に出てきた「コボルのおばちゃま」を思い出した。
あの段階で「ちょっとセンスが古い」と書かれていたのに やる仕事はクソつまんねえけど食い扶持にはなる。
つまんないけど。 >>26
メインフレームは何一つ置き換わってないのでバリバリCOBOLですよ そもそもcobolを他言語に置き換えなくてはいけない理由ってあるの？
割と簡単で可読性も高いと思うんだが。 タイターだって未来の人類滅亡阻止？のために80年代のIBMパソコン回収に来てたやん 最近の技術はなんでも値段が高いからな
保守契約ライセンス料とかいろいろと
確かに今のもののほうが機能は上だろうが
料金は高いし、いざというとき小回りが利かない
それにセキュリティホールとかバグとかが出やすい 今、アメリカでコボルPG滅茶苦茶需要あるらしい。主に失業保険システムの保守管理らしい。 クリント・イーストウッドのスペースカウボーイとウォー・ゲームを足したような、
かっこいい爺コボラーが世界を救う映画を
「何でこんなところに冷戦時代のコードが」的な感じで いまだプロペラの戦闘機が活躍しているようなもんか。 たとえるなら、COBOLは給料は良くてもひたすらそろばん計算だけさせられる苦痛があると思う >>3
パチンコのメイン処理は今でもZ80だから、そこなら需要あるかもな。
払出し計算は警察の審査が必要で、事実上Z80以外では提出出来ない仕組みになっている 素人の疑問なんだが、コンピューター言語って新しけりゃ
それだけで無条件にいいもんなの？ >>32
まさかとは思うがコポリとかけてるのかね? そもそもコボルはＩＴじゃないからな。
バックオフィスにアイドルみたいな若い女の子をはべらせている流行のＩＴ企業を想像しちゃいかん。 >>45
そういうわけじゃない。
大抵は実用性よりシステム部門が「俺たちスゲー」と言いたいだけのもんだ。
少し前はRubyがその立ち位置だったが最近はGOがその立ち位置になってる。
なので「GOやってます」みたいなとこは避けた方がいい。
専門家気取りの使えない馬鹿ばっかだから。 最先端でもまともに業務システム組めないような言語よりも、
半世紀前の遺物でも現代の業務システムを動かせてる言語の
ほうがはるかに有用だろうに。 >>45
Java以降のは基本的に仕様がどんどん付け足されてる感じなので
パラダイムが同じ奴なら他の言語でもある程度応用は出来る(業務内容は別として
あと根底はやっぱりCとか古めの言語だったりする(Pythonのライブラリとか
言語そのものは適材適所、だが明らかに使ってる奴の意識が低い言語はある
VBてめぇのことだよ COBOLが悪いのではなく、コボラーさんたちのプロセス指向がダメなのよ
しかも何かあるごとに既存ソースをコピペして亜種プログラムを増産する
出力帳票の固定タイトルが違うだけ、あとは全く同じ、ていうプログラム何本作るんよ
アタマわいとんのかキサン 何で無くならないかと言うと、ハードだけ最新にしてソフトは既存資産移行するのが一番安上がりだからだよ 30年物の保守の案件もあるけど、
値打ちも作業ボリュームも理解できないような奴らが勝手に3人月とか
ほざいてくるから、一蹴（笑） アメリカ国防総省様にもう一度新しい開発言語を開発して貰えば良いじゃん >>45
最近の言語にあまり手を出してないから完全に印象だけだけど、
古い言語の方がマシン語に落としたときの状態がイメージしやすいのもあって、省メモリとか低スペックで十分動く。
だけどメモリ管理やらなんやらが諸々手作りなので、バグを作り込みやすいし、
コード流用なく作れば、本当に一から作らんといけないところも多くて大変になる。
最近のは下の部分はある程度勝手にやってくれるし、ライブラリや流用しやすいコードもあるので、
メモリとかのリソースは食うけど、管理ミスってバグ作り込むとかが少なくなってるかなと思う。 だれもきいていないのに、やれITじゃないとか
なんだその考えｗ プログラム言語の翻訳ソフトってできないのかね
一社が数百億、それが世界中なら
できたらひと財産やで >>55
ユーザーの鶴の一声でウォーターフォール開発なのにSTフェーズでも仕様変更が入るのが帳票や画面なので
亜種PGMを作るアプローチは間違いでもない
というか、Javaや.Netでも編集処理を実装するクラスは分けるよ
下手に統合するとバグのリスクが増えて、リグレッションテストの範囲が広がるだけだから
そもそもクラスの継承という概念はそうした亜種PGMを作りやすくする為に生まれた仕組み >>62
20年以上前からそんなん山ほどある
プログラミングにおいて、素人の趣味とプロの仕事の違いは「成果物が正しいか検証しているか」の違い
「翻訳結果に間違いがないか？」を検証する作業だけでも膨大な金がかかるから、何か特殊な事情がない
限り使われない事が多い
どうせ大金かけるなら翻訳するよりもっと使いやすく作り直そうって考えに普通はなるからな PERFORM VARYING I FROM 1 BY 1 UNTIL I > 10
MOVE 'ヌ’ TO WK-1
MOVE 'ル’ TO WK-2
MOVE 'ホ’ TO WK-3
MOVE '゜' TO WK-4
MOVE SPACE TO LP-132
MOVE WK-AREA TO LP-132(I:4)
WRITE LP-R AFTER 1
END-PERFORM. 確かロケットの制御はフォートランて聞いたな。
見かけは先端なんだが問題を出し切った枯れたものを使っている。
日本でも工場など今だにPC98やMS-DOSを使っていたりする。 >>66
フォートランは未だに計算最速だから
最新のプログラムでもコアはフォートランかc
っての科学計算でよくある >>66
工場で古い機器が使われる理由は交換する金がないだけで、良いから使っているわけじゃないぞｗ
業務継続における障害耐性とか考えれば、保守部品が手に入らない機器を使う事は極大レベルの
リスクになるのは当たり前の話 >>22 >>52
COBOLの恐ろしさがわかった((((；゜Д゜))) >>37
多分、ブコフ探し回らないとリファレンスブック置いてないかと >>65
DISPLAY "ガッ" UPON CONSOLE. >>29
１．更新・更新、また更新により
既存プログラムの可読性が落ちすぎ。
２．コボラーの減少により
メンテナンスできる人が減った。
こんなところかな。 昔、昔、まだコンピューター言語がバラバラじゃった頃
事務処理にもっとも便利ということで世界初の標準言語に選ばれたのじゃ
そのおかげで今日に至るまで生き残ってきたというお話 >>72
あちゃ〜 またABEND データ例外だwwww インディペンデンス・デイみてモールス信号学んだはw
手旗信号もやっとこうかな 俺が現役COBOLerだった頃は0C7とか出すと恥ずかしいバグの典型例だったが、今だと低脳COBOLerが通っぽく振る舞う為のキーワードなのか・・・
世の中変わったな cobolからjavaなんて冗談じゃない(´・ω・｀) うーん、加齢臭のキツいスレですね…
みんな元気そうだけどw >>14
はあ…………
そんな大雑把なやり方で移行できるなら苦労はねーんだよ。
どうしてど素人は自分がそれまでの誰よりもよく分かっていて頭が良いと勘違いできるかねw まさか今は名誉教授で存命中の
伯父さんにも声が掛かってるとか
あんのかな？ >>79
0c7に反応してレスしてる時点でお前も同じだろ
「目くそ鼻くそを笑う」だ
ちなみに俺は耳くそがカサカサだ >>29
生産性が極めて悪いからな
COBOLの機能を純粋に見ても生産性は低いけど、それ以上にそれを取り巻く環境が、真空管の時代からたいして進化してないって事の方が深刻
汎用機の世界だと80桁x24行のISPF画面でペチペチ一本指タイピングするジジイが現役とか、IDEが無いからコード補完やリアルタイム構文チェック、静的デバッガが無いとか、
デバッグ作業でブレークポイントが使えないとか言い出すとキリがないくらい劣悪なんだよ
低脳COBOLerが自慢げに話す0C7だって、最近の言語の普通の環境ならコード書いてる最中にエディタがアラートが出して、その場で直して終わるレベルの話だからね
それをコンパイルして、クソ分かり難いログをダラダラ追いながらシンタックスエラーとか直して、テストデータを悪夢レベルに使い難いエディタから作って、
クソの塊みたいなエディタからクソの塊みたいなJCLとかいう最高に無能なシェルのご先祖様を使って動かしてみないと分からないっていう世界が汎用機COBOLの世界
笑えるだろ？w NEC が ACOS を作り続けてくれるので、まだまだ現役。
https://jpn.nec.com/products/acosclub/charter.html
COBOLのシステムも、そのまま動き続けるよ。 >>14
それ仮想通貨屋さんがやって大爆発したｗ
孫請けの中国人が盗みまくった ０ｃ７に食いつくやつが多いなwwww
よっぽど懐かしいのか、知識をひけらかしたいのか？ さすがに情報処理試験の選択言語からは外されたようだな >>29
ＡＫ47もみたいなものだなｗ
100年後もＣＯＢＯＬ使ってるだろうね コボルなんて一番簡単な言語だから別にジジイ使わなくても若い奴の方が
すぐ使えるようになるよ >>87
ACOSは継続かぁ、HITACはどうなったんだろう >>14
そんな簡単にできるなら60年も同じ言語使ってない 夜間バッチで、オペレーターから電話があるとヒヤヒヤしたな
指示書、JCL、プログラム修正どれかをミスったかと
大抵、オンラインプログラム側の入力チェックの甘さから被害を受けて、えらい目に遭っていたが 要は以降が遅れただけで
別に流行ってる訳では無いでしょ そこまでするなら
完全アナログ手法でもよくね？ww >>86
コンパイル、シンタックスエラー
あかん、懐かしくて見てて楽しくなってきた 言語はcobolでもコンパイラが賢くなればいいんじゃないの？ >>98
アナログ手法ってなによ？
「アナログ」は「古い」って意味じゃないぞ(笑) スマホから申請できるからクラッシュする
ＦＡＸで申請するようにしろ >>50
後はいかに高速化、正確さ
信用度だと思う >>86
「俺、知ってる、俺、すごい」感 強すぎwwwww
COBOLで金稼いでた時代の人たちは
言語が古くなったことは認めるけど、けして馬鹿にしたりしないよ。
苦労もしたけど、今も現役で頑張ってくれてる戦友のようだから。
勉強もさせてもらったしね。 >>69
機器の鉄則その一
新し過ぎる者には手を出すな >>98
完全アナログ手法ってなによ？意味不明なんだけど。 実際はCOBOLが問題なんじゃなくて、誰も管理できなくなってるのが問題なんだろうな
どうせ設計仕様書とか何もないんでしょ >>78
光信号も追加したら？ww
もっともアナログなものは絶対に
無くならない >>113
そうだと思う。作った人も行方不明ってのが多いだろね。
２０００年問題のときでも面倒だったわ。 >>114
モールス信号とか手旗信号はデジタル符号だよ。 >>99
そんな希少種使うなら
PC以前に戻せばいいじゃないww COBOLに関しては今後が見物だな、30代以下の世代の連中は誰もやりたがらんだろうし
キャリアとしての意義も無い、今の技術者を死ぬまで飼い続けるしかないんだろうなぁ
10年後にはどうなってるやら >>119
元設計が60年前なんだから行方不明どころか、もう死んでる事例多発かと >>121
COBOLは希少なの？PCはなんの関係があるの？ >>113
世界は謎の機器に管理されている
とはヤベーよww >>125
ターミネーターの世界でもCOBOL動いてるらしいから・・・ >>125
チームで行うプログラム開発について最低限以下の知識しかないなら
無理に話に絡む必要は無いぞ 金のやり取りを効率よく書けるんだよな。
まちがってもゲームなんて作れない。 少なくとも1990年初頭は教育実習学校でやってた。
まぁ、面白くもなかったな。 他のエンジニアのスキルシートを見る機会が多いけど
30代でもCOBOL経験してる人は多い。
大体が一番最初に配属されたプロジェクト。
運がなかった >>2
いきなり艦砲射撃が一番有効かつ必要になった感じかな？ｗ
つかイージスシステムもアップグレードがマストな状態になってるみたいだし、
これを機会に・・・って莫大なコストすぎて無理かぁ・・・ COBOLなんて他の言語やってるプログラマーならちょっと学習すればすぐ覚わる。 AIに学習させデータと今風ロジックに分離させればおｋ 少しずつでもいいから、最新アーキテクチャで作った最低限のシステムに
徐々に徐々に移行していったほうがいいと思うけどね
いっぺんにとか、旧来あった機能をすべて移行するとなるとリスクが跳ね上がるけど COBOL馬鹿にしてるの、縁故ばっかのNTTの馬鹿くさいのだけど世界的に
いっさい成果ない上に、俺がISDNとか窓口で手続きした時代とかIBMのCOBOLの
キーボード使った端末じゃなかったか
Javaも駄目にしたのNTTなんでは >>140
unixで動くCOBOL機材の設計かなりしたぜ、俺は >>140
そのままの方がコスト的にもリスク的にも良いって判断してるからこれなんだけど、
どういう基準で新しい方が良いって言ってるの？
とにかく新しくするためなら、コストがかかってもリスクがあってもやるべきとか思ってる？ だったら、若い奴も勉強したら残存者利益でウハウハなんじゃ？ COBOLはソースプログラムが残ってるだけまだマシ。
今でもPC-9801で動いてるような業務システムは、それを作ったソフトハウスも
ソースコードも仕様書もなく、実際に動いてるEXEファイルしかないのもあるぞｗ ＣＯＢＯＬはたくさん作ったが、テストだけはいやになるよ、バグの履歴とかテストケースを作成するだけで億劫になるし、時間がかかる 俺はもうすぐくたばりそうなロートルだが
自分の作ったシステムが何度もハードのリプレースを経て
今でも現役で動いてるのを知って驚愕した。
俺より長生きしてくれるなら嬉しいよ。 実行環境開発環境がうんこだと近づきたくはないわな
今時の開発環境で手軽に動きゃ業務システムとかつまらなすぎなのでボコル一択とかなるんだろうよ
しらんけど COBOLの何が嫌かというと、冗長な見出し（DIVISIONとかSECTIONとか）や構造化がきちんとできないところ。
だがメリットもあって、データの構造体が画面や帳票の見た目とほぼ一致したり、バイト境界など考えることなく部分的に取り出したりぶった切ったりを簡単にできる点は他の言語には無い。
だからCOBOLのいい点悪い点を踏まえた上で、比較的移行しやすい新しいプログラム言語を作れば結構イケるかなと思っている。
なんで誰も作らないんだろ？ >>154
まさにPL/IがCOBOLの代替となるはずだったんだが、COBOLより先に廃れてしまったw こう言っちゃなんだけど動くシステムをわざわざリプレースする必要がある業種とない業種はあると思うんだよな >>154
ggrks
何度も言われてるけど自動変換ありのマイグレパッケージなんてぐぐれば死ぬほど大量に出てくる
そんなゴミでイケると夢見るのはプロジェクト管理、コスト管理を経験した事のない底辺エンジニアだけ >>86
昔を思い出してスゲー笑えたｗｗｗ
こんだけアホで無駄な事をやってるのに「COBOLはJavaより優れてるのだー！」とか
言い出すから今のCOBOLerって厚顔無恥というか、井の中の蛙というか・・・ >>140
問題はDBを汎用機が掴んでいる事なんだよね
（下手すりゃSQLが出てくるより前の階層型DBとか使ってるし）
コントローラーとビジネスロジックが綺麗に分かれているとか、ビジネスロジックが関数的に
作ってあるとか、元の作りが良ければラッパーシステムかましてWeb API化とかもあり得るん
だろうけど、実際はごちゃ混ぜの闇鍋状態だからね
だから部分的に徐々に移行なんてできんのさ
やるなら業務単位、サブシステム単位でまるごと移行がセオリー >>154
構造化は設計者・プログラマーの問題で
ＣＯＢＯＬで構造化できない奴は辞めた方がいい
大昔のソースでは、非構造化ソースがあるが、
それは化石と思って諦め論 >>159
部分的に置き換えたとろこで、テストの工数が大きく減る訳じゃない
ならば、システム刷新のときにやれば良いじゃないか！
がこれまでの流れ
そして、一挙に変え過ぎてデスマーチにｗｗ >>4
関数自作できれば、覚えることはさほどない。 >>162
>>4は「COBOLは優れているのか」と聞いているのであって、
覚えることが多いかどうかなんて聞いていないけど。 COBOLはコンピュータを理解してる人には書き辛い言語。 >>44
いつの事態の話だよ、、、
もうサウンド制御のサブcptにも使われてないよ、。。 >>9,>>149
今時のスパーコンピュータが Fortran で動いていると思っているんだ
今は技術系計算の 95%以上の ほとんどがC系だよ
作り直したり、改造したりする価値の無い 物が特殊なところだけFortran で動いている
オブジェクト指向とか 構造化が進んだ現在では 別に一部がFortranでもJAVAでも何の問題も無い
スパコンでいくら計算しても 今は結果はUI(表や図形)で見るんだからココをFortranで書く
バカは居ない >>12
黎明期だからじゃないのか
キーボードの配列だって効率的なのはいくらでもあるのに打ちにくいままだし >>169
親指Shiftキーは正しいのに、主流派にならなかった。
未だにShiftキーはキーボードの両端にある。 >>72
COMPUTE HOGE = 食費 ／ おまえの給料 PC/Windows10上で富士通かMFのCOBOL
VBSをJCLとして使い
VBAでエクセル経由の帳票出力
ESC／P制御が必要なら今でも動くF/BASIC
COBOL、事務用途なら３０年経っても基本は変わらず
昔のソースが簡単に読めるし、使えるなら使えば良いだけ COBOLは既にオブジェクト指向機能を持っていると知らない奴がいるな
でも、それをフル活用した人間は一人も知らない 金融系はCOBOL 科学技術系はFORTRANて言われてた >>14
新しいシステムに元データ入れる際に不正や間違いが起きる。やるなら複数回に分けて、検証作業も入れて行う必要があるから手間もお金も掛かる。 COBOLもFortranも地味に進化し続けているからな。
プログラマーに大事なのは言語よりも言語を使って行う業務の知識なのは常識。 誰でもちょっと教わればそのくらいできる
そんな困る話じゃない >>178
昔のやつのメンテナンスいうてるんだから
地味な進化は関係なし >>173
そう。ただ現実的にはソースが簡単に読める事はなく、長年のメンテでパッチだ拡張だで技術負債が溜まり込んで、なんの業務なのか顧客も理解できてないって現状が一番な問題。
それはCOBOLの言語と言うよりは、その世界でしかやってこなかった人達のドキュメント力や更新されない概念で作られたものの品質が良くないってところかな。 >>178
むしろFORTRANより早い言語が未だに無い現状よ COBOL知ってても、メーカー独自のインターフェースとか噛んでるから
そのメーカーのCOBOLとDBと画面やプリンタのインターフェースを理解してなきゃ
ソース読んでも追いかけるの大変だもんなぁ。
漢字の扱い一つとってもX16'0A42’’0A41'とか、560/20端末は癖があったから
他社リプレースで泣きそうになった。
VOS3とVOSKの懐かしい思ひでポロポロwwww お前らそんなにマリーアントワネットをかばうなら、日本をマリーアントワネットに占領してもらえよ。お前らの会社も学校もマリーアントワネットに買収されればよいだろ。
いやなわけ？ｗｗｗ だったら 米国もフランスも関係ないじゃん。(俺はゴーンの味方をしていないぞ)
お前らの会社も学校も、財務省や経産省に買収されればよいだろｗｗｗいやなのか？ｗｗｗ だったら 米国もフランスも関係ないじゃん。(何度も言うが俺はゴーンの味方をしていないぞ)
お前らが老後入所する老人ホームも お前らの老後の年金も マリーアントワネットに管理されればよいだろｗｗｗいやなわけ？ｗｗｗ じゃあ米国は関係ないだろ？ｗｗｗ
お前らのガキが入園する保育園も マリーアントワネットに買収されればよいだろｗｗｗいやなわけ？ｗｗｗ じゃあ米国もフランスも関係ないだろ。
お前らが老後入所する老人ホームも お前らの老後の年金も 経産省に管理されればよいだろｗｗｗいやなわけ？ｗｗｗ じゃあ米国は関係ないだろ？ｗｗｗ
お前らのガキが入園する保育園も 経産省に買収されればよいだろｗｗｗいやなわけ？ｗｗｗ じゃあ米国もフランスも関係ないだろ。
で、国とか官僚とかカスミガセキを信頼してるわけ？ｗｗｗ
俺は「お前ら日本に、外国人労働者さんが奴隷扱いされている」のをよいことだとは言って無いぞ。
だから、解決策として。
日本は、日本はいらっしゃる外国人労働者さん・日本へいらっしゃる移民のかたにも、外国人地方参政権をよこせ。
今すぐ、東京にもっと東南アジア系移民のかた・アフリカ系移民のかたを受け入れよう！今すぐ、東京にもっと東南アジア系外国人労働者さん・アフリカ系外国人労働者さんを受け入れよう！
今すぐ、日本にもっと東南アジア系移民のかた・アフリカ系移民のかたを受け入れよう！今すぐ、日本にもっと東南アジア系外国人労働者さん・アフリカ系外国人労働者さんを受け入れよう！
日本人に民主主義は無理なんだよ。日本およびドイツを1945年に完全に滅ぼしておくべきだったんだよ。今すぐ日本死ね。今すぐドイツ死ね。日本およびドイツは人類の敵だ。
お前ら日本にいるジャップの従来の主張からすれば、
感染したら、老害や寄生虫や弱者のほうが死ぬ確率が高く、
進化論における自然淘汰が起きるわけだから、
日本にいるジャップが感染しまくったら、お前らとしては喜ぶべきだ。
さらには、結果として生産性も上がるだろ。
結局、お前ら日本にいるジャップこそが寄生虫だったんだな。
日本にいるジャップがもっと感染し、日本にいるジャップが死滅しますように。 あんだけの規模のソフトウェアを一気に書き換えってのは簡単じゃないわな プログラミングは良く分からないが、古いから部分的に置き換えるとかできないんだろうな。 >>186
最新システムの補助で良い部分と業務の仕様が分かれてるなんてお行儀の良いコードじゃないからね FORTRANで書いたソフトウェア今も毎日回してるよ？
多分77だろうけどちゃんと計算してる >>186
耐震性に問題があるビルを建て替えるか補強するかという話をしてるときに、
とりあえず鉄骨の交換を徐々にしていけば良いんじゃねというのと一緒。 ゼロシーセブンってなに
データ例外ってなに？
数値項目の位置に、漢字とかカナとかFILLER
であったｗ コレポンコーディング禁止ってなに？
エバリュエイト使用禁止ってなに？
IFのほうが速いってなに？ｗ identification division
MAIN section
read infile end
造りが単純な分 固い とも言えるけど、組み方の面倒臭さはデバック地獄との戦い >>1に比べりゃ
みすぽのアレは英断と言える訳だな！ いまの小中学生だかは（結構まえから）プログラムが必須だったと思うが
ＢＡＳＩＣとかやってるのかな？？？
ワンチップマイコンのプログラムをＢＡＳＩＣで書いたんだが、
生まれて初めて仕事で役に立ったはｗ 数年前まで納付書印刷に汎用機でCOBOL使ってたわ。 >>192
correspondingは、多くの開発現場では無条件に禁止ではない
構造体単位での転送のほうが早いが、 乱用するバカが時々いるから
また、データの使用状況調査で、判らなくなるから禁止の場合もある
evaluate はコンパイラの賢さ次第、バカなコンパイルもある >>193
メモリ使用が大きく、そのジョブステップの間中割り当てが必要になるから
通常はソートだけで、１つのジョブステップにして、
多くの目盛り使用時間を最短にする >>168
alias問題があるからC系は遅い
C++にrestrictはないしな
ポリモーフィズムも間接参照まみれでキャッシュマシンに相性が悪い 10年前ぐらいからCOBOL特需って言われてるけど新規参入エンジニア増えないもんだね >>163
学習負荷が少ない事も優劣のポイントとするならば、この指摘もアリだと思う。
でも純粋に言語仕様的にはどうなんだろうね… 昔、カセットテープに収録した古いコンピューター言語が理解できず、
ウイルスとなってクラッシュした未来の巨大コンピューターの漫画があったが、
どうやら、そうはならなかったか >>22
後、10年もしたら技術者居なくなって本当のクライシスがくるね。
COBOLシステムの更新特需と言う名の地獄が待ってるね。 FORTRANは最古にして最先端の言語。
世の中のスーパーコンピューターは、
すべてFORTRANで動いていると言っても過言じゃない。 こういうスレでCOBOLやFORTRANを嬉々として語る輩はなんなのだ
自分の市場価値が示せて嬉しいのか
それは勝手だけど未来ある若者を己の業界へ勧誘するのはやめてな >>132
A10退役を始めたんでは？
>>184
何このキチガイ作文 >>37
去年ポケットリファレンスなら買ったよ
今でも需要あるし リプレースで得られるメリットはJALがFORTRANのシステムリプレースした事例でわかる
時間も金もかけて綿密にやらんといけないが
全日空が25年ぶりに国内線基幹系刷新
https://xtech.nikkei.com/it/article/COLUMN/20130830/501167/ >>172
そこはちゃんとゼロじゃないことを確認してからじゃないと このままでは誰もメンテ出来ないブラックボックスの出来上がりになるのは目に見えてるから
いずれ置き換えはされるだろうな
今のCOBOLerには仕様書書いて貰う方が今後の為になるだろうさ >>214
cobolの置換もだがJavaにしたがるセンスがわからん 単純な事務系作業だと、C言語やJAVAよりもCOBOLの方が優れてるように見える
問題は、汎用機しかないどころかモニターすらあるか怪しい時代の言語だから
PCやサーバに対応してなかったりするし、JCLというスクリプト言語で
資源を割り当てないといけないとか汎用機の使用を前提にし過ぎてるのが問題
（この辺、汎用機のエンジニアならすぐわかるが、そうでないと
何を言ってるのかすら分からないだろう）
JCLがなくてもプログラムを組めたり、サーバでも機動的に動かせるように
なればCOBOLはもっと使われると思うのにな >>217
javaの方が資源は食うがリアルタイム系の処理は最適なんだと
予約の注文や変更とかは時間との勝負だからjavaの方が向いてる
ってことなんだろうな
それとANAにしろJALにしろ国際線を扱う関係で海外との取引が多い
海外からの注文が仕様が違うから受け付けられないとかの事態を
避けるために航空業界は同じシステムを使う傾向が強くなってる >>219
リアルタイム処理って別に速さじゃないんだけど… GCがあるJavaでリアルタイムなんて信じられん。
可用性が求められる大規模システムにJavaというのはすごく納得なんだが。 コボルのデバッガーは聞いたことないな。今でもデバッガー無しでやってんのかね。信じられんね。ちなみにオレは、C,C++専門だけど。 航空関連で使うなっていうのが
許諾条件になかったかな？ >>217
みんなが使ってるデファクトスタンダードにしておけば将来の拡張性が保証されるし人員調達も楽だから
今から40年前にCOBOLでみんな揃えたのと同じ理由ｗ
オタクの趣味のプログラムならなんでもいいけど、大企業の基幹システムならサポート体制とか
パフォーマンスとか将来性とか各種リスクなんかを考えると今はJavaが手堅いというだけ >>218
お爺ちゃんｗｗｗ
PC COBOLなんてフリーのも含めていくらでもあるんやでｗ
つか、10〜20年前はUNIX系OSで動くPC COBOLへの移行が流行ったじゃん
EBCDIC依存コードとDBI系処理を潰して、JCLからshellへ書き換えとかなｗ
それどころか、みんな大好きなmicro focusなんかJavaや.NetでCOBOLをラップする
ミドルウェアとか出してるんやで
まったく売れてねぇけどなｗｗｗ >>222
使い難いヤツだけど、昔はあった
けど、そういうツールの必要性を理解する当たり前の感覚を持ってる会社なら、とっくの昔に
Javaとかに移行してるんじゃないかな
数年前に現役コボラーの知人から聞いた話だと、最近の現場はデバッガもUTフレームワークも
カバレージモニタもリソース管理も何にも無いとか言ってた
よくそれでやってられんねと笑ってやったけど パンチカードでプログラムをインプットする現役システムは流石にないよね？
博物館で動態保存してるシステムはあるだろうけど >>226
言語はCOBOLのまま、現代的なソフトウェア工学を適応するのが筋が良いと思うんだけどな。
どこまで取り入れてるのか知らんけどリファクタリング行ったり、CI導入したりとか。
ドキュメントもちゃんとメンテして。
COBOL案件がグダグダになってるのってそういうところが原因なんだから。 >>233
なんか10年以上前にEclipse・SVN・JUnit・AntあたりをCOBOLのお爺ちゃんに見せたら「未来だ！」
って大興奮してたのを思い出したｗ
COBOLしか知らないお爺ちゃん達は知らないんだけど、CIツールにしろ、IDEにしろ、
フレームワークにしろ、VMやクラウドにしろ、Javaならそういうサポート製品が
世の中にたくさんあるんだよね
COBOLなら製品がないか、あっても足りない機能を独自作成する必要があるけど、Javaなら
そういうツールを導入して、業務フローをツールに合わせて調整するだけでその恩恵にあずかれる
あと、システム外とのI/FだってJavaでの実装例や標準的なライブラリにも事欠かないから
互換性の意味でも強いし
デファクトスタンダードの良さってそういうところでしょ
IBM汎用機とCOBOLが40年前に流行ったのだって似たような理由じゃん
（汎用機で言うならeasyとかHULFTとかなｗ） >>233
普通に今のCOBOL(COBOL2002から)はオブジェクト指向とか取り入れてるが…
でも今更、COBOLのままオブジェクト化するより
もうちょっと可搬性が良い言語にしたくなるのは当然かと COBOL2002とか使ってるところを見たことがない
実務経験が無いのがバレバレ
だいたいOOPが理解できなくて時代の流れに取り残されたのが今のコボルおじさんじゃないのか？
現役コボルおじさんも使えない、若手エンジニアも使えない、将来性もまったく無い、なんていう言語でまともに使えるエンジニアが集まるのかよ
そんなメリットの無い代物を選択するアーキテクトが居たら降ろされるだろう >>238
あまりにもヤバいからまともな技術者が一斉に逃げて残存者利益が大きくなってしまった
あと、COBOLが優れているのではなく、この業界の新規開発の成功率は２０％程度なので
それを生き延びたシステムを捨てて、また８０％は失敗するリスクをみんな背負いたくないってことでしょ
金融系はフィンテックという大きな波で既存銀行がシステムどころか丸ごとつぶれるリスクを背負っているわけだが >>35
それが壊れたら？
直すのに5倍位大変じゃないか？(´・ω・`) そもそも>>1もコロナという急激な世界の変化に旧世代のシステムが対応できず
業務スキームが壊れたという話だからな
動いてるならいいじゃん思想で脱COBOLを怠ったツケを今支払わされていて
そのツケが思った以上に大きかったってことだよね >>246
論点がちがうかと
新世代でもオーバートラフィックで停止はありえる バグが残ってたり、停止するのは言語によらずに起こりえることで
今回のもバグを知りつつ放置してなら、古いやつを使い続けたのが悪いとはいえるだろうが
バグがあると思わずに使いつづけてたなら、対処は難しいかった
これはコボルにかぎらず起こりえる >>247
トラフィックってネットワーク通信量の事だろ
トラフィック不足ならインフラチームが頑張る場面であってCOBOLとか関係ない
エンジニアの端くれなら用語くらい正しく使えよ
勉強不足 >>247
あと、サーバーのマシンリソースが足りない場面でも、新しい技術で組まれた環境であれば、
CPUクレジット買うなりプラン変更するなりしてサーバーのスケールアップをすれば
すぐ追加できるだろ
追加の画面や処理が必要になったとしても、新しい言語なら技術者を集めるのも早いし、
生産性が高いからすぐリリースできる
そういう拡張性の面で古いシステムは非常に劣っていて、COBOLとメインフレームなんか使ってると、
マシンリソースは追加できない、人集めも苦労する、追加機能もできるのは数カ月後、みたいな
状況に追い込まれるのが問題になってる
こんなネタは日経レベルでも散々出てるし、これくらい予想できないならやっぱり勉強不足 そもそも、いままで動作してたシステムが停止した原因がなんなのか、書いてないわけで
申請がいちどに集中した可能性があるとおもったんだ 用語集｜トラフィック
通信の分野におけるトラフィックとは、インターネットやLANなどのコンピューターなどの通信回線において、一定時間内にネットワーク上で転送されるデータ量のことを意味します。
Webサーバーの分野におけるトラフィックとして、外部からの接続要求数やアクセス数、サイト内のWebページを移動する閲覧者の流れを指すことがあります。
https://www.idcf.jp/words/traffic.html >>247
設計時の見積を超えるような処理が来た等のトラブル時の対応に違いがあって、
旧世代のシステムは対応できずに苦労しているって話だろう
>>250
そういうところが今時の開発環境やクラウドのメリットだよね >>249
処理量をトラフィックというのは俺も違和感あるな
今まで聞いた事がない
ネットワークの負荷やWebのアクセス数で使うのなら分かるけど、話題はメインフレームが
扱うような基幹システムの処理なわけで むしろ、インターネット以前のコボル時代、クライアントサーバ型のほうで
トラフィックが使われてて、そっちは処理件数の意味あいだったのでは?
２．クライアントサーバ型システムの問題点
受注入力・伝票発行・請求書発行‥等様々な部署で複数台のパソコンが必要になる企業の業務システムには
「クライアントサーバ型」はそのメリットが活かせる最適なインフラであるといえますが問題点もあります。
それは、サーバ⇔クライアント間のトラフィック（データ流通量）です。
サーバで管理しているデータをクライアントで処理し、その結果をまたサーバに書き込むため、サーバとクライアント間には膨大な量のデータが流れます。
https://bflat.co.jp/bfnews_bn/0608/topnews.html ホッパーおばさんは偉大だったなあ！
COBOL言語はコンピューターが非力すぎてGUIすら実現できなかった時代に一般人でも気軽に使えるように開発された言語なんよ。 >>250
スケールアップなんてミッションクリティカル系のシステム見てたら
そう簡単にできないのなんて経験してると思うんだけど。
あ、スケールアウトの間違い？そんな間違いしないよね。 COBOLの仕事で検索しても無名の派遣会社しかない ＰＣ９８も現役で活躍してるからなｗｗ
ＣＯＢＯＬもフォートランもあと100年は生き残るかも？
ＡＩの理論なんて200年前にトランプ博打用に開発されたんだぜ？
ｂｙ エイダ 言語変換するAIの需要がありそうな更に最適化するみたいな感じで ググったら、こんなものが・・
>ttp://cobos.metrixware.com/
>Eclipse-based COBOL IDE 今だと逆に美味しい職場じゃないかって気もするんだけどなぁ・・・
個人的にはワークライフバランスが確保しやすいのがありがたい
高齢者が多いせいか平時は19時までに終わるのが普通で17時帰りも全然できる
デスマーチ状態でも21時で終わりなことが多い
（汎用機のスペック不足が慢性化している現場だと、夜間バッチ始まるとオンラインも開発環境も
落とされるから強制的に残業不可みたいな美味しい現場もある）
Java、C#、PHPなんかだと終電までとか、家に帰ってリモートで深夜までとか普通にあってマジきつい
22時以降に普通にチャット飛ばす奴等、全員死ねばいいのに >>259
派遣会社が無名でも、そこそこの時給で仕事があればそれでいいのでは？ >>117
伝送する手段はアナログだよ
アナログ信号をデジタルに見せかけてるだけ ちゃんと理由があって移行もできないとかお金がかかるってわかってるならちゃんとできる人を育成しといてもいいんじゃね。
これを機にずっと使うからみんな勉強してねって言えばいい。 昔は保守性とか考えて作ってないだろうから悲惨な事になってんじゃねーの ハリウッド映画化決定。
「ジイさん、あんたの力がもう一度必要なんだ！」
「昔の話さ。もうワシは足を洗っている。ワシはPythonもJAVAも知らん」
過去にその手腕を知られていた人物が、時流の変化の中で世間から忘れ去られて
いたが、突発的な事情により、その能力が必要になって、現場の最前線に立つと
いうプロットの映画は数多くあるので。
『七人の侍』とか『許されざる者』とか『スペースカウボーイ』とか。
主演はクリント・イーストウッドで。 俺はC/C++、VB、Java、JavascriptとSQLしかやった事無いけど
COBOLはソースコードからのリバースはやった
これって言語としては難しくはないだろ
ただ問題なのは、仕様書が残ってなくて(だからリバース)、
ユーザーも何でその仕様なのか判らない、ていう所だろ
昔のコボラー呼んできても、この状況は変わらないと思うぞ イタコ呼んで、物故した原担当プログラマの指示を仰ごうｗ >>272
C++やJavaやVBも言語としては簡単というか
統計分析とか学術計算とか3D座標計算とかAIとかの分野でもない限り、言語やロジックで難しいというのは
無いように思うけどな
色々やった事のある立場から言うと、OOPや開発ツールの使い方、フレームワークのお作法を知ってる程度で
イキってる方がキッズに見える
結局、どんなエンジニアでも一番慣れている環境がパフォーマンスが出るのは当たり前なわけで、
PMとしては不慣れな素人連れてくるより、経験豊かな手練れが欲しいってだけだよ COBOLは特殊だからコボラーじゃないと手を出せないと言う御仁が多いのは如何なものか 5Ｇ携帯も300年前の数学理論
つかってるらしいな
逆フーリエ変換とか >>275
C++はダイヤモンド継承(MixIn)が簡単にできたり（その際気をつけないとメモリリークする）する時点で、仕様的に複雑だと思うけどね
コンストラクタで例外とばしたらメモリリークするとかいう都市伝説もあったりしたし >>276
COBOLが特殊だからというより
メインフレーム周りの処理と銀行系の業務知識が特殊だから、生粋のコボラーじゃないと手を出さないほうが無難って話かと
どっちもネット上に情報が潤沢に転がってるとはおもえないし >>277
大学院の研究所での研究それだったけど、ただの割り算だぞ >>278
言語としてできるから難しいとか、だからC++エンジニアは他より優秀みたいな話は違うと思うんだよな
多重継承はやらないのが今では基本的なお作法だったりするし、GCのようなメモリリークを防止する仕組みの
ある環境でも特殊なライブラリを使って組み方が悪ければメモリリークを起こす事もあるし
コードの作りが悪い事と本質的な難しさは混同してはいけないと思う >>276
C++エンジニアが多重継承やメモリリークがあって特殊だから他は手を出せないとか、組み込み系エンジニアが
開発環境やロジックの組み方、テストの考え方が特殊だから他は手を出せないとか言い出すのと似たようなものかと
どんな分野でもそれ固有のノウハウがあって、それを知ってる人の方が効率が良いというだけ
>>279
そういうことだね
金融系は関係者のみ周知のクローズドな業界知識が多かったり、汎用機関連の技術情報はググっても出てこないから
（大昔に発行されたボロボロの本が今でも置いてある現場とかあるくらい） ■ このスレッドは過去ログ倉庫に格納されています
