富士通「助けて!汎用機やめたいのにまだ700台もあるの!COBOL100万ステップとか早く捨てろよ!」 [632443795]
■ このスレッドは過去ログ倉庫に格納されています
現状問題ないのに更新して問題起きたら困るだろの精神
衰退国マインド 副社長の島津さんってもしかしてあの島津?
島津製作所とも関係あったりする? >>2
COBOLは全然廃れてない
むしろ最も使われてるのでは
帳票出すの簡単だし金の計算も正確
何より過去の資産大して直さなくて使える
エミュレーターで何とかならんのか クラサバ化したりJAVAで動くCOBOLにしたり、なんならクラウドで動くCOBOLにしたらいい >>2
不都合なければ変える必要もない
メリット(売上とか具体的な将来性とか)とデメリット(不具合とか必要な経費とか)との兼ね合い COBOLは事務処理用として生まれた言語だしわかりやすいからデバッグしやすい そういうのはエミュレーターに移行するものではないのか >>22
2進化10進だな
小数点以下を扱う場合は分かりやすい ITが発達する前に作られたクシャクシャのソースがいっぱいあるんだろ。
怖くて置き換えなんてできねぇよ。 >>7
ゲームや動画と違って金勘定の処理に新しいものなんか出てこないからなあw
ネットワークは別の仕事だし SQLは使われてるのにコボルがレガシーなのなんでなん そろそろAIが勝手にマイグレーションしてくれるだろ >>13
レガシーなプログラムを今のプラットフォームに
移植するソリューションは普通にある
大昔のオフコンで残業してバッチ動かしてたのが
数秒で終わるようになったとかいう話を聞くと
物持ち良すぎるのも問題だな ま、この前のグリコみたいに
システム以降に失敗して大損害!!なんてふつーにある世界だから
そう簡単に以降出来るわけ無いだろ… 今はやりのAI使って今時の言語に変換すればいいだろ >>35
COBOLプログラムは高性能、高効率で業務に最適なソリューションのままですよ
最新の言語()なんかに移植しても実行速度が遅過ぎて実用に耐えないんですよ 100万ステップのCOBOLをAIに食わせてコボラーのAIを作ればいいだろ 廃止までのスケジュール出てるのにギリギリまで使ってなんとかなるだろ精神やめろ 開発案件が少ない言語だからな
グラフィカルな時代には必要ねーはね(´・ω・`) >>1
簡単に捨てられるもんならとっくに捨てとるわな。 >>39
汎用機で使ってるメーカー独自OSやDB、オンラインプログラムでの排他制御等、安心出来たな
何と言ってもマルチベンダーでなく、一つのメーカー保証だったから安心感が違った
高かったけど COBOLを置き換えたいと思ってもCOBOL技術者がすでにいない、いても単価が高くて出来ないというジレンマ >>8
うちバリバリ現役
自社でコーディングしまくり
逆にAS400しか使ってないから
AS400もう作りませんって言われたらどうしていいのかわからん
大変なことになるという事だけははっきりわかる。 COBOLやるひといっぱいいる
やりたいなwまじで
久しぶり >>33
SQLに代わる簡潔で可読性の高い言語が登場しないのがね
あと既存のメジャーなDBMSがSQLを採用した方が都合がいいって判断で切り捨てないのもありそう >>48
汎用機をオープン化する際にCOBOLのままの方が高効率を維持出来る部分と他言語に移行しても問題ない部分
こういう所の見極めがちゃんと出来ないと汎用機捨てたら業務効率が低下したとか遅くて使い物にならないとかが起きるんだよね
COBOLを馬鹿にしてる連中は馬鹿にするくらいなら覚えて対応してから馬鹿にしてみろ
としか言いようが無いわ
そんなに難しい言語じゃないよ? 富士通ってなんかイギリスで大問題起こしてなかった? 何もかもITで出遅れている日本
このままじゃ中国やロシアと戦っても電子戦になれば
火縄銃でマシンガンに立ち向かうぐらいのテクノロジーに差がついた戦いになる
ケツモチのアメリカ様だけが頼りだ AIがCOBOLのソースの可読性を高めることで
他言語への乗り換え捗るんじゃないかな COBOLが悪いんじゃない
COBOLでスパゲッティコードを書いたプログラマと度重なる仕様変更でスパゲッティコードを書かせた発注者が悪い 保守料で法外な金額を吹っ掛ければいいんじゃね
諦めて他に行くだろ COBOLってローカル変数あるん
昔の言語だから色々原始的そうなイメージ >>39
今はそこらのサーバでも十分速いけどね
富士通汎用機から移植して夜間バッチは格段に速くなった
ただCOBOLはシンプルな処理は読みやすいしずっと汎用機が有れば良かったんだけどね
どうせまっさらの新規なんてやらないんだからクラウド上で汎用機エミュレーター実装してくれれば富士通の顧客離れも減っただろうに 高校の頃のプログラムの授業がコボルとフォートランだったな
2つ下の学年からベーシックになり羨ましかった 汎用機からの脱出とCOBOLからの脱出を1度にやると失敗する うちは今年でやっっっと脱COBOLするわ。
5年ぐらい前に導入したパッケージソフトに統一される。 >>70
COBOLがスパゲッティになりやすかったのは
・COBOLのプログラム(exe)1つがアクセス可能なRAM空間が16MBまで
という糞仕様が2000年過ぎても残ってたからだよ
これを回避する為のテクニックがいくつもあってスパゲッティ化しやすかったんだよね
今時はそんな糞仕様も無くなり、オブジェクト指向で組むことも可能なんで使いやすくなってるよ >>75
> 高校の頃のプログラムの授業がコボルとフォートランだったな
> 2つ下の学年からベーシックになり羨ましかった
あんた、いくつよ? GO TO使うなw
他の言語でも BASICの連中もgo to だらけ >>74
特定のバッチ高速化はDECがサーバ売り込む際からやってる事だし当然でしょ
IBMのやった完全オープン化前のステップとしてZLinuxのサーバを大量並列稼働させまくってオンライン性能を維持させる
がやはり重要なんじゃないかな? >>86
RPGはどうなってるんだろうな
数年前までAS400とかのがあったが、これはIBM 海外ではCOBOL需要が増えてコードも3倍まで増えて使える人も増えてるそうだ
日本は方針転換できないお国柄だから減らそうと必至だけど >>85
いや、実際夜間バッチがサクッと終わるとぜんぜん変わるよ
汎用機に対してだいぶコスト削ったサーバーでもだし
オンラインの安定性なんかは出来ることが少ない分汎用機の方が今でもいいと思ってるけど結局会計系はバッチがどうかでしょう もう今の時代は頭いい奴は投資の世界に行っちゃうからな
ババ抜きみたいなもんで残ったもの負け >>89
AS400の案件見掛けなくなりましたね
今はSYSTEM iとしてIBM POWERサーバの仮想環境内で動いているようです
https://www.ibm.com/blogs/systems/jp-ja/ibmi_tandtrust_isv/ >>96
RPG は、ビジネスソフトウェア向けの高水準言語に位置づけられるプログラム言語である。IBM独自の言語であり、IBM-iまたはOS/400のシステム上で動作する。
これだぞ acos2はまだ現役なのかね
IDL2が好きでいい仕事させてもらったわ COBOLで十分なことしかしてないから変わらないし変えられない
余計なことをすると無駄や障害が発生する >>97
そこはお客様の考え方でしょう
バッチが終わったら翌日の業務の準備をすれば良いだけなのか
業務が24時間継続するのでオンラインの裏でダラダラと常にバッチ計算が動いてる方が嬉しいのか
などなど プロジェクトメンバーの8割が名刺を切らしてるという異常事態 PEFORM 1=1
富士通=アホ
END PEFORM COBOLの最大の利点は、構造型データレイアウトをソースでちゃんと表現できることだと思う。
PL/Iでもそれは踏襲されていたのに、Cを覚えたときこれじゃデータの読み書き大変すぎるし、金額の桁保証も無いし、事務処理はCOBOL一択だと思った。 >>63
大問題起こした会社を富士通が尻拭いしてやってるが正解 >>75,94
その時代に高校でプログラミングの授業やってたのすごいわ
ミニコンでもあったのか as400 rpg2
なついわ
おれが6502アセンブラで作ってるときに別部署でやってたな パソコンでエミュレートすれば長期にわたって今のソフトを使い続けられる。 ACOSとBOSからWindow系へのシステム刷新は3件やったけどもうやらねえ バッチてどんな処理してんの?DBの最適化みたいな? とっとと切らないから甘えに走る
引きこもりみたいなもん
マイコーソフトみたいにばっさりいかないと >>108
たまにVisual Studioを使うとC言語がおまけのような存在になっていて驚く
使えれば何の文句もないのだが隔世の感があるな 磁気テープ回ってたり紙テープでプログラム食わせたり嫌だ 古いシステム使ってるのって、ほとんどが政府関連の施設なんだよな。 >>79
言語仕様に要求スペックを盛り込むもんじゃないなあ どうせシステムだけでなく業務の仕組みそのものが古くてダサダサなんじゃないのかね
全部捨てて作り直せよ AS400とRPGは逆に将来安泰な気がしている
他社の汎用機とかオフコンが撤退していく中での受け皿になってコイツだけは最後まで生き残りそう >>2
基幹システムの心臓部にあるから下手に触れない
銀行だと債券管理とか勘定系とか。 >>112
多分パンチカードシステムでプログラミングしてた時代じゃないかな >>39
そう思うなら勝手にやってろと思うけど周りにいる普通のエンジニアと関わらんでほしい 時代遅れとなって、みんなヤメてく中、しがみついて辞めなかった爺どもは今や高給取りになってる。みんな辞めちゃってcobol技術者がレアになったが、システムはまだ残ってるから。 >>130
オーケー
新システムの新会社作って少しづつ移していこう >>39
誰もメンテナンスできなくなってから手遅れだと気づくんですね。淘汰されてください >>132
「PDP」って「PDP-11」なのだろうか?
消えるっていうか、PDP11が載ってる辞書ってなんだよ… >>2
金融機関とかのシステムは新しくしてみずほ銀行みたいになると困るから枯れた基幹部分は何十年も触らない。
2階建てを増築するみたいに基幹部分の上で動くスマホアプリとかポイントシステムなんかを作る 「COBOLやりたい」と言う若い子がおらんのじゃよ
マジで COBOLのコードを解析して
管理や改善に使えるソフト開発したら
もう少し延命できそう
モデルチェンジで何もかも新しくするのはハードル高い >>140
どこで動いてるのか今の子は知らんと思う >>140
そりゃ若い子じゃ居ないだろう
諦めて50代以上にやらせりゃいいよ
出来るようになったら月給50万にすりゃやる気だすだろ クラウド上にエミュレータ構築して丸ごと移設するしかないな 今でも汎用機を使い続けてる理由は処理が単純で絶対にフリーズしないから。
ホントは使い続けたいけど運用できる技術者が少なくなってるから仕方なく移行を進めてる。 >>137
GUIだけでもかなり余計なパワー使ってるよ >>72
30年前の派遣バイトにクビなってた人が来てた。俺は学生だったから大変なんだなぁとか思った COBOL使えるメイン世代が60歳前後だから厳しいね
基幹だけそのまま使って見た目はJAVAに置き換えたところが10年くらい前まではよくあった >>145
汎用機の良いところは安定性と絶対的な保守性なんよな
汎用機で20年同じプログラムを動かしても問題なかったのに移行したら数年おきに移行だのの問題出てきて嫌になる なぜCOBOLは現役なのにfortranとpascalは消えたのか
>>2
コボルはクソだけどコボルの入出力が明確な記法は保守性が高い。
逆に規模が桁違いにデカくなるとオブジェクト指向は保守性がやばくなる。
それで関数型と呼ばれるErlangなんかが台頭してきた。 ビジニューのbASICからコピってきた
ヤッホー、フォートランランラン!ヤッホー、フォートランランラン!ヤッホー、フォートランランランラン!ヤホホ!
ヤッホー、フォートランランラン!ヤッホー、フォートランランラン!ヤッホー、フォートランランランラン!ヤホホ!
>>152
fortranはGPUを何本も刺したサーバーで主流だぞ 鉄鋼大手はCOBOLとかPL/Iだったな。今は知らんけど。残っててもあの膨大な量をどうするのか オープン系の人間が、案件無いから汎用機でcobol使う案件にアサインされると、大概壊れて辞めていく。 >>162
COBOL簡単だぞ?
スパゲッティコードだって >>164
メインフレーム
日立→ハード製造撤退
富士通→ハード製造撤退
結果ほぼIBM一択になる COBOLerが作ったVBAのマクロはすぐわかる
クソどうでもいいようなところにも律儀にユーザー定義型を使ってたりするから >>167
これ
今からIBMやっとけばこれから単価ガンガンあがると思う
ジジイになっても仕事に困らない高級取りになれる
システムを作った当時の担当者が誰もいない設計書もない複雑怪奇な基幹システムを何とかして、っていう地獄のような案件だらけなんだろうけど。 COBOLって標準化されているようで実際はプラットフォーム毎に微妙な差異があることが多く
いまどきの環境に移行するのが難しいんだっけ? >>173
順調に動いていたレガシーシステムを捨ててSAPに移行しようとしてるのにやらかしで未だに動かず
製品出荷もできなくなって赤字を増やしてるグリコって例もあるからなあ >>177
新規で入らないからね
保守で食いつなぐようなとこに若いの来ないから この言語で召し食うてた方々は、かなり引退した後じゃ無いのかねえ >>2
富士通はサーバで動くネットコボルってのを売っててな、
汎用機のプログラムをそのままオープン化できる様に用意したんだよ コボルはどうでもいいけど旧型汎用機のタイマー問題は大丈夫なんか?
西暦一回転してバグる問題 >>166
簡単とか難しいとか技術者にとってはどうでもええんよ
ほんの少しでも学習コストをかけて理解した結果がアホな言語ってだけでストレスなのに仕様書が悉くクソやからテストに嵌るんよ
客も全容を分かってねえから前と100%同じ動作をしてくれってのを堂々と要件にしてきやがるし COBOLソースのプログラムをCに書き換えるのならやったわ 結局 一番早くて安定してるCOBOL
他の言語は使えない >>2
COBOLって十進数計算なんだわ。2進数計算じゃないので誤差が出ないのが利点。
まだまだニーズはある。もちろん過去の遺物のメンテだが。 みずほはIBMのzosに富士通COBOLソース移行したんだろ データベースの存在さえ知らないのがほとんどだろ?
富士通はネットワークデータベースだ。
GET ANY
それにVSAM、DAMを使ってるだろな。
SQLに移行なんてしたら、排他待ちと
デッドロックの嵐になるなw コボラーの作ったSQLのデータベースがひどかった
わざわざ固定長で文字列が全部空白で埋めてある
表の連結て概念がないから
一度PCの行列に読み込んでそこから再度ループさせてクエリ投げ直してる
一人だけかと思ったら数社渡り歩いてみてみんな同じ作り方してた 今でも1980年頃に書かれたCOBOLをメンテしてるが。何か >>7
新しい機能の追加のためにどうしても必要なわけでもないのにシステムを入れ替えるのは、「車輪の再発明」と同じで無駄以外の何でもないんだが
>>190
データベースが巨大化した時はその方が速い。
レコード数が億単位を超えるとそうしないとまともに動かない。 間違いだらけの黒人系アジア人とか要らない。cobolをそのまま使っとけ。>>1 昔の汎用機って巨大な冷蔵庫みたいな箱が幾つもあったのがデスクトップPC1台くらいになっただろ。 富士通もSAPに移行したからそっちへもっていきたいんだろ。 >>190
効率よく作ってテストデータでうまくいっても膨大な本番データを流すと動かなくなるんですよ >>1
COBOLが未だに残ってる時点でアレだなwwwww 社会インフラを管理システムで止められない(リスクが高くてHWの更新が躊躇われる)ものが多いから仕方ない。
例えば継続して数値監視しているシステムは、データ断続が発生すると深刻な問題や災害の見逃しに直結するから。
(水位や汚染濃度の監視システムとか提供電圧の監視システムとかね。) ブートキャンプはビリー・ブランクス
インチキレスラーはボブ・サップ
サップでは名前からしてダメだろ、詐欺られんじゃね。(´・ω・`) >>75
一年の頃Basicで二年になってマークシートを使ってフォートランのコード書かされた
面倒臭いんだわあれ >>202
そうして回避したつもりのリスクが積もり積もってシステム更新時に一気にくる
少しづつリスクを払ったほうがマシ 新しいものが必ずしも優れてるとは限らない
金融とか絶対に止まることが許されないとこはフリーズする可能性のあるシステムには移行できない。 >>209
ハズレのITドカタはCOBOLのソースコード読めないからwwwww >>183
>>166
原因は技術的なハードルではないんです
ソースと乖離したドキュメント類と
ドキュメントを放置してきた老害が原因なんです
ドキュメントに載ってないことをひたすら老害にヒアリングするのですが
「ソース見れば分かる」と言って無視
hogeに1をセットしている事実を知りたいのではなく、理由を知りたいのに
あげくコメントにも
* hogeに1をセット
しか書いてない >>213
いや「見直し」を業務としてしなかったツケってだけだろwwwww >>214
まさにそれです
そのツケを、オープン系からアサインされた若手が払うことになって、飛んじゃう訳です システム障害とかよくニュースになるが現代病みたいなもんだよな。
汎用機全盛の時代はありえなかった。 >>216
イマドキの若者、COBOLとかFORTLANとかのソースコード読めないでしょwwwww
>>217
みずほのシステムとか本当に酷いもんなぁwwwww >>150
みんなどこへ行った(定年退職)
見送られることもなく(最後まで残った猛者はだいたい見送ってもらえたぞ) 結局オープン系のシステムは使い物にならんから画面だけオープン系で作ってデータ処理は汎用機てとこもある >>222
それこそAIに学習させれば良いんだよなぁ・・・。 >>2
金融システムだと全く廃れてない
超大規模な金融システムだと
新システムでJavaに置き換えとか莫大な予算かかるからな >>17
プッチンプリンが食えないだろ。どうにかしろw >>217
安定して動いてるものまで今時古いという理由で強引にオープン化するからだよ 機器の問題ならエミュレータじゃあかんの
コードのメンテは置換しなきゃあかんやろうけど
多少遅くなった方が痴漢に前向きにもなるやろ IBMは諦めて終息しない。
chargptがソース読んで移植するとか余裕だと思うよ
今はポンコツだけど プログラムのことは分からないんだけどさ
メインフレームが700台売れ残りってどゆこと?
あんなの注文入るたびに仕様にあわせてワンオフで作るもんじゃねえの? 今動いてるものの更新予算出させるの大変だからなあ
うちもISDNなくなる話がなかったら今のシステムいつまで使うことになったか >>23
そもそもハードウェア自体の耐久性がパソコンサーバとは段違いなんだよ
50年フル稼働で動き続けるパソコンなんかないだろ? 汎用機って最先端でもTSSでしょ
開発やデバッグしにくそうよね TSSって何?味なプレゼント?
タイムシェアリングシステムってことなら、いまどきパソコンですら64コア128スレッドのプロセッサ使えるのでは メンバメイコボルスミなんとかっていう
くそおもんないというか、むしろそれを売りにしていた漫才コンビがいた 大昔 Fortranだけど FACOM 230-10 使ってたな
紙テープとテレタイプ端末だったか
その後 IBMの360になった(紙カード) COBOLのコードをmain関数だけでjava実装しないならさ オープン化が正義みたいに言うけど、圧倒的に遅くなったのを実感してる
一歩間違えれば翌朝までにバッチ処理が終わらんリスクを抱えてしまった 高校の時にFACOMが導入されることになって
トレーラーから電算室まで生徒総出で運ばされたから嫌い
ユニットひとつがロッカーや事務机くらいあるしクソ重いんだよ >>231
置換して問題起きたらどうするの
勘定系でそんなこと起きたらそらぁ身投げするレベルよ JavaのWebアプリとCOBOLの勘定システムの連携をやるミドルウェアの保守をやってた事があるけど
トラブルが起きるのはいつもJava側だった ソフトメーカーは新しいソフトを売りたいだけ。
現場がどうなろうが知ったこっちゃない。 メインフレームのシステムは処理時間がだいたい読めるからな。
そんなにブレないので計算しやすい。
オープン系は処理時間の振れ幅が大きい。
夜間バッチのスケジュールが重なって余計に事態を悪化させることがある。
顧客に原因を説明するのが面倒というか心が病む。 COBOLの問題なら、UNIX系サーバーでCOBOLコンパイラとリンカを作ればだいたい済む 汎用機で動いているものは、入力画面などは無いだろう
COBOLからSQLを発行しているのは、
RDBの移行を含めて、ちょっと面倒かもしれない 信じられないかもしれないが
COBOLはソースが仕様書なの
仕様書なんて見るだけ無駄のことも多い >>7
君が知らないだけでどこの国も古い施設は古いのを使ってんだわ
アメリカもそうだしイギリスやドイツも古い機材を使って変えてない
変えるコストとバグ取りが鬼門になって日本と同じく変えられてない >>257
富士通は普通にunix版cobolあるし使ったことある
jclとか周辺含めた環境だと思う。
とにかくおじさんは詳しいしなんでも知ってるし解決できちゃうのよ。
オープン系とは違いすぎるとオープン系、クラウドもやってるインフルエンジニアのおじさんの俺は思う >>260
それソースの定義場所が○仕様書というだけじゃね? 変数名が謎のコードになってて、それが意味するところは仕様書に書いてある >>259
それがあるんだよ
Delphiとか使ってな 仕様書と設計書がごっちゃになっている現場はグダるね。
ごっちゃにする人はわりと多い。
詳細仕様書は必要だけど、詳細設計書は不要。
ドキュメントの種類や枚数が多いのが正義みたいな現場は詳細設計書を作りがちだけど、大規模案件になるとだいたいデスマーチになるし品質も悪くなる。 仕様書ないならソースの中にコメント入れてどういう処理してるかわかるようにしてほしい https://www.cobol.co.jp/
のトップページの写真みたら
なんか楽しそうだった >>268
まともなところなら多少は書いてあるはず
毎回デスマーチになるようなところはそれもない >>261
イギリスでも普通に「動いてる法律とプログラムは弄るな」って言うしね お金の計算にかかわる部分だから
簡単には刷新できないのだろうな
万一故障したらエラいことになる💸 仕様書が古すぎて更新されてない
何故か何パターンもある
結局ソースを確認 コボルは取引企業専用のプログラムとかあるからな
企業コードとかベタ書きしてる 富士通の古い仕様書とかワープロのオアシスで書いたやつをスキャナーで取り込んだ時代のものとかある。
あとマニュアルはココム規制のこととか書いてあるね。中国ロシア北朝鮮には情報渡せない さあみなさんご一緒に!
COBOLはソースが仕様書
COBOLはソースが仕様書
COBOLはソースが仕様書
元々コードがそのまま仕様書になるというプログラム言語だからな >>275
ベースとなる仕様書が残ってるだけても保守のしやすさは変わってる GOTO文ばかりで飛び先は分かるが保守性は最悪なコードを見た事あるぞw
三菱電機でww >>167
GCOSの流れを汲むNECのACOSがまだあるぞ。
三井住友銀行がある限り、無くならないだろうね。
三菱UFJはIBMだな。日立もメインフレーム売ってるけど、中身はIBMだ。 昔書いたプログラムだとデータ領域制限でテーブルとか潤沢に使えなくて
HDDを主記憶代わりに使ってたよな
あんな効率の悪いプログラム今でも動いてるんかな 元コボラーに戻ってもらう
とか
若手にCOBOLを覚えてもらう
とか
どちらも高給() >>286
今のHDDはバッファ持ってるから大丈夫 大昔、大森別館でやってたCOBOLの研修に参加したことがある 京浜東北線 青い普通電車
蒲田の手前は大森
蒲田駅南、京急のところの富士通の研究所? >>278
SE課長がオアシスばかりしてないで仕事しろと怒鳴っていた このスレメインフレームばかり言っているが
富士通K GSのオフコンCOBOLは大丈夫か
NECのA-VXももうなにかに移行したのか?COBOL85は問題ないのか
メルコムはまだ三菱の本体工場、関係会社で動いているようだ
三菱は電機メーカーだから自社のハードくらい部品供給できるだろうな
IBMのことはいいわ
東芝とエルム?とか沖電気のハード、もうないだろうなw そうだNEC N5200がまだまだ稼働しているはず
全国でw 内臓BASICかな、まれにCOBOL85でうごいているはず PRIMERGY 富士通だな
日立のオフコンってみたことないな、アセンブラかなんかでハイタック8150を
みたような記憶 紙テープリーダー
懐かしい Mシリーズしってます
すごいよなw
昔銀行も行員のおねえちゃんが年中20度未満の冷蔵庫みたいな
マシンルームで磁気テープデデッキにかけとった
大卒のねえちゃんがw
冷え性になってつらいとw 富士通のコンピュータ部門は中国企業になったのだし、中国人の技術者てやはり出来る出来る詐欺ばかりの似非技術者で役に立たないんですよねえ?まずはそこから認めないと先に進めませんよ?>>1 Mは富士通だけでなく日立もMです
IBM互換
M780ha水冷だった、驚いた
今は自作のPCでも水冷だしw Mの紙カードの時代
銀行の女行員がパンチャーのねえちゃんから受け取った
紙カードをカートで運んでいるとき躓いて
紙カード銀行の廊下の散乱
大泣きw 順番に並んでいた ダイクストラのストラクチャーで記述してれば go toレスにできるはず
設計も構造化でね 紙テープは途中でちぎれても、事務用糊で貼ったらいいだけw
あの穴を読むのですw 大変 COBOLは1991年には廃れてたよな
C言語の時代になってて >>276
environment division >>269
契約形態は業務委託契約(請負契約)による客先常駐スタイルです
2020年に応募は終わってんのな
COBOL入門クリックしたら、懐かしくて涙出そうになったw 2012年くらいまでRPGの開発やってたけどまだ需要ある? >>303 これだね
1970年に発表されたIBMシステム/370は第3.5世代といわれ、先の超高性能電子計算機プロジェクトを突き放した。
1972年にIBMが実施したアンバンドリングは、それまでのソフトウェアやSEサービスはコンピュータのおまけという販売方法を根底的に覆した。
コンピュータ輸入自由化が時間の問題になった。
このような状況に際して、通産省はコンピュータメーカー6社を3グループに再編して、重複開発を排除した開発合理化を図る政策をとってきた。
その実現手段がこのプロジェクトである。
日立・富士通:Mシリーズ(IBM互換機)
東芝・日本電気:ACOSシリーズ(提携先がHIS)
沖・三菱電機:COSMO シリーズ(提携先がスペリーランド)
この3グループはそれぞれ組合を結成し、補助金を受けることとなった。 >>122
16MBは16bitシステムのメモリ管理用アドレッシング20bitって事だよ
要求スペックでは無く限界まで使えるように設計されてただけ >>128,135
1980年代に高卒の子が覚えて使ってたCOBOLが今の理系大卒、理系院卒には難解な言語だと思われている理由は何なんですかね?
資料も強化書も解説書も充実してるのに何故なんでしょうか?
今の大卒院卒の学習能力、理解力は1980年代高卒未満って事にしかならないですよね 若いころに官僚の人ともにお仕事を頻繁にしていて
何も知らない私
つうさん、つうさんという言葉
どこのお店の人かとw
通産省 今は毛さんw >>315
1970。80年代は商業高校でも
当時は大量に人が必要だったからです
当然女子大文学部、英文科の女性でも優秀なSE、プログラマが育ちました
彼女たち結婚、出産、今は手が空いてまたCOBOLでお仕事して数百万円の
ダイヤ指輪買って嬉しそうですよ
旦那買ってくれないんだって >>315
コンピューター言語は昔の言語の良いところをベースにしつつ、より書きやすいように進化してきたから、昔の言語より最新の言語のほうが断然書きやすい。
「tiobe index」を見てもらうといいけど、今なおたくさん言語が生まれ、日々改良を加えられているのです。 構造化やオブジェクト化がデタラメでだらだら書いてるから本人以外誰も触れないんだろ
無理に触るとバグの頻発でシステム停止
そういうことだろ >>315
検索してもサンプルコードが出てこないからです コード規約とかない開発現場ではのちに、そいつが
俺しかわからないように爆弾しかけて退職したとかw
また、自身の仕事を死守するために、ネットに嘘の噂を
流した連中が今も現役でいる
現役でやっている爺 AS400バリつかい、新大阪の超高いビルのw 覚えている
AS400もCOBOL動いったけ >>308
. が無い コンパイルエラーリスト山盛りプレゼント >>315
見たことも触ったこともないから
もうひとつは、COBOLにお金の計算以外をやらせようとするから よー分からん
お前らの話し聞いてるとCOBOLは優秀な言語に見えるが
自分の中では脱COBOL・脱汎用機みたいな流れなのかなと思ってる
コボラーがいないから保守できないからなの?
糞コードだらけなら今ならAIに読ませてリファクタリングさせたらほとんど治る気がするけど
ほとんどだとテストが大変だからやれないってこと? オープンよりメインフレームの方が優れている。
劣っているのはコスト。 うちにも帳票計算用のコードが結構あるわ。
デバッグやメンテが楽だし、問題が出た時の対処もし易いから未だに使われてるのもわかる。
今の開発環境は複雑になりすぎてメンテが難しいから、コボルの方が楽って事もあるんよね。 >>315
系統が違うかな。Cやpascalとは違う。
APL、アセンブラ、basic、cobolは今の言語とはかなり異質に感じるはず >>326
汎用機という古いハードウェアを使い続けたくないだけじゃないの?エミュレータに移してそのまま使えばいいのでは。 それでみずほ銀行はシステムを改善できなくて泥沼の状態が続いているのか COBOLとかJCLとか昔やってたからやりゃ出来るけど案件がだいたい銀行系か行政系で夜間バッチでエラー吐いたときの呼び出しとかあるからすぐ病むんだよな… >>326
汎用機のメーカー原因
ずっと値上げ傾向だしサービス停止のリスクもあるからオープン系に移行させたい企業が多い
残ってるのは安定を優先して値上げに耐えてる会社
言語が悪いわけじゃない >>292
元日立だけど研修はCOBOLだけだったよね
当時は勘定系がほとんどだったから仕方ないけど配属先はPL/Iだった COBOLって言語自体が廃れた原因は何?
言語が悪い訳じゃなければ今でも学ぶ人はたくさんいるはず >>330
たしかにCOBOLはお金の計算専門って感じの言語だよな
小数の2進誤差なんど許さない設計だし
CやBASICなどはFORTRANやALGOLなどの系譜って感じ >>340
お金にならないからかな?
一旦安定稼働してしまえば開発の仕事がなくなる PC-9801にLEVEL II COBOLっての出てたなあ、とふと思い出した
LEVEL IIって何のことかと思って調べてみたら、ANSI-74の言語規格での実装レベルか
そういえば80年代のパソコン雑誌には簡易実装の記事がよく出てたなあ 言語の特性上、汎用機や勘定系がメインで使われて
それ以外の場所ではより良い言語が現れて台頭したってことなのかな
汎用機や勘定系は安定を好むから仕事自体があまりなく仕事の多い言語を学ぶ人が増えて今に至る
と解釈した >>340
メインフレームの運用料が高い、これは事実。
開発請負メーカーが30年間変わってなかったりしてどんどんコストを圧縮した結果、給与の低い職場になった。
でオープンシステムにしたら安いかと言うとそんなことはなく、大森林隕石落下大火災レベルになることも多々ある >>340
言語が悪い
いや正確には言語を取り巻く文化が悪いのかもしれない
複雑な問題を細かく分割して単純な問題の組み合わせにして1個ずつ解決するということがやりにくいんだ >>152
FORTRANは数値計算の分野ではまだ現役。まあCOBOLも金融処理ではまだ現役だが。
PASCALはBASICとの競争に負けたので消えた。 >>340
構造化プログラミングが提唱される前の古いタイプの言語だから。 オープン系はちょっと負荷がかかったくらいですぐ止まる
こんな欠陥品によく移行なんてできるよな あれれ?みずほ銀行の「ミノリ」はコボルからJavaに自動変換って売りで始めたんだよね
その後いっぱいコボル経験者募集したのは何処に消えたの? >>349
パンチカードや穿孔テープも現役なのか? 顧客にお役所多そうだし切るに切れないのでは無かろうか >>354
未だにフロッピーを使っている役所はあるからな >>356
法律や政令で「フロッピーディスク」が指定されていたら行政の執行機関である省庁に
はどうしようもないこと
昨年デジタル庁で問題提起していたのである程度はオンラインで処理できるように
改善されているはずだが、そもそも立法側の遅いのは「モリカケ」、「桜を見る会」など
野党が的外れな質疑を繰り返して国会の審議時間を浪費したことによるもの
こんなのは政治闘争による妨害であって政権交代しようが延々と続く とっくの昔に辞めた会社からコボラー求むの連絡がいまだに来るぞ。
もうワシもジジイだから勘弁してほしい。 どういったところで現役で使われてるのか気になる
やっぱお役所関係かな COBOLで書いたシステムですけど
アセンブラもちょっと使ってます べーしっ君のコボルのおばちゃまぐらいしか知らんわ。 >>340
古いから
一部のコード変更しようと思っても
全体の中で名前がかぶってないか仕様書調べないと不具合を起こす
常に周り全てと不整合が起こってないか人が確かめないといけない
現代の言語は完全にモジュール化されててその中だけで話が済む >>362
まあ、そのモジュールやランタイムにバグがあると不具合の原因がこちらからではわからんけどな。
ソースだけでチェック出来るのはコボルの強味かね。 >>363
全部ソースがあるアセンブラも同じ強みを持つな 100万ステップってw
モジュール化出来ないんか。 >>366
今時の大物ソフトの規模と比べたらかわいいもんなのでは >>367
今時の大規模ソフトを1モジュールで書けるなら
人間を超越してるよ COBOLはすべてを1つのモジュールで書かないといかんの? >>3
保守できる人も保守パーツも既に枯渇してるんだよ。 >>353
そのころの入出力機器や記録媒体はさすがに絶滅したと思うが、ソフトウェアはなかなか変えられない。
ある意味、ハードウェアより変更困難で固い。 汎用機でCOBOLはBCDで計算するから,金勘定の計算で誤りがでない.
BCD計算命令あるCPUを作って,それで計算する言語ができて,その言語に
COBOLを変換できれば汎用機も止めれるだろう.
0.1+0.2が0.3にならない言語は怖くて使えない.金勘定の世界では.
一応,AdaはBCDでいけるけど,COBOLをAdaに変換はキツイだろうな. >>190
非正規化データーベース設計
昔のプロラマーは偏差値70レベルの高学歴が多かったのでバカにできない >>218
みずほ銀行のシステム開発のプロラマやった事あるけど、あそこは3つ位の銀行が合併したので役職の席が減ったのでお互い足の引っ張り合いでピリピリしててヒステリックに怒鳴り散らすような人ばっかりだった。あれではまともに動くシステムはつくれないだろうなあ NetCOBOLとかでオープン系に移行できないのかね
ランタイム上で動くことになるけど >>343
LevelⅡでやったことあります
パソコンでしかもDOS上で動くのは当時しりませんでした COBOL/Sってなんか嫌いというか、そこでやっておられる
独自のモジュール規約
ACOS上だった でも変w >>355
8400GSというNVIDIAのグラボありますw ファン付き LGA775自作機で動いてます
win2k xp vista 7 8.1 10のマルチブート機です
とGS8000は富士通のGSのことなのにw 1990年代に今の超巨大企業ソフトバンクがCOBOLの本を出版してました
まだ小さい零細企業のソフ銀w モデムも京都四条通りで配ってなかった時代w あーあ
印刷が地獄
こーんな、でっかい帳票だ、ログ?
でかい紙だれが確認すんだ?
ばっかだろ HDDディスクパックなどと言った時代ですがHDDにログ放出は無理ですねw
容量ないし
だから応用用紙にパタパタ
または高速レーザープリンターに、フラッシュw
応用用紙ひと箱に、半角1だけひと箱印刷した同僚がいました
プログラムミス メインフレームシステムコンソールの横に置いてあった
ドットインパクトプリンター、インクリボンメビウスの輪
ラインプリンターは個人でも98にアンフェノールでつないで
やっていたひと多い
インクジェットが発売される前 >>375
システムの共通化をせずに、それぞれの銀行のシステムや業態に変換するなんてトンデモ仕様だって関わった友達が言ってたな。 銀行系の案件入ったけど上流がコボラーばかりできつかった コーディング用紙に書いていた時代が懐かしい
設計書も鉛筆シャーペン消しゴムでw
電電公社のパンチャーのいつもおねがいしている綺麗な(想像)女性
コーディングミス一部したら付箋で訂正してくださった
私よりよくご存じノパンチャーのお姉さまw テンプレートw思い出した
構造化ヤックツーチャートも思い出した >>369
CALL文というものがある。
外部プログラムを呼ぶことできるよ。
CALL文で呼ぶモジュール自体はCOBOLで記述する必要はない。 元号変換は今はどうしているのかな
当時はCALLで 1988のとき >>381
COBOL/Sはプリコンパイラではなかった?
Cで言うところの#◯◯関連と同じことやってるはず。 >>369
汎用機ではわかりやすい処理をJCLでつなげて誰でもわかりやすくが基本 >>394
後にDOS3.3 5.0AでターボC ボーランドCをやって、もうCOBOL/Sのことなんか
すっかり忘れてましたw
そうなんだ#ね 平林さんのC言語辞典お世話になりましたw
書庫にCOBOL関連の本も読んでみる
なぜか家にJCLなどの古いマニュアルがあるw
yac ibmではHIPOです >>400
CもCOBOLもほぼ忘れたわ。
JCLも忘れたな。 >>401
JCL N5200ではJS ジョブストリーム
DOSでもAUTOEXEC.BAT お忘れになってもコードを見れば思い出しますよ
最近は仕様書類がいい加減だからソースコードを解析して
書類通りかを確認して再構築する案件もありますw >>402
研修でN5200でCOBOLのコンパイルしてたことあるわ。
8インチフロッピーだった記憶ある 笑 パンチカードでぶいーんバラバラってのはやったことあるけどFORTRANだったな >>404
N5200はそもそもACOS汎用機の端末利用ですが
PTOSというオペレーティングシステムでBASIC
COBOL85とか表計算とかワープロが動いてました
スプレッドシート、DOSでは労を足す123 ワンツースリーwの
時代 Unix系だとシェルスクリプト。
CP/Mだと名前は不明だがSUBMIT用のファイル。 >>406
PTOSは研修中に使ってたな。
仕事で使ったことは一度もないな 笑 >>409
使ったことはないが 笑、COBOLの文法強化したものがCOBOL/S。
NECが開発した。 訂正します ソースコードが正しく、書類がいい加減w
うあぁどれがほんまや?wwww
稼働してみないとわからない
ロードモジュールが最新でソースコードが古い
恐ろしいわw 昭和平成の元号変換のコード書き換え
もうへぇええええとか叫びw
2桁、他にも古いコード眺めていたら
今偉い人々の昔やった記録と名前
もう嫌徹夜でやったあの当時
残業代ありがとうw フル支給 2000年問題は逃げました
お家でNHK国谷クローズアップ現代みて絶対に逃げたると思ってましたw COBOLやFortranよりもアセンブラで書いたほうがコンピューターは速く動くからアセンブラを覚えろと言われたことがあったが結局アセンブラは覚えなかったな >>414
メインフレームのアセンブラはマクロアセンブラ。
標準マクロや自分でマクロ定義もできるが、柔軟性が高いため、きちんと管理しないとわけわからなくなると思うわ。
アセンブラもほぼ忘れた。 プッシュ ポップ スタック オペランド アドリブランドw
パイプライン 石油ガス あどさぶまるてぃでぃばいど 分ける division
寝るかw
NHK深夜の隙間梅番組フィラー COBOL FILLER アセンブラも楽しかった
ABS 絶対値
車のALB ABS アンチロックブレーキシステムじゃないよ >>414
COBOLもコンパイルした時にアセンブラに変換してるだけだよ
DATA部とプログラム本文の間に隠れたレジスト部分があって
ここでアセンブラ風の構文が見えない形で書かれてるから
DATA DIVITIONの最期の部分に固定長の間違った短いDATA文書いてしまうと
見えない構文が実行時に上書きされてしまい、プログラムが機能しなくなる COBOL 求人検索 爺でも良いというのがたくさんあるw
がんばろうっと、おやすみなさい EasytrieveのCAがブロードコムに買収されて
クソ値上げ提示されて
コボルに戻す作業が急ピッチで行われてて
コボルやってた年寄り求人がいま盛んなんだよ >>190
どっかの銀行のAPIでCSV読み込ませる時今でもそんな感じで作らされてたわ >>374
頭の良い人達が汎用機やら索引順編成ファイルやらの環境で最大の性能を発揮できるように考えてくれた素晴らしいやり方を
オープン系のRDBでもそのまま守り続ける頭の悪い人達がよくないってわけだ
素晴らしいやり方が素晴らしくなれる条件とかぜんぜん考えちゃいねえ >>326
COBOLは古語で書かれてるって考えれば良いよw >>388
一強なら簡単だったのに対等合併のせいでキメラ仕様だから https://qiita.com/ipponshimeji/items/a89038c58b9466a497ab
COBOLが10進演算得意ってのはよく聞くけど固定小数点なのね
そこをきっちり再現できないとベタ移植は大変なことになる、と >>190
数億件データを日次で動かしてた
ADABAS構文をSQL構文に変えたら
全く動かない
まあそうだよな ■ このスレッドは過去ログ倉庫に格納されています