アカウント名:
パスワード:
https://twitter.com/E_Hartmann666/status/1438650645599297542 [twitter.com]
>「バッチ処理は時代遅れ」三大メガバンクとJPBの勘定系&業務系の設計・構築やってた経験から言うと、夜間バッチ処理は「センターカット」と呼ぶんだけど、処理遅延すると翌日のオンライン開局が遅延するので、MUFGとSMBCは夜間バッチ処理を削減する方向で設計している。↓日銀RTGS、全銀システムはリアルタイム処理になってる。(全銀は全加盟機関じゃなくて、一部の機関だけだけど)みずほ銀行の勘定系システム更改の誤謬は、銀行の経営陣が第一勧銀+富士通のSTEPsに固執したことにある。富士銀行+日本IBMのTOPsに片寄して、その後にシステム更改すればこのような事態にはなっていない。「COBOLを利用してるから」ってのも間違い。↓
金融系システムは十進法演算が必須なので、汎用機で稼働する言語で十進法演算命令に対応しているプログラミング言語はPL/1とCOBOLしかない。補足すると演算する桁数も多いので、それに対応する言語となるとCOBOLが最適解になる。>RDBMSを採用すればいいじゃん
これも誤謬で、階層型DBMSのIMS処理能力は13万TPS。一方RDBMSの代表であるOracleは7万TPS(しかもNECが魔改造して)なので、メガバンク級のトランザクションを処理するシステムにRHEL+RDBMSを採用するのはダメ。現行ではz/OS+IMSが最適解。
銀行の勘定系システムの初見者にはこれが参考になります
進化する銀行システム 24時間365日動かすメインフレームの設計思想 (Software Design plus)
夜間バッチ削減…そうなの？時間帯や処理を分散させはするけど、削減という話は…うーん。
最終形態がリアルタイムだとしたらトラブった時に地獄しか思い浮かばないなw
トラブったリアルタイム処理の復旧・修正・再実行なんて素人目にも大変そう。
全くの外野から見ると、上流で「(システム名)」の「時間帯や処理を分散させる」と呼んでいる方向性を、下流では「夜間バッチ」の「処理を削減する」と表現している予感
上から見ると「えっ? 夜間バッチは(システム名)の極々一部だし、単一障害点にならないよう分散化を進めているだけだけど…」とすれ違っているのかもしれない
JavaもCも動かない、その時代遅れの汎用機なんとかしなさいと
汎用機でもCやJavaは供給されてますよ。普通の事務処理ならCOBOLの方が使いやすいから選ぶ理由がないだけ。
正直、C言語で、銭の計算はしたくないですね。
消費税の計算は、寿命が縮みましたよ。
> JavaもCも動かない、その時代遅れの汎用機なんとかしなさいとJava は分からんが、C言語はメインフレームで使ったことあるぞ。.... そのメインフレームはもう無いけど。
知らないなら黙っとけば?かなり恥ずかしいこと言ってるよ。
JavaでもCでも十進法演算ができるだろう？PL/1とCOBOLしかないって言うんだから、ってここまで言わせんな恥ずかしい。
そもそも、
と、JavaもCも動かない前提で理論展開してたくせにｗ
関係ないけど、「C言語では10進数の0が書けない」って話を思い出した。0bを前置したら2進数、0を前置したら8進数、0xを前置したら16進数。「0」と書いてあったら8進数の0を意味する。仕様上10進数の0は書けない。
何とかした結果が、JavaもCも使えるz/Linux。せっかくのメインフレームをつかってIAサーバで出来ることをやって何がうれしいのかわからないが。
いや、z/OSでもJavaやC使えるよ。
そりゃ信頼性とI/Oのスピードだろう。
javaもcもbcd外付けでしょ。
そもそもモジュールの概念が無きに等しい言語と対比して後付けと言われましても。まああるソースコードをいじっても他のプログラムに影響を与えないことが保証されているという性質がこれまた金融系と相性良かったみたいだけど
＞そもそもモジュールの概念が無きに等しい言語無知が何か言っている
リアルタイムで処理が溢れないならそれに越したことはないですね。
# キューに積まれたタスクを処理するプログラムはバッチとは言わないのかな？少なくとも夜間バッチではないけど。
＃のはオンバッチとか言ってる気がする
DB遅いのでシーケンシャルファイルに全部落として処理してたけどいまも一緒なの?
オフトピだけどセンターカット・・・懐かしいなセンターカットって処理としてはバッチだけど更新処理部分だけリアルタイムAPを呼び出して実行すること。
なぜそんな処理の仕方をするかと言えば更新処理をリアルタイム処理とバッチ処理で別々に作ると、もし万が一どちらかに考慮漏れでもあった場合、気付かないうちにバッチとリアルタイム処理でデータの不整合が起きることを防ぐ為・・・とかだったはず。
ネット上のCOBOL, COBOLer談義で「COBOLは時代遅れ」という話はあっても、「時代遅れのCOBOLの代わりに□□□という十進演算が正式に言語仕様でサポートされているプログラミング言語を使ってる」という話はいまだかつて聞いたことが無い．たしかRubyか何かにCOBOLの置き換えを狙った標準の十進パッケージがあるのは知ってるが、他に安心して金勘定・金利計算の出来るプログラミング言語って何があるんだろ？
もう一つ不思議なのはCOBOLerが足りないという話は良く聞くが、ならJAVAerやCerにCOBOLをやらせれば済む話ではないのか？COBOLerを馬鹿にしてる才能溢れるJAVAerやCerなら自学自習でCOBOLプログラミングぐらいお茶の子さいさいだと思うのだが
結局、ハードな金勘定・金利計算なんかやったことのないアプリ屋がわいわい騒いでるだけじゃないのか？
COBOLシステムって、現場業務とソースと仕様と定年間際のオッサンの椅子が渾然一体になった闇鍋からソースのコメントを抜いて変数名はCPUのレジスタのみ指定するようにしたようなものなんでしょBCDの計算がしたければ言語が何だって理論上可能だけど、誰も首を突っ込みたくないんだと思うよ
「アプリ屋」の発想なら、銀行を倒産させて預金を返してユーザーには再度口座開設から始めてもらえばいい話銀行じゃ無理ですって言うなら、技術的に筋悪で高コストなシステム更改やってりゃいいじゃないってこと何を疑問視してるのか分からないけど、究極的にはそこに手を出す人がいないのが「COBOL言語」の問題でしょ
言わなければ気付かない人のために「COBOLは難解で熟練者が居ない」って言い方を甘くしてるんでしょ
オベロン系になかったっけ？
現代では、十進演算が標準ライブラリでサポートされていない言語のほうが稀だろうに。無知にも程がある。
というか「言語仕様はミニマムとし、機能はライブラリで拡充する」ってパラダイムの洗礼を受けてないのだと思われるCOBOL/COBOLerが時代遅れである所以のひとつ
ソース読んだけど、紹介されている『進化する銀行システム 24時間365日動かすメインフレームの設計思想 (Software Design plus)』がセンシティブな内容が含まれている可能性のあるメディアになっててちょっと笑える
どうもよくわからないんだが、このHartmanとかいう人が#4116784氏なの？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
「ITジャーナリストの佃均」 (スコア:5, 興味深い)
「IT専門紙の取締役編集長」やってたと言うけど、その「専門紙の名前」すら伏せてる時点で判断以前な気がするなぁ。
そんなに的外れでもない「バッチ処理は時代遅れ」 (スコア:4, 興味深い)
https://twitter.com/E_Hartmann666/status/1438650645599297542 [twitter.com]
>「バッチ処理は時代遅れ」
三大メガバンクとJPBの勘定系&業務系の設計・構築やってた経験から言うと、夜間バッチ処理は「センターカット」と呼ぶんだけど、処理遅延すると翌日のオンライン開局が遅延するので、MUFGとSMBCは夜間バッチ処理を削減する方向で設計している。
↓
日銀RTGS、全銀システムはリアルタイム処理になってる。(全銀は全加盟機関じゃなくて、一部の機関だけだけど)
みずほ銀行の勘定系システム更改の誤謬は、銀行の経営陣が第一勧銀+富士通のSTEPsに固執したことにある。富士銀行+日本IBMのTOPsに片寄して、その後にシステム更改すればこのような事態にはなっていない。
「COBOLを利用してるから」ってのも間違い。
↓
金融系システムは十進法演算が必須なので、汎用機で稼働する言語で十進法演算命令に対応しているプログラミング言語はPL/1とCOBOLしかない。補足すると演算する桁数も多いので、それに対応する言語となるとCOBOLが最適解になる。
>RDBMSを採用すればいいじゃん
これも誤謬で、階層型DBMSのIMS処理能力は13万TPS。一方RDBMSの代表であるOracleは7万TPS(しかもNECが魔改造して)なので、メガバンク級のトランザクションを処理するシステムにRHEL+RDBMSを採用するのはダメ。現行ではz/OS+IMSが最適解。
銀行の勘定系システムの初見者にはこれが参考になります
進化する銀行システム 24時間365日動かすメインフレームの設計思想 (Software Design plus)
Re: (スコア:0)
夜間バッチ削減…そうなの？
時間帯や処理を分散させはするけど、削減という話は…うーん。
Re: (スコア:0)
最終形態がリアルタイムだとしたら
トラブった時に地獄しか思い浮かばないなw
Re: (スコア:0)
トラブったリアルタイム処理の復旧・修正・再実行なんて素人目にも大変そう。
Re: (スコア:0)
全くの外野から見ると、上流で「(システム名)」の「時間帯や処理を分散させる」
と呼んでいる方向性を、下流では「夜間バッチ」の「処理を削減する」と表現している予感
上から見ると「えっ? 夜間バッチは(システム名)の極々一部だし、単一障害点にならないよう
分散化を進めているだけだけど…」とすれ違っているのかもしれない
Re: (スコア:0)
JavaもCも動かない、その時代遅れの汎用機なんとかしなさいと
Re: (スコア:0)
汎用機でもCやJavaは供給されてますよ。普通の事務処理ならCOBOLの方が使いやすいから選ぶ理由がないだけ。
Re: (スコア:0)
正直、C言語で、銭の計算はしたくないですね。
消費税の計算は、寿命が縮みましたよ。
Re: (スコア:0)
> JavaもCも動かない、その時代遅れの汎用機なんとかしなさいと
Java は分からんが、C言語はメインフレームで使ったことあるぞ。
.... そのメインフレームはもう無いけど。
Re: (スコア:0)
知らないなら黙っとけば?
かなり恥ずかしいこと言ってるよ。
Re: (スコア:0)
JavaでもCでも十進法演算ができるだろう？
PL/1とCOBOLしかないって言うんだから、ってここまで言わせんな恥ずかしい。
Re: (スコア:0)
JavaでもCでも十進法演算ができるだろう？
PL/1とCOBOLしかないって言うんだから、ってここまで言わせんな恥ずかしい。
そもそも、
JavaもCも動かない、その時代遅れの汎用機なんとかしなさいと
と、JavaもCも動かない前提で理論展開してたくせにｗ
Re: (スコア:0)
関係ないけど、「C言語では10進数の0が書けない」って話を思い出した。
0bを前置したら2進数、0を前置したら8進数、0xを前置したら16進数。
「0」と書いてあったら8進数の0を意味する。仕様上10進数の0は書けない。
Re: (スコア:0)
何とかした結果が、JavaもCも使えるz/Linux。
せっかくのメインフレームをつかってIAサーバで出来ることをやって何がうれしいのかわからないが。
Re: (スコア:0)
いや、z/OSでもJavaやC使えるよ。
Re: (スコア:0)
そりゃ信頼性とI/Oのスピードだろう。
Re: (スコア:0)
javaもcもbcd外付けでしょ。
Re: (スコア:0)
そもそもモジュールの概念が無きに等しい言語と対比して後付けと言われましても。
まああるソースコードをいじっても他のプログラムに影響を与えないことが保証されているという性質がこれまた金融系と相性良かったみたいだけど
Re: (スコア:0)
＞そもそもモジュールの概念が無きに等しい言語
無知が何か言っている
Re: (スコア:0)
リアルタイムで処理が溢れないならそれに越したことはないですね。
# キューに積まれたタスクを処理するプログラムはバッチとは言わないのかな？少なくとも夜間バッチではないけど。
Re: (スコア:0)
＃のはオンバッチとか言ってる気がする
Re: (スコア:0)
DB遅いのでシーケンシャルファイルに全部落として処理してたけど
いまも一緒なの?
Re: (スコア:0)
オフトピだけどセンターカット・・・懐かしいな
センターカットって処理としてはバッチだけど更新処理部分だけリアルタイムAPを呼び出して実行すること。
なぜそんな処理の仕方をするかと言えば更新処理をリアルタイム処理とバッチ処理で別々に作ると、もし万が一どちらかに考慮漏れでもあった場合、気付かないうちにバッチとリアルタイム処理でデータの不整合が起きることを防ぐ為・・・とかだったはず。
Re: (スコア:0)
ネット上のCOBOL, COBOLer談義で「COBOLは時代遅れ」という話はあっても、「時代遅れのCOBOLの代わりに□□□という十進演算が正式に言語仕様でサポートされているプログラミング言語を使ってる」という話はいまだかつて聞いたことが無い．
たしかRubyか何かにCOBOLの置き換えを狙った標準の十進パッケージがあるのは知ってるが、他に安心して金勘定・金利計算の出来るプログラミング言語って何があるんだろ？
もう一つ不思議なのはCOBOLerが足りないという話は良く聞くが、ならJAVAerやCerにCOBOLをやらせれば済む話ではないのか？
COBOLerを馬鹿にしてる才能溢れるJAVAerやCerなら自学自習でCOBOLプログラミングぐらいお茶の子さいさいだと思うのだが
結局、ハードな金勘定・金利計算なんかやったことのないアプリ屋がわいわい騒いでるだけじゃないのか？
Re: (スコア:0)
COBOLシステムって、現場業務とソースと仕様と定年間際のオッサンの椅子が渾然一体になった闇鍋から
ソースのコメントを抜いて変数名はCPUのレジスタのみ指定するようにしたようなものなんでしょ
BCDの計算がしたければ言語が何だって理論上可能だけど、誰も首を突っ込みたくないんだと思うよ
「アプリ屋」の発想なら、銀行を倒産させて預金を返してユーザーには再度口座開設から始めてもらえばいい話
銀行じゃ無理ですって言うなら、技術的に筋悪で高コストなシステム更改やってりゃいいじゃないってこと
何を疑問視してるのか分からないけど、究極的にはそこに手を出す人がいないのが「COBOL言語」の問題でしょ
言わなければ気付かない人のために「COBOLは難解で熟練者が居ない」って言い方を甘くしてるんでしょ
Re: (スコア:0)
オベロン系になかったっけ？
Re: (スコア:0)
現代では、十進演算が標準ライブラリでサポートされていない言語のほうが稀だろうに。
無知にも程がある。
Re: (スコア:0)
というか「言語仕様はミニマムとし、機能はライブラリで拡充する」
ってパラダイムの洗礼を受けてないのだと思われる
COBOL/COBOLerが時代遅れである所以のひとつ
Re: (スコア:0)
ソース読んだけど、紹介されている『進化する銀行システム 24時間365日動かすメインフレームの設計思想 (Software Design plus)』がセンシティブな内容が含まれている可能性のあるメディアになっててちょっと笑える
Re: (スコア:0)
どうもよくわからないんだが、このHartmanとかいう人が#4116784氏なの？