« 土星衛星タイタン探査機カッシーニ撮影と石油 | トップページ | ウォークマンスティック用ケース »

2005.11.15

東証停止原因はエイリアス?名証はパスワード?

(2005/11/17追記 日経産業新聞)
東証事件の報道、さらに内容変わってるし…。本日月曜の日経産業に大きく詳しく載っていたのですが、
そこでは「エイリアス名の参照プログラム名を空欄にしていたので、エイリアスを実行してもプログラムを起動できなかった」という経緯が詳しく…
って、前回はITProが「DASDコンデンスが原因」で最初のNHKニュースでは「インデックスがずれてデータ順序にズレが生じ…」って図解説で、どれもこれも違う報道でした。
真実はただひとつなので、なんでそれがこうも変わるのか?原因は当日に解決できたのだから、当日に原因は判明しているのに「エイリアス」って言葉が14日に初めて聞きました。なんでこれが初日にキーワードとして出てこなかったのか?
初日にちゃんと聞き及んでた人もいらっしゃった
東証が一向に原因把握できてないのか、富士通が恐れ多くも東証にくるくる変わる答弁をしたのか?初日に復旧を担当した当事者が東証&報道に直接話せばこんなことにならないだろうに?
そして14日目にして聞いた「エイリアス」なんでしょうこれ?UNIXならともかく、富士通汎用機でこういう用語って使われてましたっけ?
システム起動の方法には、昔ながらの汎用機なら『JOBNETコマンド』『楽2自動運転ソフト』の経験しかない私ですが、エイリアスってJCLなのでしょうか?それとも東証独自機構?
日経産業の記事によれば、エイリアス内のプログラム欄に呼び出す名前が作業ミスで空欄のままだった。これが月末の索引リスト再構築で、以前記述されていたプログラム名A´(ダッシュ)とエイリアス名Aの関連が切られたのが原因だそうで。
索引リストという用語も漠然として何者かわかりませんが、索引リストが実体は単一ファイルなら先に説明したようにコンデンスで内容が変わるのはおかしい。winでデフラグしたら、txtファイルの中身が変わるか?
まだ不思議なのは、富士通の指示でエイリアスAの中にプログラムA´が漏れたとあるが…
*旧エイリアスAには「A´」と書かれたままで更新指示忘れなら、A´は依然残留してるのではないか
 記事では書面による指示のように書かれている。
 東証システムの作業者が記述指示が無かったからってA´とあった文字列をエディタで消したか?
*富士通が作業者にファイルでリリースした場合、そこに空欄があったのなら、
 リリース前から空欄なのだからテスト段階で既に異常なのでこれでテスト合格したのか?
 空欄なエイリアスファイルを受領した作業者は中身の空欄に気付かなかったのか?
*上記の見逃しがあったとしても、リリース時にも一応チェックしたらしい。
 このときに中身が空っぽなエイリアスがなんで動作したのか?

このようにこの記事でも聞いておかしい。
私が富士通メインフレーム担当者で、「君も注意してくれたまえ」と注意喚起でこのような記事情報をもらっても、結局何が悪かったのかが把握できません。そのエイリアスと索引リストという高度な?機構を私が経験無いからですけど…。
ちなみにJCLやJOBNETでは、端末から叩いたコマンドでエイリアス相当のファイル(テキスト)を読みに行きますが、そこで空欄なのでそこで文法エラーですぐ異常終了します。空欄なのに動くことはしません。
WindowsやUNIXのようなpathの通りは悪いので、「無くても動く」は起きないようになっているはず。winはwinフォルダやsys32フォルダとかいくつかにpathが通っているのでどこかに実行体があれば動きます。それが汎用機には無いです。
この記事の通りだとすると、汎用機が「関係が切れているのに勝手に解釈して動作し続けた」ということで、そんなに融通がきいたかな?という感想です。
記事では『バグ』と表現されてましたが、プログラムA´とかは論理的におかしくないし、移行作業でのポカミスって感じに見えます。
なので富士通マシン性能自体が原因では無さそうで、人為的ミスって感じですが、そのミスりかたがわからないなぁ。
これでは参考にできない。まぁ注意して移行しろってことでしょうけども。
しかし「ちゃんとやる」「注意してやる」という行為と「やる」とでは何が違うのだろう…プロなら「やる」だけで完遂するだろうにと思うところではあります。
でも…
空欄原因ならエラー画面に「モジュールA´ not found 発生箇所はA」とか出るので(汎用機はあらゆる正常異常動作にメッセージを出します。分厚いコード表で全エラーコードに対処法を示しています。だから原因は追及しやすい)、
これで呼び出し元エイリアスAでの発生が特定できるので、空欄にすぐ気付けそうですよね。
なんで午前いっぱいかかったのだろう。それに直すったってエディタでAを開いてA´を書くだけでしょう?
「こんなマニアックな障害じゃあ仕方ないよね」という原因を予想していたのですが、なんか「これに復旧7時〜12時で5時間かかったの?」という感じです。
もうこれ以上報道に変化はないと祈ってますが、変わっても人為的ミスなのは変わらない気がしてきました。
東証トラブルはエイリアス?


