【IT】横浜銀行が脱メインフレーム。Redhat＋PostgreSQL＋COBOLでオープン系に移行。
■ このスレッドは過去ログ倉庫に格納されています
「今を逃すと10年後」、横浜銀行をオープン化に踏み切らせた危機感
2021.04.21 日経クロステック
「今を逃すと10年後になってしまう」。横浜銀行の小貫利彦執行役員ICT推進部長は、勘定系システムのオープン化に踏み切る理由をこう語る。
メインフレームの更新は10年スパンが原則。ここで決断しないと、次にメスを入れるタイミングは遠い先になってしまうわけだ。
横浜銀行を中心に、北陸銀行、北海道銀行、七十七銀行、東日本銀行の5行が参画する共同利用システム「MEJAR」が、オープン系の
システム基盤を採用する方針を固めた。2021年4月には本番開発に着手しており、2024年1月にも稼働させる。将来的にはクラウド移行も視野に入れているという。
■「メインフレームからの脱却」を狙う
最大の目的はメインフレームからの脱却だ。2017年には日立製作所が同領域のハードウエア開発から撤退することを発表した。
MEJARは富士通製メインフレーム上でNTTデータの勘定系パッケージ「BeSTA」を稼働させているが、対岸の火事ではない。
国内ベンダーがメインフレームの開発から手を引く動きが続けば、ハードウエア供給側に価格を巡る主導権を握られてしまうと
いう危機感がある。この点は、アプリケーションの開発・運用を担うNTTデータとも利害が一致したようだ。
目先のメリットもあるという。横浜銀行は今回のオープン化によって、ハード費用や運用費を圧縮し、勘定系システムを巡る
ランニングコストを3割削減できると見込む。システム更改費用を勘案しても、コスト面で有利だとする。
https://xtech.nikkei.com/atcl/nxt/column/18/00001/05491/
https://cdn-xtech.nikkei.com/atcl/nxt/column/18/00001/05491/ph.jpg
https://i.imgur.com/KeRx8Iy.png
>>1の続き
システム更改に当たっては安全性を優先させる。アプリケーションの仕様や言語に大きく手を加えない「リホスト」方式を採用した。
OSは「Red Hat Enterprise Linux」、データベースは「PostgreSQL」に置き換えるものの、アプリケーション部分についてはBeSTAを
温存するほか、COBOLプログラムは富士通の「NetCOBOL」に移行する。勘定系システムへの機能追加も凍結させるため、
新旧システムを比較するだけで問題の有無を見極めやすい。
地方銀行による直近のオープン化事例として、静岡銀行が挙げられる。アプリケーションの刷新を伴う「リビルド」方式で臨んだが、
2度の延期に追い込まれた。2021年1月に稼働に至ったものの、システム障害が続発した。MEJAR陣営は今回、リビルド方式は
ハードルが高いと判断したもようだ。 オラクルのせいでCOBOLでマイグレなんていう意味不明な事態にw 横浜銀行は待ち時間長過ぎる
みずほ銀行のように落ちぶれたな その構成でCOBOL？
既存ソースを流用したいということなん(´・ω・`) COBOL維持してどうする。
こういうのを問題の先送りって言うんだよ。 >>6
どういう事？なんでCOBOLとオラクルに関係あるの？ 稼働したばかりで不謹慎ながら
OMCSってコケた時の責任ですごい揉めそう >>9
少数の高価なコンピュータに何でもやらせるってのがメインフレーム
それを作ってる会社が撤退するから
小さい安価なコンピュータを何百台も集めて動くように変えましょうって話だと思っとけばいいよ 数年後に言語変換するんだろ？
ベンダーに余計に金取られるだけだっての。アホか。 >>5
Oracle回避だろ
とにかくオラクルから可能な限り縁を切るか
どっぷり漬かるかしかない >>21
javaのライセンス料やろ
普通はマイグレなんてCOBOL→javaにするもんや 次は「動かないコンピュータ」の記事で取り上げられそう >>14
基本的にはデーターベースからの数字の出し入れだからCOBOLでも別に困らんだろう
細かいところはデータベースのストアードプロシジャなんかで処理するだろうし >>28
>MEJARは富士通製メインフレーム上でNTTデータの勘定系パッケージ「BeSTA」を稼働させている >21
jdk有料化でjavaだと金かかるからじゃね？ 保守より現存機能の維持を選択したんだろ
規模は違えどみずほ見て懲りたんだろ
いい選択だとは思うが レッドハットってすごい高いけどサポートって何してくれんの？ なんだかんだでCOBOLなんよね
むりやりJavaにしてもしょーもない >>9
雑魚が集まってもサイヤ人に勝てないと予想したピッコロは今のうちに御飯を鍛えることにした >>49
ステークホルダーに安心感を提供してくれる。 横浜銀行クラスの規模でもポスグレでやれるのか
なんだかんだでボラクルの呪いからは逃げられないかと思ったが
銀行側に理解のある人が多いのか いっときはCOBOLは絶滅すると言われてたのに…(´・ω・`) 新しいプログラミング言語は次々と出てくるんだし
銀行専用の最新言語も作ればいいのに >>55
昔のシステムだともうドキュメントなんて無いからな。皆リスクを避けたいし、これからもしぶとく残り続けると思うわ >>55
Java化してクソ遅くなったり運用が柔軟にできなくなったりで、COBOLの需要はまだまだある
知り合いのオッサンは定年まで完走できそうだわ >>54
メガバン系でoracleから移行したシステム作ったから
それを実績として他に売り込んでるタイミング >>54
VMの時代にオラクルのライセンスはおかしい
オラクルに割り当ててないCPUまで金取るからな 不明にされてるが、ソフトバンクもlinuxとCOBOLらしいし
みんなそうなるんじゃないか、業務系統 時代はクラウド！クラウドならサーバーいらないんですよ
R4 >>45
マイグレーション
機能を変えずに古いコンピューターから新しいのにプログラムを移植するってことや 金融系システムはCOBOL以上に親和性ある言語ってないよね？ >>36
ストアドプロシージャはやめとけ
次の移植で地獄を見るぞ >>69
大して違わんくね？
速いのが欲しいならSAPHANAとか使うでしょ PostgreSQLは追記型のDB。これをどうとるか。 ひと頃のJava信仰はなんだったのか
今人気のpythonもそうなるのだろうなあ そこまでやるならもうCENTOSでいいんじゃね？
サポート有る無しにかかわらず人件費は発生するだろ >>14
現在運用しているソースコードを読んで理解できる人がいないからそのまま流用するしかない、というのが正解だと思う。 トムとジェリーをキャラクターに使ってた頃が最強だった 地元だけど死ぬほど不便だからここは使わない
給料振り込みに指定されて強制されてる人はそこそこ居る模様 貧すりゃ鈍す、か
東大に進学された先輩が就職なさった先だが、なんか悲しい BeSTAってパッケージは言語は独自なの？
どうやって作り込みするんだろ。 新しくするということは古いものを捨てる事
あとは覚悟次第 COBOL廃止すると今いるオジサンたちが失業しちゃうから仕方ないけど
先のこと考えたらCOBOLは捨てるべき
メンテできる人材が死に絶えるから 数十年後、メインフレームの方が良かったと後悔しないの 不完全な運用で北朝鮮からハッキングされる未来が見える だいぶ前に、メインフレーム撤去を経験したけど、メチャクチャ大変だった
メインフレーム側で、データ移行用プログラムを短期間で、大量に作るハメになった 他所の金で実験してもらえるんだから静観するのが正解 >>46
サブシステムをJAVAにしてみたけど思ってたほど良くなかったパターンで
メインの部分はやっぱりCOBOLのままでいいですって需要が根強かったのかもね データベースが原因の事故が起きた時、表向きとは違ってデータベース屋がある程度補償するのが通例になっていてさ
大手のデータベース代って一種の保険料みたいなものになってるんだよな
そこを浮かすって言うのは、いいことだけじゃない気がするんだけどな・・・・ よく分かんないけど、銀行業務ってどこも同じなんだから、どっかのオープンシステムをパッケージ販売してもらってそれ使えばいいじゃん。
なんで出来ないのか専門家さん教えてくろ？ >>80
CENTOS自体はRHの開発チームが終了宣言してるし
金融ってサポートの有り無しを凄く気にするから
OSレベルでトラブルがあった場合にベンダーさん対処できますか？と言われ
流石に全部は無理って事でそこだけ有償サポートのある物を選んだんだろう CentOSのニュースはそんな昔じゃなかったと思うんだが
タダより高いもんはない >>68
数値がデフォルトでBCDなのがいいよな
固定長データでバッファオーバーフローなんかのリスクも少ないし まあ古い銀行は現行システム使い続けて新しく参入した利便性の高いところに飲み込まれれば良いんじゃないの >>106
フロントエンド処理に使うわけじゃないからユーザーの利便性はあまり関係ないようには思うけどね でもCOBOLなんだ
てかこのメインフレームの処理能力はどれくらいだったんだろうな COBOLちゃんと書けば可読性かなり高いから別に悪くはねーよ
GOTOとラベルばっかりのはダメだが ポスグレってSymfowareのOpenインターフェースではないんだ。 >>99
FLEXCUBEってのが世界では強い銀行勘定系パッケージ
まあOracleですけど 無理矢理オラクルJavaで作り直すより。
LinuxサーバーでCOBOLをエミュレーションさせたほうが安定するし安い
そういう話？ COBOLってAWS Lambda上でも一応動かせるんだよな、導入した企業が存在するか知らんけど
メインフレームは止めるけど、COBOL資産はそのまま使うって需要はあると見込まれてるんだよなあ >>33
昔の富士通ホストのDSSがIBMのまるごとコピーで
シスログにCOPYRIGHT IBMって出たことがあるって聞いた オープンシステムってMWのバージョンアップとかで無駄に更新が入るイメージしかない でもぶっちゃけ
raspberrypi500台にqnapとmysql+pythonで作れるとは思うわ
勘定系って結局のとこ誤算訂正付きのCPUが要るだけでソフト部分は何でも良いからな
それこそFT系のサーバー入れたらそれだけで数千万だからな >>123
作れるメーカーが減少して、値上げされるかもしれないからって書いてあるべ 脱メインフレームは年間保守料と各ライセンス料が高いからってのもあるんじゃね？
とはいえ、MWのアップデートで対応する工数考えるとどっこいな気もするけども 移行に失敗して客の預金が吹っ飛んだといったことは過去にあったりするの？ >>123
自分が経験した頃は、主な理由は巨額のホストのレンタル料削減だった >>123
次の取替まで技術が残ってないかもしれないから >>24
>>28
ありがとう御座いました、おかげで髪が生えました
>>52
ハゲろ ホスト機利用料が高い
ユーザー減る
ハード開発や技術の停滞
将来不安
こんな流れなんか オープン化でランニングコスト下がるってホントなのかねぇ？
ベンダに払う金だけがコストじゃないと思うんだが。 >>89
.NET COBOLとかできないのかね。 >>26
ついでにIBMともてを切っとくと良いんだけどね
金融系のネットワーク絡んだ人は必ず言うね IBMCは糞糞&糞って 多重下請けの連中や折衝しかできないバカ1次請けに金の計算できるわけねーからな
既存プログラム流用したほうが計算ミスは発生しないからいい判断 >>123
メガバンクとちがってここいらの規模にはオーパースペックすぎるんじゃないかな。
4CPU構成のWindowsServer6台のクラスタでも処理速度は足りると思う。 >>99
ネット銀行とかは普通にパッケージ使ってるよ。
日本の大手銀行が、この種のパッケージに移行できないのは
古臭いローカルな業務慣行みたいのが多すぎて、業務を標準化出来ないから。 これをオープン化って言うのも違和感があるけど
塩漬けにするならCOBOLそのままってのはアリだな
COBOL技術者が消える頃にはマイグレなんて完全に人がやらんでも良くなってるのでは >>99
銀行そんなたくさん要らないし銀行減らしたらいい >>123
もはやメインフレーム向けのCPUすら二十年近く新規に作ってないんだが。
レジスタが大きいIA64が販売してた頃は
これを使ってメインフレームのエミュレートができたが
今やそれも生産終了。メインフレームは完全にオワコン >>26
エクソダスできて羨ましいな
うちの会社はどっぷり漬けよ >>146
利用者が減ったからハード開発が減衰したって話じゃないの？ >>149
CPUの開発コストが上がったっていうほうが近いだろ。
昔からメインフレームのCPUなんて大して数出るものじゃないし。 >>141
ネット銀行って融資業務とか口座振替とか段違いに少なくないか？為替もしかり
業務の範囲が全然違うというか 結局、維持費が高いから安くしようぜってこ事ね。
ほぼマイグレで行くんだろうね。
ツール作っても対してかからんだろうしな。
手作り部分がどれだけあるかね？ うちの会社も今COBOLのマイグレやってるけどマジ地獄
マイグレ実績ありまーすって謳い文句のとこに発注したらしいんだけど、VOS3はやった事ありませんでしたとか今更言うなボケ >>154
VOS3レベルだと、かなり巨大なシステムだな
普通の会社は二の足を踏むと思う 基本設計を理解してないんだろうな。
だから部分移行もままならない。
一年の収支が合うようになれば元のシステムなんて必要ないのにね 銀行のシステムはフリーズが許されないからメインフレームを使ってるんだが大丈夫？ >>148
なんかcentosでファン切りした感じ。 >>106
新しいところは業務絞って参入してるだけだからな >>135
＞>>89
＞.NET COBOLとかできないのかね。
それが富士通の、NETCOBOLなのでは？
"NetCOBOLは、マイクロソフト社の.NET Frameworkに完全に対応しています。Webアプリケーション、Webサービス、Windowsアプリケーション、コンソールアプリケーションなど、.NETの特性を活かしたシステムをCOBOLで構築できます。"
だとさ >>5
NTT系列はIBMと親密。
IBMはDB2をパクられた恨みでOracleと敵対している。
かと言ってDB2はポンコツだし、NTTがスポンサーのPostgreSQLを選ぶしかない。 >>116
「何でこういう処理をここで行ってるか分からないが、これで何十年も業務を回してきた」
という処理が沢山あるからやろ。
特定の個所の部分に謎のロジックがあるだけではなく、メイン処理の筋の運び方自体がすげー
動かし方してて、これでこれまで上手く行ってきたのは「たまたま」かもしれんから、
ソースから仕様書を起こすのが怖いパターンもある。
何のためにやってる処理か分からん処理同士が組み合わさってたまたま業務が回る結果を出してるのであれば
もはや言語を変えるという話にはならないわなｗ。このソースで行くしかないｗ
違う言語にすると小数点以下の計算の部分とかが微妙に違ってきて１円の違いが出てきたりするかもしれんし。 >>134
それは本当。時代とともに確実に下がってる。
特にメインフレームからオープンは絶対に下がる。アホみたいに下がる。 >>165
>>166
COBOLもFortranも言語として名前は残ってるけど
すっかり主流から外れてしまったな
結局、言語名としては使われなくなったALGOLの系統の言語だらけになったな >>169
利用者側もそうだが、システム運用側も熟知してる人がどんどん引退しているんだろうな
メインフレームのマニュアルは、大きな複数のロッカーにギッシリ詰まる位あるから、セレクトして
読み込むだけで相当日数がかかる。
市販書読んでどうにかなるものでも無いし。 >>68
EASYPLUS っていうのがあって
日本のアシストっていう代理店が売ってたけど
日本CAって言う会社が扱うようになって
価格がとんでもなく跳ね上がって
脱EASY、COBOL回帰してる >>4
クラスも普通に使えるよ？
今のCOBOLは お、netCOBOLの経験あるぞ。
年棒いくらかね。 とりあえず今のところ横浜銀行のユーザーで良かったって感じ >>178
あれJCLに直で書いてリスト出力させるのに便利だったんだがな
ただ、本番でそれやってて某銀行は大変な目にあったと聞いた 仮想化環境でバッチ処理かな
トラブル対応は迅速になるよね >>170
共同化とかもそうだけど、値段下がった分、目に見えない何かを失ってる気がするわ。
有識者の経験だったり、対応の早さだったり。
多分、次に大規模更改するときは完全にベンダの言いなりなんだろうなぁ。 >>134
下がるんだろうけどそれまでの正常稼働してたシステムやら経験値やらの資産がなくなるから一長一短じゃね
長い目で見たらいつかはやらないとダメだと思うけどね yum -y update
で動かなくなるんですねwww >>123
ここに関しては富士通のを使ってたみたいだけど
富士通自身が脱メーカーの動きを加速しまくってるから
ユーザーとして不安を感じてるのかもな >>141
それはただ新しく出来たところは、そういうパッケージがあるなら
それに合わせて業務を構築すればいいけど
そんなもんが無い時代から業務やってたら独自のルールで構築されるからだな
途上国が何もないから一気に進んだ設備を入れられるのと一緒 >>190
未だに独自システムでやってるのは日本だけなんだが
海外は大手でもパッケージだぞアホ 昔、メインフレームの生ログを解読できるジジイがいた
そういう職人というかびっくり人間みたいなのもだいぶ前にお役御免だったろうな JAVAもoracleになって有償化とか微妙になってきたからな。
言語仕様もごちゃごちゃしてきたし。
それならCOBOLも悪くないと思う。
DBもPostgreなら最悪富士通で何とか出来るだろう。
symfowareの関係で中身をよく知ってる人がいるだろうし。
ライセンスもBSDなんで改造する手も使える。 enterprise postgresなんてものがあるんですね
symfowareとの違いがわからないけど 仕様や言語に大きく手を加えない？
ってことはまたまたRDBに索引順編成ファイルみたいな繰り返し項目だらけのべたっとしたデータを入れるのか。
正規化？JOINってなんですか？って世界が続くのか。
ほんと馬鹿な話だよ。 >>14
何気に需要でかくて羨ましい
俺はForttanだったが需要はイマイチ
とはいえ機関系はやりたくもない >>22
俺の古い知識じゃデータがでかくなるとクソ遅くなる
結局オラクルに土下座する未来が見える >>27
難しい処理でもないしCOBOLで十分なんだろうな
帳票とか優秀だろ
知らんけど >>74
ORCLEが買い取ったのが転機だな
金むしり取りことしか考えてないから
みんな逃げてるんじゃね >>191
そのままIT技術の低さに反映してるな
元請けから下請けに半額で投げるだけの簡単なお仕事 もはや電子マネーもおおいんやし小数点以下の端数もガッツリ演算させたら うちも早くCOBOLを無くさねば。
若い技術者を集められないのが痛すぎる。 COBOLは処理は早いけど将来的に保守できる人いなくなるこらやめた方がええわ 変にUNIXやLINUXとかにこだわらないで素直にWindowsサーバーに移行でいいのにな
どうせ莫大な金払えるんだから有償か無償かなんて気にしねーんだろ？ >>210
速いだけでなく、ちゃんと構造化プログラミングされていれば、ソースも読みやすい >>212
Windowsはやめとけ
普段WindowsServer使ってるけど、正直不安定すぎて銀行のシステムには向かないと思う。 >>168
> IBMはDB2をパクられた恨みでOracleと敵対している。
ジム・グレイ引き抜いたのはマイクロソフト
SQL Server が version 7 から DB2 なみに手のかからない DBMS になった >>209
やめとけ
代わりの言語が急に
「オタクの顧客数いくつ？じゃあ契約金今までの10000倍ね」
ってなるから COBOLしか使えないおっさんだけどもうあの環境で開発するのは嫌です。 普及している丸めが発生しないプログラム言語さん側にも問題がある >>200
あれはMicrosoftでしょ？
結構前から導入してる日立ならともかく、富士通が一気にそちらへ切り替えるかね？ IBM360なら使ったことがある
モデル２０
パンチカードだ >>184
トラブった時の対応は変わってくるな
メインフレームならハードもソフトも自社で、会社の威信をかけて対応にあたる
オープンだとハード、OS、ミドルのサポートをたらい回しにされて大変よ
外資なんて直ったからいいでしょの精神で原因究明まで付き合ってくれんし >>224
一般の人が目にする事はあまりないんじゃないかな。
役所や小売店で使ってるパソコンをチラ見すると、緑の背景に白い文字で作られてる画面を見る事があると思うが
大抵 メインフレーム（大型汎用機）の端末で、今はWindowsの上に専用端末のエミュレータソフトで
動いている。
後は、今もストックフォームに印刷された物を見ながら仕事をしている所もある。 >>184
ベンダに最初の改修で荒らされてそのまま見捨てられる可能性もある 言語やプラットフォームなんて、何でもいいんだよ ランニングコスト削減なんて嘘に騙されて不安定なハードウェア使うのが不安でしかない 富士通みたいな蛭企業がへばり付いているから、失敗の予感しかしない もはや解読不能なノウハウがCOBOLのソースに埋もれてんだろ。
Javaとかにする場合でも、COBOLのロジックをそのままJavaに置き換えるしかないレベル。
なら、COBOLでいいじゃん、その方が安全だろという話。
ちなみにVB6とかもCOBOL化しとる。 そもそも マスターファイル、トランザクションファイル、マッチング、コントロールブレイクとか聞いてもチンプンカンプンだろう
データ例外等でアベンドした時、何を戻して、どこからリランするとか考えるだけで精神積に参るから、普通の人はあまり関わらない方がいいかもしれん
ただでさえスパゲッティ状態にメンテナンスが幾度となく加えられたソースを読み取るだけで時間が過ぎていってたな 知り合いの中国人がlinux系ならユーザーアカウントくれるならどんなシステムでも絶対にroot取れるって豪語してた奴いたなあ
共産党関連の仕事決まったとかで帰国していたったけど >>18
cobolでできんならcobolでいいんだよ うちでは1981年初版のCOBOLをまだメンテしてる。 つーかね、なんのために存在してるロジックなのか、どう考えても入っていかないロジックとか、山ほどあって。
それを仕様に落とすとこでバグや抜けが発生して、
新たに仕様を起こすとこでバグや抜けが発生して、
新たなコーディングにてバグや抜けが発生するわけ。
全ての仕様を把握している人間など存在せず、
全ての真実は巨大なCOBOLのソースの中だけにあり。
いやぁ〜マジでCOBOLは不滅だわw >>248
基幹システムは電車等と同じで、正常に動いていて当たり前、異常があると即叩かれる世界。
負の遺産で手作業等の職人芸で汗を流しながら、何とか運用いても報われる事はあまりない。
また、機器・システムの老朽化の時は、ストレートコンバージョンが一番安全なのだが、予算確保のため
新機能を加えたコンバージョンとなり、地獄を味わう事が多い。（無茶を言いだした上層部は、既に異動で居なくなったりと） 金融システムはバグがあるとクソ叩かれる世界で100点満点以外は許されない世界
だからCOBOLからリプレイスしたがるやつなんて現場には殆どいない
インフラ変えるだけでもすごいよ 巨大な企業やシステムほど、わけわかめなコンサルとか暗躍してて、わけわかめな営業と話を決めるもんだから現場は地獄を見る。
こう言っちゃなんだが、本当に優秀な人材はこういう案件には入らないか、早々に逃げるね。
残念ながら逃げられない人材によって、さらに火を噴いてどこかの巨大銀行みたいになる。 あ、横浜銀行のCOBOLは懸命な判断だと思うよ。
仕様を変えなければね。 >>249
ストレートコンバージョンって言われて参画したら全然ストレートコンバージョンじゃなかった思い出
結局一から設計するハメになったわ ソースから移すのって想像以上にしんどい
ちょっと書かれてる一行で全然変わってくるし
そういうキーになる行をちゃんと見つけないといけない
それ以外のしょうもない処理も大事な処理もソースは同じように書かれてるし バグはもちろん処理時間のバラつきも問題視されることがあるからな。
夜間バッチが終わらなかったりすると大障害だし。 ソースそのまま流用かな？
リコンパイルは意外と大変
VC6.0のプロジェクトをVisualStudioで初めてコンパイルさせて通すのに半日かかったよ >>66
そのクラウドのAWSもCOBOLでやってなかったか？ >>239
なunixコマンドライン時代からそういうツールあるよ
俺は知らないけど
どうせ電力線をいじるやつだろ >>239
あなたが作ったシステムは絶対にroot取れるってことですか？って聞いてやれｗ おぼえようとする人がいないだけで、COBOLベストだと思うけどな。ただデータベースは大丈夫なのが気になる >>178
懐かしいな！EASYの時から使ってたよ。
プラスついてプログラムっぽくなったが、
EASYの素朴な構文のほうが好きだった。
あれはJCL界のawkと思ってる。
ほんとにお世話になりました。 海外はアプリに合わせて運用手順を変える
日本は運用手順に合わせてアプリを作る COBOLなんてエンジニアを確保するのが大変だろ？ COBOL → Java の失敗例はたくさんある。
究極はスピードが落ちてバッチが時間内に終わらないとか。
ホストはチェンジしてもCOBOLは変えちゃいかんな。 COBOLは会議室で動いてるんじゃない
現場で動いてるんだ >>269
今までCOBOLだから慣れてるCOBOLを使う！って話じゃねえからなぁ
事務処理用に作られた言語だからメインフレームに必要な処理速度とか諸々考えるとCOBOLだなってなるだけで IDENTIFICATION DIVISION
全て懐かしい そこでawsにnosqlとlambdaでサーバーレスであえて作ってみてほしいわ
勘定系をawsのサーバーレスなんて夢あるじゃない
確かnasdaqのバックエンドがオンプレ版awsになったんじゃなかったっけ COBOLは事務屋に取っては理想的な言語だよ。
金額計算と確かさと金額の印字書式で他に敵う言語はない。
ファイルのレイアウトも構造的に定義できるし
その表現も見てわかりやすい。
命令構文は冗長だが、素人には理解しやすいのも確か。 >>260
警官の大馬鹿で無理矢理つかまえて手の指紋みんな採取してるからだろ
イギリスのあほ保険屋の手下の大アカが Jave有料化って嘘で、アメリカ軍が流してる大嘘だぞ、あと >>282
いまのヤンとか日本風の格好のかの字もねえわ
馬鹿しかいねえじゃねえか 富士通メインフレームのCOBOLリホストとか無理
そのまま動かせて別の銀行システムをスクラッチ開発してろ >>285
過去データの移管、少なくてもDB参照部分は全てプログラム修正が必要だろう(同一メーカ汎用機でもOSバージョンアップはメーカー提供ツール使って、しかもめちゃくちゃ修正が必要なのにRedhatとか)
ちょっと無茶な気がしなくもないが こういうのって役員が自分の手柄にしたいだけで現場は大迷惑だろ
そもそもコストが下がってどこに利益が還元されるんだって話し
コストは下がっても今までの運用ノウハウが通じなくて余計にコストがかかる
みずほが今年障害連発したのだってそういう影響があるんじゃない？
あとメインフレームの良いところはバージョンアップが頻繁に無い所
バージョンアップによって現行機能の変更で影響確認とか手間とコストがかかる
金融系ではこれが凄い大事 >>4
COBOLを笑うものはCOBOLに泣くぞ？ COBOLはすげーんだよ
使いこなすのに妙ちくりんな概念みたいなものを理解する必要がない >>47
NetCOBOLだからオブジェクト指向化されてるし
C#とかと同じクラスライブラリが使えるゾ COBOL最強説。
まあ、貧弱な言語ならとっくに淘汰されているしね。 >>293
だな
>>290の「使いこなすのに妙ちくりんな概念みたいなものを理解する必要がない」
これが最強たるゆえん
天才君はC++でも使ってろという感じだな
個人的にはみょうちくりんな概念みたいなものは好きだけどな 地方銀行の規模だと下手したらすでに2周遅れだものな
2000年ごろの契機で踏み切ったところもそこそこあったのに >>4
実稼働している資産が大量にあるからね。
それに５０年近く動いているプログラムも今や珍しくない。
もう他言語に置き換えるのは無理だよ。 20年前にコボラーは必要ないと言われて転職した。今でも使えない事無いけど今更エンジニアしたいとは思わないなぁ。 アラフォーで新卒から3年ぐらいコボラーやらされてた
単価がすごい高ければもう一回コボってもいいけど、COBOLよりもgit管理されてないコメントだらけのソース読むのに耐えられか自身がない >>16
NetCOBOL----オブジェクト指向COBOL PostgreSQLは追記型
MySQL、MariaDBはOracleと同じ更新型
COBOLソースは引き継ぎしてるがDB書き込み部分はいじってると思われる ■ このスレッドは過去ログ倉庫に格納されています
