メインフレームの異常処理 - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事では、メインフレームでは異常時の処理でどのようなことをやっているのか、また、Linuxの異常処理との違いなどについて話してみようと思います。 この記事を書くに至った直接的なきっかけは、とある人からリクエストがあったからです。が、日ごろからメインフレームの異常処理の考え方については、PCサーバーやクラウドによるシステムがメジャーになった現代であっても、参考になることは多いと感じていてはいました。 筆者は今でこそLinux Kernel周りの仕事をしていますが、20年ぐらい前のころはメインフレームのOS開発部隊に配属されて

[ledsun]

"クラスタリングや分散システムによるリカバリの難しさについては、これを読んでいる読者のほうが詳しいかと" そんなわけあるか！（笑

[kkobayashi]

UNIXはそういう時はとにかく落とす文化だからね。。マシンチェックでリカバリとか考えられん。メインフレーム絡みのシステムとかメインフレームを長年やってた重鎮の方と仕事したりとかすると目からウロコが落ちる

[yosf]

MFかオープンに移って、異常処理の仕組みに関しては弱いなと感じたのを覚えている。メモリが足りなくなったらkillしますとかMFの世界ではありえん。

[ksugimori]

面白かった。追記部分のこれもなるほどと思った。 “「ハード故障を回避」するというより、「運用時のトラブル発生状況を「説明可能」にするための情報を残すという考え方をしなさい。」”

[programmablekinoko]

"メインフレームの信頼性の本当の凄さは、このようなハード故障時の異常処理ですらシステムを止めないという態度で実装" アーキテクチャもあるが、マインドセットが異なると

[tagomoris]

改めて読むと興味深い / Unixは「このようなエラー処理をユーザに触らせない」ことによりアプリケーション実装効率を大幅に引き上げた、と言えるのではと考え始めた

[annoy]

メインフレームの情報ってネットには出てこないよね。ネクタイ締めた別の世界の人達がやってる。僕、簡単なJCLとIEFBR14しか知らない。

[inose660]

メインフレームの凄いところは、こういうノウハウが活きているところ。だけどアプリの実装次第なので若干弱みでもある。TandemとStratusとの思想とはかなり異なる / 記事を書いた http://inose660.hatenablog.com/entry/2020/05/04/000000

[mkusunok]

汎用機の信頼性が今以てスゴい仕組みであることは間違いない。「他のノードから回復処理を行うべき」という後続はTandem/HimalayaとかStratusあたりと推察するんだけど、あの手の技術って今に引き継がれてるんだろうか？

[estragon]

パラレルSysplexは他のノードに回復させる仕組みか。ユーザプログラムのバグはさておき、システム障害時にダンプ等の資料不足で原因がわからないことは、あんまりない（分散系では圧倒的に分からないならことが多い

[yojik]

なぜかテスト用の電文一発でメインフレームを落としてしまったことがあり、いまだに何が起きたか謎。

[hdkINO33]

“メインフレームの信頼性の本当の凄さは、このようなハード故障時の異常処理ですらシステムを止めないという態度で実装してきており、それをずっと継続してきたことによるものだと思います。”

[naglfar]

つよい。強すぎる。追記部分の説明可能という考え方、現代でも通用する。

[sugawara1991]

レビューの内容は例外安全の考え方とか非同期完了処理の取り扱いと匂いが近いか。永続的な故障じゃなくてビット反転(ソフトエラー)への耐性と考えるとコストが合う場合もある？ただビザンチン障害どうするねんとか

[tmatsuu]

わいわい。とても面白い。

[quabbin]

MVSの解説本なんてあったのか…とおもったら、1986年刊。むむむ。ペーパーバックのありがたさよ。ポチるだな。あと階層型DBとネットワーク型DBの解説本があれば嬉しいのだが…ふ～む

[John_Kawanishi]

SMPのPCサーバー見てIBMのSEだか営業から｢これCPUが1個壊れても正常に動き続けるの？」と聞かれて当時は何いってんだと思ったけどそういう思想で作られて動いているのがMainframeなのかなぁと後から思ったり

[NOV1975]

落ちたら落ちたでTKOの速さよ。

[fashi]

未知の世界だった

[htnmiki]

信頼性が高いのはわかったんだけどそこまでの「止めちゃいけない」という圧力？はどこから来てるんだろうな（すっとぼけ）

[knok]

触ったことはないんだけど最近アベンドとか聞かなくなったな

[uunfo]

oomkillerやめて

[topiyama]

異常時でと動かし続ける・続けない は実装コスト次第だけど、何が原因で動かなくなったかを外に伝える仕組みはどんなソフトウェアにも気にして欲しいところ。

[bell_chime_ring238]

“「ベストエフォートでは許されないとまず認識しなさい。」”←これに尽きる、汎用機とオープン系の設計思想の違い。この考え方のおかげでいろんな事象にほぼ全て説明つくので、自分的に安心感があった汎用機の仕事

[InoHiro]

ハードの故障って実際のところどれくらい発生するんだろう

[nilab]

「銀行の勘定系、すなわち皆さんの口座の元帳を預かっているシステムでは今なおメインフレームが多数」「毎日正常に動き続けて当たり前、トラブルになると社会問題になるようなシステムとして使われてきた」

[qtamaki]

これはあと読む

[harumomo2006]

CGMTの読み書きの動作ログがハード内のフロッピーに逐一書き込まれていたのは驚いた。リカバリできなくても何が原因でエラーになったのか誰が悪かったのかを特定できるのはすごい

[crexist]

すごいけど文化が違うな

[hokkey]

"メインフレームの正常系の処理と異常系の処理は直感的に比率にすると3:7ぐらい"

[sharaku3eyes]

濃い…

[masa8aurum]

“メインフレームの異常処理の考え方については、PCサーバーやクラウドによるシステムがメジャーになった現代であっても、参考になることは多い”

[tohokuaiki]

“この様子を簡単な図にすると、以下のような形になります。” 簡単じゃなかった…

[aktkro]

わからんけどおもしろかった

[Kenju]

現役で扱っているはずなのに記事の内容がほぼほぼ理解できない。自分とは違うレベルのところで仕事をしている。

[buhoho]

たまには後で読むをちゃんと後で読んでみようかしら