(2005/11/12追記)
名古屋証券取引所の事件のほうは、パスワードを富士通の担当者が間違ったのが原因?
うーん、これも本当なのかなあ?
一般人はシステム素人だからって富士通や名証や報道機関は適当な説明をしている印象が。
これだけIT化が進んでいる現代ですから、一般人でもシステムの仕組みがわかる人も多いはず。
以下の記事でスッキリできますか?私はモヤっとしています…。

名証のシステム障害、原因はまた富士通…入力ミス
http://www.yomiuri.co.jp/atmoney/news/20051112ib01.htm
名古屋証券取引所で4日午前の取引を停止させたシステム障害は、システム管理を委託されている富士通の関連会社社員が前々日にシステムの終了処理をした際、パスワードの入力を誤ったことが原因とわかった。
システムを管理する社員は、取引後にシステムを終了させ、次の営業日にシステムを起動するためのパスワードを打ち込むことになっている。
前々日の2日、パスワードの入力を間違っていた。このため祝日をはさんだ4日早朝、別の担当者がシステムを起動しようとしたが作動しなかったという。(2005年11月12日3時15分 読売新聞)


セキュリティ高めるための魔法の呪文で重用されるパスワード、私には単なる文字列でソーシャルハックの前には意味がないものと思えるのですが、どこでもパスワードで固めまくったから起きた弊害か?
普通は早朝に自動起動するのでそのレガシーシステムではパスワード設定はしないわけですが(UNIXだってcronは自動で、passwdを毎朝誰かが入れているのか?)
この名古屋の「前営業日終了時にパスを設定する」という運用ははじめて聞きました。国内最高レベルの重要システムですから、さぞかし意味がある運用方法なのでしょう。
しかしシステム一般論としてこういう運用はより良いものか?
*封じ手や合言葉の方式なら前日の設定者が誤ったのでなく翌朝の者の過失になるはず?
*翌朝に前日のパスワードを無人自動でロードするなら、パスの意味がない。鍵を挿したまま車を一晩置くようなものではないか? 規定のパスがあるなら、昨晩の誤入力時点で「それじゃ翌朝動けませんよ。パスワードエラー」と表示してシャットダウンを拒むべき
*毎晩パスを書き換えてるなら、防護よりもこうした引継ぎミス誘発のほうが非常に危険性が高い。だれがこんな運用を思いついたのか…
*最悪パス誤りだったとしても、朝の担当者が前日の者に電話で叩き起こして聞くとか、連絡とれなくても管理者モードでログインとか、手順書を作るまでも無くそういう行動起こすでしょうに?午前中に大事なシステムを止めてしまうほどこのパスのエラーを誰も復旧できなかったのか?>名証&富士通

以上のように、「パスワードミスでしたー」の一言で済まされるにはあまりにもおかしい点が多いですよ…
名証も記者も富士通の上の説明で納得してるのでしょうか?
というか富士通の社長もこんなん原因&説明で責任取らされるのもかわいそうに思えてきました…。
ミスは他山の石としてこの世の日々の運用の糧になれる情報ですので、正確なところを知りたいです。


