前代未聞の東証のトラブル

今回のシステムはメインフレームを使っていたのでしょうか。銀行のシステムなど滅多に止まらないですよね。
UNIX系のサーバクライアントシステムなら運用経験の差が出たのかもしれませんね。
原因ですが、私はTVや新聞の報道とサーバの増強の為の更新ということでデータベース関連のバグが原因かなあと思っています。

Unixサーバベースのようです。Unixサーバもハードウェアベースでの信頼性はかなり高くなってますが、やはり運用ノウハウの蓄積等の点でまだ課題がありそうです。
銀行のオンラインシステムはハード、ソフトの信頼性は当然として、信じなれないくらい厳密な運用管理が行われてますので、あのような事実上ノンストップの信頼性が達成されているわけです。

ベンダー広報担当だったころは、こういう報道があるとかなりびびりますね。自社製品が使われているか、製品バグなのか、SIerの立場、顧客の立場など瞬時にさまざまな情報が飛び交います。急ぎFAQを作ったり、場合によっては社内に緘口令を敷いて問い合わせ窓口を一本化したり。製品ベンダーは、こういうときあまり強い立場ではないことが多いですね。

今回の事故はソフトウェアのバグと言う捉え方が多いようですが、私はテストの不備と考えます。
新聞のコメントによれば、一度も月次処理を含むテストをしないで本番プログラムとして使ったとの事ですが、それが本当であれば弁明の余地がないと言わざるを得ません。
運用の責任者が、テストの意味を理解しているか疑わしい事態と考えます。

今回のシステムはメインフレームとどこかで見た気がするのですが、私の推測ではオンライン起動JCL内のデータセットに対するカタログが間違ってたんじゃないでしょうかね。テストの時はテスト用データセットのカタログが付いていて、本番のオンライン起動JCLにもそのままカタログを持ってったとか･･･。
(ここ5,6年程メインフレームからは離れているので記憶があいまい。今回は富士通ですが、CICSはそんなカンジだった気が･･･)
4時間半程度で直るとしたらJCL周りかなと思いました。それにしてもダウンした時用のバックアップシステムは動かないんでしょうか。それも同じ理由で動かなかったのでしょうか。

トラブルの詳細については、あまり憶測してもしょうがないので、某誌の「動かないコンピュータ」の報道を待ちましょう。
一般論として言えば、大規模システムの障害のほとんどがオペミスか変更管理のミスに起因すると言ってよさそうです。

私の聞いた話だと Unix ではなくて Global Server (MSP) だそうですが... (「0C4」とか言われてたし)。

>通りすがりさん
そうなんですか。初報（ http://itpro.nikkeibp.co.jp/article/NEWS/20051101/223818/ ） では、「業務サーバ」という言葉を使っていたので、Unixサーバかと思い込んでいました。まあ、メインフレームも「グローバルサーバ」なんですけど。
しかし、記事によると「午前６時３０分に業務サーバの電源を入れたが、、、」と書いてありますが、昨今は週末には基幹系マシンの電源落としちゃうんでしょうか？私が現役SEのころはハード保守が入るときしか落とさなかったと思います。たまたま、この週末に保守が入っていたのか、それもIPL（リブート）のことを「電源を入れた」と表現したのでしょうか？

　当日夜のNHKのニュースを見たところでは、単なるプログラムのデグレードですね。月初の銘柄情報の移動を探しに行く機能が新しいプログラムに欠落していたと言っていました。
　私が問題だと思うのは東証の対応です。確かにバグを発生させたのは富士通かもしれませんが、当日中に富士通に損害賠償の話が出ていました。しかし、富士通は東証に無断でプログラムの変更を行えるはずが有りません。当然のことながら東証の管理者がプログラム変更の確認を行っていたはずです。ここで漏れているので東証側の管理責任は免れません。
　この東証の態度はJR西日本のあの事故を思い起こさせます。自社の責任ではなかったという方向で情報をリークして行くやり方です。SIであろうとなかろうと受け入れチェックを行う責任は受け入れる側にあるということは絶対に逃れることはできません。自社の管理体制を棚上げに富士通の責任だけを問う東証の態度に憤りを感じます。

>障害管理者さん
確かにそれは言えますね。結局丸投げ体質、責任転嫁体質が問題の根のような気が。事実関係が明らかになった段階で総括してみたく思います。
>通りすがりさん
（話戻ってしまいますが）本番オンラインで0C4ですか!あーなぜか胃が痛い(>_<)
（注：0C4はメモリ保護例外。通常、プログラムに致命的なバグがあることを意味する。リランしてもまず解決しない）。

月中に動的（システムを止めない状態で）に移行したプログラムモジュールはオンラインシステムがアクテイブな状態ならばコーディングされたプログラム中のファイル（ＭＳＰならデータセットか）定義部分を無視してプログラムは実行されるのではなかったかな・・・
報道を見る限りでは、オンラインシステムを多分月一で停止させてシステムの持つ「メモリ部分」のフラグメンテーションを解消させているんでしょうね。
システムの停止・再起動をしたから、オンラインシステムで定義されているファイル定義情報とプログラムで定義されているファイル情報が新たに読み込まれてディスクレを起こしてシステムが立ち上がらなかったのではというのが推測です。
これが正解ならばテスト系というものがあると思いますが、プログラム中のファイル定義情報部分自体はその名前がテスト環境と本番環境で違っていたりする場合があると思います。

推測はしてもしょうがないですよね（＾＾；）
ローカル・専門用語は可能な限り故あって控えさせて頂きました。
ものすごい昔に自分も似たような事やってしまった経験がありますのでコメントだけさせて頂きました。

グローバルサーバを調べたら富士通ではメインフレームのことのようです。最近はシステムの中心にいるコンピュータはみんなサーバと呼ぶみたいですね。
だからメインフレームであっても業務サーバというわけのようです。確かに機能を考えれば間違ってはいないですね。