【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 >>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からリプレイスしたがるやつなんて現場には殆どいない
インフラ変えるだけでもすごいよ ■ このスレッドは過去ログ倉庫に格納されています