ちょっと関連ログ:
テストではバグがあることは示せるが、バグがないことは証明できない
公的個人認証サービスでpath変数破壊問題
価格.comの最大のセキュリティホールは『無知の脆弱性』
プロジェクトの姿


(2005/11/08)
結局バグではなくて運用上のミス(指示漏れ)だったようで?
デグレードっぽい気はしますが、新プログラム自体とか性能は悪くなく、その新プログラムを指し示すように改修してなかったらしい?

(2005/11/8追記 事故詳細の続報)
ITmedia
東証システム障害、原因は富士通の項目記載漏れ
http://www.itmedia.co.jp/news/articles/0511/07/news069.html
ITPro
東証システム障害の真相、富士通の指示ミスでプログラムが呼び出し不能に
http://itpro.nikkeibp.co.jp/article/NEWS/20051107/224141/
2005年11月07日
10月31日のコンデンス処理では、13日に再登録したサブモジュール間の呼び出し関係をシステムが自動検証した結果、これらを別個のモジュールと判断し呼び出し関係を切断した。
翌11月1日朝、参加者データ・ファイルを読み込むプログラムが起動したものの、正しいサブモジュールを呼び出せず、読み込みに失敗したため、売買システムは起動しなかった。

なんと、コンデンス処理で?
私の「DB再構築が原因か?」な予想よりもっと物理的なレベルで不整合が起きていたと?
うーん、ホントかなあですね…。

(以下に汎用機の仕組みを紹介してみたいと思います。パソコンや他OSで知識があるかたも読めば、所詮同じコンピュータですから通じるものがあるのではと思います。メインフレーム=レガシー=ブラックボックス&悪と呼ばれるのは悲しい…汎用機はシステム透明性があり機能も貧弱なほどにシンプルでよほどWindowsが複雑怪奇…)
上の記事によれば、COBOLプログラムを修正したがその新モジュールを指定忘れ(記事では「サブモジュール間の呼び出し関係を指定し直す手順漏れ」と表現)で古いモジュールのまま動き続けてたらしい。これを仮に月末にコンデンスしなければ11月も普通に動いてたかもしれない、ということか。
しかし、私が10年以上従事してきた経験からは、コンデンスでモジュール関係が失われる、というのが想像できず。どういう状態なんだろうか?

コンデンスとは:
私の触ってきたシステムでの「コンデンス処理」とは、DASD(ハードディスクドライブ)全体をデフラグ圧縮する機能です。(先日にお話ししたDB目次のデフラグは所詮1ファイル内での再構築でms-accessの圧縮と同等)
他にも「PO圧縮処理」というのもあり、POライブラリ(区分編成ライブラリ:物理的1ファイルに複数のモジュール(メンバ)が論理的に格納されている)のメンバの更新でスカスカに膨らんだライブラリをぎゅっと圧縮する処理もあります。各メンバの世代管理も出来るGEMライブラリよりも原始的な構造ですが、その分シンプルに動作するので、COBOLのコンパイル後のLOADモジュールはPOの中にメンバとして格納されます。(むき出しでDASDに単体で置かない)
.cabとか.zipみたいなものです。
コンパイルを繰り返したりするとPO内で分断化が進むので定期的にPO内デフラグが必要。
しかし先のDB-INDEXのデフラグと違って、この2つのコンデンスは
・ファイルの根幹にかかわるので頻繁にコンデンスするものではない
 (仕様的にはOKでも、経験則やベテラン先輩指示から禁忌という感じで)
・コマンドはコンデンス命令一発だけなので不整合は先のDBよりも起きにくいはず?
 (というか私はコンデンスで不整合に遭遇したことない)
不整合が起きにくいという度合いは、例えるならば、Windowsでデフラグをしてみたら、とあるフォルダのファイルが一個ロストした。という確率。ロストの可能性は確かにあるが頻発しない。
ファイルとディスクTOCの関係は人間はコンデンス作業でいじれないし、単に移動するだけのはずなんだけどなぁ?

