【IT】何度でもよみがえる『COBOL』需要 1978年版、1999年版発行の専門書も増刷へ なぜこんなに根強いのか ★2 [ネトウヨ★]
レス数が950を超えています。1000を超えると書き込みができなくなります。
「COBOLは滅びぬ。何度でもよみがえるさ」。ご存じ「天空の城ラピュタ」のセリフのもじりだ。手あかがついた表現で恐縮だが、最近、COBOLについてこんな風に感じることが増えた。
長期的な視点でCOBOLが消えゆくプログラミング言語であることに異論がある人はいないだろう。よほど特殊な事情がない限り、システムの新規開発にCOBOLが採用されることはない。IT関連資格の定番である「基本情報技術者試験」でも、2019年の秋期試験を最後にCOBOLの出題が廃止された。
以前このコラムで、このときの基本情報技術者試験、すなわち「最後のCOBOL試験」を実際に受けたてんまつを紹介した。試験自体には合格したものの、COBOLの出題部分の成績は散々だった。
その試験勉強のためにCOBOLの解説書を書店で探したところ、ほとんど見つからなかった。大型書店の書籍検索機で「COBOL」がタイトルに付く書籍を検索したところ結果は0件で、表紙が傷んだ解説書をようやく店頭で見つけた。
この最後のCOBOL試験が実施されてから、もう2年がたつ。さすがに新たにCOBOLの勉強を始めようとする人はいないだろうし、解説書も絶滅しただろう。そう思って、大型書店の書籍検索機で2年ぶりにCOBOLの解説書を検索してみた。
すると驚くべきことに、6〜7種類のCOBOLの解説書が「店頭在庫あり」と表示された。以前よりも増えていたのだ。売り場を確認したところ、小さいながら「COBOL」と表示されたコーナーがあり、そこに解説書がずらりと並んでいた。それらの奥付ページの発行日を確認したところ、1978年に初版が発行されたような古い本もあるが、2000年代になってから出版されたものもあった。
その中の1冊を見て驚いた。初版発行こそ1999年と20年以上前だが、「第3刷発行」の日付に「2021年2月25日」と記されていた。今年になってから新たに印刷されていたのだ。値段は少し高かったが、思わず買ってしまった。
以下ソースで
https://xtech.nikkei.com/atcl/nxt/column/18/00682/101900055/
※前スレ
https://asahi.5ch.net/test/read.cgi/newsplus/1635941818/ がんばれFORTRAN PL/I推奨の人々
アセンブラもおもろいぞｗ アセンブラはマジで早めに触っといて欲しい
「なぜキーを押したら色が変わったのか」
全てのコンピュータの動作を最も細かいレベルで
理解できるようになる
ブラックボックスがブラックボックスで無くなるんよな
組み込みマイコンとかやらない人でも
いろんな部分で役に立つよ データディビジョンの考え方がわかって、何かを悟った気がしたな。この部分を極めれば究極のデータベースが作れそうだと思った頃にプログラマー辞めた。AIみたいな方向性を考えつかなかったあたりが俺の限界だったんだろうな。 未だにCOBOLとか日本のITレベルの低さの現れだろ。 正確にはアセンブラ触る過程で通る概念、が有用なのかな
ビット演算から代入、ループ制御にベクトル演算...
最後どんなバイナリになるのか
感覚的に理解できるのとそうでないかは
特にこれからの時代相当な強みになると思うんよ 電子ブロックにマイコンついたやつ持ってたけど、パソコン組み立てはできるけどプログラムはBASICどまりなんだわ。 全部作り直すよりメンテナンスしたほうが安くて確実だからだろ
金融機関とかはまだまだあるだろ >>8
> 全てのコンピュータの動作を最も細かいレベルで
> 理解できるようになる
この効果は大きいよね
コンパイラやインタプリタ言語をマスターしても結局イメージでしかない
実際にはどう動いてるかを知ると障害事例とか聞いても
更に踏み込んで想像できるようになる Visual C++はどういう風にVisualなのか昔からわからん
Visual BasicみたいなGUI作成画面が最初にはでてこないとおもうんだが 会社のエクセルのVBがエラー出して死にそう。誰が作ったかも分からんし ５ちゃんみたいな古臭いサイトで脂ぎったハゲ連中が今でも書き込んでんだし
そりゃ、COBOLもしぶとく生き残るだろなｗ >>17
それ以前のコンパイラなんて
テキストベースのDOS画面みたいなインタフェースが当たり前やったんよ
GUI上で動作するからvisual...の商品名になった
なおもうvisualstudio使うような仕事からは逃げた方がええ
vscode慣れとこう アセンブラやるならLLVMのほうがいいとおもうがな
どっちも対して知らんが
LLVMアセンブラは架空や疑似みたいな、最終段階一歩手前の言語なんだろ? アセンブラができればHaskellでで洗練されたアルゴリズムを組める、というわけではない でも電気電子でASM Cのおじさんたち
COBOLを嫌がるのはなぜかｗ フロントエンド作るわけじゃないから
Oracleの読み書きに使うんでしょ
固定長の10進数が扱えるので親和性が高い
ひたすら金の計算するのにオブジェクト指向とかいらん
ストアドでやてばいいのにとは思う
グレースホッパーは偉大 低級言語、高級言語の意味が分からない
部長代理に遭遇
ラダーもASMもやる人なのに まあ、たしなみとしてはアセンブラだけじゃなくてOSの設計やチップの設計もな またコボラーの天下？
はようオジイ引っ張ってきて教えてもらわんとヤバいぞ
年齢的も ボケ入ったらヤバい ちなみに組み込み系っぽいのはオブジェクト指向が持つと光と闇が両方そなわり最強に見える おまいらまだやるんかｗｗ
だいたいの人は今日仕事の日だぞ
オレはMicrosoft 365のテナント構築しないといけないから寝る 「もうついたのか！」「はやい！」「きた！エクセルレガシーきた！」「メイン担当者きた！」「これで勝つる！」 研修センター的なところに行ったときの立て看板が印象的だったな
新人研修の日程にCOBOLってあった
あれ新人の頃を思い出す研修だったんだろうか？ >>8
理解できるようになるが、そういうのを意識しないでも組めるようにしたのが高級言語だし アセンブラっても、8ビットとかの時代、手書きで書いたりライブラリリンクしてやらせてた多倍長整数や浮動小数点実数の演算が一命令でできちゃう時代だよなあorz アセンブラっても、8ビットとかの時代、手書きで書いたりライブラリリンクしてやらせてた多倍長整数や浮動小数点実数の演算が一命令でできちゃう時代だよなあorz 俺も左利きだからわかる
サイコガンはオッサンの憧れだ >>23
各高級言語を
実在しない、無限のレジスタ数を持った
架空のCPUのアセンブラのような低レベル言語に
一度変換してから最適化するのよllvm
もし今既にJavaなりc++触ってるけど
アセンブラ全くしらん、みたいな人には
ちょっと面白いかもしれないね
なぜコードは遅いのか、速いのか理解するヒントが沢山ある つってもCOBOLで取った2級程度では使い物になんのでしょ？ 言語レベルで２進化１０進サポートしてるのは珍しいだろ
C#もサポートしてるけど細かいとこまで書くのは怖いし カネになりゃいいのよ
ついで読みやすさは明日の自分へ コボルは簡単だから銀行員とかでもちょっと勉強すれば読み書きできる
実際、銀行とかは行員と技術者が一緒になって開発してたよ 昔携わった会社の御偉いさん曰く、実績のあるもの以外使うのは許さん！
それを評価する側の人間の知識が更新されないので
昔の成功経験のあるものが優先されちゃう 日本医師会の作るレセコンのORCAはDebian GNU/Linuxで動いているにも関わらず帳票部分にCOBOLが使われている
俺も一時期関わったが設計のメンツがキチガイばっかりでオナニーのような設計をしていたのが印象に残ってる >>41
知らなくても触れる、事の大半は
「知った方が更に深く楽しく触れる」だよ
GPUシェーダーやテンソル処理に
ネットワークインフラ周りにオーディオIFまで、
アセンブラの基礎知識があるにこしたこたぁ無い部分はごまんとあるのさ コボラーおじさんのプログラムって日記みたいな注釈書いてあって嫌いじゃない 未だ多くの金融機関の基幹システムが汎用機で動いてるからな。ハードだけ刷新しても中身はうん十年前のソフトとかね。
なぜかと言うと仕様書が無いから作り直せない。 ま、文系は視野が広くコミュ力が高いが
直ぐにカネになる実務能力の低いのも
多いからな。 会社にたくさんはイラネ。 むしろなんでCOBOLを有効活用しないのかと思う
みーんな、自分の知ってる一つの言語でやりたいんだろうなぁ
COBOLは計算するところだけに埋め込んで使えばいいじゃん
全部COBOLでやる必要はない適材適所で使えばいいんだよ
なんで全部同じ言語でやろうとするんだろう
ヴぁーかばっか >>61
サーバーみたいに古い環境を仮想化してるかと思ってたけど
今でも実機の汎用機で運用してるの？ おまえらのIDENTIFICATION DIVISIONには無職高齢童貞とか書いてあるのか 2年休職中に何故勉強しなかったかって
それができるなら休職なんてしてないんだよ
しかもコロナ前の仕事しかしてないし
いろんな意味で復帰が恐ろしい 三十年前市町村のシステム作ってるときに使ったわ
まだオープンリールのテープ使ってて普通の町の住民データならテープ一本で収まった
読み込みに三十分かかるが プログラマーの実務哲学の１つに
既に作ったルーチンと同じもの似たものは
２度と作ってはイケナイ。
コボル資産がそれ。その資産の保守管理に
コボラーが必要。ただそれだけ。生産性を
高めるため。
既に存在しバグ取りもされたソースを
活用するほうが、はるかに早くて安く済む。
当たり前のお話。 私は若輩者だが、COBOLを少し勉強すると、
COBOLではなく例えば20年前くらいのJavaで書かれたものでも、
なんでこんなにコードになってのかわかるよな
90年代−2000年代の頃はCOBOL脳のおじさんたちがそのままJavaに置き換えて書いてたんだろうな
何この大量のワーク変数とか、ゼロ埋めとか、空白埋めとか思うし
COBOLは金額計算とか、固定フォーマット形式の親和性とか
なるほど秀でたところあるなーと思ったけど
COBOL前提？の設計を他の言語でもしてほしくないなと思う 高校の時に習った以来、全く触ってないな
なんかチャート？みたいなやつ書いてた気がする 馬鹿でも書けるし、馬鹿でも読めるからだよ
だから無くならない 現代でのCOBOLとFORTRANの一番大きな違いはCOBOL弄る奴らはプロのプログラマーで会社などの
為にやってるのに対しFORTRANを弄るのは研究者とか学生とかのアマチュアが自分の研究などのために
やるケースが比較的多いって感じかねこの時代。
最近はCを使う例も増えてきたが、勘違いする奴も出てきて困る。FORTRAN用の関数なのに4バイトuint返すとか。
久しぶりにequivalenceなんか使わねばならない羽目になったぞ。 >>77
昔FORTRANも仕事でやったけど
・橋梁の設計計算
・通信設備の線路設計（CAD）
とかやっぱ勘定とは違う計算が多かったね まぁ最前線やってるような連中からすりゃそんなに難しい言語でもないからなぁ
必要になった、覚えるかで済むレベル
ぶっちゃけCOBOL出来るからって特別なスキルでもない
だから専門書読めばいいから、それだけたまに売れるんだろう >>77
Cとfortran混合でプログラム書いてリンクして使ってたりする環境なんですか？ 第二種情報処理試験の内容を覚えてないな。
免状に書いてあった大臣の名前が深谷だったことしか覚えてない。 COBOLなんてぶっちゃけ、構造体を理解できない奴が構造体を使える様にしてるだけだもんな COBOLというよりJCLとかジョブ文が運用しやすいからだと思う ものすご〜く初心者なのでアホっぽい質問だけど、COBOLは他のデバイスとのやりとりは何でやってるの？
やっぱりOSが仲立ちして入出力装置を動かしてるのかな セキュリティの事を考えてない時代の言語だからね。
そんな石器時代の道具を骨董屋並みに揃えているのは日本くらいじゃない？ >>24
これの意味がわからないんだけど
俺って発達障害かな >>68
ハードディスクより保存性はいいだろ
バックアップには適してる 80年代は専門卒を即戦力で採用してた。大卒で入社してから教育するより早いので。 >>79
こっちは理工系の学生時代に始めて当時はそれ以外の選択肢はなかった。教える側も自分が研究で
使うので覚えたというタイプ。
>>82
こっちの分野で広く使われているちょと特殊な形式のファイルからデータを取り出す関数群を
そのフォーマットを開発した組織が提供しているのだけど、それにFORTRAN用とC用があって
それのFORTRAN用の関数がuintなんて返してくる。で、その関数群を書いたのはc村の住民だなと。
で、しょうがないので８バイトの普通の整数に変換したのだけど、最初はcで４バイトのuintを
8バイトの符号付整数に移して返すという1行の関数書いたが、そこでFORTRANも8バイトの
普通の整数の下４バイトをequivalenceで4バイトの整数としてそこに元の4バイトのuintを移せば
いいと。
その過程で習ったのはFORTRANのコンパイラはコンパイル時には大文字を皆小文字にしてしまうが
リンカーでcでコンパイルした関数をリンクする際には関数の名に大文字が入っててもそれを
小文字にするようなことはないと。リンクできない理由がしばらくわからなかったべ。 >>8
RISCのアセンブラを組んだことあるのか？
インテル系の腐ったアーキテクチャ引き摺ってるオヤジの出番はないぞ >>1
ネトウヨ★wwwwwwwwwwwwwww
あんなに必死に工作しまくったのに、
大幅に議席を伸ばし大躍進する筈の立憲狂惨は公示前割れし
壊滅予想の自民は単独過半数超えどころか絶対安定多数の260超えるはで、
赤っ恥丸出しで脱糞涙目発狂憤死wwwwwwwwwwwwwww
反日バカサヨチョン地獄堕ち糞ざまあああああ〜〜wwwwwwwwwwwwwww
悔しい脳www 悔しい脳wwwwwwwwwwwwwwwwwwwww 最近はオブジェクト指向COBOLとかあるんじゃなかったっけ 何の事やらさっぱりわからんが、５ちゃんが爺さんだらけなのはわかった COBOLを倒すと言って出てきた言語
みんな死んだよ >>102
すまん現代の文明人は大量のデータ処理にはPythonを使うんだ filler pic x(20).
35年ぶりに書いてみた 別に動けば何でもいいんだけど、さすがにコボルをメンテできる人員を確保できないだろ
コボルを読める40代って存在するのか？
50代の連中の雇用を延長してメンテしてるのか？ >>109
４０代ならいるよ。
俺は秒でハンズアップしたけども。
宇宙船の信頼性なら
ソユーズ>>>>>>>>スペースシャトル 何かしらプログラミング言語を習得した人なら、
COBOLくらい1週間で使えるようになるだろ
別に大して難しい概念もないんだし COBOLだけじゃ動かんから最低JCLかshell知識は必要
あ、win系COBOLはEXEも出来たか >>8
ブラックボックスがなんでブラックボックスか分かってんのかなあ >>8
アセンブラ関係ないだろ。それはハードウェアアーキテクチャだ。トランジスタからやり直せ COBOLを支えてるのは信頼と実績だろ。時間がかかるから誰もCOBOLに勝てない >>17
ダイアログ画面をビジュアル系で作れるだろ サーバーサイドはjava、c#、python、cobolできるがもうcobolなんてやろうと思わんわ
あんなクソつまんねえ言語 楽しくプログラミングより稼げるプログラミングになっていくのか 今までのコスト考えると資産移行したくないのが本音だろう こんな夜中朝になにやってんだ
なんか財務省のコアがIBMだから日本はCOBOLのままなんだろ、たしか
IBMってもどこからか盗んでいった中古らしいが >>95
（１）FORTRANのコンパイラはコンパイル時には大文字を皆小文字にしてしまう
（２）リンカーでcでコンパイルした関数をリンクする際には関数の名に大文字が入っててもそれを
小文字にするようなことはない
（１）はFORTRANの常識だが（２）は知らなかった
ありがとう >>78
CASTLEがそんなにメジャーな言語だった時代があるとは、ホント、ちーとも知らなかったわ。 プログラミングなんてC言語を知ってればそれでいいんでしょ。 もういらねえよ
インターネットの母体であるUNIXとCの習得者が育たなさ過ぎる
基礎知識が無いから恒常的に非効率なことやってる
コボルの価値は認めて来たが
これが技術体系を壊し続けてて修復不可能になりつつある
コボル - JAVA の系譜が致命的に技術力低下を招いている 懐かしいなprosdure divisionってのだけ覚えてる >>114
shellはUNIXだからよ
そのコボルは本物のコボルじゃなくて
UNIX技術者がいないからわざわざコボル変換を入れて
コボル環境にしてる擬似コボルなんだよ
無駄な処理を一つ入れてんの >>17
同じだよ
出てこなかったっけ
MDIとSDIとダイアログベースがあるけど >>100
世の中には有名マンガ知らんやつもおるやで
俺もいまだにバキなのかバギなのか定かでない コボラーの人件費1000万位上を10年保証すると確約したらみんなやるのに
どうせ中抜きの最下層にやらせるんだろ？ 1990年代の入社時研修で常識としてちょろっと教わった程度で
その当時もほぼ同じことが言われてた
まさかその頃からCOBOL始めても一生食えるスキルにできたとはなあｗ >>137
ずっと言われながら残ってるけど
残ってる人間はそれなりに出来る人ばかりだと思うぞ
業務仕様に強くないとコーディングだけのコボラーは残れてない コボルって銀行のシステムに使われてて刷新もしたくないから渋々使ってるだけじゃねーのか 別にどんな言語で書こうと関係ないからなぁ。
他の言語に移植するよりも過去の資産を読み解いた方が早いと思うならやればいいだけの話だしな。
古いも新しいもねーんだわ。大体言語3-4言語やればハードルは低くなるだろ。 >>141
レセコンやってた人なんや
保険請求側やっててよく眺めてたな >>142
複数言語やる人ってそっちの業界じゃあまりいないんよ >>75
馬鹿でも読める馬鹿でもかけるなら
とっとと移植した方が早いのになｗ
現実的に動いて使われるシステムにするまでは大変なんだよ。 >>145
そうなのか。
違うパラダイムの言語を2−3やればかなり書けるようになると
思うけどな。1つの言語で1人で小さなシステムでも書ければまぁいいのだろうけどね。 >>142
クルマと同じだな
最初の3種くらいまではなれるまで大変だが、次からは1200-200０ｃｃまでは同じ、２−４ｔトラックは別物だった。
PCも９５さえ覚えれば大体いけた（８は訳が分からなくて、放棄した。２１１も３１１も３３３も経験したが）
FORTRANからCやアセンブラーに行くときは苦労した
女性経験がない大魔道師なので、そちらの比較はよろしく、 地方銀行が遂にクラウド勘定システムに移行仕出したけど
そこでもCOBOLとか走ってるの? >>153
サーバーで動かしていたソフトウェアをクラウド上で動かしているだけだから中身はCOBOLのままだよ 60代の元コボラーです。Fortran でも仕事したことあります。
COBOL をバカにしてはいけない。
金額計算、出力などの事務処理用に使える機能が標準でついてる。
SORT も標準でついてるんだ。
随分使ってないけど。 >>153
ごちそうさまでーすエミュ動かしてるだけにお金払って頂いて >>160
多分なくなんないよ
マスにはならんけど、ある程度の枠は残る、ずっと 金欲しければやればいい
全くつまらない仕事だけどな >>157
>>8
アセンブラとかマシン語とか
別にどっちでもいいわ
他人の作った決め事をなぞるだけの話だ
自慢する話じゃない ベーシック、アセンブラ、フォートラン、コボル
懐かしい響きだなあ >>166
センスとか関係ない言語だもんね
誰が書いても一緒になる >>167
S360
S370
S390
4004
6502
8008 >>165
オラはコード屋じゃ無いけど
学生の頃、マシン語とアッセンブラの違いって何よ？と
プログラミングやってる奴に聞いたら
大体同じだ同じ、と言ってたな 計算を中心とする事務処理システムの開発効率ならCOBOLはやはり優秀だと思うね。
他の人が見ても分かりやすいし、コメントなくてもなんとかなる。だからこれまで何十年も保守出来た。
Javaの方が10年先にどうなってるか？分からんな。 >>168
それがいいんじゃね。パートのおばちゃんでも使える。 でも学生がやっても意味無いんだよな
企業が欲しいのはCOBOLの専門家なんだもん 別業種の人用にその都度例えるとお仕事ごとに新しい呪文を覚える感じなんだわ
古代魔法になりかけてるのがコレ >>171
マシン語は0と1だけ、アセンブラは一応文字ベースだと教えられた。
往年の技術者は0と1だけ使ってコンピュータを動かしてた。 日本が発展できないのは西洋の作ったロジックを学習しただけでそれを自慢する
だから追い越せない
ノーベル賞ありがたがるだけで自前の価値観ないから自前のノーベル賞など作ろうともしないし作ろうとするやつをバカにする
マシン語アセンブラいって他人の作ったのを知ってるのを自慢するようなのはそのレベル 基幹系で他の言語とは比較にならない膨大な過去資産があるので、メンテ需要が尽きない。
なんだかんだいっても基幹系のリプレースは、よほどのことがないと経営視点で却下になる。 でも普通に素人でもロジック読みやすいからいいと思うけどな >>179
ルートだって虚数だってゼロだって謎呪文だけど
それがあるものとして考えようと前提を定義してその上に論を作り上げた
日本人はそんなのおかしいって言って作らない
作ったやつをバカにする
で海外で流行ってカネになるとみるやいなや飛びつく >>178
マシン後は言語と言うよりプロトコルみたいなもんか >>171 マシン語は16進数じゃなかたっけ？最終的には２進数で解釈するんだろうけど。 >>178
おいおい
あたりまえのはなしだ
8ビット16ビット32ビット64ビットってのは同時にスイッチオンオフできるってだけの
スイッチの数
0と1とか言ってないで
スイッチオンオフなだけよ
スイッチから線がその本数だけでてるだけ（あとアース）
なんも難しかないだろ
そのスイッチの組み合わせを言ってるだけだ みずほのシステムがアレなのはCOBOLから無理矢理違う言語で組もうとしたからじゃね マシン語は文字通り、CPUに直接命令
だから思考そのものがCPUと同じ >>190
そんな事は無い
処理に速度求めるなら依然として低レベル言語(やっている事は高度)が必要 >>184
プロトコル＝外交儀礼
国同士のお付き合いの決まり事
通信プロトコルに応用しただけ
通信用語
CPUには使わない > ID:C8Gfn/wl0
日本企業がダメな原因の証明
本人がいう日本が発展しない原因でもある >>189
アセンブラでOSを改造しまくった上にCOBOL
アセンブラがATMまでのすべての機器を制御
自前ですべてのレイヤーを制御
そうしないとトランザクションはけないだろ
他人の作ったものは信用しないしできないそういう時代のレガシーの再構築 >>196
ID:hOhJykTP0
ここは5ch
ゆうだけ只
言ったもん勝ち ぐーぐるトップがそうだからマシン語だアセンブラだってやってんのか? >>201
日本語わからなそうだな
言ったもん勝ちが通じないとは わからんもんだな・・・
Windows95の頃にも「先のない言語ｗｗｗｗ」って馬鹿にされてたのに >>202
アナリティクス側ならだ
トランザクション系でありえない
下の下のハードウェアレイヤーから通信機器からその先の機械までプログラマーが面倒見るんだよ 日本の銀行なら日本人らしく
ひまわりやなでしこでシステムを組むべき >>134
>いまだにバキなのかバギなのか
俺もバキ？キバ？どっちだっけ、となる これは、意味もなく、
未だにコラボを推進しているTV局への牽制か？
世間は、5年まえから
さめていますよ！！！！ >>204
先がないことには変わりない
知ってる連中がまだ生きてるからこうなる
全滅すりゃ否が応でもシステム全部新規に作り直ししてジエンド >>202
膨大なコストに釣り合うメリットが無いの却下。 >>193
高度じゃないな
ハードウェアに近いってことで
ハード側を理解する必要があるだけ
Webアプリ作るやつは使う人間の気持ちを理解する必要がある
高度かどうかはどれにもある そろそろCOBOLを重要無形文化財に指定した方がいい >>24
俺も意味がわからん
最後の一コマってなんなんだ？ PC88の頃のプログラマーが未だ健在で
70歳超えてるのに当時のゲームをスマホアプリ化やったり、リニューアルしている >>215
バカかどうかは関係ない
ハードバカはビジネスロジックが理解できずまともなコード書けないかも知れない 求む、COBOLからJAVAに移行するための技術者
こんな求人出してどうにかなるんだろうか コボラーだったのに企画や営業に回されて開発に戻してくれって懇願したらリストラされた。再就職しようとしたらコボラー要らん連発で建設会社入った。結構面白くてウキウキで重機使ってたら何故か社内のソフト開発に回された。現場に戻りたい。 >>219
藤井でもAIの時代
脳内よりも素晴らしいIDE 誰かが作ったレガシーシステムの管理に一生を捧げたかったらCOBOL勉強すればいい 昭和のIT技術に頼らないと
平成以降の日本には、IT技術って
何にもないからなあ。
恥ずかしい状態に落ちぶれたもんだ。 >>228
それは間違い
システム上から下まですべてを知らないとああいうことになる みずほ銀行のシステム障害のように、システムが大規模になり大勢の人が関わると
言語より間違いによるデバック率で障害が起こる。だから簡単な言語が必要になる。 西陣織や寺社建築みたいに伝統技術として
極少数の精鋭が生きていく世界になったりして まあ金の計算メインならCOBOLで困ることはそうそうないもんな だからダメなんだな 使う理由が使い易いだもの 敵にしたら同じこと >>178
今でも中で同じことやらせてるんだよ
プログラマーは
往年の技術者じゃなく今も >>139
それ
だから野良コボラーが美味しい思いしてるかというとそうでもないのよ
金融の業務仕様にくわしくないと実際まったく機動力なくて使えない
そしてそれはかなり社毎にローカルでありかつ法令遵守でもある
人材不足ならばソコソコ現場食ってて総務周り業務に詳しい妙齢社員をシステム部or保守部門子会社に出向突っ込んで
軽く全体システム把握させた後一からCOBOLやらせりゃいいんじゃねえの？とは正直思う
COBOLなんて難しいもんじゃねえ社員になる頭ついてりゃ根気と根性だけで行ける
数人突っ込めば誰かは適性あんじゃね？根をあげるのもいるだろうが
正直そんなに数が要るわけでもないしさ
下手に飛ばされる社外出向よりはいいですぅって奴居ると思うんだけどねー
外のコーディング屋さんのコボラー持って来たって全然使えないのよ
逆がいいよ社員をコボラーにする方がはるかに使える(寝言) ステップ数ご多すぎて、作ってて楽しくなくない？
もう、長文小説を読破するレベルの体力使うじゃん 未だにステップ数(笑)とか言ってる大手もあるぞ
2021年なのに
どうやら管理側がスクリプトの内容がわからないから、
ステップ数を管理する方式らしいな、中身の確認はしない、
それがジャパンクオリティ 仕様書？有るには有るけどスパゲッティだから読んで分かるかな？ コンビ名は2人が高校のコンピュータの授業で同じクラスだったことに由来し、「メンバメイ」(=メンバー名)、「コボル」(=プログラミング言語COBOL)、「スミ」(=出身学校の大阪市立住吉商業高等学校)、11(=岡村理世の出席番号)という意味合いがある COBOLだろうがCだろうがコンパイルされたらマシン語になるがな
しかし2020でもまだ需要があるとか
まさか学術計算とかはFOTRANとか生き残ってるの? さすがにFORTRANは無いだろ。
IBM系なら、PL/1が残っているかもしれないが。 「新しい」モノを売って儲けたいから、他のものを「古い」とラベリングする。
ぐーぐるが蔓延ってからロクなことがないな 金融だけでなく官庁もだそ。
入社して40年常駐して保守して定年退職する。
他のことがまったくできない、そのシステムしか分からない職人になってしまう。
いまどき数か月から数年でプロジェクトを転々とするのとは別世界やで。
自分は新しいもの好きで飽きやすいからCOBOLから逃げたけど、プロジェクトガチャが辛い。選択肢失敗したかも。 適材適所でしょ
JAVAにしとけばOKみたいなのが謎理論 入社1年目に某プロトコルのファームウェアの階層開発チームに入れられて擬似アセンブラのPL/Gて社内独自の言語使う羽目になったがわけわからんかったｗ 同時代のFortranはどうなったかと思ったら
Fortran2018があったｗ >>207
某役所ではひまわりで観測してる
さらにFOTRANで予報する 今でも大手数値解析(CAE)のソルバーソースはFORTRANが使われてるので、
ユーザーが拡張しようとするとFORTRANコンパイラをわざわざ買わなきゃならんのよ >>8
アセンブラちゃんと覚えないまま来たわ
カタコトは分かる
機会あったら勉強しよう Web系の言語で全てできると思ってる奴いるな････ >>251
おっさんばかりだからな
かくいう私もコボラーでね >>19
ランサーズやクラウドワークスで依頼して
直して貰えば？
派遣とか通すより安いよ >>254
CPUアーキテクチャ違えば違う言葉だから一つじゃないよ
ハードウェアの動かし方だから 絶滅すると謂われて、もう１０年以上
雑誌とかのコラムニストの見る目の無さが笑えるわ〜 バイト先の店舗のシステム？がCOBOLって店長が言ってた
PCのウインドウ？画面？を右上の×押して消すな壊れるからって最初に言われた 改良型コボル
コブラ をご存じか？
ネイティブでwebに対応。
ｖｂ言語 c#言語の取り込みも可能。 もう40年前に 大学で勉強させられた。
>>4
>がんばれFORTRAN PL/I 推奨の人々
FORTRANで よくプログラミングしたなぁ。
PL/1って IBMが開発した言語で
Program Language No.1の略なんだな。 COBOLからのマイグレが成功した案件見たことない 実行できる設計書が求められる限りCOBOLは滅びない
これを目指した簡易言語やフレームワークが出来ては消えてきたけど、
生き残り続けたからな。 >>268
PL/1 ＝ COBOL + FORTRAN
の汎用言語狙ってたからの名前らしい
40年前Pascalが最初だったわ >>264
言語とアプリのボロさはカンケーないけどな 如何にして簡単に誰でもミスなく高度なことを実現させることが命題という事を理解せずに、
こんな事も出来ちゃうんだぜとか、こうしたら何とかなったみたいな事を嬉々としてやり
それを一般的なものにしようとしない馬鹿がいるからしょうがない。 世界的にコボルはどうなってるん？
発祥のアメリカではもう残ってないのか？
1978年版ってのはCOBOL-78の仕様か
そんな古いのも残ってるのか >>272
C言語とか流行りだした頃から言われてたな
でも、なぜか今でも残ってる・・・もしかして、近年でもコボル使ってるのかな 記述が面倒臭いたけで他の高級言語と変わらんのでない？
入社時の研修期間中しかCOBOLはやっえないから詳しく知らないけどさー >>277
アメリカでもコロナ禍で社会保障関係のシステムがパンクしそうになって
コボル開発者を急募していたよ。
古くからITをやっていた国ほどレガシー遺産は多いだろうね。 俺が知らないだけだろうが、メインフレームでCOBOL以外の言語って使えるんだっけ？使えてたらちょっとは世代交代した気がする ﾚｶﾞｼｰｼｽﾃﾑの更新費用とか決裁できるtopとかなかなか居なそう >>173
事務員でもコーディングできる言語を目指して作られてるしね >>270
だって動くから
滅べって言ったって無理だよ
仕方ないだろ? 動くんだから >>276
Windowsのダミー向けだってあるみたいな
http://opencobol.add1tocobol.com/oc_gettingstarted_windows.html
ユニクスリナクスの人はここじゃない書いてある
>>277
商用ならイギリスのマイクロフォーカスになんでも集まって日本法人もある
このスレにも首突っ込んでくるかもね
マイクロフォーカスに聞いてわからないなら誰もわからない >>66
にわかすぎる、書くならdataかenvironmentだろ 動くっつうか既にそれで動いてるからな
他の分野でも似たようなもんだ、新しい環境や新バージョンが出ても当時のバージョンのまま極力変えずに更新してくれるとこありかせんかって仕事はわりとある ほんと馬鹿でもコーディングできるから、超使える言語
ケース文とかモジュールなんかは使えない部分だけど >>10
アメリカでもCOBOLはまだまだそこら中に残ってて、コボラー需要も日本に負けず劣らず多いぞ。 >>221
グラップラー刃牙って格闘漫画がある
原作者の板垣氏は格闘が同士の緊張と熱量を背景をグニャアと歪ませる独特の表現をする
それをコボちゃんの絵柄で再現した
つまり刃牙とコボちゃんの２つの漫画が分からない人には全く意味が分からないマイナーなネタなんよ >>281
すべて動くだろ
VMWareとかあるから言語だけじゃなくOSがなんでも動かせるし
ちなみに80年代にCも使えてたわ 座学で聞いたくらいの言語だわ
見たことない 金融のプログラムに使われてるとこあるらしいぐらいしか >>60
COBOLじゃなくても、何でこんなトンチキな事してるのかは注釈書いといてくれ マシン語はBASIC、COBOL、FORTRANの3種類があって時代はBASICですって情報処理の先生が言ってたけど教わったのはFORTRANだった
完全に忘れた >>262
絶滅するからと新人作らんできたツケがひどいことに･･･
現場が50代普通になってるぞ コメントアウトされた注釈が独自の略語だらけで解読できない >>72
バカチョンコンバータ作ったメンバーでスマン >>289
select-caseはpythonにもないわ
いややっと3.10でそれよりいいmatch-caseが使えるようになった COBOLから抜けるには給与振り込みを電子決済にする
とかになるのかな
今の置き換えを新言語で作るのは無駄すぎるよな 生粋のコボラーとか江戸っ子みたいな呼ばれ方してるが大半はリーマンショックで切られ急にJavaができるワケもなく自宅待機ののちクビ→年末恒例年越し派遣村の常連という厳しい人達だ たいがいの言語は雰囲気でわかるけどCOBOLと RPGはさっぱり ACOSでCOBOL走ってたからな〜
まぁ・・・しょうがないw >>276
懐い
でも開発はしてないんよゴメン🙏
オープン系って久々に聞いたような気が >>277
私がいた30年前で85になってた
78は実行ファイルだったな
前スレで教えてもらったけど最新は2014だって >>314
メインフレームの妖精コボラックル可愛いなw 老人会らしいスレだねえ
68kアセンブラで夢見てたあの頃を思い出したよ
今も変わらずコンピューティングは楽しい たまにCOBOL必要な時は探せば人がいたけどマジで高齢化していなくなってきてるのか >>323
実戦で使ったレベルだと若くても50代後半だから定年退職しちゃってる可能性はあるね
ITは定年が早いし そもそもCOBOLは「プログラムの文章化」を目的に開発された
その為仕様書などドキュメント管理が蔑ろにされた
一時期日本語COBOLなんてのもあったが非常に使いづらかった 今の人達ってプログラムの最小単位は電球の配線スイッチオンオフ命令っての知らなさそう。文系プログラマーばっかだし webパッケージやら帳票パッケージやらoracleやら組み込んで、COBOLもそれ動かすスクリプトみたいになってるからねぇ
言語的に言えばメモリの動的な確保や解放が出来ないぐらしいか制限ないんじゃない？
複雑な算術命令も最悪oracleの関数に投げればいいし >>332
今の需要はほとんど金融関係じゃないか？
汎用機用のCOBOLをWindowsサーバー用のCOBOLにコンバートする仕事もよく聞くし >>321
おれはLKIT-16でとりあえずマウントしておく COBOLなんてNEO-GEOが100メガショックで売り出してた頃に使われていた言語だものなぁ
凄い大容量って思ったら単位が「ビット」というオチだったけど >>319
RPGにかじりついたけど、何の役に立つか分からないので、すぐやめた。 >>299
そんな先生本当にいるのか
アセンブラ、マシン語、インタプリタ、コンパイラー、プログラム言語
その区別が滅茶苦茶 よ、み、が、え、る よみがえる甦えるコボラー 君よ掴め
まだ愛にふるえる心があるなら COBOL最大の利点は、誰が作っても計算誤差が発生しない内部BCD演算してる点。
JavaだろうとC#だろうとそこそこの連中がつくった物でもあるとき発生する小数点8位とかに突如でてくる0.00000001円の誤差等と丸めのせいで関連したどこかで1円の誤差がうまれる。
だから勘定系開発には未だ安心してそのあたり理解できない大多数に適当に任せてても理論通りに結果が出力されるのでマジで楽。だからね。MIZUHOなんて地獄だ。
COBOLはこれがないのでエンジニアスキルを平滑化するのには楽な言語ではある。それ以外は糞だが。 >>342
実はこの誤差って、金融にとっては致命的な問題なんだよな >>343
そう
で、数千から数万人月で移行するシステムで誤差無しで作れる会社は日本に数社あるかないか。
なのでどこにも作らせることができないのでCOBOL需要はなくなる見込みすら立っていない。のが今。
あと買える必要も無いってのもあってむしろ連携系が進化中という、まあ正常進化。
ただ既に後継者不足でどうするの問題が発生中で刺さる会社には引っ張りだこですわよ。ただしそこそこの技能や学歴で入れるようなところはそんなことしていないので、さらに人不足というね。 ４０年前の商業高校でCOBOLの授業があって、
当時「COBOLなんてもう使われないよ。」とバカにしてました。
当時の先生方に慎んで、お詫び申し上げます。 >>345
大丈夫
当時の教師陣も同じこと思ってました。なんなら未だにそう言ってる人大多数。 当時、YYMMDD形式で打ち込んで
2000年になったらどうすんだろ…と思ったが
まあそのころには全て入れ替わって使ってもいないだろとも思った Javaで継承だの再利用性だのオブジェクト指向だの言っても大多数のドカタさんたちは使いこなして無いしね >>344
なくす必要がないのに見込みが立つわけない。
技術者がみつからなくなる見込みは十分立っているが。 COBOLて今風で言うと市民開発者向け言語だな
ローコードで事務員でも書ける 浮動小数点誤差が対策されている事は羨ましいな。
金融関係では無いが、CにせよPythonにせよ組み込みの丸め関数は絶対に使えない。 中学一年生の頃に買ったカシオのポケコンにCOBOLとか言うのが付いてた
何する機能かさっぱりわからんかった やっと本音が出てきたな
新しい言語の丸め誤差が理解できる挙動じゃなきゃ使えないんだよ
新しい言語 >>348
COBOLの方が簡単正確に使えるからな >>355
カシオのポケコンにはCOBOLやLIPS機能が付いた機種もあった >>347
年金計算のシステム作ってるときに、鼻血でそうだった。
4桁修正をものすっごい数やったよ。
オフコンのエディタに置換機能がなくてまた鼻血が出て。
1990年代の話。 翻訳よりはプログラムの言語変換なんて簡単に
できそうなものだけどな。 >>361
90年代にそういうムーブメントがあったけど概ね失敗した
コーディングの海外発注も仕様理解の壁で頓挫 FEの"ソフトウェア開発"から"表計算ソフト"を外してCOBOLを戻せっての。 COBOL自体は高級言語
c++なんか目じゃないレベル 上の方で、誰々にも書ける、とかバカにしてますけど、
日本人らしいですね。
言語の問題じゃなく、使う人を見下すから言語も見下す。
古い、とかバカにしてますけど、
日本人らしいですね。
古いという言葉は何が悪いのか足りないのか具体的なことを何も指摘できない言葉、
いわば格付けをしているのと同じ。 何も指摘せず、単に格下と決めているだけ。
実際に動いているものを勉強しないと。 >>288
COBOLの生みの親がグレース・ホッパーっていうオバチャン >>97
大昔に投機ストールよけでnopしこたま書いたことある 組み込みレベルで仕事してて尚且つ今も現役だと探さないと見つからないだろうな
個人的に趣味でやってたレベルなら居ても スタンドアロン４０メガＨDD
８インチＦDD
なつい >>126
コンパイル後の関数名とかサブルーチン名はシンボリック名っていうけど、gfortran等はコンパイル時の
オプションで指定しなければシンボリック名の頭にアンダースコアを付けるとかしってるよね？
オラはコンパイル時に余分な事をしなけりゃならないのを覚えてるのが面倒だからcのソースのほうに
関数宣言時にあらかじめアンダースコアを付けることにしてる。
コンパイル後のオブジェクトコード内のシンボル名を知りたければlinux系だとnmというコマンドを
使えばいい。で、FORTRAN側が必要としてるけど見つからないってシンボル名はリンク時に
エラーメッセージで表示されるべ。
あと、引数はデフォルトではfortranはアドレス渡しとか。
昔はFORTRANからCの関数呼ぶなんてことは比較的よくやったけど、最近はあまりしないみたいだが、
ネットにはまだ結構いろんな情報があるみたいだね。 機密保持が厳しい金融系が多いためGitHubとかの公開の場には滅多に出てこないだけで、
実際には目立たない所でけっこう使われてるんでない？ >>97
昔DSPで携帯電話の音声コーデックのソフトをアセンブラで書いたことあるけど、パイプライン実行のためにNOP入れて調整しまくったわ。
後に開発環境で自動的に挿入してくれるようになったけど、手動で入れてた時は気が狂いそうだった。 >>375
ちょっと前にGithubにアップした土方が居たな。
断指有無ってキーワードはなかなかパワフルだった。 流石、左腕にサイコガンを付け不死身と呼ばれた男だけのことはあるな >>10
アメリカの大手生保なんかも
基幹処理はいまだガッツリCOBOLだよ >>375
全世界で2000億行使われてて、今も年間50億行増えてるそうだｗ ５５歳プログラム未経験だけどスーパーハカー目指してこないだエキサパンクスってのとシェンツェンアイオーっての買ったからよ
コボルなんて余裕っしょ COBOL自体は、くっそ簡単な言語で
一週間もあれば習得可能。
でもレガシーシステムの問題はそこじゃない もうそういう業務は、着いてけないジジイ用にでもしとけば？ >>375
大手金融の基幹処理や、
公共系の基幹処理にガッツリ使われてる。
膨大な規模で残ってる。
今は某大手保険のシステムに携わってるが、
基幹処理は全部メインフレーム＆COBOL。
この基幹処理を全部オープン系に移行して
オープン系言語に置き換えるとしたら
みずほ並とまではいかないにしても
相当な時間がかかるだろう。 >>388
絶対大規模な事故が起こるから責任者も自分の代じゃやりたがらんやろなぁ >>387
うちはFORTRAN77だけど、さすがに原初のではない。もう少し新しいのに移行しようと考えてる
間にいつのまにかmatlabメインになったので、多分死ぬまでFORTRANは77のままだろうな。
ま、立場的には職人が自分で使う道具を自分で造るような立場だし。 >>377
1回のパイプライン処理で演算と複数のデータ転送を行うDSPを設計して
コードを生成する並行命令対応のアセンブラも自作したけど
それを使ってソフトを開発する人のサポートにうんざりしたよ >>388
それをしたから、劇的に商品開発が早いとかメンテ費用激減とかが無いんだわ。
むしろ予想外れて寿命短い言語になった場合、COBOL以上の地獄が待ってる。 >>388
それをしたから、劇的に商品開発が早いとかメンテ費用激減とかが無いんだわ。
むしろ予想外れて寿命短い言語になった場合、COBOL以上の地獄が待ってる。 バッチ処理で流す分にはCOBOLやFORTRUNもでも
最新のRustやgoでも変わらんだろう。
そしてCOBOLは大体そういう用途で使われているのでは。 >>388 コード１行直すだけでテスト１週間かかりそう >>368
http://gracehopperfilm.com/
映画
それと「コンピューターとは計算する人間を呼ぶ言葉」だった時代の1953年キャサリンジョンソンたち３人の黒人女性の物語Hidden Figures（影の重要人物）日本語タイトル「ドリーム」https://wired.jp/2017/09/28/nasa-history-hidden-figures/ >>348
JAVAのデシマルってCOBOLの少数位置と合わないんだよ。
なので計算全部に四捨五入が必要なんだ。
ここで計算機誤差の問題がでても来る。 >>396
COBOLの問題はまさにそこで、
カラム位置に文法的な意味があったり、
88項目みたいに構造の階層順を表わす
指定位置が突然特殊目的になったり、
さらに現代的なユニットテスト等のツール環境に馴染めないとか、
CIに向かない(言語サポートが弱いとか)、
マルチスレッドプログラミングができない
(ランタイム任せで優秀なコンパイラがあるとかないとか)
本当に色々現代の文化からとりのこされているのが
問題であって、だからCOBOLerなんだよ >>395
とても間違ってます バッチは大量データを一回で時間かけてやる
オンライントランザクション処理は少量データの大量トランザクション処理を全国からのATMからの引き落としにその人にだけ対応してるかのように素早くやる
わかってますよね
そのためにこそコボル
コボルこそオンライントランザクション
IMS DB階層構造DB（もとアポロ計画DL/1で現代のSQLのハシリ）
をCICSかIMS DC（Data Communication）って言うオンライントランザクションマネージャーを使ってコボルやPL/1で書いた
特にIMS DB/DC （OSはMVS）組み合わせは銀行のためのもの
富士通日立が欲しかった理由
IMS DCはいまIMS TM
コボルは当然デイリーマンスリーとかバッチもやるけどね 80x25のCUI画面のCOBOL開発ってまだあるのかな
あれは事務員誰でもとはいかん 昔、高校で習ったな。
FORTRANに比べCOBOLは覚えやすかった。
授業はさっぱりわからないから、マニュアルみたいな教科書で独学した。
実習は、教室１つ使って置いてある汎用機に、紙テープでソース読み込ませコンパイルしてた。 どんな言語でも基本設計者の頭がnullだと現場はGO TO 地獄 みずほのサグラダファミリアの完成は遠そう、遥か彼方 つうか元々はパンチカード入力やからな
だから80カラム固定
SYSINやらカード入力も同様 >>405
ぬるぬるHEAVENなら聞いたことがあります コボラーおじさんはいつまでも高待遇で食いっぱぐれないか
うらやま >>407
別にパンチカードが先じゃないと思ってたらそうだったのね感謝
https://en.m.wikipedia.org/wiki/Punched_card#IBM_80_column_punched_card_formats_and_character_codes
もともと会計処理機屋だったIBMが入力処理効率化でパンチカード機も会計機の一部として売り始めてそこで決めた入力フォーマットか
他社との法定闘争とかあったとか書いてある
50%超えのシェアだったって
コンピュータ以前の会計処理入力のデータ入力の定型化だったのか いや、言語そのものよりも
COBOLの仕様書を書くとが面倒だろ
今更、HIPOで書くのか？
昔のCOBOLのように
見積工数もステップ数で見積もるのか？
言語仕様が、どうのこうのいう奴が多いが
開発のプロマネをやったことないのか？ COBOLは誰でも理解出来る簡単な言語だから、情報処理技術者の裾野を広げるのに大きな貢献をしてきた。
今の言語は賢くないと無理。
ローコード、ノーコードに行け。 >>395
rust や go こそ要らないものでなくすべき >>413
言語はどれもこれも簡単だよ。
難しいコンピューター言語って存在しない。
使い熟すのが難しいんだ。 COBOLは情報処理試験でやったな。
PTOSというOS使って勉強。
当時は10パーセントくらいの合格率だったが高２で一種を受かった。
結局、就職には何の役にもたたなかったけどw >>413
これはある。
COBOLはクソ簡単だから
コーディング要員だけなら
若手に1週間でも仕込めば習得可能。
でも、開発現場で欲しいのは
環境周り（メインフレーム）に精通していて、
かつ、ターゲット業務に詳しい人。
今、COBOLが残ってるシステムは
ほぼ基幹処理システムだから、
その基幹業務に詳しい人が求められる。
COBOL系求人は、
メインフレームでの開発経験と
ターゲット業務開発（特に上流）経験
が
必須となってるのが多い。
そういう人材がどんどん引退していってるし、
メインフレームや、
ターゲット基幹業務なんて
机上で勉強しようがないから
一から育てるのも困難。 >>417
今はメインフレームなんていうの？
エンタープライズサーバーじゃないの？
OSもUNIX？ >>414
誰かがC++の尻拭いをしなければならないのでな。 >>277
コボルで構築した古くからの顧客データーがあったとして、
それを全部コンバートして使ったりしないのは当たり前
レガシーマイグレーションである以上コボルは残るのは
日本もアメリカも同じ。ただ、アメリカの場合、レガシーマイグレーションしたときに
古い機能は削除するが、日本の場合、顧客が強すぎるので
無駄な機能でもいつまでも残したりするのが違うかな。 結局さ
オブジェクト指向が間違ってたんだよ
生産性が低すぎる 15年前定年後もじじいが触ってたつらんから会社すぐ辞めてもうた >>350
全然分かって無くて草
後継者がいなくて技術者がいなくなるのが見えてきてるからなくすことができるところはガンガン無くして言ってる。
肝心要はまだまだCOBOLなんで当面技術者不足が続くが・いつまでもこのままでは良くないと業界内でもずっといわれている。 >>348
こういう馬鹿が勘定系のシステム開発に関わるとまあほぼ失敗する。残念だったな。 >>407
SYSIN DD * なんて知らない。
打ったカード落として順番わかんなくなったことなんかない >>425
動いているものをなくす必要がないんだよ
技術者を少し増やせばいいだけ
ガイジンはさっさと帰れ >>426
えっ、.netやSQLサーバーで精度保証されてないんか？ >>422
なんかはあったと
ちょっとまえにちょっとアプトしてためしにちょっと動かした覚えが
それ以上はわからないw >>412
そんなことが簡単にできればとっくの昔にきえている。
構造上の問題で簡単には置き換えられない。
出来なくはないがありとあらゆる箇所で、基本的な計算ロジックすらルール通りにメソッド利用して全部起き変えられりゃいいが、一人でも普通に書けばええやん、とかアホなことやる奴がいたら、破綻するんだよね。
しかもその場合、たいていはうまく動くが全然イミフな箇所の積み重ねで誤差が出てきて、探すことが困難。
そうするとまた馬鹿がその誤差を無理矢理吸収するロジック組んでどんどん手がつけられなくなる。
まあこんなのはMIZUHOに関わったことがあったり、なんらかの勘定系システム開発した人なら分かっていること。
出来なくはないが多大なコストがかかる。新規構築ですら破綻してるところあるからな。ただまあ数億円しか扱わないような一般企業向け勘定システムでそんなことはあんまりきにならないけど、地銀以上のクラスやキャリア系インフラ系はヤバいよ。
そっと蓋してCOBOLのまま置き直した方がいい。
本当にこれはマニュアルとかセオリーしかしらない未経験な人では分からないと思う。
数百人が何ヶ月もかけて作るシステムとかほんとまじでなにやらかしてくれるのレベルの奴多すぎて無理。
COBOLのまま、なら何も問題が起きないから楽。それだけのことや。 大手金融機関や公共機関で大規模なＣＯＢＯＬシステムは残っていると言っても
ＩＯ部分は既に最新化されていて計算と事務処理だけのアプリに閉じ込めているから
時間の問題ではないかな
でも、みずほみたいに取り残されたヤバイ金融機関や公共系も少なからずいるのかな？ >>428
馬鹿なの？その後術者ががんがんへってきてんだよ。
今おるやつらは軒並み40後半から60手前だ。
若い奴は皆無。
ハードやOSのリプレースで旧COBOL動かなくなってきてだわ。未経験なのか？システム設計構築したことなささうだな。
動いてるものがあっても、リプレースせざるを得ない状況なんてアホほどあるんだわ。そのための新しい環境のCOBOLがリリースされている。
今後技術者は減る一方で確保なんかあと何年かでできなくなる見込みだから困ってんの。 まだ分社する前のＮＴＴでやっていたＣＵＳＴＯＭは今はどうなっているのか知りたい
今月の過労死がコロナの様に発表される地獄だったが >>433
いやまぁ時間の問題だと思うよ。まだまだかかるから技術者居なくなる前に全部置き換えなきゃだから必死よ。
無くしていかないと立ち居かないことがわかってる。
おっしゃるとおりコアロジック意外置き換えられてきてるからね。
少しずつリプレースすすんでる。 若いやつ皆無って言ってるけど金融系のCOBOLは若いやつ結構いるぞ新卒もいるし >>437
まあ日本全国みたわけではないから井の中の蛙かもしらないけど、そのままコボラーで残る奴ほんと少なくね？
大抵将来性に不安だとかで転職してっちまう。
超大手出そんな感じでいつも新人は確かにおるけど超ベテランはもう時間の問題でいなくなりそう。
顧問とかで60過ぎても来てくれる人がおるレベル。 あーうん、おれ何熱くなってんだせっかくの有給5chであつくなるおっさん……すまんかったわ。 やっぱり、誰でもプログラミングできるって奴が強いだけだろ
特に主言語英語圏なら尚更 >>436
安田火災 NTT 三井生命 あいおい損保と渡り歩いて
最後は損保ジャパンと日本興和損保の統合で
ＣＯＢＯＬのコアロジックだけの封じ込めだけはやってきたが
今も存続しているのか知らんｗ もうさー、1から作るの嫌なら
どっかのネットバンクシステム買ってデータ移行した方が良くね？
最近のシステムなら昭和以外対応できるだろ >>395 とか
9項目もCOBOLのほうに桁数の制限があったと思うし
現代の64bit環境考えるなら、実は整数の大きい桁の問題はたいしてないのかもしれないなあとは思う。
むしろレコード構造でああやって構造体のごとく
記述できる言語じゃないとちょっと厄介？
すぐ長くなっちゃうからこの変にしとくかw
対応方式の仕様をちゃんと作れば
わかんないけど、実数の丸め処理の問題もそれぞれの言語の処理方式を見誤らなければ、受け側の言語で対処するように書くことはできるはずだとは。
まあ、オブジェクト指向のオーバーライドみたいに入れ換えができないようなら、関数を導入するとか
記述が多少煩雑になるかもしれないが、
金融とかならゆうてもそんなに広範囲に実数処理が必要なとこはないんじゃなかろうか
科学計算なんかだと、受側k
asisでおｋとか、手間のプロセッサのnativeな浮動小数点に会わせて精度上がったらそれでおｋてきな？ 近未来が舞台で
そのころすでに忘れ去られた言語であるCobolを使って
滅亡の危機にある人類を救うプログラマーの映画が作られてもいいと思う >>87
Environment DivisionのFile sectionでDD名を記述して
JCLにてDD名にデバイスを割り当てる。
PCだとどうなるかは知らない。 >>442
データ移行出来ないから１から作ってんだよ 脱メインフレームや脱COBOLでJavaだなんだって言われて久しいけど
全然進まないのはやっぱJavaがだめだからなの？ >>447 とか
EBCDICからASCIIに移行しただけでもソート結果が変わったりするし
現代は、多バイト文字がUTF-8だったりするし
昔のJISだと、SI/SOとかもあったり？
X項目なのかN項目なのかｗ
そもそも異言語異文化とかが水平的差異とすれば、
時代の変化のほうは垂直的差異かなんて風呂敷を広げて結局スルーされてみるテスト 単純に対応変換すればいいと思ったら、
３バイトばっかりになって、項目長に収まらなくなったでござるの巻 最近は需要が多いスマホ用のアプリ、特にゲーム系なんかは製品寿命が短いし、開発元の会社自体の
寿命も短い、最新のハードや普及機の搭載メモリの量といったハード環境に対応という辺りで
ドンドン新しい言語を使っていけばいいって感じか。
そういうソフトに対し一旦開発したらその後数十年はアップデート程度で使っていくソフトは
数十年後も残ってるような言語を使うと
Javaもなんかずいぶんセピア色化してきたような >>434
知恵遅れ
動いているCOBOLを無くすのと技術者を少し増やすのとどっちが実現し易いと思ってるんだw コボラー多いところって、
プロマネの仕事が「如何に新しい事を全て断ってくるか」になりがち。
若い人には面白くないよね ってか、今時のPCのプロセッサなんかだと、BCD命令は、廃止になっちゃってんでしたっけ?
（下位互換部分だとまだいきてんのかねえ？）
しらんけど、一方、メインフレームとかだとCOBOL特化で、ぱっくとでしまるはおろかアンパックの演算
(comp句とか書かなきゃデフォルアンパックでしたっけ？)
も直接扱えたり速かったりするんかね？全然しらんけど。
移行して性能差がどうこうという話になるのかならんのか全然わかんないや
想像でかいてみたw >>451
ゲームの中身は新しいものなんか何1つないけどなw >>453
若いとき面白がって新しいことやったつもりでも、大半は過去にされていたことの繰り返しだろ。 別の言語を使うと効率化できるほどの複雑なことは特にやってないのだろう >>445
ジョン・タイターがIBM5100を買いに来てるんでネタ使用済み
>>437
俺んとこは50代メインで少し40代だよ >>440
英語英語いうやつ多いけど
英語じゃないから
あいうえおと漢字でかいてあったら楽だと思うか？
記号の使い回し方を知ってるかどうかだけ
逆に勝ってにぺちゃくちゃって感じでテキトーに書かれること考えてみような >>460
うちのところも
メインフレーム系基幹処理チームの
年代構成はそんな感じ。
40代前半を指して、「あの若いのが･･･」
とか言ってる。
若いのがたまに来ても、長く居つかない。
オープン系周辺システムチームだと
平均30代くらいで、
40代以上は、基本もう管理系職種ぐらいしかいないから
えらい違いだ しかしリストラしまくっといて今更だよな
みんな、とっくにジョブチェンジしてるっての 金融の足元を支える文化財か
そこには新しいものなんて要らないな >>456
どっかがヒット作だしたら似たようなのがワサワサでてくるが、あれって著作権とか特許にひっかからないのかね。
それともそんなことであーだこーだやる暇があったら次作に取り掛かった方がいいという判断なのか。 >>452
知恵遅れは君。
コボラー増やしてみ。そんなことはとっくの30年前からコボラー作れ場なんとかなるやろってずっとや出てきてる。
それから30年立つが減る一方
俺以外にもレスしてる人居るが、現実はどうにもできない箇所だけCOBOLのこして周辺はJava等へ置き換え。
名古屋銀行は一部C#も使ってんだっけか。あそこ勘定系システムをMS SQL Serverで立ち上げて成功してる。かなり短期で成功してて素晴らしいと思っている一つ。もう昔の話だけど。
コボラー増やすなんて無理。あとCOBOL自体本当にこの先新OS対応してくれるかもわからん。動いていようが何だろうがいつかはリプレースすることがどこもかしこも決まってるが、設計も海発もできるところが全く足りない。
はたらいたことないのかな？現実そうなってるし30年前から現在に至るまで超がつく誰でも知ってる大手バンク系、保険系、インフラ系もそんなんやぞ。ワイはそこはしごしてるからな。ああもうやふみおわっちまうやん、外真っ暗やなにしてんの。 >>423
馬鹿にオブジェクト作らせたって、まともなオブジェクトになる訳ないじゃん
元から破綻してんだよ 新規開発でないとおもわれる
この辺について、あのブランコの絵で的確に表現してくれる人はいないんですか＞＜ >>468
なくす必要がないんだよw
ち、え、お、く、れ しらんけど、ふと思たけど、COBOLとかその他の古いことに特段のしがらみがないかとも思われるネット銀行とかはどうなんだろうとか
まあ、初めから新規のシステムじゃないかもか全然わかんないけど しかしなぜなんでもかんでも2進数で処理したがるのかねえ。
10進の固定小数点で32桁くらい扱えるような型を用意しろよ。 田原総一郎「COBOLを使ってるから年金問題が起きた」
いまだにその理屈がわからない メインフレーム＆COBOLを
リプレースしないと
えらいことになるぞ〜って
経産省も企業のケツ叩いてるよね。
2025年の崖とかいうキーワードまで作って。 >>473
少なくともここ10年で新規に作られた金融システムは、ほとんど.NET（VB.NET）だろうね 金融機関はメインフレームだけでなく
ＰＣもWindowsXP ７多数だよね >>473
新興系とか、金融でも規模が小さいところなんかは
基幹処理も含めて、フルオープン系＆オブジェクト指向言語で
組まれてるシステムもある。
かなりレアだけど。 >>476
経産省が解体されてもCOBOLは残っていると思うw >>480
あ、レスありがとう
じっさいのとこ、ずばっとjavaとかだったりするんすかね？
それをともかくとしても、じっさいのとこ、どこもかしこもクラスつくってオブジェクト指向のpgしてるのかとはどうなんだろうとは思ったりしますが >>485
オブジェクト指向じゃない開発なんて皆無やで。
そんなのはすでに常識というか当たり前になっているんでオブジェクト指向なんて言葉も出てこない、から余計そう思ったのかもしれんね。
Javaが幅きかせてる。糞みたいな独自ライブラリ作りまくっててほんと目がくらむけど。
C#/VB.Netもまあまあるよ。言語違ってもやってること同じなんで何ら大差ないけど。連携側システム都合に合わせて存在してる。 >>450
UTF-8との対応は大変よね
固定長レイアウト変換が手作りになって手間増えとるやんと COBOLのように、文系の事務職、役人でもプログラミング可能なように設計された言語が
いまこそ必要な時代になってるだろ。
訳わからん関数だらけの、スパゲッティコード書かれるよりは、可読性の高いプログラミング仕様になってれば
文系の事務屋でもコードが書けるってのは大事だよ。 数学は文系科目
プログラミングも文系科目
アルゴリズムは文系の理論 おまえらが見下す「文系脳」で自然科学の知識をアンキしただけのやつらが大半
それが日本人理系と朝鮮人理系 >>488
言語仕様にそもそもオブジェクト指向が無いgoなんかもあるぞ。
よって学習コストが大変低い。 >>488
ありあり
まあ、その形容通りだとすると、オブジェクト指向が本当に生かされているんだろうか？とかおもわないでもないっすが、
まあ、仮にもしも中身をみせてもらうことがあったとしても、わちきではとても評価したりするスキルはありまへんが＞＜
うまくいえないけど、誰か上のほうでちらとしてたレスからちょっと想像をふくらませると、どんぐらいがオブジェクト指向のセンスがあるのか的な？とぼんやりとうわなに みずほ銀行の鯖を管理できる人間がいなくなったから、
基礎から始めてスパゲティソース理解できる人材育てようとしてるのか なんかもういい仕組みができてるのかは知らないけど、
今動いてるこのプログラムの本物のソースはどれでコンパイラとコンパイルおぷしょんとライブラリはどれですかー
まあ、なんかツールで見れば相当の情報は、あるんだろうが、 リモートワークのおかげでリモートでできるならおれがリモートでサポートしてやってもいいぞ
それなりの給料くれるならな netCOBOLの本読んだ時は、お前らこうまでしてCOBOL使いたいんかと呆れたわ >>495
いまどきオブジェクト指向じゃないほうが学習コスト高い どんなに新しい言語を作っても、たくさんの可哀想なエンジニアを操っても、COBOLから離れては生きられないのよ！ >>432
メソッド利用して無いものは自動的に弾けばいい
言語によってはコンパイルすら通さないようにできるし >>419
メインフレームとUNIX(オープンシステムと呼ばれる事も)は明確に区別されてる。
メインフレームは足回り(通信系)は別プロセッサで制御や処理をするから多数の処理を安定にこなせる。 メインフレームでさえ死後に近いのか 驚きｗ
じゃあ汎用機なんて化石か >>513
現場だと「ホスト」って言うことが圧倒的に多いけど 言語仕様とかの技術的よか、要求仕様が問題なんだろ。
「このシステムは何をやってるのか」「ここを変えたらどこに影響するのか」とか。
既存のシステムが巨大かつ複雑怪奇過ぎて下手に弄れない。
かといって要求仕様を洗い出そうとすると、みずほになる。 >>515
>かといって要求仕様を洗い出そうとすると
「新しいのを作ったら、過去はデータ以外全捨てして乗り換える」
をやるしか出口は無いんだろうね
「以前と同じに…」が出た瞬間全員爆死が確定する 何となくソフト会社に入って、大した志も無くCOBOLやってた57歳。COBOLで何とか70まではやりたい。ろくに年金保険料払ってないので、老後の年金がありませーん！から。
自分より10歳下の人は苦しんでいたのに。 >>513
古い日経コンピュータの見過ぎ
現場はホスト ヘタにPCに移行しようにも、コード体系がUTF-8じゃなくてEBCDICだったり、
漢字コードも別物だったりするから、ソートかけたりするとPCと全然違う結果になるだろうな
データ突き合わせて同じデータが漏れなく出ているかどうか検証するのが大変そう
プリンタもフォントのサイズが違ったりして、専用帳票の位置合わせも必要になるだろうし 「COBOL使えます」
「BASIC使えます」
↑
印象そんなに違う？ 計算がしっかりしてるからやめられないんじゃねえの？
物が多すぎるのもあるんだろうけど ＣＯＢＯＬ始めてから４０年以上経ったか
パソコンも無い時代だったな
紙カードや磁気テープ持って出張したわ おかんはカードパンチャーだった
そのおかげでパンチという概念はスッと入ったw
COBOL生きてるよな多分。昔いた会社で聞いた話では
プログラム内にデータ書き込んでるとか言ってた
取り出す術がないらしい（金と時間と人がいれば可能だが誰が出すw ドクターストーンで先月あたりはまさにマシン語の復活やってたで
おっちゃんらにおすすめ NECのオフコンではCOBOL4ってのもあったな。 >>504
さっきぶらぶらみてたら、いつコボルだかしらんが、コボルでもポインタとかあって
そうまでしてコボルでかくのかとあたまがぬるぽ >>531
マシン語がおっちゃんはカンケーないだろ
ハードウェア直接触るやつなら知らないといけない
カーネルメンテしてんのがジジイだけなら世の中終わるわ 「Scratch」から「Python」そして「MQL4 (MT4)」まで出来るのが導師。 >>534
おっちゃんらの子供の頃はハードウェア直接触るのが普通だったんだわ
子供の小遣いではアセンブラとか買えないからマシン語でプログラミングしてた 夜のなると定年以降のおじいちゃんの書き込みで
知識得ています
もっとおながいします >>520
あと13年くらいならまだCOBOLは残ってるだろうし大丈夫では？ なんだかんだコボル技術者はいまでも必要だからな
クライアントの60代のシステム部員のおじさんが引退させてもらえないと
半分自慢気味に嘆いていた >>534
フォローありがとうw
>>534
ドクターストーンっていう原始世界から文明を作る漫画があって、
コンピュータをゼロから作る話があんのさ。見てないならぜひ >>536
フォローありがとうw
安価ミスったorz
おっちゃんらの話は楽しいから好き >>294
たしかにクラップラーってのがわからん
新聞に載るくらいだと思ってたのに誰もわからないのでは？ しらんけど、ゆうても、OSつくってる部隊とかは別段、メインフレームとかで、実用するアセンブラのpgかいたことある人とか、めったにおらんちゃうん？
そうでもないもん？ まあ、基幹システムではまだ動いててメンテナンスしてる連中もいるらしいとは聞く 今年５５歳ですけど
おかげ様で食うに困りません
僕が新入社員の頃は
情報処理の国家資格は４種類で
第一種情報処理者の手当一万五千を
もらって喜んだものです
コボルを学べば一生困りませんて
セミナーのおねーさんが言ってたけど
本当にこうなるとは思わなんだw
まあ、６０ぐらい迄は大丈夫そうだから
後はゆっくり暮らすとします 30年前に入社した頃は「時代遅れのCOBOL部署に配属されて可哀想」言われてた
まさかこっちの方がフリーになっても仕事に困らなくなるとはね ＣＯＢＯＬで特に金になるのはＰＬ ＰＭ経験して
ＣＯＢＯＬソースを解読して新システムの最上流行程でＳＥに設計指示する事
その後は若手にＣＯＢＯＬ指導する事
お手伝いだけで時給５０００円以上貰える ゲームだと「それは裏技」で済むバグもCOBOLの仕事じゃ新聞ネタになっちゃう COBOL教えるのよりユーザー（仕様書チェックする側）に業務教えることの方が多いよな >>553
自分の経験ではそれはないな
業務を熟知するユーザーが知りたいのは
どこまで正確にシステム側が反映しているのかを知りたがっている ＣＯＢＯＬソースはメンテされ続けてきてもドキュメントが放置されている事例が多い
ＣＯＢＯＬソースを解読してドキュメントを最新化させる需要はある なんでCOBOLを完全に置き換える変換コンパイラを誰も作らねーんだ？
70年前の技術に追いついてないのかよ >>556
ほとんどの場合、問題はCOBOL言語そのものが起因ではなくて、
仕様書が無いとか、今動いてるシステムと整合が取れてないとかそんなのばっかり。
COBOLから他の言語へのトランスレータは既にあるけど、上記の解決にはならない。 Javaバイトコードを吐き出すCOBOLコンパイラは出来ないものかな。 >>559
ＣＯＢＯＬからＪＡＶＡ変換ならどこの会社もやっているよ
広告もあるから見てごらん ソースの置換なら簡単
でもＣＯＢＯＬソースがどんな業務をこなしているのか
システムを知らない人間に判る様な日本語に変換するのは難しい
大雑把ならできるけれど なくす必要がないのになくせなくせって何なの?w
なくす必要がないんだよw
#gnucobol は ソースをCに置き換えるのと同じな 結局、COBOLが実走してる整数演算部分を弄りたく無いからね〜
わかっててみずほ事案になりたくないでしょw 何度でもよみがえるさ
COBOLこそ人類の夢だからだ もうソースなくしてどう動いてるのかよく分からんのです >>561
銀行で例えたら良くね？
スマホ前はATMの向こう側作ってたんですよって
言ってたよ
お店でバーコードをピッてやるでしょ？
その後どうなるか知ってますか？
その仕組みを作ってたんですよ、とか 銀行って何がそんなにむずかしいの？
台帳でしょ？そんなにむずかしいか？ >>565
大昔あったよ
夜間バッチだったので
元ジョブとインのデータとアウトの成果物が
まったく同じ新規ジョブを作った
たまたま客先から同意を得られたのでできたが
もし客が新規で作るなとか発狂したら詰んでた >>567
みずほのことだったら
システムそのものより客が…😱 >>563
芸術作品模写して別の芸術作品作れだからな
もうそのままにしとけよって話な訳で >>558
大昔やった修正でコピー句レイアウトが紛失で
ソースも注釈が無く不明ってのがあって
まだ古き良き時代だったので
元実行ファイルを使ってテストデータを流して
ダンプを見て変更箇所を特定し
Redifineをかけて修正したことがある
もう処理そのものが無くなってると思うけど
あの類は単純変換しても失敗しそう >>558
>>561
ほんとこれ。
だから、現場に長くいるヌシの脳内仕様頼りになる。
あとから現場入ったやつは
ヌシにペコペコせざるを得ない。
おまえらがドキュメント整備してないせいで
こんなことになってるんだろーが！
という怒りを抑えながら。
俺がいた現場では
一次請負の最大手ベンダーのPMよりも
業務仕様熟知してる1BP要員のヌシのほうが
立場は上だった。
こういうヌシ達もたいてい高齢だから
このへんが抜けたら、
本当にどうするんだろ。 >>573
そのヌシもドキュメントなしで引き継がされてたりな
新規に起こすとして内容を誰が担保するのかという問題が残る 別に情報処理システムに限らず、日本企業というか日本人集団はそういうヌシのｽｸﾂなワケよ
その企業でしか通用しないやり方をあちこちに仕組んで自分のプレゼンシーを高めている
日本企業の業務が明らかになるとは思えない >>573
せめて作業用にフロー作っとこうと手が空いた時にJCLから起こしてたらPMに見つかって「そんな作業は発注されてない、勝手するな」と怒られたことあった メーカーのマニュアルが最強の解説書。
富士通のCOBOL85は岸壁なマニュアルになる。 >>546
昔の中小の銀行のシステムは、COBOLでアセンブラのサブルーチンを呼んでいた >>546
昔の中小の銀行のシステムは、COBOLでアセンブラのサブルーチンを呼んでいた 色んな人が書いてるけど
cobolそのものが問題なんじゃなくて
あの時代の開発手法そのものが古かったんだよ
gitもなんも無い時代にファイル名だけでバージョン管理してたし
差分抽出もコードレビューもテストドリブン開発も無し、
「動いてテスト通ればOK」だけの闇鍋上等開発やってたんだからどこも
そんな時代の機械はとっくにリプレースされていったけど
変化をとにかく嫌気する体質の金融業界ではゾンビのように長く生き続けてしまった なんか二回書かれた。ごめんなさい。
ともかくアセンブラがわかるに越したことはなかった。必須ではないが。 みずほ案件も結局はcobolだけじゃなくて
アセンブラの箇所がそこら中にあったんだろね
それを電卓だけで見積り立てたい上に
リファクタリング完全否定な連中が
どんぶり勘定積み上げていったらあの大惨事になったんだろう >>581
何でそう書いたの？ってのが分かる内までの話よ
gitは道具として悪くないが、なぜそう書いたのかまで分かる物じゃないからな >>10
日本を辱め貶めしたいのだろうが…
日本だけじゃ無くアメリカやヨーロッパでもなんだよ…
中国はどうしてるのかは分からん…期待したいね
伝票処理が無いはずは無いからw >>584
それはコメントをどう書くかの話かな
どんな道具も使う人次第なのはどの言語、インフラも変わらず
gitはちゃんと使えばかなりの部分を生きたドキュメントとして残せるよね
もちろん使う人次第で VOS3上のオンライン処理用COBOLソースコード見たのを思い出したわ…職人技だわw
BASICのスパゲッティにCのごった煮を合わせたような感覚だったよw
可読性なんて皆無w
いちよう論理設計書と物理設計書にコード設計書は有ったから良かったけど…コードだけ「ポン！」と渡されて保守してなんて言われたらギャン泣きするよwww 大手銀行 生保 損保でもＣＯＢＯＬで組むと
非効率（処理時間が掛かる）な部分だけアセンブラーで組んでいる
今もＲＯＭの様に一切変更を加える事も無く埋めたままの地雷がある アメリカの国防省は一度脱COBOLを試みて結局断念してCOBOLを使い続けているんだっけ？ >>588
逆でスピード命でレスポンスタイム命だから全てを自分たちでコントロールするためOSから通信機器からその先のATMまでの間の全てをプログラムできるようにする
OSはもとより通信の全てを
そのために機械を直接コントロール
OSもNTTも全て
その我が社フレームワーク我が社プラットフォームができてプログラムのした半分も全て機械語アセンブラで組んであって最後の最後のビジネスロジックだけコボル
コボルは表面の皮部分だけ 余計なシステムのループなどあったらシステムを改造
通信とコンピュータの一切のビットのムダは許さない
ビジネスロジックのコボル部分など10000分のいちもないだろ
通信だけのプログラム部分だけでも100人きかないだろ
データベースだけでもだろ
コンピュータOSなんてほぼ自分たちが中身をくり抜いて自分たちだけのためにしか動かないように絞り込むexitルーチンのお化けだろ 一円の違いがあったら家に帰れない文化
1ビットのムダがあったら家に帰れないんだよ
オブジェクト指向とか皆無の世界
Cでビルトインで以下にバイト数削減するかの世界以上のシビアさ
カネが消えたらどうなるよ
レスポンス要件どんだけよ >>593
許さない
通信会社も下っ端として改善させる >>595
メタルだろうがファイバーだろうが物理遅延が有りますがな(笑) >>597
そこまで見る話
チューンできる限界まで
人がコントロールできる限界まで
ハードまで COBOL使えるけど人間関係処理がウンコだから仕事いけないわ x.25が思いの外長生きだったのもこの影響なんだろか >>601
x.25パケットなんてあたらしいほうよ
そんな標準がなかった時代のオンライン
1964年オリンピックだろ >>603
そもそも専用線だからなX.25の役割じゃない データベースだってなまものじゃ使えないからな
データベースだけでもスペシャリストのかたまり
つまりそんなスペシャリストがわんさかいたから省庁のような鼻っ柱の強い縦割り行政の銀行システムなんだよ
三行が一つになるどころか通信省とDB省で話が通じないんだよ COBOL使う仕事やっててSEやめてから10年経ちますが、まだ使ってもらえますか？ >>604
X.25は必要時に時々つないでコスト安く済ませたいためのもの つまり銀行コボル置き換えるにはその下のインフラ部分全てとの絡みがわかってないと
カネがなくなるかもしれない
ビットがなくなるかもしれない
不安で
こ・わ・い
わかるわけないじゃん
そんな魑魅魍魎システム COBOL85でRS232Cプログラミング
相手シーケンサー通信機器との
タイミングでCOBOL85でもループ処理ｗ そらまぁ、コンバーターあったとこで全テストだけど中身わかってるやついないしな
同じ言語でバージョンの互換性チェックしてちょっと依存コード書き換えて、ビルドして動作確認の方が遥かに楽なんで おそらく一定期間金融を完全に止めないと実現できないよ。
国が特別の法律を立てるくらいじゃないと無理。
大規模事故待ち状態 コボルと無縁な銀行システムもあるんだろ？
それ使って巨大化すりゃすぐ以降出来るじゃん >>599
通信インフラが何社の製品で出来てると思ってんだ(笑)
ケーブル素材やチップ性能、シリコンウェハーまでやるんか？(笑)
実装だけでもかなり差が出るぞ(笑)
金をふんだんに使うか？(笑)
経年劣化は？毎月交換か？(笑)
もっとやらないとまだまだ言ってることに近づかないぞ？(笑)
パカの相手はこれまで(´・ω・`) >>584
ISSUE発行して紐つけるとか色々やり方はある COBOL.NETでアプリつくってるやつおらんのか >>581
なんもないわけないだろ
全くわかってないコメだな
全部やってるよ当然だろ
当時の最先端だ
闇鍋も大ウソ
問題はビジネスロジックじゃないところにあって
それは機械メーカーや通信機メーカー側やコンピュータOSの側との絡みにあるからだ
長年のというのは今やってるようなおんぶに抱っこのプログラム開発じゃなかったからだ
ビジネスロジック部門じゃない機械類通信機器
含めて全テスト
それぞれの部門まで見える話じゃない
富士通の1980年代の詳細な活動内容と仕様とその実装とを日立がいま探るようなレベルの話だ >>585
中国は遅れていたから、COBOL全盛期はアナログ人海戦術やっていて、レガシーが無いって可能性も >>530
俺が昔保守していた時は、部門によって特殊処理が必要になった時
IF分に部門コードで書き込まれていたんで、組織変更の都度判定してる
プログラム全ての修正が必要になっていた
その時は楽だろうが、保守の事をまったく考えられていないんで後々
開発じゃなく保守担当にボディブローのように効いてくる
やばいのは、保守の大変さを知らない開発担当が、同じような感覚で
プログラム開発を進め、雪だるま式に保守作業が膨らんでいく事 巨大システムだと全てを人間が把握するのは不可能になる
原発がその良い例
あれも下請けに丸投げしてたので東電社員は原子炉の設計書がどこにあるかさえも知らなかった
東電社員は運転スタートとストップのボタンを押すだけ >>623
.NETになるとCOBOLの安定性が無くなりそうだから普通の.NET言語でいいだろ >>626
つまりデータとプログラムが独立してないんだろ？
それをいったん独立して作り直すだけで移行できるじゃん >>630
偉い人「は？移行？ふーん。それタダでできるの？え？カネがかかる？そうなんだ...で、機能はモリモリ追加してくれるんだよね？なに？動作も機能も今と同じ？ならやる意味ないね」
...と、まぁ大体こんな流れで有耶無耶になるのが一般的だな。 >>626
それも当時の保守の常識ベースでしか作れないだろ
稼働時の品質キープで保守はかかせない
開発がどうとかじゃなくて全社的な考え方がそうだったわけ
銀行にとってのオンラインシステムはトヨタにとっての調達システムと生産システムと販売システムとを合わせた以上の銀行って会社そのものだからね
後になっても会社の品質キープに貢献してるのは保守担当だから気持ちはよくわかる
しかし開発がアホとか考えてないってのは違うよ
そこまでしか見えてなかったわけ
継続的な巨大金融サービス業はトヨタのようにモノ作って売るのじゃなくてコンピュータシステムサービス自体が商品
その継続性を担当してたあんたは偉い >>630
それに加えて
ネットルーターとその先のサーバーとそのアプリと通信レイヤーとデータベースレイヤーとそれに途中のNTTのスイッチと沖電気とかのATMコントローラーとそのたもろもろな COBOLで第一種受かったけど、もう何も覚えていない。 >>633
んで開発ドキュメント以外に保守ドキュメントが積み重なると後年のやつが開発ドキュメント見ても実態が違うしね >>630
OSの中身ほとんど全てや周辺機器IOコントロールもな >>629
同感。
C#にBCD演算ライブラリ追加したほうがマシかも。 >>587
しらんけど、そういうのって、プログラム中で、一項目入力するごとに、ロジック判定したりあちこち飛んだりして
つぎはこの項目の入力、、、みたくベタ書きしてある的な？
Gotoで飛んでいくのかな >>632
銀行はそれが商売道具だよ
今振興のネット企業と全く同じ
コンピュータシステム自体がサービス
その例えも的はずれ >>640
そんなレベルなら全部読み込んでとにかく関連付け直せば概要は把握できるだろ
そんなロジック部じゃなくて
プログラムでコールしてるだった1行の銀行独自ルーチンのなかが巨大な宇宙なんだよ
それが通信プロトコルに繋がってたりデータベースに繋がってたりATMに繋がってたりするのは
プログラム書いたやつの範疇じゃない
高度なレスポンスキープを達成するための方策が
あちこちにワープ部分があるわけで しかもそれが機械経由だったらデバッグの範囲を越えるだろ
全部違う世界を繋げてATMにいるひとに瞬時にあなただけの特別待遇ですといいながら別の銀行との取引をしつつ >>628
それな…前は良かったんだけど、
github.py とか無理やり突っ込まれてな… >>644
東京都民が新宿という超都会でも山手線に乗るのに並ばないで降りる人より早く乗り込んでいた1980年代前半が第三次オンラインシステム開発真っ盛り
そういうカルチャーの中では立派な統制でいままでもってるだろ >>635
FORTRANで合格したがソフト関係に配属されたくなかったので履歴書に書かなかった
そして全く覚えてないｗ >>640
初期のソースはそうだな。紙一重で動いてて、これデータにより落ちるるやんってバグ発見したり
COBOL８５時代になるとGOTO無くても済むようになるから、構造化が出来ない年寄りがスパゲティを書いてた
サブルーチン使わずGOTOで済ますメリットは当時のコンパイラの都合上だけど処理が速くなるんだよ
汎用機の速度も遅かったからねえ。意図的にGOTO使ってるパターンもあるけど、意図的だからまだ読み安いソースになっとる >>624
金融機関はやったこと無いけどCOBOL案件でまともなドキュメントが出てきたためしがない
改造ステップ数がいくらだとか、修正ファイル一覧とかやたら細かいドキュメントは書かされるけど Z80でプログラム組んでた時は暴走しまくりで参った Z80を「ジーエイティ」と正しく発音できる人が少なかったな >>582
全然違ったらすまんす
それだとなんかおそらく機器とのデータのやり取りあたりっすかねえ？
他の部分のいわば普通にCOBOL書いてたひとがそのルーチンも書いたのかとか
まあ、かける人もいるだろうがそうそういないのではないかとか １０数年前に某証券システムから足洗って別業種だけど、
まだ需要あるのかｗ
データセンターとかに泊りに行ったなぁ。。
jclミスってて青ざめたりとかしてたな。 影響範囲が恐ろしく広い2038年問題って解決の目処はたっているのか >>643
その話はその話、>>587の話は>>587の話なんじゃねえの？(´･ω･｀)
その、かなりこんがらがってそうな作りのもので「ソースしかないけどソースはあるから同じように動くものつくってね」てやったら、
相当の工数は食いそうだしとは思うんだが >>653
プログラムの終わりなんで76HALT書いたら固まったでござるの巻 メインフレームかわからんけど
メインフレームのCOBOLで、
そんな232Ｃ直接外部機器相手するPGかけるんか
すごい実行クラスもらっとけば、ドライバなみに居座れるん？
とかおバカなことかいてぼろくそに言われてみようw >>651
入力の項目による分岐とか自体が複雑だったりすると
構造的に書いても
構造から脱出してやり直しとかわけわからなくなるかもってのはあるかもですよねえ
無駄にスパゲッティになってるのか、入力にしたがってやる過程によってはきれいにかいてもそ…いやさすがに考えすぎかw
仕様自体がはっきりしてれば作り直しちゃうのがいいんでしょうがとか思いました >>656
豊洲のデータセンターか？
もしかして不要電文を削除する対応とかをやったクチだな！ >>661
そもそもメインフレームで通信周り処理は、
通信用プロセッサにやらせるから、メインフレームCPUのリソースは食わんしね。 >>588
生保の決定成立処理とかアセンブラだったな
PCだとCPUがRISCに移行したのに伴って高級言語にシフト、かえってアセンブラの方が効率が悪いって状況になっていったが、
汎用機は下手にアセンブラが残っているせいでRISCへの移行が難しい印象 COBOらない
COBO ります
COBO る
COBO る時
COBO れば
COBO れ >>669
私のような老人は
アセンブリをアセンブラでアセンブルｗ COBOLとVBAは当分無くならないよ
最先端の技術・言語をキャッチアップしてるエンジニアからは嫌われる言語だが
これだけ長く残るにはそれなりの理由や存在意義があるということ >>41
高級言語にこんな機能があって欲しいけど、どれにも入っていないみたいなことが良くあるけど、
頭の中でどんなコードでそれを実現できるかサラッとイメージできるだけで無駄なことは言わなくなる ちなみに日本の銀行やクレジットシステムはCOBOL使われていて欧米や中国人達の不正に加担してる間抜けなシステムであります >>202
python、計算が遅くて有名
使い物にならない 目が辛くなってきたから引退する言ったら慰留がすごい
10年後どうするつもりなんだか >>575
日本だけじゃない。アメリカ国防総省も昔のシステムを刷新しようとして失敗、そのままCOBOLのコードを使い続ける事になった。
昔からコンピュータ使ってる所抱える共通の問題だよ。 >>676
すんげえ初歩的な質問ですみません
pythonって、インタープリター言語なんですか？ >>632
それな。全国規模のシステムがって聞いてもう、誰もできないんだって知った
銀行は知らん 偉いさんたちはこういうのを「ぜひやって！」と言う
でもお金がかかることを想像できない。そこで渋ちんで話が終わる
日本のデジタル行政はお金はぽいぽい出すが
「できる人に渡したつもり」
そうじゃなかったとあとでわかる罠 某政令市の移行の話って、どうなったのか聞いちゃいけないんですか？
(´･ω･｀) 国防総省もCOBOL資産多すぎて完全には置き換わってはないやろ スレタイ見て予想した通りメンバメイコボルスミ11を懐かしむスレになってた >>682
部落民が多いと全く別の大きな問題があるし。 素人考えだとCOBOLで作ったシステムを別言語で作るのは
造作も無いことだろうし、データ部の移行もCOBOL→別言語への
データコンパイラくらい天才プログラマが本気になれば
出来ると思うが無理なのか？ ただコードを置き換えるだけじゃなくて、ちゃんとオブジェクト指向とか取り入れたいじゃん。 俺の若い頃は、「これからは、構造化言語のPascalの時代だ」とか言ってた。
やたらと構造化言語という言葉が流行って、アホみたいに「goto，if，for文は使うな」
「メインルーチンはサブルーチンを呼び出すだけにしろ」とかいって、
while 1
gosub xxx
gosub xxx
wend
みたいなことしてた。 40年前の時点でCOBOLは枯れた技術でプログラマーも高齢者だった記憶がある。
70代や80代の現役プログラマーが引退すると、後継者が居なくなるのだろうか？ 独学でやったところで仕事が無くて
採用の時点でベテランしかいらんって言われても
育つ訳が無いじゃないっていう 他の言語わかる奴なら見ただけで大体読めるから大丈夫だろ
ポインタなんて複雑なものもないし見たまんま >>690
それでModula-2覚えたわコンパイル実行エラーの対処がし易いんだよね 最近の目新しい言語はバックヤードの並列処理とか優れてるけど、プログラムのフロントはむしろ簡略化されてスクリプトみたいになってるね
結果、関数構造による変数のスコープ以外はCOBOLと大差ないという ただ不思議とモダン言語から来た若いのがCOBOLで上手く働いてるのは見ない
勘所が違うのか泥臭いデバッグが出来ないのか かつてDB2とCOBOLで開発していた
勘定系だったらもっと長くやっていたんだろうなあ 昔コボラー今アバッパーの流れに乗ったやつも多いだろう >>687
プログラミング言語は基本2進数
COBOLは10進数だから単純に置き換えると誤差がでてくる
銀行みたいに扱う金額大きくなると致命的 二年前かな
軽減税率対応とかいって
四半世紀以上大昔から動いているCOBOLソースいじったわ ん、メインフレームはアセンブラレベルで10進を扱うよ。
PACK,UNPACKあるし、計算も10進そのまま >>692
４０年前はＩＢＭでも未だＣＯＢＯＬ２が普及する前
これからＥＶＡＬＵＡＴＥとかＥＮＤ−ＩＦとかが出て構造化が始まった時期
プログラマも３０代主流 ４０代課長５０代部長の時期だ >>708
というか他言語で１０進数小数点で誤差が出ないものがないんだよな
確かC#がなにか使って出来たように記憶しているけど標準装備じゃないし
なぜ誰もCOBOLに代わる言語を作らないのかわからん
python辺りが標準装備になれば一気に取って代わる気がする ＣＯＢＯＬを多言語に変換するのは簡単
だが何度も指摘されている通り計算誤差の問題を解消するのは難しい
もっと厄介なのは誤差問題を解消する言語に変換が可能でも
プログラム（モジュール）１本毎にどんな業務をこなしているのか
誰にでも判る仕様書は出てこない
機械的にどんな処理をしているかだけは簡単に出せる >>716
Cでプログラムを組んでた時ポインタとやらを使った記憶がある
30年以上前でどんなものだったかすら忘れたｗ ＣＯＢＯＬにポインタ？って調べたてみたら後の方のやつにゃあるみたいだな
昔のＣＯＢＯＬにゃなかったんだわ あっても使う意味がない >>677
SESやってるけど前の現場もその前の現場も
辞めると言ったら泣きつかれて大変だった
他社の人に頼るきるなよ全く… ＣＯＢＯＬはプログラミングの原点。文系事務職の原点だな。 >>722
簡単だし事務処理用にはよく出来た言語だね
難点は長く使われている分、何十年も改修に改修を重ねたシステムが多いから
経験の浅い人がメンテするには難しすぎることだな >>22
> もうvisualstudio使うような仕事からは逃げた方が
なんでなんでせう、先生、教えてくだはい。 >>718
おおざっぱないいかたをすると
変数って、実体は名前がアドレスであとは格納されている長さ とそれをどう解釈するかなんよ
こないだlong doubleを表示しようとしたら、なんか形式によって、なかみははいってるらしいのにうまくprintfできないらしくて
char*でみて一バイトずつなかみ16進表示してみたわw
デバッガでみりゃいいじゃんって言われるとは思うがw 文系の俺はＢＡＳＩＣでオイチョカブゲーム作って遊んでた 動的に領域確保するとか、
ポインタでさして見ていくことに強い意味とかある場合じゃないと、なかなかポインタ使わないよな
COBOLにPOINTER句実装した経緯と使われ方はちょっと興味ある？ >>714
あっちはあっちでIEEE754の浮動小数点演算っていうスタンダードが出来上がってしまっているし、
今までに組んだプログラムもデータもそれ前提で動いているから、下手に変える事が出来なくなってしまったんじゃないかね
標準で10進演算をサポートしていたMSX-BASICも、当時の他のPCからすれば浮いた存在だったんだろうな ってか、それを言ったら、INDEXED BY句あたりでも使う人は当たり前に使うかもだし、
使わん人によっては、こんなんあるのも知らんかったなんに使うんだよ？
的な？ >>728
あり、うん、そういう想像はしてます。
64bitか80か128かコンパイルオプションがあったんで、言語の骨的にはかなり対応してんじゃないかと想像。
80でも領域は16バイトとるってのも面白かったw >>368
グレース・ホッパーは本当に偉人だと思う >>728
COBOLのほうの10進演算問題は、もっと具体的に突っ込むなり精度よく整理すべきなんだろうというか
想像として持ってるとこはすでに確立したノウハウんじゃないかとか、計算機やってる学術の方で、誰でも見れる論文とかになってないのかな、調べてないけどw
10進ベーシックが大して流行らなかったのはやっぱり直接的に特段必要として使われるもんじゃなかったからじゃないかと >>8
昔々IBMのSystem370のアセンブラでTCP/IPのプログラム組んだ思い出 >>732
string系データ同士の演算をサポートすればいいんだけど、どの言語もやらないね ところで
ハイパーインフレで銀行のCOBOLのコードが対応不可になった例ってあるのかな
普通はそこまで行く前にデノミとか米ドルへの切替とかするんだろうけどさ 732 名前:名無しさん＠お腹いっぱい。 [sage] :2021/11/04(木) 20:35:12.50 ID:/GkLIQxX
俺はマシン語を極めかけた頃に精神に異常を来たし業界から引退した
そもそも人間がマシン語なんてやるもんじゃない
マシン語に長く関わった奴らはみんな精神に異常を来した
恐ろしい時代だったな C・C++・Java等から安全高速なRustへの移行が進んでいるけど
この件も日本では遅れているよね >>737
マシン語って極めるもんじゃ全然ないからな
チップ作ったやつが決めた決まりってだけだから
道具使う時の基本
人間がやるもんじゃないじゃなくて人間が作ったもん
このラノベ書きは全く理解してない 何の言語が役に立つかを前時代の人が現世代の人にアドバイスするなんておこがましい 自力で設計して一定以上の大きさまでのPGかける人間は、
他言語の仕事に駆り出されても必要な調べものすれば、まあまあいけるともいえるかもしれないし、
一方COBOLの事務系プログラムバリバリ書けますってひとに、
組み込みマイコンのアセンブラとかそれに特化されたCとかJAVAとか、タイミングチャート読め割り込みちゃんとハンドリングしろとかにどれくらいこすとかかるかはわからんけど >>714
> なぜ誰もCOBOLに代わる言語を作らないのかわからん
10進演算やりたいならライブラリで十分だから
言語仕様になんでも詰め込むのは古い >>742
ライブラリで実現すると著しく性能や可読性が落ちるから、言語仕様に組み込めないかな？って言ってるんだぞ >>739
いやいやマシン語は、極めた者とそうでない者との差が段違い
PC88全盛期の頃のゲームの出来が全く違う
速度もデータ圧縮技術も桁が違う
FM音源を64分音符単位で再生しながら全方向高速スクロールゲームやれてるのは天才がいたからだ 日本工学院出版のあのオレンジとブルーのCOBOLの本は会社で人気だったな
オレンジの文法編はよかった >>743
性能や可読性が落ちるという思い込み
10進演算命令持ってるハード向けにはその命令使うようにコンパイルすればいいだけだし 前の会社は上層部がコボラーばっかで俺がヤメたら潰れたわw
全国倉庫のWeb入退室システムの開発責任者が納品直前に逃亡して、ヘルプで見に行ったら
COBOLオンリーで作ろうとして八方塞がりでトンヅラとか
「おまえC++出来るやろ？COBOLっぽい仕事やけどC++でっヤツ取ってきてやったから」
って渡されたのがCOBOLじゃ無くてCORBAのロボット制御とか
もうメチャクチャで愛想尽きてヤメた。 COBOL技術者の引退を何度も見送ってここまで来たが
自動テストを当たり前に書き
C#ではvarを、C++ではautoを当たり前に使う時代になって
いよいよ引退かもと思い始めてる COBOLをこぼら、こぼり こぼれ こぼろ って言った人いますか？ >>744
それを極めるってのが日本の悪いところ
正しく使おうと使い方を広めるのが日本以外
使い方を知らないだけ >>750
おれはそんなん全然かけんけど、
アクションゲームのプログラミングなんて、ハードの性能最大に引き出してなんぼだし>>744がなんもおかしな話とかしてへんと思うけどね。
ハードに精通とかよく理解してて、これくらいのことまではさせられるはず的な
まあ、そもそもハードの設計した人とかは相当程度見通してるはずだし、
ゲーム特化的な仕組みはMSXのスプライト辺りから？
ゲーム専用機になるとサードパーティー向けの開発ツールもセットにああ語りすぎか >>742
COBOLはソースそのものにドキュメント性を持たせるってのが言語仕様決定の際の一つの目標だったし 学生の時の情報センターのコンピュータが
IBM3081だった。 >>744
秘伝とかいって隠して代々にしかつたえない
老舗とかいって偉ぶって弟子とか育てるのに何十年？
そこやめたら義理を欠いた切腹もの許さん！とか
かたやオープン
大会社の技術もその技術者もそれを独立後エピソードとして語って自分の技術を宣伝するのは当たり前
ネットはそれを加速させてる
日本は明治以来取り込むだけで世界に発信しない
世界にじゃなくて誰にも発信しないから
身内だけの義理と人情の世界
ドキュメントとか歴史とかは抹殺
人間関係だけで価値を測る文化
天才とか極めるとかじゃなんも育たない
だからおまえマシン語知らねーだろとかいいだす
まさしく寿司職人刀職人
匠とか秘伝とか隠してるだけの文化の言い換え >>732
昔Windows95が発売された時、電卓で2.0-2.01って計算をやったら、-9.99999・・・みたいなおかしな値になったって大騒ぎになって、
果ては新聞沙汰にまでなってたのを覚えてる
それ位誰も十進演算の重要性ってのを認識してなくて、いかにコンピュータの世界の常識が、
世間一般からズレているかって事を痛感させられた出来事だった >>750
一方、大規模なシステムとか、標準性や可読性を重視して
近年の、性能面をハードでカバーしやすい(これがどこまで正しいか文句ある人いると思うが)環境であれば、性能的技巧を駆使しない方がいいとかが必要とされることも少なくないだろうというのも、もちろん理解できるつもりだけど。 >>756
日本のマスコミ含めて今いうところの上級さまがそういうレベルのままというだけ
世界の常識日本の非常識
あ世界は知らない人はしらないままでいいんだが
日本は末端まで一様に知らないとバカ呼ばわりの一律兵士養成文化をひきづってるからな >>754
すげえな
勤務先がやっとそれに変わったばかりだったのに >>721
ただの事務処理まで降ってくるからな
いや、どう考えても社員のお前のが詳しいやろっていう >>754
その頃のそのホストのメモリーって1Mバイト1億円とか2億円とかしてたんだよ
だからシステム大変だったわけで
オブジェクトどころか悠長なプログラミング
なんてできないわけで
今でいうリファインってのがレスポンスタイムとメモリーサイズ目標
削って削ってわかりにくくともスピードと処理量優先 >>756
そこまで理解してるなら、もうちょっと話を分析できるんじゃない？
コンピューターが間違ってる的な話で騒ぎやすい話だとは思うけど、本当に本質的に困る話なら、今ごろ言語全部10進化してんじゃね？
例えば、それなら、内部で端数が出てても、有効桁数考えてprint using #.## みたいので出せばでるだんべーなりゲタはかせて整数かして対処するなりするんだろうし
以外略 >>757
数で勝てばいいだろと、質で勝てばいいだろは国民性に根ざしてるかもしれんな >>8
まだDOSとWindows3.1が混在してた頃、
アセンブラで書いたっていう競馬データベースがあった
他のソフトに比べてめちゃめちゃ処理が速くてびっくりした >>763
色々あるよね
前スレ当スレでもメインフレームでアセンブラ書いた人もちらほらいて
わからんけどおそらくは、様々な事情や時代のなかで、おそらくハードや周辺機器叩くとか性能面での何らかの理由か特権的ななにかが必要だったかとか
なんらの必要もなくアセンブラで書かんだろうから、必要もあり技術的能力が充分あるから書いたんだろうと
黎明期ぽい状況だと研究系とか面白がって書いてみた系もあったのかもしれんけど>< >>764
VBしかやってないのをPythonでやると同じ感想になるからべつにASMがすごいわけじゃないよ
比較対象がそういうもんだったというだけ >>24
>>294
バキとコボがどういう経緯で？という背景がわからないと
特に思い入れがない人（たとえば俺）には何なのか分からんと思うｗ >>764
んで当時のオンラインプログラミングもそういう処理速度と時間単位の処理量優先
ちょっと太れば億単位の損失
だから万人向けわかりやすさはカット >>768
370ならそれが標準だったよね
ハードを触るシステム部分はアセンブラ どうでもいいけどパイチャームってエッチな響きだよね >>762
あと、科学計算とかの方でも、演算によって有効桁数の桁落ちと精度の問題とかあって、
古来？論じられてきたり精度を保持しやすいように演算の順番を考えないといけないとか
まあ、ＰＣでも128ビット浮動小数点演算させられる時代になって
そこらへんをおおざっぱにしてもあまりこまらなくなったのかは全く知らないが こぼるちゃん４こまとかすでに実在しそうにも思ったけど探してません＞＜ >>736
某通貨の記事ざっとみたけど
都合なん桁圧縮したのか>< >>770
このスレを見てると
ソフト屋さんはアセンブリ言語と
アセンブラの区別をしないようですね
コンピューターのハード屋でもない
機械屋の方がつまらん拘りがあったのかと思いましたｗ 英語が喋れても馬鹿は馬鹿なのと同じ
Javaのコードすらすらが書けても、馬鹿が作るプログラムはゴミですよ 「動いてはいるが手の付けようがないプログラム」てのは世の中の皆さんが思っているよりずっと多いのよ
うちもだけど
しかも古いシステムのドキュメントなんて例外なく紙だからな
そりゃ散逸しますわ >>746
まるで演算仕様がちがう
小数点以下桁数とか指定しなきゃいけないんだぞ レガシーを切り捨てる決断を現場のプログラマはできない。権限がない。
権限のある人は理解する能力がない。
不幸だね >>779
プログラムなんて思うから何とかなると思うんだよ
あれは芸術作品 >>780
通貨を計算するには向いてる言語なんだよな
>>781
レガシーつうか、まともな人間つかってりゃ他の言語に置き換えるのも面倒ではないはずなんだけどな
見る分にも数千ステップだろうし
オブジェクト系つうかC++(オープンソース)で３万ステップ追っかけたことあるけどもorz 大きい銀行のシステム全体だと何万ステップくらいあるんすか？ と言うことでみなさんお疲れ様。
こちとらCOBOLが読み書きできるというだけで（正確に言えば加えてIMSやCICSもOKだが）で年に1500万円頂いている。
定年まであと3年余りのロートルで定年延長とかあってもあと5年なのでこのまま逃げ切るつもり。
しかし私みたいなおっさんが高い給料もらっているのに、私には理解のできないようなものを扱っている若いものが安月給で働かされているのはとっても不憫なものよのう。 >>784
大きいだけで、やってることはアクセスに毛が生えた程度だろｗ >>786
アクセスにあんたの預金預けるw
ブタさん貯金箱w >>785
給与は需要と供給で決まるからそれで良いんだよ。
業界違うけど俺も同じような立場だわ。 COBOLが古くても未だに使われてる処があるのは
OA化最初の投資や企業実績があってこそで
あの時のブラックながら、がんばったＩＴ土方は
リストラされて捨てられた、もう俺はやらんよ >>784
メガステップが規模の単位
COBOLでは、その言語仕様からモジュール間の悪性の「絡み」と「伝播」が避けられない
手を入れようにもどうしていいか分からない状況は、言語面ではそこから発生する >>785
と言うか年収そのままで良いから75歳まで引退しないで欲しいのだが
そんなゴミ触りたくないって >>780
COBOLだって最終的には機械語に落ちるわけで
COBOLからしか使えない特殊な命令を使ってるわけじゃないからね アセンブル アセンブリ アセンブラ
のことから、かなｗ >>792
ちなみに、それって具体的に例示できます？
ってか、保守を想定してか移行を想定してかとか >>795,798
実装対象として考えられた初期の汎用機群は10進ストリング的な機械命令群を予め持っていたが、
それが現在のPCやサーバには欠落してるんだ
COBOLの大抵の処理はファイルをいくつか読みだしてファイルをいくつか書出し修正や作成するというものになる
そのときファイル内の重要項目の定義が変ったりすると、友達の友達はその友達式にファイル経由で影響が拡がり易いんだ
DBを中心に置いて組んだシステムはこうはなりにくいが、そんな素直なプログラムばかりではない
いずれにせよ、モジュールの独立性が高い言語と環境しか知らない人にとっては想像外の事だと言える COBOLなくなるって言ってるやつは石油が無くなるって言ってたやつと似てるな >>687
技術的なことは天才がやれば可能とは思うがボランティア必至
さらに、止められないシステムを動かしながらやるのは現場的に無理w >>801
えっと、前後しますが、先にファイルの話から
ファイルレイアウトいじる必要があるなら、それにアクセスするプログラムに影響があるのは当然でCOBOLという言語に限った話ではないのでは？と思うんですが、
まあ、いわゆるファイルレイアウトのCOPY句で参照するなにがどうわなに >>801
>10進ストリング的な命令群
9項目をoperandにして直接演算する命令群的にとらえていいんでしょうか
よしんばPCやオープンの鯖で機能的に等価なPGやシステムを構築できても、性能がでないあるいは出にくい推定でしょうか >>802
団塊のじーさんがCOBOL仕事を死守するための・・ 複数人で印象操作するという仕事で、
嘘を展開していた
奴がいた >>804
どちかっつうと逆で、必要に迫られてプログラムを改修しようとすると、ファイルフォーマットに影響し易いんです
もちろんCopy句大活躍
ただし、Copy句を参照しているプログラムユニットをすべてチェックして
必要なら再コンパイルと再テストです
オープン系だと、COBOLの基本10進32桁保証のために、素直には128ビット整数+スケール1バイトを使って
エミュレートすれば素直ですが、至る所で10進←→2進変換が入るので大きなオーバーヘッドになります
でも、ieee754に10進演算関連の命令があるようですけどこれはスペックの点で使えないようです
結局、マシンと言語でネイティブでサポートしてくれないと、無意味なオーバーヘッドを喰らいそうです
ただし、ファイルフォーマットから全面的に見直せば、別言語での再構成は十分現実的です 日本の昭和からの風土
動いていて問題部分は触るな
例、出荷先でも埃がかぶっていても
その線、端子を触るなとか
ラダー、その回路をを触るな
汎用オフコンパソコン、組み込み
それを触るな、相手にさせろとか
とにかく、新しくやるなｗ 今の頭取クラスがやった金融のCOBOLモジュール、すっぱでも触るなｗ >>811
丁寧な回答ありがとう
となると、10進演算の話は移行に関する的な話で
ファイルに関する話はどちらかと言えば保守改修でしょうか
特段に答えていただいたことに否定的と誤解されないよう願いたいんですが
保守改修でも移行でもそこまでやってきたチームメンバがなにを継続的に把握しているかや、よくある？(少なくとも言われる？)関連ドキュメントの存在や整合性とかもかなりかかわるんじゃないかとか
また、拡張性にとんだ言語がどれくらいどのようにこうだからこのようにCOBOLより変更に強いとかを平たくかつ証明的に示せるもんでしょうか
とは思うんですよね 他言語でもBCDライブラリ使えば同じなんだけどね。 コンピュータの開発言語を学ぶな
やるんだよ、それだけ あと全然知らんすが、近時の汎用機資源が、いまもその手の命令を持った現物で動いてるのか、あるいはもしかしたら、エミュレータみたいなもので古いマシンからリプレースされて動いてることはあるのか、後者のケースがもしも存在するなら、やはり性能要求は厳しくはないが、とにかく以前からのものに継続して動いてほしいとか、元がかなり以前のものでエミュレータとトントンになったり？とか？ちょっと想像しすぎですか いわゆるＰＣのプロセッサの世界で命令とかある(あったなのかわからん)ＢＣＤは、COBOLでいうところのパックトデシマル？
一方COBOLの指定なしの9項目はアンパック？ あ、ＰＣで持ってるBCD命令ってももちろん任意の桁のそれを演算してくれるもんじゃなくて
せいぜい補正命令くらいすか
なんか、386(7？)でいうFBLD/FBSTみたいんは実数に変換して計算させるみたいんで話が違うってことですかね
9項目って最大18桁かと思ってたら違ったようで><
32桁だとINT128に収まるかな COBOLが大好きとかでない限り、ただの地獄だな。
金のためならこんなオワコン業務にしない方がいいし。 実際、金融系って数字ばっかで、あんまり面白くないじゃん >>825
東大の数学科卒なんかがいる保険数理の部屋なんか嫌だ
あの部門からのシステム開発要件なんて誰も近付こうとしなかったｗ メインフレームで（マクロ）アセンブラを使って
事務処理だとレジスタを意識することがほとんどないな このスレは本当に懐かしい事だらけだな
４０年少々前からこの業界に入り６月に足を洗ったはずだが
コロナが落ち着いたから時給５０００円のアルバイトでＣＯＢＯＬ解読を再開した >>824
おまけにCOBOLやってる会社は変な会社が多いw >>8
アセンブラってアセンブリ言語の事？
8086なら30年前に仕事でプログラム組んでたわ >>830
8086でアセンブラ使うと絶望する
相対ジャンプのオペランドが8bitとか
テメーは16bit CPU名乗るな！と… >>826
数理のPG仕様は謎記号がいっぱい書いてあって読めないんだぜｗ
仕様者に気きに入っても記号が分からないの理解してもらうのが大変でｗｗ
奴ら一般コミュニケーション能力欠けてるｗｗｗ >>823
ですです。
IntelのFBLDは詐欺です。
AMDが、IEEE 754r の10進浮動小数点演算サポートする
って話どうなった？ >>809
COBOLはロジック組めないとあかんからな
ちゃんとしたソート、マージ、ブレイクぐらいの知識は必要（ちゃんと出来ない、汎用的に作れん人がおるからスパゲティ化）
面倒な処理はソースに説明書きも入れてたり、後進者への優しさが必要
設計するべき人がレビューだけすませて仕様書に反映して貰ってないこともあるのでな
オブジェクト系はクラス呼んで来て終わりだから私としちゃ簡単だけど 既存コードの再利用はそのままコピペしてきてたな
だからこそずっとわやくちゃにならずに保守しながら使えるのだろう >>822
68000だとABCD/SBCDというBCDによる加減算命令があったけど、0x09+1=0x0Aじゃなくて0x10になるという、
16進数を見た目10進数として扱うってだけで、実用性としては？？？な命令だった
そもそもBCD自体規格がバラバラで、誰もまとめようとしなかったのがずっと尾を引いている印象 >>838
ちゃんとBCD演算してんじゃん。
どうなればいいと思ったの？ 123c + 456c --> 579c
メインフレームならAP 命令
パック形式をゾーンにすると123fはF1F2F3となり
印刷すれば人間に123と見える 他の言語出してくる輩は、
COBOLでちゃんと組んだ 実務経験と知識はゼロだろうね
COBOLは触らないほうがいいよ、先人の作品をぶち壊すから >>836
お恥ずかしい質問だと思うんですが、
「ソートされたデータ(データセット)の性質ってこういうもんなんよ」的な話とかって、
経営工学とかで使いそうなテキストとかにあったりするもん？
そりゃキーの順に整列させたもんはそうなんだけど、こういう仕事にこう使えるんよ的な 金の計算に必須な、10進演算ライブラリが充実してるのが要因らしい。 ライブラリ以前でネイティブ対応だから使われてる
割り算は切捨て切り上げ四捨五入五捨六入等々意識してやるのが10進演算 >>849
なんかそれって、プログラムの仕様に合わせて業務を設計している感じ まあ、思うに、シビアな性能問題がなければ、プロセッサが直接演算しなくてもいいとは思うんよね>BCD
スレの元ネタは、移行とも保守改修とも出ていない(暗示には当然なっているだろうが)が、レスのベクトルはこの通り
小規模中規模な移行なら、よほどの人的あるいは資料資産的不足でもなけりゃ新規開発に近い移行してもいけるんじゃねーの？的な
(誰も知らない、になってるなっちゃったやつを文系がうま×)
移行するのに体力あるか、ようはコスト負担できるかがまずあるんだろうかなとか。
オープン化の流れみたいのに、(例のライセンス云々で？)変化もみえたとかマジあるのかわからんし、しばらくやって実例がでてなにか見えてきたことがあるのか？全然知らない
かききれないなw だから、どこのだれがメインフレームとか言い出したんだ。
日本IBM本社が六本木にあるころは
センターマシンで通用したんだがな。 ダウンサイジングが出始めた頃からメインフレームと呼んでた気がするがセンターマシンと言う言い方はしたことなかった気がする 計算センターにあるマシンだからセンターましんてきな？
「メインフレーム」とか「汎用機」とかの定義しらべてこんとあきまへんかね？
「オフコン」と区別される気もしますよね ２段落めにもう明確な定義は存在せずって><@Wikipe 俺の周辺では汎用機 メインフレーム ホストと呼ばれてきた 上か前でだれかメインフレームのインストラクションの資料リンクしてくれてたよね
命令すごく多くてみきれんかった >>840
これも、お恥ずかしい質問ですみません
(くれぐれも皮肉にとらないでね本当に初見)
後ろにcとかfをつける表記って、どういう意味か教えてください >>859
cは+(正), fも同様に扱われる 、ゾーンをパックにするとfになる、アンパックするとcになるからfに変換する必要がある
C'123'(x'F1F2F3') ->パックにすると x'123f'
dは-(負) >>860
cはゾーン10進の正の数、dはゾーン10進の負の数、fはパック10進の符号なし、でしょうか？
(そうの場合パックの符号ありの正と、符号なしの差がよーわからん＞＜)
X''は、16進定数、C''は文字文字列だけど、正の数なら数字をそのまま書けば当然ゾーン10進そのもの
ってことすかね
当然C'-123'と書いても、123dにはならない、でおＫ？ >>861
ずいぶん昔の記憶だから、怪しいかもしれないが、メインフレームの話で
EBCDICのゾーン10進で負数は末尾1バイトが
x'd1'とかになるから、c'J'に該当する。
で、パック10進数には符号なしは存在しない。必ず末尾4ビットが符号になる
アセンブラでパック命令は、数字を意識してなかったような気がする。
8ビット区切りで、下4ビットをつなげてるだけで、最後の8ビットの上4ビットを符号ビットにする。 ゾーンおよびパック 10 進数データのサイン表記
ttps://www.ibm.com/docs/ja/cobol-zos/6.2?topic=arithmetic-sign-representation-zoned-packed-decimal-data JavaのBigDecimalで書き直したことあるけど足し算するだけでも、
BigDecimal a = new BigDecimal("1");
BigDecimal b = new BigDecimal("2");
BigDecimal c = a.add(b)
こうだからな
1+(2-3)*4/5
みたいに括弧も使った四則演算をaddとかsubtractとかクラスメソッドで書き直すのかなりダルかったわ AP命令の方ググったら、汎用機用のC言語の関数、
通常はコンパイラから生成されないハードのAP命令を意識して用意されてる的な、
のに当たりました>< まぁ業界の事情は知らないけどみずほ銀行見てると基幹システムってなかなか変えられないんだなぁと >>866
金融系は特定のユーザー部門に紐づいた専門的な計算処理だけ
ＣＯＢＯＬに封じ込めればある程度はシステム部門でもメンテ出来る様になる >>864
これはだるそうっていうか、
コンパイラになった気分を味わえそう><
JAVA全く書いたことないんすけど
オブジェクト志向なら、せめて、
Big…("1") + Big…("2")
みたいに書けるように導入できないんすか>< メインフレーム時代の話は懐かしくなる人も多いだろう
自分がCOBOLやってた時代は、空調効いたマシンルームにメインフレームがありオペレータが操作、パンチ室で8インチFDにデータ入力するパンチャー
JCLはまだカードで床に落としてバラバラになると大変な事になってたな 5大Sierのどれとは言わんが、Javaの新規案件でStrutsを選択してるの見ると、
日本のあまりの、IT後進国ぶりに悲しくなるよね。
「VPNからしかアクセスしないからいいんですっ！」とか顔を真っ赤にして主張するけどよ。
新しいライブラリも使えないし、第一将来的にお客さんがそのソフトを流用して、
インターネットからアクセスしたいとか言い出したらどうするんや？
ああいうの見てると、45歳定年制度とは言わんが、勉強する気のない人は引退して欲しくなる。 >>868
自分でそういうメソッドを書けば済みそう >>870
実は、この物言いが、飛び付きやすいけど、よく考えなきゃならないはなしなんじゃないんですかね
日本の労働環境、賃金というか報酬というべきか、また
時間的自由度においても、なかなか、
新しいもの勉強していく時間とかとれないんじゃねえの？ >>869
いいなあＦＤ普及するまでは
信じ難いだろうけれど紙カード、紙テープ、磁気テープ（オープンリール）持って出張だよ
新幹線グリーン車に着脱可能なＨＤＤを乗せて行った事もある >>871
詳しい人きたー.ﾟ+.(・∀・)ﾟ+.ﾟ
だと、なんでそうしなかったんですかねえ？ てか、あるのかは、しらんすけど、
例えば、
1BD +2BDとか、かけるように導入できるもんですか？ >>862
パックだけかわからんすけど、項目そのまま命令で計算できると、
すごくはやそうですよね
アンパックも、負の数についてはそのままcharにはならないと、
そのまま表示印刷できるにも、ぎもんはかんざるんですが、
なんとなく計算機の進化の歴史的事情をたくさん含んでるのかなとか想像します。 COBOLの現場の方が超まったりしてて良かった記憶 >>854
多分だけどEVALUATEが使えるようになった(78年版）のと
同じ時に実装されたと思う
それより古いのは使ったことないです >>873
カード穿孔機カードで正しくパンチ出来てるかどうか確認するだけでも神経使っていたのに
持って出張とは大変だ
磁気テープはオペレータの代わりに、マウントしたりしていたけど結構重いしでかい
FD持っての出張は、ホスト専用端末から端末エミュレート可能なワークステーションに切り替える時かな >>876
古い記憶であやふやだが、
古いCOBOLに近い感覚で印刷・表示が可能
----9や****9などのパターンを用意しておいて
2命令くらいで編集ができる >>882
ああ 出力するとき0つけるかスペースにするかマイナスにするか
あったな Ｚ付けるのもなかったけか >>883
そう、ピリオド、カンマ、スペース（ゼロサプレス）、￥、＄、まぁいろいろ
新しいCOBOLだとレポートライター？ 数年前、ウチのマスターの院生でコボラーになったのがいる。2年卒業(修了)直前に基本情報技術者試験受けて落ちた奴だからちょっと心配だけど。 さっきから改めてPIC句でなにが書けるのかとか
計算のための項目と表示印刷のための項目がいっしょくたになってて、
色々な記述力はあるけど、
大真面目に等価なものを他言語でつくるとなったらこりゃ赤なり大変じゃないのかと
試してみるのにインストールしちゃいました>< >>1
蘇るとかじゃなくてCOBOL以上に事務処理に適した言語が今まで存在しなかった ぶっちゃけて、A項目なんて
数字とか記号いれたらアウトなん？ マイナンバーの管理がCOBOLだったはずだから当分無くならんだろ >>890
っていうか、よー知らんけど、
COBOLっても、端末？でやり取りする仕組みとか？画面単位で抽象化して端末に任せるみたいな仕組みみたいのとか
印刷もページ単位で、レイアウトを記述したりとか、
みたいのは、各社の独自の実装だったりするんすか？ >>878
それ以前は、構文の終わりが"."だったとかありましたかねえ>< いいじゃん、去年の米みたいに高齢になっても
COBOLでなにかやらせて貰えるって 実際のところ、どういう仕事があるのかないのかそこまでの話なのかは、
本が売れてるということから直ちになにかが言えるのかはわからない？ 日経ってCOBOLのことをむちゃくちゃ書いたり
こんどはあげかｗｗｗｗ
2000年ころまでの日経コンピュータ、まだ残してある
定期購読していたｗ今はやめたが 汎用機から撤退したメーカーって、そういう系列のハードとか全く作ってないんだろうか >>888
ひょっとして事務処理というものをなくせば
COBOLを成仏させてやれる？
>>891
技術的なとこは全然わからないけどそういうのは確か
オープンシステムに
メインフレームからdatデータみたく引っ張ってきて
PC側で
WYSIWYG(What You See Is What You Get)なんちゃらで
カッコ良くしたんじゃなかったか？
>>894
知り合いのマネージャークラス爺さんは
今も売れっ子。働き先を選べると聞いてる。
ずれたレスしてたら堪忍な >>897
>>894はそういう話っす><あってます
聞いておっ？と思う人にもいい仕事があるべき待遇で回るいいなと、真面目に思っとりまし。 うちの会社はホストだったなー
メーカー名のイニシャルで呼んでた
それで会社が見当ついたりされる世界
インターネットを控えた時期、COBOLで組んだシステムを
絶対に捨てられない訳を
寂しげに話を聞かせてくれた課長さんたち
生きててねと心で祈ったわ
出世してたわ >>898
よかった(;´д｀)
自分などは使えない社員だったので
見学に来た人に「これがイーサネットです」って
イエローケーブル見せる係w メインフレーム」のWikipeにあるだけでも、
オープン化が始まった頃の、当然全部置き換わってあとは滅びると思われてた動きの頃とは、事情が違ってきました的な？
ただ、想像の域を出ないけどいま使われてるそれぞれシステムに互換的なリプレースマシンがあるのかないのかは、
各ユーザにとって軽くはない？ >>901
事情は2kの頃にはわかってたはず
ワークステーションに置き換えるにはあまりにデカくw
自分には答えられるほど知識がないのでパスする
とにかく「カネ」と「上の意識」と「しがらみ」がネックと思う
それがいまだ生きてることに驚いてさえいる。落ちます identification division
environment division
data division
procedure division
専門学校時代の先生は、上から純に
あいでんとふぃくしょん でびじょん
えんびろめんと でびじょん
でぇたー でびじょん
ぷろせであ でびじょん
って発声してた >>897
＞ひょっとして事務処理というものをなくせば
＞COBOLを成仏させてやれる？
金融機関では預金や貸付の残高を管理したり利息の計算をするシステムにあたるから無理だろうね しーおーぴーえーえる COBOL
のネタはもう出た？ 今のコボルを解読して作り直そうとするからトラブるんでしょ？
やってることは入出金記録に毛が生えた程度だから一から作れよ
仮想通貨どもはコボルなしで作ったんだろ？ 同じ結果が出るシステムを数億かけて開発する意義はあるのか、って話 そもそも旧システムのバグがあったりするので同じ数字を出すのが至難の業だわな。 金融機関の勘定系はCOBOLしかないような気がする・・・ >>913
えーお前まだCPBOってないのぉ？おっくれってるぅ〜！
って感じで使えば良いのかな？ >>915
やべ、何でPだよ、「COBOってないの」w ワシの知ってる金融機関ではCOBOLを見たことはない!!
アセンブラとPL/Iじゃった。 COBOL一筋で金融系30年
生保とクレジットだけだがな >>844
このスレには、そのネタが判る人は結構いるね。 みずほのサグラダファミリア建設に奴隷が必要なんだよ
察してやれ 釣りなら釣り針がでかすぎるし
本気で言っているなら無知もいいところ 今のテックスタックでゼロから構築するとしたら
何使うべきなんだろうね？
AWS移行した銀行が無かったっけ
そしてペイパルとかは何使ってるんだろう まずgithubエンタープライズかgitlabを自社ホスティングして、
自動CI/CDパイプラインは必須としよう 詳細は不明だが、１次オンライン（？）２次総合オンラインは自行のPで
システム開発したんでないのか 一人一台のPCでExcelが使えなかった時代は
COBOLでゴミプログラム毎日作っているだけで給料もらえた
夢の時代だったな。
DAかMTからデータ読んでソートして集計して印刷するだけで
有難がられる良い時代だったわ。 アメリカ空軍の給料計算システムは今どうなっているのかな？
（Cobolはアメリカ空軍の給料計算を機械化するために女性が考え付いたプログラム言語） 処理系仮想化する方が安上がりな時代になったからなあ
ハードに先がなくてもなんとかなるわな >>932
確実に仮想環境とかエミュレータが用意される保障もないんじゃ？と思ったらおかしいん？ >>922
ためしに夜間バッチ一つpythonで書いて流してみたらいいんじゃね？
突き抜けなければ使えるのかも >>930
それを読んで「ラクで良いなぁ」と感じる人と
「やりがいねえなぁ」と感じる人が居ると思う >>933
今の物理的なハードウェアが壊れる可能性よりは
エミュレータの方が長期的に使える可能性のが高いと思うな >>936
エミュレータだれがなにをベースマシンにつくんねんねんな ハードぶっ叩きまでエミュレートする気はしないが、そこだけ入れ替えるのか 富士通に日立のがあるかはわからんですが
わかる人が生きてる間に作ってほしいねぇ
https://aws.あまぞん.com/blogs/apn/automated-refactoring-of-a-u-s-air-force-mainframe-to-aws/
AWS移行はこの辺のホワイトペーパーがわかりやすかった 芸人ヒロシに触発されて山買った奴ら終わるｗｗｗｗｗｗ ヒロシがとんでもない暴露ｗｗｗｗｗｗ
http://nkou.rutilus.net/VCLP/151537467.html 2410240 udhiv 研修時代にもらった富士通のテンプレート、バッキバキに折れながらも手元に残っている
この文字は9ポで、追加項目はちょうど住所欄の真下に来るように・・・とか、定規の部分で帳票出力での文字の位置取りとかやってた覚えが
半角1文字あたり1/10インチ、全角文字は2文字で半角3文字分占有だったような覚えがあるが、
手元にある生保の控除証明書と突き合わせてみると微妙に合わないな、どうだったんだか 電気関連工学部卒は、ASM ラダーで回路はやるんだが、いざ経営経理など管理系のソフトウェアは嫌がる >>947
経営工学ってどんな学問なんですかね
ってかunixばっかりじゃないですよね>< 俺が高校生の頃にパソコンに詳しい友人が「やるならCOBOLが良い。」
って言ってたが、結局俺はC言語ちょっとやっただけでプログラマーには進まなかったなー。 >>949
失礼><
意味不明ですよね
撤回します>< COBOL製品つったってWindowsやUNIXでは
Cで作ったランタイムライブラリくっ付けて動作させたりするよね？
帳票定義体での印刷やWebから起動とかもできるんだから息が長いんじゃないかな >>950
現実の実務を分かってる友人だったんですね。
パソオタだとCかオブジェクト指向に走りがちなんでw CASLを学んだのに解いたのはFORTRANだったな
BASICの知識で解けるんだもの >>905
>>907
発想の転換的な何かないかな、うーんうーん
事務をやる人はロボット化されていくのに、なぜだw レス数が950を超えています。1000を超えると書き込みができなくなります。