例えば、COBOLでコンパイルしたモジュール「CBLMAIN」があり、その中でサブモジュールで「LOAD1」があると、CBLMAINのソース内で「CALL 'LOAD1'」とか記述しています。
それを10/13のバグ改修でLOAD2を新たに作ったのなら、CBLMAINのCALL文を書き直してリコンパイルします。
コンパイル後のバイナリは先ほどPOに格納すると申し上げたので、
例えばLOAD.LIBというPOライブラリ(見た目は大きな1ファイル)にCBLMAIN、LOAD1、LOAD2の3メンバがあるとすると、
起動JCLの宣言セクションにLIB=LOAD.LIBとか書いてあれば、プログラムの途中にLOAD2のCALLとあればLIB=を参照するので通常は見つかるはず。
(細かい言い訳をしますと、CBLMAINのリコンパイルは面倒だし重要な箇所なのでいじりたくない、だからJCLのLIB=のほうを細工してLIB=LOAD.LIB2とか新たにPOを作ってそこにLOAD2を名前をLOAD1として置いちゃえばいいとか、実装方法はたくさんありますが、今回は全メンバを同一POに置いたと仮定させていただきます)
だから、
DASD全体のコンデンスした場合→LOAD.LIB自体が移動するが中身は変わらないのでLOAD1もLOAD2も残ってるはず。
LOAD.LIB自体がロストしたならCBLMAINさえも見えないので起動時に一切沈黙してしまい、もっと影響は大きかったのでは。他の関連モジュールも一切認識できないのですから。
POのコンデンス→コンデンスはLOAD.LIB内で移動するだけなのでLOAD1もLOAD2も残ってるはず。
以上のことから、コンデンスのコマンドでは移動するだけなので「関係が切れる」という事象がよくわからないなぁ??
古いLOAD1を削除した上でコンデンス、ならまだ判りますが。(報道では古いのを削除したという表現は無いのでLOAD1は依然として残っているのか。普通は安全のため削除はしないでしょうし)

さらにDASD全体のデフラグが必要なのは、そのDASDがテンポラリとして一時的データセット(DS)が激しくやりとりされてる場合。
普通の設計なら、プログラムライブラリとテンポラリのDASDは分けます。DASDは10本20本は揃うもので、東証ほどの大規模ならもっと本数はあるでしょう(DASDの1本の容量はちょっと前までも数ギガバイト、百メガバイトとかパソコンHDDより小さいので自然と本数多く構成される)
私だって、パソコンでプログラム=c:¥program-files、CD書き込み作業=D:¥ とか分けています。
¥TEMPと同じところにLOADモジュールも同居して毎月デフラグもされている?仮に分けてあったとすれば、LOADのライブラリは頻繁にコンデンスかけないほうが無難だし、本来はコンデンスしても全然平気なんですけどね。私はコンデンスでの失敗は経験が無いので…

最後に運用&指示作業の面ですが、10月13日に指示が漏れた、ということは、
バグを富士通が見つけちゃんと直したバージョンもリリースしたが、現場が新バージョンを気にも掛けなかったことに。
現場作業員と開発エンジニアが共通のバグトラックを持っていたなら、現場から「この前見つけたバグの改修はまだですかね?」「テーブルだけ新規企業対応に更新指示ですが、COBOLのほうはLOAD1のままなんておかしいです」という声がかかるだろうし、
新テーブルは稼働済みでプログラムがバグをLOAD1で抱えていたなら、それを10月まで見抜けなかったというのは明らかにテスト不足だったことですよね。
もしも13日にLOAD1からLOAD2への変更指示もあれば、その場でLOAD2で本当に大丈夫かの追試をして、そこで11/1の再現をできなかったとしても(この時は関係が壊れてないので?悲しいことに今後起こる悲劇を見抜けないかも)、
10月末のデフラグで「システムが自動検証した結果、これらを別個のモジュールと判断し呼び出し関係を切断した」
このときに、システムがちゃんとエラーを表示していたと思うのですが、その点でも運用がちゃんとされてたのかなぁ?と疑問。

だから、リレーションが壊れたのが直接原因だとしても、
・現場から作業漏れを心配しなかった連携の悪さ
・現場がバグ自体を知らされてなかったならそれも連携悪
・バグをなぜリリース後10月まで見つけきれなかったかのテスト不足
・最後の砦の月末デフラグで『呼出関係切断』発生をなぜ気付けなかったか
以上の4点でやはり運用上の問題ではないかと思いました。
4回もチャンスがあったのに…これだけ見逃していたからの報いでしょうか(まぁ被害を被ったのは投資家とか顧客だから最悪)

個人的には直接原因の『呼出関係切断』も本当かなあと信じがたいです。
コンデンス処理はデフラグであり移動するだけで関係が切れるどうこうが頻発するものでないと私は経験上感じていますし(いや、富士通さんのメインフレーム性能はいいと思いますよホント)。
東証が特別で切れやすい?ファイルシステムを採用していたのなら、毎月そんなリスキーなデフラグしないほうがいいのでは(汗…。

これも2007年問題の一環だったりするのでしょうか。知識超豊富で気配りのできるエンジニアが減っているのか…。
オラクルとか今時のシステムでは複雑なことができる分、もっと知識や配慮が必要なのでしょうか。
ここに書いたメインフレーム知識は従事者には基本事項で特別でない。
こういう事件の裏で、トラブル起こさず黙々と運用を守り続けているエンジニアさん、本当にお疲れさまです。


(2005/11/4追記)
証券会社や報道機関などに株価を伝えるシステムのコンピューターに数値処理ソフトウエアの問題で障害が発生。担当者などが復旧を試みたが取引開始に間に合わなかった。同システムは富士通製という。

なんか本日朝から今度は名古屋証券取引所がシステムが止まっているらしい。売買でなく表示伝達系で問題が出たので止まっているらしい。
これも富士通製だと報道されてますが、あれほどの大企業ですからその社員&関連会社全員が同一のスキルで従事してるわけではないので、東京証券取引所の影響でどうこうじゃないと思いたいのですが、なんか見えない重力みたいなのが働いているのか…。
本日の新聞報道では東証のほうの原因は依然不明。日経産業新聞では会見で「運用の問題ではない」とありました。本当に?
…となるとバグか物理的故障であり以下のような考察外の要因ということに?ううむ。


(2005/11/1)
プログラムのミスやバグよりも、運用のミスの印象がありますがはてさて…
東証のトラブル、ITmediaでの記事を読むと心当たりあります>トラブル原因

ITmediaニュース:東証の取引停止、原因はプログラムミス.

東証のシステムは毎月末、データ格納領域の空き部分を整理・統合し、各データの格納位置を最適化する処理を自動で行う。10月末の自動処理の際、証券会社のコードなどを記録したデータの格納位置が変わったが、新ソフトがデータの移動先を特定できず、障害が発生したという。

今回の富士通のシステムがどんなマシンか不明ですが(汎用機らしい。11/2日経産業新聞によると、東証では富士通1、日立2の合計3システムが稼動)、私が触っていた富士通の汎用機でのDBシステムでは心当たりあります。
まぁDBならどこでもありえる話ですけど。

汎用機FACOMのMシリーズにはAIM-DBというデータベースがあり(RDBよりシンプルな富士通機では定番DB)、アクセス速度をあげるためにADL定義でINDEXを付け足すことができます。目次専用テーブルです。
DBに書き込み命令をすると、INDEXとDB本体の2箇所を同時更新します。だから通常では同期は維持されている。
ところがDBやindexは、パソコンのデフラグ画面のように使うほど歯抜け状態になるので、このフラグメンテーションを定期的に解消する必要があります。
このとき、AIM-DBではDBとINEDXが別々にデフラグできるところが落とし穴です。
正式には、先にDB本体をデフラグしたら(私の場合は全件抽出し、完全クリアし、頭から順に再登録という運用をしてました。Windowsのような外部にexportせずに自己内でオンライン中にデフラグする荒業な機能は汎用機にあるのかな?)、その次に必ず「INDEXの再構築」をします。新配置なDBのデータ位置に基づいてindexを作り直すわけです。collect&createというツールコマンドで呼ばれています。
だから、もしもindexの再構築を忘れると、inedxには古いDASD(ハードディスクのこと)アドレス番地が残っているので、それでアクセスしてもデータはそこに無い。
CMT(カートリッジテープ)にDB構造をバックアップできるのですが、構造をそっくりバックアップするので(いわゆる汎用性のあるexportだと時間がかかるので見た目のまま取得するのが速い)、ADLの定義上は、DB本体とINDEXは必ずセットでバックアップし、リカバリするときも同時に戻さないと不整合になります。
緊急事態で古いデータで戻すとき、どうしても両方リカバリできないならDB本体だけ復旧して、そのあとindexの再構築をする必要があります。
それだけ、ディスク上のデータの物理的アドレス位置におもいきり依存しているのでちょっとでも移動したら必ず追随措置をしないといけません。
いろいろオートマチックなパソコンのファイルシステムより不便ですが、これも、セクタやトラック単位でDBを設計できるためです。例えばディスク1周が1000で、あるDBの1件のレコード格納長(レコードの長さ+管理ヘッダ)が100だったなら、ブロックサイズ10とすると隙間無く格納され、9だと100余るのでDBが巨大になるほどその無駄も大きくなります。MS-ACCESSではデザインしてデータを格納したあとに何キロバイトになるか予想つきませんが、AIM−DBならば「100をブロック10で件数はこれで、ディスク種類は1周1000のタイプで…」から生成されるDBのシリンダサイズは設計段階で算出できます。実際のDASD上にそのサイズ通りに作れるとちょっと気持ちいいです(笑)。

というわけで、
今回のような事象は、DB本体だけデフラグして、indexを放置していたら絶対に発生する現象です。
あと、DBには目次付ける以外にも「オンメモリ」にすることも定義できます。要はディスクの中身を丸ごとメインメモリにキャッシュ。究極の高速技ですが当然メモリを食うし、物理レコードとオンメモリのレコードが非同期にならないよう、一般的には参照専用テーブルで使われます。今回はシステム起動時に発生しているので、メモリにロードするだろうから非同期にはならないです。だからメモリキャッシュとかではないと思います>原因
再構築はメーカー提供の標準DBツールの範疇なので、取引システムは直接関係無いでしょう。システムをどんなに厳しくテストしてもこの現象は見つからないでしょう。
いわゆるI/Oのトラブルのようでしたから、プログラムのバグというか、プログラムが物理アドレス直接指名して読みに行くようなことは今どきしないと思うのです。
せいぜい、DBのバックアップ&リカバリの訓練&チェックをする中で非同期の可能性に気付けるかと。バグよりも運用ミスの色合いが強いです。

このようにミスすると大変なので、通常なら、デフラグのJCLバッチの中でindexの再構築のフェーズも最後に入れておけば忘れるはずが無いわけです。
私のDB系JCLでは、再構築の結果リターンコードが0正常を返していること、indexとDBのそれぞれの処理件数を確認するとかやっていました。

結局ちゃんと作業の自動化できるので、同期忘れは起きにくいと思うのですが、改修後の初めての月末だったから、JCLの自動化スクリプトが不完全だったのでしょうか?index再構築のところをstep記述漏れ?
ウチのよりずっと高度なサーバなり汎用機なら、私のような分けてそれぞれデフラグする手間自体がもう無くなっているのかもしれない。
となると非同期になった理由がわかりません。
同じシステムならば上記のような不整合がありえます。

「目次と本体を別々にいじれるなんて怖い。非同期の要素が入りまくりじゃないか」と思う人もいるでしょうが、確かにその通り。
indexの部分も実は小さな単独DBですので、保守運用的には個別に扱えるのも便利/仕方が無いです。
indexは1つの本体に複数個定義できますので(主キーとできるキーはひとつとは限らない)、余計に同期が肝要です。

あと、

東証のシステムは、ハードを二重化してバックアップ体制を整えているが、ソフトは「ソフトのバックアップを整えることは、現実的には不可能」

これも判る気がします。
以前に航空管制計画システムのデータにバグがありダウンしたことがありましたが、バックアップにも同じソフトとデータがあるので、ハードの故障でなければ、切り替わってもそこでバグが再現されてまたダウンしてしまいます。
だからソフトのバグに対してのミラーリングはあまり意味がありません。
じゃあ「古いバージョンに戻すリカバリバックアップ」はどうかといいますと、今回の東証のようにデータ構造に変更があったので、プログラムだけ戻しても古いプログラムは新しいデータに対応してないので読めない(従来の範囲を超えたらエラーとかになる)。
じゃあデータもセットで昔に戻せば同期が合いますが、取引会員が増えての更新や、新フライトプランの時刻表では、もはや昔に戻るわけにはいかないです。データの構造変化を伴う更新の場合、もはや後には引けないのが運用の実情かと。

じゃあどうすればいいの?と問われれば、
究極には、やはり運用者の気配りでしょうか。
「あの作業やってくれた?」と声をかけてくれたり、「まて、その場合はこの作業も必要だぞ」と気付いてくれる人が最後の砦だなあと思うのが私の実体験によるところです。

(補足)
http://www.atmarkit.co.jp/news/200511/02/tse.html
こっちの記事によれば、今回のシステムはメインフレームだとありますね。となるとMかGSのシリーズの機種なんでしょうね。
汎用機って自己修復とか自動変更とか仕掛けは少なくて、作業は人がその都度小分けで実行するアーキテクチャという印象があるので、過程が見やすいぶん、作業漏れもあるわけで。WindowsXPのエラーからの自動リカバリなんか何やってるのか見た目で判らないので本当に直ってるのか不安ですけどね(笑)。
あと、歯抜けとかの表現をしましたが、物理的にディスク上からデータの消去はたぶんしないと思います。削除フラグを書き込んで隠すだけかと。MS-ACCESSでも「ファイル圧縮」があるように、レコード削除をしても実際は消えてないほうが効率がいい。空き隙間を探して上書きするのは時間がかかるのでファイルの末尾にひたすら足すほうが速いとかありますから。
だから月末に削除フラグのレコードをまとめて撤去して隙間を詰める作業が必要になります>データベースたるもの
あと、人の話で「新生データセットのカタログ忘れじゃないの?」ということも聞きました。
まさか…と思いますが可能性はこれもありますね。
汎用機ではデータセット(DS:ファイルのこと)を作るだけではプログラムからは見えず、「カタログ」という作業でDASDのDS一覧情報に掲載されてはじめて認識できます。普段はDSを作ると同時にカタログもされるので不整合は無いのですが、カタログ未登録でDASDには存在する(アンカタログ状態)、DASDから物理的に消去されているのにカタログ情報が依然として残っている、という現象が汎用機のファイルシステムではたまーに発生します。(運用のミスとかテスト実行失敗でファイルが中途半端になる)
参照テーブル(データベース)がアンカタログ状態になっていれば、プログラムはfile-not-foundでエラーになります。
今回のニュースでは「読み出し位置が狂った」という表現をしていたので、アンカタログではないのかもしれません。DBの各テーブルはDASD上ではテキストファイルとかと同格にDSに過ぎないのでカタログは必須です。
運用ツールではカタログを経由せずに直接DASDを閲覧するとかできるので、アンカタログ状態のも把握はできますが、見えないのは不便なことには違いありません。
あとデータベースとしてのDSは「排他制御ロック」という属性があり、これがアクティブだとプログラムからのアクセスを拒否します。リカバリーでデータを復旧中とか、データをこれ以上更新されたくない場合にツールやコマンドでこの属性を与えます。
作業後にこれの解除を忘れると、翌日にプログラムがアクセス拒否されましたエラーとか出すわけです。

コンピューターはウソ付かないので、やはり人のミスでのトラブルなのでしょう。ハード故障由来よりは多いかと。
機能や仕様が複雑なほどチェック項目が多いので、大規模システムほどミスする確率はあがりますよね…。
私も用心しないと。

|

« 土星衛星タイタン探査機カッシーニ撮影と石油 | トップページ | ウォークマンスティック用ケース »

IT・汎用機」カテゴリの記事

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/3180/6828775

この記事へのトラックバック一覧です: 東証停止原因はエイリアス?名証はパスワード?:

» 東京証券取引所のシステム障害 [次世代情報都市みらいBlog]
11月1日、東京証券取引所のシステムに障害が発生して全銘柄の取引が停止した件ですが、インターネット上では技術的原因について以下のような情報があります。 [続きを読む]

受信: 2005.11.07 22:11

« 土星衛星タイタン探査機カッシーニ撮影と石油 | トップページ | ウォークマンスティック用ケース »