(57)【要約】【課題】保守員が顧客先に出向くこと不要として、レイド内でプログラム交換を自動的に行うこと。【解決手段】ネット上にホスト４、レイド７および監視装置６が設置されている状態で、ホスト４から監視装置６にプログラム交換を指定した場合、監視装置６では、レイド７内に格納されている保守情報を分析し、その分析の結果として最適なプログラムや最適交換順序等を抽出し、抽出された情報に基づき、レイド７にプログラム交換を指示するようにしたものである。【選択図】　図１
2004013524.tif 000002
【特許請求の範囲】
【請求項１】
個々の記憶ディスク装置内に保守情報を格納し、該保守情報を分析し、該分析の結果としての交換順序に基づき、プログラム交換を行うようにしたプログラム交換方法。
【請求項２】
請求項１記載のプログラム交換方法において、複数のプログラム交換パターンに応じたロードプログラムを記憶ディスク装置内に持つことで、選択的に交換順序を決定し、プログラム交換を実行するプログラム交換方法。
【請求項３】
請求項１または２に記載のプログラム交換方法において、
前記記憶ディスク装置は、前記プログラムが格納される部位を局部的に断電する局部断電手段と、前記局部断電手段によって断電された部位に再度通電された場合に前記プログラムの再起動を行う再起動手段と、を有し、
前記交換順序性が保たれなかった場合に、前記局部断電手段が、当該プログラムが格納される部位を局部的に断電する断電ステップと、
前記断電ステップによって断電された部位に再度通電するステップと、
前記プログラム交換を再施行するステップと、
前記再施行が終了した後に、前記再起動手段によって前記プログラムの再起動を行うステップとからなるプログラム交換方法。
【請求項４】
請求項１または２に記載のプログラム交換方法において、
前記記憶ディスク装置は、前記プログラムが格納される部位を局部的に断電する局部断電手段と、前記局部断電手段によって断電された部位に再度通電された場合に前記プログラムの再起動を行う再起動手段と、を有し、
前記記憶ディスク装置内でプログラム単位にトレース管理することにより、局部断電再起動が必要となった場合、プログラム交換が失敗した場合、および動作が不安定となった場合のそれぞれの場合に対応したプログラム交換のリカバリーを実行するプログラム交換方法。
【請求項５】
ネット上にホスト、記憶ディスク装置および監視装置が設置されている状態で、前記ホストから前記監視装置にプログラム交換を指定した場合、前記監視装置では、プログラム交換対象の記憶ディスク装置に格納されている保守情報を分析し、該分析の結果としての交換順序に基づき、該記憶ディスク装置にプログラム交換を指示するようにしたプログラム交換方法。
【請求項６】
請求項５に記載のプログラム交換方法において、前記ホストから前記監視装置を介して、複数の前記記憶ディスク装置の各々に、プログラム交換上の個々の設定を行うようにしたプログラム交換方法。
【請求項７】
請求項６に記載のプログラム交換方法において、前記ホストからの最適化設定の指示に基づき、前記監視装置では、各々の前記記憶ディスク装置の構成情報、固有実績データ、マイクロ交換進捗情報、障害情報を含む情報を参照し、前記記憶ディスク装置各々の環境を、プログラム交換により、最適環境に変更するようにしたプログラム交換方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、プログラム交換技術に関し、特に記憶ディスク装置内にあらゆる保守情報を格納し、この保守情報を分析し、この分析の結果に基づき、プログラム交換を行うようにしたプログラム交換方法に関する。
【０００２】
【従来の技術】
現在、記憶ディスク装置はその機能や構成が複雑になり、個々の記憶ディスク装置レベルで特有の複雑構成を持つようになったので、高度な知識と技術が保守（保守員）に必要となっている。その保守には膨大な情報を得ている保守員でなければ、対応することができなくなっているが、その情報量は人間が得られる範疇を超えようとしているのが現状である。記憶ディスク装置でのプログラム交換はその最たるものとされており、今後の記憶ディスク装置の保守に危惧が持たれている。因みに、ここにいう記憶ディスク装置とは、磁気ディスク装置（ＲＡＩＤ＝Ｒｅｄｕｎｄａｎｔ　Ａｒｒａｙ　ｏｆ　Ｉｎｅｘｐｅｎｓｉｖｅ　Ｄｉｓｋｓを含む）やハードディスク装置（ＨＤＤ）と同義語となっている。また、ここにいうプログラムには、ミドルウェアやファームウェアが含まれる。
【０００３】
【発明が解決しようとする課題】
従来にあっては、顧客からの要求があれば、直ぐに保守員が出向き、一台一台手作業でプログラム交換を実施していた。しかしながら、今後、記憶ディスク装置が多様化／多機能化していくためには、あらゆる面でプログラム交換の自動化が不可欠である。この状況を認識し、図１（本発明に係るプログラム交換システムを示す）を参照しつつ、以下の事例１〜５を課題として紹介する。
【０００４】
事例１
ある不良対策を実現するために、Ｄｅｖｉｃｅｃｔｌ１（キャッシュ制御ソフトウェア）とドライブｃｔｌ１（ドライブ制御ソフトウェア）の同期修正を実施した。ドライブｃｔｌ１はＨＤＤ単独で出荷されることが多々あり、オン中（基幹業務中）でのプログラム交換を実現する上では、ドライブｃｔｌ１を先に交換する必要があった。この順序を守らないと、レイド（ＲＡＩＤ−Ａ）７の電源を一旦、切らなければ、交換したプログラムの対策が有効にならないという課題があった。
【０００５】
理由
事故対策時にＤｅｖｉｃｅｃｔｌ１とドライブｃｔｌ１間で新規インタフェースを追加。　ＤＫＵ（キャッシュ・ＨＤＤ接続用ハードウェア）マイクロ（マイクロプログラム）が新インタフェースをサポートしているか否かを確認するには、Ｄｅｖｉｃｅｃｔｌ１側からＩｎｑｕｉｒｙ（問合せ）コマンドを発行して確認する。しかしながら、通常、Ｉｎｑｕｉｒｙコマンドの取込みは、ＨＤＤ増設やリプレース（ＲＡＩＤ内局部を断電（ＤＫＡの抜差し））以外では、Ｄｅｖｉｃｅｃｔｌ１のマイクロ交換のタイミングしかないため、Ｄｅｖｉｃｅｃｔｌ１の交換を実施した後にドライブｃｔｌ１の交換を実施した場合には、Ｉｎｑｕｉｒｙコマンドが発行されないため、再度、ＲＡＩＤ−Ａの電源を一旦、切るか、あるいは再度、Ｄｅｖｉｃｅｃｔｌ１の交換が実施されなければ対策が有効にならない。他にも全ＤＫＡをダミーリプレースすれば、ＨＤＤドライブとの調停を結び直すので有効であるが、これは指示できない。なお、ＲＡＩＤ内局部断電が必要とされているのは、ＲＡＩＤの場合は、多数のユーザが使用しているので、断電することはできない。そこで、局部断電→再起動が必要になる。
【０００６】
因みに、Ｄｅｖｉｃｅｃｔｌ１等について補足説明すれば、Ｄｅｖｉｃｅｃｔｌ１は各ＰＫｃｔｌ（パッケージ制御ソフトウェア）１−ｎにアクセスする機能を持つ。また、ドライブＣｔｌ１−ｎにアクセスする機能を持つ。更に、ＲＡＩＤ内のＤＢ（ＤＢ：データベース）（ＲＡＩＤ−ＤＢ）にアクセスする機能を持っている。更にまた、ＨｏｓｔｃｔｌＭ（ＨｏｓｔｃｔｌＡアクセスソフトウェア）にアクセスする機能を持っている。これら以外にも、各Ｐｏｒｔ（ポート）に流れる入出力データを監視制御する機能や、ＰＫｃｔｌ→Ｐｏｒｔｃｔｌ（ポート制御ソフトウェア）を経由して監視ｃｔｌ（ネット内一括監視／管理ソフトウェア）にアクセスする機能を持っている。
【０００７】
以上のように、Ｄｅｖｉｃｅｃｔｌ１とは、本システムを全て制御するプログラムを言って過言ではなく、全体を監視制御することで、ＲＡＩＤ内の特性の基準値（母数）を持った実績データを収集することが可能となる。例えば基幹入出力時間に対する特性、基幹入出力数に対する特性、Ｄｅｖｉｃｅｃｔｌ１のタイムクロックを基準にした特性、エラー数に対した特性、稼動時間に対した特性、稼動機能に対した特性等を採取することができる。
【０００８】
また、ドライブｃｔｌは、勿論、定義ファイルを含めたプログラムのことで、通常、ＨＤＤに依存したプログラムとなる。ＨＤＤの特徴を活かした、付加価値を持ったプログラムである。
【０００９】
事例２
ドライブｃｔｌ１でＳＣＳＩリセットが発行されると、ＨＤＤドライブがハングするという問題があり、対策版マイクロを発行した。単独でドライブｃｔｌ１を更新すれば問題はないが、Ｄｅｖｉｃｅｃｔｌ１と一緒に上げる場合には、事例１と同じ様に、ドライブｃｔｌ１→Ｄｅｖｉｃｅｃｔｌ１の順番で実施する必要があった。
【００１０】
理由
Ｄｅｖｉｃｅｃｔｌ１交換時にＨＤＤに対してＳＣＳＩリセットを入れるため、ＲＡＩＤが未対策版の場合に、ハングアップするという問題を引き起こすため。対策のためのプログラム交換で手順を誤ると、当該不良を発生させる可能性があった。
【００１１】
事例３
ＲＡＩＤのＸＸ−１２（ＸＸ：バージョン、１２：レビジョン（ｒｅｖｉｓｉｏｎ））版で、新ドライブサポート情報（互換ＨＤＤ含む）をＤｅｖｉｃｅｃｔｌ１側に反映させるため、ＨＤＤ定義ファイルの交換を実施する手順を追加した。従来の手順は定義ファイルを最後に実施する手順であった。即ち、従来の手順では、ＨｏｓｔｃｔｌＡ（ディスクアクセスソフトウェア）→それ以外→定義ファイルであったが、ＸＸ−１２版未満からＸＹ−１２版以降に上げるためには、ＨｏｓｔｃｔｌＡ→ドライブｃｔｌ１以外のプログラム→定義ファイル＋ＨＤＤ定義ファイル→ドライブｃｔｌ１という手順に変更した。
【００１２】
理由
ＨＤＤ定義ファイルは各種情報定義ファイルの１つで、ＨＤＤに関する各種パラメータが格納されている。ＨＤＤには、互換ＨＤＤというものがある。この互換ＨＤＤとは、新型ＨＤＤのことで、大容量、且つ付加価値／付加機能を持っており、従来のＨＤＤとの互換性を保つためにインタフェースを同等とし、加えて新インタフェースが付加されている。古いマイクロ（古いＤｅｖｉｃｅｃｔｌ１）でも互換ＨＤＤは搭載可能であるが、当然、新しいＨＤＤタイプそのものは認識できないため、古いＨＤＤタイプと認識する。ところが、古いタイプのＨＤＤに見えても、実体は新しいタイプのＨＤＤなので、古いマイクロでは、互換ＨＤＤのドライブｃｔｌ１マイクロ交換が実施できない様細工している。ＸＹ−１２版ではＤＫＲｘＢ／ｘＣ（ＨＤＤの型名）の互換ＨＤＤが認識できるマイクロで、　ＸＹ−１２未満、且つ互換ＨＤＤが搭載されている可能性を考えると、ドライブｃｔｌ１マイクロ交換前にＤｅｖｉｃｅｃｔｌ１を認識対応のマイクロに上げ、且つ必要な構成情報をＤｅｖｉｃｅｃｔｌ１側に渡すという段取りが必要になるので、このようなプログラム交換には順序性が必要となる。一般にＨｏｓｔｃｔｌＡ→Ｄｅｖｉｃｅｃｔｌ１であるが、通信のしかたを変更等する場合には、Ｄｅｖｉｃｅｃｔｌ１→ＨｏｓｔｃｔｌＡの順序で交換を実施しなければならないケースもある。
【００１３】
事例４
ＲＡＩＤには、複数ＲＡＩＤと同期を取って実施する機能（データ移行機能等）が多々ある。例えば、ＲＡＩＤ−Ａとレイド（ＲＡＩＤ−Ｂ）３がリンクしデータを移行させる際には、ＲＡＩＤ−ＡとＲＡＩＤ−Ｂ内のプログラムも適合したものでなければ機能しない。機能、あるいは用途に合ったプログラムをＲＡＩＤ−ＡとＲＡＩＤ−Ｂにインストールしなければならなかった。
【００１４】
事例５
顧客先でのプログラム交換作業で、装置指定（記憶ディスク装置製造番号指定と順番）、プログラムレビジョン指定、時間指定、期間指定等の要求に応えなくてはならず、ＯＮ中（基幹常務中）での交換や、実績のある（故障がない）プログラムの交換要求に応えなければならなかった。更に、顧客は常に良い環境であることを希望するが、そのためには、何度も保守員が顧客先に出向く必要があった。
【００１５】
以上の事例１〜５からも判るように、記憶ディスク装置には特殊な事情があり、これら事情を考慮しつつ、プログラム交換を行うことが必要となっている。
【００１６】
本発明の目的は、個々の記憶ディスク装置内に格納されている保守情報を分析し、その分析の結果や、記憶ディスク装置に局部断電・再起動機能を持たせる等することで、順序性が崩れたプログラム交換、または一部のプログラム交換の失敗にも容易に対処可能として、その記憶ディスク装置内でプログラム交換を自動的に行い得るプログラム交換方法を提供することにある。
【００１７】
また、本発明の目的は、保守員が顧客先に出向くことを不要として、即ち、遠隔からの指示により、記憶ディスク装置内でプログラム交換を自動的に行い得るプログラム交換方法を提供することにある。
【００１８】
【課題を解決するための手段】
本発明のプログラム交換方法は、個々の記憶ディスク装置内に保守情報を格納し、該保守情報を分析し、該分析の結果としての交換順序に基づき、プログラム交換を行うようにしたものである。
【００１９】
また、本発明のプログラム交換方法は、複数のプログラム交換パターンに応じたロードプログラムを記憶ディスク装置内に持つことで、選択的に交換順序を決定し、プログラム交換を実行するものである。
【００２０】
さらに、本発明のプログラム交換方法は、前記記憶ディスク装置が、前記プログラムが格納される部位を局部的に断電する局部断電手段と、前記局部断電手段によって断電された部位に再度通電された場合に前記プログラムの再起動を行う再起動手段と、を有し、前記交換順序性が保たれなかった場合に、前記局部断電手段が、当該プログラムが格納される部位を局部的に断電する断電ステップと、前記断電ステップによって断電された部位に再度通電するステップと、前記プログラム交換を再施行するステップと、前記再施行が終了した後に、前記再起動手段によって前記プログラムの再起動を行うステップとからなるものである。
【００２１】
また、本発明のプログラム交換方法は、前記記憶ディスク装置が、前記プログラムが格納される部位を局部的に断電する局部断電手段と、前記局部断電手段によって断電された部位に再度通電された場合に前記プログラムの再起動を行う再起動手段と、を有し、前記記憶ディスク装置内でプログラム単位にトレース管理することにより、局部断電再起動が必要となった場合、プログラム交換が失敗した場合、および動作が不安定となった場合のそれぞれの場合に対応したプログラム交換のリカバリーを実行するものである。
【００２２】
さらに、本発明のプログラム交換方法は、ネット上にホスト、記憶ディスク装置および監視装置が設置されている状態で、前記ホストから前記監視装置にプログラム交換を指定した場合、前記監視装置では、プログラム交換対象の記憶ディスク装置に格納されている保守情報を分析し、該分析の結果としての交換順序に基づき、該記憶ディスク装置にプログラム交換を指示するようにしたものである。
【００２３】
また、本発明のプログラム交換方法は、前記ホストから前記監視装置を介して、複数の前記記憶ディスク装置の各々に、プログラム交換上の個々の設定を行うようにしたものである。
【００２４】
さらに、本発明のプログラム交換方法は、前記ホストからの最適化設定の指示に基づき、前記監視装置では、各々の前記記憶ディスク装置の構成情報、固有実績データ、マイクロ交換進捗情報、障害情報を含む情報を参照し、前記記憶ディスク装置各々の環境を、プログラム交換により、最適環境に変更するようにしたものである。
【００２５】
【発明の実施の形態】
以下、本発明の実施の形態について、図１から図１２により説明するが、その具体的説明に先立って、その概要について簡単ながら説明すれば、以下のとおりである。
【００２６】
即ち、監視装置からネット上の全ての記憶ディスク装置を自動的に監視可能とし、記憶ディスク装置内にあらゆる保守に対応した情報（現象と対応システムと常に蓄積される稼動実績データと相性と癖とプログラムとロードプログラム等）を格納可能とし、この情報を分析することで、最適なプログラムの選出と適合性と最適交換順序等の抽出が可能となり、これまで、人間が作業に介入しなければならなかった局部断電をも自動化し、常に個々の記憶ディスク装置状態を監視解析しながら、個々の記憶ディスク装置環境と使用機能に適合した状態に、ホストからの指示でプログラム交換の実行を可能ならしめたものである。
【００２７】
記憶ディスク装置は、プログラムが格納される部位を局部的に断電する局部断電手段と、前記局部断電手段によって断電された部位に再度通電された場合に前記プログラムの再起動を行う再起動手段と、を有している。
【００２８】
具体的に、事例１，２での課題を解決するには、ＲＡＩＤ内のデータベースに、交換規則性と特徴性を記録させ、それを制御するロードプログラムを記憶させておく。また、万が一、同時に実行（交換作業）したプログラムのある一部が失敗し規則性（順序性）が狂った場合でも、自動的に失敗したプログラムをリトライ（再交換）で復活させて、自動的に局部ダミーリプレース（ＲＡＩＤ内局部を断電（ＤＫＡの抜差し））をすることで、課題を解決すればよい。
【００２９】
また、事例３での課題を解決するには、事例１，２での解決手段に加え、ＲＡＩＤ内の全プログラムの管理（レビジョン等）、全構成（ＨＤＤ）の管理を行うことで、課題を解決できる。
【００３０】
更に、事例４での課題を解決するには、事例１〜３での解決手段に加え、総合管理監視装置（図１に示す監視装置（監視―Ａ）６に相当）を複数ＲＡＩＤからアクセスできるネット上に配置することで、課題を解決できる。
【００３１】
更にまた、事例５での課題を解決するには、事例１〜４での解決手段に加え、複数のＨｏｓｔが遠隔地からプログラム交換に関する様々な要求を設定実行する機能と、細部的に状態−構成−進捗−障害−稼動率性−障害性−安定性を参照・分析する機能を総合管理監視装置、即ち、監視―Ａに持たせることで、課題を解決できる。
【００３２】
さて、本発明について具体的に説明すれば、図１に、本発明に係るプログラム交換システムの一例でのシステム構成を示す。図示のように、ホスト（Ｈｏｓｔ−Ａ）４と監視−ＡとＲＡＩＤ−ＡとＲＡＩＤ―ＢはＮＥＴ−Ａ（低速ネット−Ａ）で接続されている。ホスト（Ｈｏｓｔ−Ｂ）２とレイド（ＲＡＩＤ−Ｃ）１は別のＮＥＴ−Ｂ（低速ネット−Ｂ）で接続されている。ＮＥＴ−ＡとＮＥＴ−ＢはＷＡＮで接続されている。ＲＡＩＤ−ＡとＲＡＩＤ−Ｂと顧客（Ｃｌｉｅｎｔ１）５と監視―ＡはＮＥＴ（高速ネット）で接続されている。なお、図１は、あくまでも、一例でのシステム構成であるので、ネッ規模／各装置規模／各部位は無限の拡張性を持っていることに注意されたい。
【００３３】
Ｈｏｓｔ−Ａは、ＨｏｓｔｃｔｌＡとＨＯＳＴＡ−ＤＢを持っている。ＨｏｓｔｃｔｌＡは、記憶ディスク装置とアクセスする時に必要なソフトウェアである。例えば、ＲＡＩＤ−ＡのＨｏｓｔｃｔｌＭにアクセスしてＲＡＩＤ内の情報を取得、または記憶ディスク装置内に情報に設定することができる。ＨＯＳＴＡ−ＤＢはその時に取得した情報や作成した情報を格納し、これら情報は、記憶ディスク装置とのアクセス情報として扱われる。Ｈｏｓｔ−Ａの機能はＨｏｓｔ−Ｂも同じように持っている。また、Ｃｌｉｅｎｔ１は、ＮＥＴを経由してＲＡＩＤ―ＡとＲＡＩＤ―Ｂに接続されて、入出力データ（この入出力データとは、ファイルデータのような、ディバイス装置が本来の目的で使用するインプット／アウトプットの情報（顧客が基幹業務で扱う情報）を送受信している。
【００３４】
監視―Ａは、監視Ｃｔｌと監視−ＤＢを持っている。監視ｃｔｌは、ネット内を一括監視（状態／構成／マイクロ交換作業）／管理するソフトウェアである。監視ｃｔｌは、ＨｏｓｔｃｔｌＡとＨｏｓｔｃｔｌＭに接続性を持ち、Ｈｏｓｔ−ＡとＲＡＩＤ−Ａとのアクセスを可能としている。Ｈｏｓｔ−Ａは監視−ＡとＮＥＴ−Ａで接続されてアクセスをする。ＲＡＩＤ−Ａと監視−Ａは、ＮＥＴ−ＡとＮＥＴを経由して接続されてアクセスをする。監視―Ａは、プログラム交換前に、それぞれのＲＡＩＤにプログラムを、ＮＥＴを介して速やかに格納することができる。監視―Ａは、Ｈｏｓｔ−Ａからのプログラム交換の詳細な要求を処理し、指定されたＲＡＩＤに指定された要求項目で交換要求することができる。交換中のＲＡＩＤの状態も、随時、または必要に応じ目的のＲＡＩＤから取得することができる。
【００３５】
監視−ＤＢは、ＨＯＳＴＡ−ＤＢとＲＡＩＤＡ−ＤＢとの間に位置し、情報の取得／送信と更新を常時可能としている。例えば監視−Ａは監視ｃｔｌを使って、ＲＡＩＤＡ−ＤＢに格納されている構成情報／状態情報／マイクロ交換に必要な情報をＮＥＴ経由で常時取得／設定できる。その結果、必要なデータは監視−ＤＢに格納される。
【００３６】
ＲＡＩＤ−Ａは様々な機能を持ったパッケージＰＫ−１〜ＰＫ−５／キャッシュメモリ／ＤＫＡ／物理ドライブ（ＨＤＤ−Ａ〜ＨＤＤ−Ｅ〜）を装備している。他には、電源やバッテリー、ハブ、センサー等、多くの部位を備えているが、本発明には直接関連がないので、説明を省略する。他のディバイスの詳細部位も同様である。
【００３７】
各パッケージＰＫは独自のソフトウェアＰｏｒｔｃｔｌ１／ＰＫｃｔｌ１／Ｐｏｒｔｃｔｌ５／ＰＫｃｔｌ５で動作している。また、それぞれのパッケージＰＫは複数のＰｏｒｔを装備し、そのＰｏｒｔからＮＥＴに接続されている。Ｐｏｒｔｃｔｌ１とＰｏｒｔｃｔｌ５は、各ｐｏｒｔを制御するソフトウェアであり、また、ＰＫｃｔｌ１とＰＫｃｔｌ５は、ＰＫの母体となるソフトウェアであり、Ｄｅｖｉｃｅｃｔｌ１にアクセスする機能を持つ。
【００３８】
キャッシュはＤＫＡを経由して各ＰＫとディバイス（ＨＤＤ−Ａ〜ＨＤＤ−Ｅ〜）と物理的に接続されている。キャッシュは主なアクセスが必ず経由されるといって過言でなく、そのキャッシュを制御している母体ソフトウェアがＤｅｖｉｃｅｃｔｌ１である。このＤｅｖｉｃｅｃｔｌ１はディバイス（ＨＤＤ−Ａ〜ＨＤＤ−Ｅ〜）とアクセスする機能を持ち、ＨｏｓｔｃｔｌＡにアクセスするのに必要なＨｏｓｔｃｔｌＭが存在する。
【００３９】
ＤＫＡは、キャッシュとＨＤＤを接続するハードウェアであり、内部はクロス論理となっているので、あるポイントが故障しても、問題なく動作することができるようになっている。
【００４０】
ＨＤＤ−Ａ〜ＨＤＤ−Ｅは、顧客が実際に基幹業務で使用するデータを管理しているもので、そのデータの管理と入出力の制御等を行うドライブｃｔｌ１〜５を持っている。ドライブｃｔｌ１〜５はＤｅｖｉｃｅｃｔｌ１にアクセスする機能を持っている。
【００４１】
次に、図２，図３それぞれに示すプログラム交換世代記録ＤＢ（Ｐ＿Ｃｈｅ−ＤＢ）について説明すれば、プログラム交換世代記録ＤＢはＲＡＩＤ内に存在するデータベースであり、図１に示すＲＡＩＤ−Ａ内のＲＡＩＤＡ−ＤＢに相当する。このプログラム交換世代記録ＤＢには、本発明に欠かせない情報と、本発明に欠かせない活用の仕組みとなっている。
【００４２】
このプログラム交換世代記録ＤＢは各記憶ディスク装置に存在しており、図２に示すように、主キーはＲＡＩＤ（製造番号）２１となる。主キーのＲＡＩＤ２１と同じレベルには、ＲＡＩＤプログラム（副キー）２２や交換進捗情報２３、交換障害情報２４、交換履歴２５が存在する。交換進捗情報２３には、プログラム交換時に随時変化する交換状態／進捗状態／構成状態に関する結果とトレースが詳細に記録される。この情報には、例えば障害が発生した瞬間（の時間）での各ＲＡＩＤ内部位の状態／進捗状態が、各モジュールレベル／スレッド（ｔｈｒｅａｄ）レベルで小刻みに記録されているので、著明に解析できる。あらゆる部位‐あらゆる部品・あらゆるプログラム（１プログラム内のスレッド単位）に詳細なスタンプ（時間）とともに記録され、また、顧客がある機能を使用している時のトレースも、詳細なスタンプ（時間）とともに記録される。
【００４３】
交換障害情報２４には、交換進捗情報２３を監視しながら、障害情報とその障害に対する対処方法が詳細にトレースし記録される。この情報には、例えば障害が発生した瞬間の各ＲＡＩＤ内部位の状態／進捗状態が各モジュールレベル／スレッドレベルで小刻みに記録されているので、著明に解析できる。どの部位‐どの部品・どのプログラムにどのような障害が発生したか等も記録され、併せて、各対処法でのリカバリー結果等も詳細にスタンプ（時間）とともに記録される。
【００４４】
以上の交換進捗情報２３と交換障害情報２４が活用される場合での一特徴としては、以下のようなものが挙げられる。
１）Ａプログラムは、どのような機能を使用している時に、どのような現象になり易いかが解析できる。
２）Ａプログラムは、どのような機能を使用している時に、どのような安定性−稼動率を実績したかが解析できる。
３）Ａプログラムは、どのような構成の時に、どのような現象になり易いかが解析できる。
４）Ａプログラムは、どのような構成の時に、どのような安定性−稼動率を実績したかが解析できる。
【００４５】
これらの各対処（リカバリー）法の解析が可能で、最適解を分析することが可能となる。
【００４６】
交換履歴２５には、プログラム交換間（世代間）での情報が記録される。例えば、前記の分析／解析の結果を記録しておけば、固有ＲＡＩＤとしての履歴書として扱うことができる。世代間の特徴や、ＲＡＩＤ間の分析等としても扱える。
【００４７】
ＲＡＩＤプログラム２２は副キーとなり、これには、各世代（番号）情報が格納される。ＲＡＩＤのプログラムが交換／更新／変更される度に世代番号が採取され、その世代番号内テーブルには、交換時に必要になった／必要となる情報が格納される。ある一部のプログラム交換があった場合にも世代が変わる。この情報は、次のプログラム交換時（次の世代）に必要となる情報である。また、現在の状態を確認／監視するのに必要な情報となる。更に、障害が発生した時の修復の情報としても必要となる。更にまた、世代間の特徴を知る情報として扱える。
【００４８】
世代番号２６はキーとして、世代構成情報２７、交換日２８、世代交換進捗情報２９、世代障害情報３０が存在する。その交換日２８には、プログラム交換された日が記録される。世代交換進捗情報２９には、交換進捗情報の情報が記録される。最新の世代テーブル内の世代交換進捗情報２９には、交換進捗情報２３と同期して同じ情報が記録される。世代が変わる、即ち、プログラム交換されると、それまでの情報が保管される。新しい交換進捗情報２３の情報は、新しい世代テーブルの世代交換進捗情報２９に記録されていく。
【００４９】
世代障害情報３０には、その世代で発生した障害情報／対処方法が詳細に記録される。最新の世代テーブル内の世代障害情報３０には、交換障害情報２４と同期して同じ情報が記録される。世代が変わる、即ち、プログラム交換されると、それまでの情報が保管される。新しい交換障害情報２４の情報は、新しい世代テーブルの世代障害情報３０に記録されていく。
【００５０】
図３に示すように、世代構成情報２７にはキーとして、ＰＫ１〜ｎのロケーション情報（ＰＫ１のロケーション情報３１）、キャッシュメモリのロケーション情報、物理ＤＩＳＫ（ＨＤＤ１〜ｎ）のロケーション情報、ＨＯＳＴ情報、ＤＫＡのロケーション情報等のＲＡＩＤ内の構成情報が詳細に記録されている（他の部位については、本発明に直接関係がないので、その説明を割愛）。
【００５１】
ＰＫ１〜ｎ（ＰＫ−１、ＰＫ−２）のロケーション情報には、配置情報が格納されている。その配置情報から、例えばＰＫ−１はＳＳＳ（ＳＳＳ：スロットの名称）スロットに設置されていることが判る。ＰＫ１〜ｎ（ＰＫ−１、ＰＫ−２）のロケーション情報にはキーとして、ＰＫの型名情報３２、Ｐｏｒｔｃｔｌ情報３３、ＰＫｃｔｌ情報３４が格納されている。ＲＡＩＤ内の存在するＰＫロケーション数分のテーブルが存在する。これにより、ＲＡＩＤ内のＰＫ実装状態／構成を世代別に把握することができる。
【００５２】
Ｐｏｒｔｃｔｌ情報３３は、レビジョン／管理代表レビジョンをキーとして、稼動情報３５、障害情報３６を持っている。（例えばＰｏｒｔｃｔｌ情報）稼動情報３５には、プログラムの稼動状態／安定性が定期的に記録されることで、次の世代（プログラム交換時）の実績データとして扱える（世代交換進捗情報と世代障害情報内に含まれたＰｏｒｔｃｔｌ情報だけに特化した部分の詳細な情報を稼動情報に格納）。また、この実績データは、他のＲＡＩＤ（同一構成）で同じプログラムが交換される際での検討資料として扱える。
【００５３】
稼動情報３５としては、ＲＡＩＤで使用しようしている形態／機能も統括して管理することで、形態／機能に対する稼動情報も採取することができる。例えばＲＡＩＤ−ＢでＰＫ−１にＰｏｒｔｃｔｌ−１−Ａをインストールしたい場合、ＲＡＩＤ−ＡのＰＫ−１内のＰｏｒｔｃｔｌ−１−Ａの稼動情報を参照して稼動の安定性を確認し、ＲＡＩＤ−ＢにＰｏｒｔｃｔｌ−１−Ａをインストールするか否かの判断資料として扱うことができる。使用しようしている形態／機能も統括して管理しているので、癖のあるプログラム（例えば、形態／機能によって稼動状態が違うプログラム）も判断することができる。監視―Ａの監視範囲（接続ＲＡＩＤ数）が大きい程、採取できるデータが増えるので、その価値は高まることになる。
【００５４】
（例えばＰｏｒｔｃｔｌ情報）障害情報３６は、次の世代（プログラム交換時）の実績データとして扱える（世代交換進捗情報と世代障害情報内に含まれたＰｏｒｔｃｔｌ情報だけに特化した部分の詳細な情報を障害情報に格納）。また、この実績データは、他のＲＡＩＤ（同一構成）で同じプログラムが交換される際での検討資料として扱える。どのような状態で、どのような障害が発生し易いのかを稼動情報と併せて解析することができる。これで、癖のあるプログラム（例えば形態／機能によって、障害の発生率が違うプログラム）も判断することができる。
【００５５】
以下、キャッシュメモリテーブルやＤＫＡテーブル、物理ＤＩＳＫ（ＨＤＤ）テーブル、ＨＯＳＴテーブル等も、前記ＰＫ１〜ｎのロケーションテーブルと同様に構成された上、機能している。因みに、ＤＫＡテーブルについて補足説明すれば、図１ではＤＫＡが１つしかないが、実際には複数個存在し、固定されたＲＡＩＤ筐体のロケーションスロットにＤＫＡがインストールされる。このＤＫＡテーブルからは、何れのスロットロケーションに何れのＤＫＡが配置（インストール）されているかが判る。ＤＫＡの局部断電とは、この個々のＤＫＡのことで、分割して局部断電することで、ＯＮ中でのマイクロ交換が可能となっている。
【００５６】
更に、図４，図５それぞれに示すプログラム依存関係ＤＢ（Ｐ＿Ｄｅｐｅｎ−ＤＢ）について説明すれば、プログラム依存関係ＤＢもＲＡＩＤ内のＲＡＩＤＡ−ＤＢに格納される。図示のように、１つ１つのプログラム単位に、管理番号４３、プログラム名４１、レビジョン４２、プログラム格納先ポインタ４４、対応ハード（ハード相性）４５、世代相性（相互相性や癖を含む）４６、プログラムカテゴリ、プログラム交換ロードプログラム等が記録されている。また、実際のプログラムもこのＤＢに記録されている。管理番号４３はそのプログラムを管理している番号であり、１つ々々のプログラムを管理する番号として扱える。
【００５７】
以上のデータ（情報）は製造元から支給されるが、特徴（世代相性−相互相性−癖）については、プログラム交換世代記録ＤＢに記録される実績データを考慮し、修正することが可能である。プログラム交換ロードプログラムには、あらゆるプログラム交換パターンに対応したインストールプログラムを持つ（癖、特徴、実績、相性等を考慮している）。
【００５８】
ＰＫ対応型名リストには、プログラムに対応したＰＫの型名が格納されている。また、ＰＫとプログラムとの相性情報も格納されている。例えばプログラム交換できるＰＫが複数存在したとしても、様々な情報から優先順位は存在する（最適ＰＫが存在する）。そのハード的／ソフト的／論理構造的解析見地から得られた情報が格納されている。
【００５９】
世代相性４６では、プログラム交換できる可能性がソフト的論理的見地から判断されている。例えばＡ１，Ａ２，Ａ３，Ａ４のプログラムがあった場合で、現在、Ａ２のプログラムがインストールされていたとする。その時の、あらゆる角度から解析したＡ１，Ａ２，Ａ３，Ａ４との相性／可能性を解析した情報が格納される。
【００６０】
さて、図６に、本発明のプログラム交換方法の概要を、また、図７に、そのプログラム交換方法が実施される際での処理フロー例を示す。先ず図６から説明すれば、図示のように、ＲＡＩＤはＲＡＩＤ−ＤＢを持っているが、このＲＡＩＤ−ＤＢには、既述のプログラム交換世代記録ＤＢ（Ｐ＿Ｃｈｅ−ＤＢ）およびプログラム依存関係ＤＢ（Ｐ＿Ｄｅｐｅｎ−ＤＢ）の他に、実際のプログラム群とロードプログラムが格納されている。監視−ＡはそのＲＡＩＤ−ＤＢを参照することで、図８に示すプログラム世代関係表（ＤＢ）（Ｐ＿ＧｅｎＲｅｌ−ＤＢ）と、図９に示すプログラム相互相性関係表（ＤＢ）（Ｐ＿ＭｕｔＡｆｆ−ＤＢ）とが生成される。このＤＢからは、更に、図１０に示すプログラム交換ロード表（ＤＢ）（Ｐ＿ＥｘｃＬｏａｄ−ＤＢ）と、図１２に示すプログラム最適環境関係表（ＤＢ）（Ｐ＿Ｆ−ＤＢ）とを作成できる。
【００６１】
監視−Ａは、プログラム交換ロード表（ＤＢ）（Ｐ＿ＥｘｃＬｏａｄ−ＤＢ）から、実環境に最も適したプログラム交換手順とその交換の実行を可能とするロードプログラムを参照することができる。プログラム交換方法には色々なパターンがあるが、最適な交換方法は限られ、それぞれに交換成功の確率が高い順に優先順位が存在する。監視−Ａはそのプログラム交換ロード表を参照することができ、また、格納されたアドレス（ロードプログラム格納先）も知ることができるので、監視−Ａはロードプログラムを起動することができる。図１０に示すように、交換優先順位は簡単に順番として付けられているが、実際には、環境／構成／ＯＮ中状態により前後する場合があり得る。
【００６２】
監視−Ａが取得／生成できるＤＢはＨｏｓｔ−Ａからみることができる。実際にロードプログラムを起動指示するのはＨｏｓｔ−Ａである。このＨｏｓｔ−Ａが取得した情報はＨＯＳＴ−ＤＢに格納することができる。
【００６３】
次に、例えば図１を参照しつつ、図７によりプログラム交換方法が実施される際での処理フローについて説明すれば、先ず実際のプログラム交換に先立っては、監視―Ａによりプログラム依存関係ＤＢのデータと各プログラムがＲＡＩＤ−Ａ内のＲＡＩＤＡ−ＤＢに格納される（ステップＳ１，Ｓ２）。この作業はプログラムが変わる（レビジョンＵＰ）時に行われ、併せて、プログラム依存関係ＤＢデータも更新されることで、常に最新番が格納される仕組みとなっている。また、監視―ＡとＲＡＩＤ−Ａはプログラム交換作業に拘らず、常に密接に係わっており、監視―Ａからは障害／状態／構成／進捗等の情報が随時、アクセスにより取得されており（ステップＳ３）、Ｈｏｓｔ−Ａはまた、任意に監視―Ａにアクセスすることで、それら障害／状態／構成／進捗等の情報を取得できる。
【００６４】
Ｈｏｓｔ−Ａは任意のタイミングで監視―Ａに対し、指定するＲＡＩＤのプログラム交換指定をすることができるが、その際での指定の仕方は様々で、複数ＲＡＩＤに同時に指定することもできるし、また、一部のプログラムのみ、指定のレビジョン、複数プログラム同時起動指定、時間指定等、様々な指定が可能となっている（ステップＳ４）。例えばＲＡＩＤ−Ａ（製造番号ＡＡＡＡ）、……………の指定で監視―Ａに命令したとすれば、監視―Ａではそれを受け取り、対象のＲＡＩＤ−Ａが指定された設定で実行できるか否か、交換組合せの確認をする（ステップＳ５）。その交換組合せ確認では、先ずステップ３で読み込んでおいたプログラム交換世代記録ＤＢとプログラム依存関係ＤＢが分析されることで、図８に示すプログラム世代関係表（ＤＢ）が作成された上、各プログラム単位に世代相性と対応ハードの面で交換が可能か否かが解析される。プログラム世代関係表（ＤＢ）では、表内データは新しいプログラムをＲＡＩＤーＤＢにインストールする時に更新される。追加された個々のプログラムについての特徴が格納される。表には３個のプログラムしかないが、実際には、インストールされたプログラムの数だけ存在する。
【００６５】
具体的に、例えば表内のＰｏｒｔｃｔｌ１で説明すると、表中は「Ｃ−Ａ」のプログラムだけであるが、実際は様々なレビジョン（「Ａ−Ａ」「Ａ‐Ｂ」．．「Ｃ−Ａ」．ｅｔｃ．．）が格納されている。この個々のプログラムには他に属性が付加されている。対応ハードは「Ｃ−Ａ」で動作可能（インストール可能）なＰＫの型名を全て格納する。世代相性では、プログラムを交換する際の世代相性（交換成功可能性）を記述する。この世代相性では、現在、バージョンがＣで、レビジョンがＡのプログラム、即ち、「Ｃ−Ａ」のプログラムがインストールされているとすると、この状態で「Ｆ−Ａ」をインストールした場合での相性を知ることができ、「Ｃ−Ａ」から「Ｆ−Ａ」へのレビジョン変更は可能であることが判る。表中は１プログラム（「Ｆ−Ａ」）についての相性しか示されていないが、実際には、保管された全てのプログラムについての相性をも知ることができる（「Ｃ−Ａ」をベースに「Ａ−Ａ」「Ａ‐Ｂ」．．「Ｃ−Ａ」．ｅｔｃ．．への交換相性）。尤も、表中の世代相性では、単に「ＯＫ」としてしか示されていないが、実際には、詳細な分析結果が格納されている（交換の成功率、ハード間の交換時相性、環境／構成／使用状態（ＯＮ中）での交換の可能性等）。プログラム格納先ポインタには、実際にプログラムが格納された位置を示すポインタが格納されている。
【００６６】
次には、図９に示すプログラム相互相性関係表（ＤＢ）が作成される。これにより、インストールされるプログラム間で相互相性が分析されるが、これも、実際には、プログラムの癖、稼動中機能との相性、稼働率−安定性−故障率−実績データから分析される。その表中の認識ＩＤ「Ｏ＃」は図１０に示す「Ｏ＃」とリンクしている。本システムには、役割を持った複数のプログラムが存在するが、その個々のプログラムの種類別に認識ＩＤが付けられている。
【００６７】
ここで、例えば「Ｏ＃１　　Ｐｏｒｔｃｔｌ−１」によりプログラム相互相性関係表（ＤＢ）の説明をすれば、プログラムの種類別に認識ＩＤが付けられるが、個々のプログラムには複数のレビジョンが存在するので、あるプログラムには複数の認識ＩＤが存在することになる。この表の主キーはレビジョンであり、相互相性リストでは、レビジョン「Ｃ−Ａ」をベースに各種プログラムについての相性を知ることができる。
【００６８】
次に、それら分析結果から顧客の環境（装置）に一番適した交換方法が導出される。いくつか有る候補に、これまでの分析結果を考慮し、優先順位を決めるが、問題がなければ、優先順位の高いものからＲＡＩＤ―Ａに対し交換命令を実行する一方、問題があれば（交換が不可能ならば）、そこで終了し、Ｈｏｓｔ−Ａに知らせる。
【００６９】
ＲＡＩＤ−Ａは、監視―Ａから交換命令を受け取ると、格納されたロードプログラムとインストールするプログラムをキャッシュに読み込み、読み込みが完了すると、インストールが開始される（ステップＳ６）。そのインストールの進捗状況は随時、監視―ＡとＨｏｓｔ−Ａから確認可能とされる（ステップＳ７）。
【００７０】
もしも、全交換完了前に、万が一、障害が発生したとしても、交換対象のプログラムに対してリトライインストールをすることも可能であり（ステップＳ８〜Ｓ１０）、その場合、既述の事例１，２のような順序性が必要な場合は、自動的に判断し、保守員が介在することなく、図１１に示すように、局部断電・再起動処理をすることで回避することができる（ステップＳ１１）。また、万が一、回避策が上手く行かず、何度もリトライが発生した場合は、監視―Ａ経由でＨｏｓｔ−Ａに問い合わせ、プログラム交換を中止することができる（ステップＳ１２）。しかし、プログラム交換を中止することを回避する選択もできる。その場合、図１２に示すように、最適環境関係表（ＤＢ）（Ｐ＿Ｆ−ＤＢ）が作成される。例えば、今回、ドライブｃｔｌ１のあるレビジョンをインストール中に、リトライ交換を実施しても、また、局部断電処理をしても、プログラム交換が成功しなかった場合には、最適環境関係表（ＤＢ）（Ｐ＿Ｆ−ＤＢ）が作成・参照される。この最適環境関係表には、各プログラムの各Ｒｅｖ（レビジョン）単位に詳細な最適環境に係る情報が格納されているので、ここからＲＡＩＤ環境−用途に合ったプログラムをＨｏｓｔ−Ａが選択することができる。この図１２に示す情報は、監視―Ａがネット内の各ＲＡＩＤから採取できるので、一番適した実績データ、相性データ、障害データを知ることが可能となる。
【００７１】
因みに、図１２に示す最適環境関係表（ＤＢ）（Ｐ＿Ｆ−ＤＢ）について補足説明すれば、図示のように、追加属性として、稼動機能、稼動実績および障害情報が格納されているが、これら稼動機能、稼動実績、障害情報は各稼動機能をキーとして情報が格納されている。この表を使用することで、環境／構成／ＯＮ中状態にした最適なシステム環境を構築することが可能となる。稼動機能（例えばドライブｃｔｌ１−「Ａ−Ａ」についての動作可能な（お勧め）機能を格納）からは、対象プログラムがインストールされている状態で、どのように機能していたかが判るようになっている。また、稼動実績からは、対象プログラムがインストールされている状態で、どの程度安定して動作していたかが判るようになっている。例えばドライブｃｔｌ１−「Ａ−Ａ」で「ＦＦ」の機能が１０２０時間、問題無く動作したような情報が判るようになっている。稼動機能単位に稼動実績を分析することも可能である。更に、障害情報からは、障害の内容と件数、機能別の件数、障害のレベル等のプログラムが持つ癖が分析可能となっている。例えばドライブｃｔｌ１−「Ａ−Ａ」で「ＦＦ」の機能が１０２０時間で「ＺＺ」のエラーが３回発生したような情報が判るようになっており、エラー内容も詳細にどこの部位にどんなレベルでどの時点でどんな風にエラーが発生したか等の情報が判るようになっている他、処理能力も格納可能となっている。更にまた、相性リストは、図８に示す世代相性の概念と同じもので、これからは、全体の相性が分析される。相互相対リストも、図９に示す相互相対リストの概念と同じもので、これからは、全体の相性が分析される。
【００７２】
したがって、以上のようにして、各種情報が判ると、例えば、ある顧客サイトでドライブｃｔｌの性能に不満を持っており、「ＦＦ」機能が動作している状態で、ドライブｃｔｌ―「Ｃ−Ｃ」がインストールされていることで、最大性能を発揮できないことが、図１２から知ることができる。この場合の最適プログラムは、「Ａ−Ａ」であることを知ることができる。また、顧客サイトでは、「ＦＦ」機能だけでなく、例えば「ＧＧ」機能や「ＪＪ」機能も動作させることがあると予想される。このような場合には、図１２を参照し、最適プログラム交換を行うことによって、場合にあった最適環境を構築することが可能となる。
【００７３】
図７に戻り、説明を続行すれば、Ｈｏｓｔ−Ａはこれらの情報を基に、再度、回復策の実行（最適プログラムのインストール）を指定するが（ステップＳ１３，Ｓ１４）、候補の最適プログラムの中から監視―Ａが自動的に判断して、回復策の実行を指定することもできる。万が一、これによるプログラム交換が失敗した場合は、監視―Ａを介しＨｏｓｔ−Ａに報告されるが、そのプログラム交換に失敗することなく、プログラム交換が全て完了すれば、それぞれのＤＢ更新後、監視―Ａを経由してＨｏｓｔ−Ａに完了の報告を行い、その後、随時、状態監視を行う（ステップＳ１５，Ｓ８，Ｓ１６）。
【００７４】
ところで、突然の不具合、即ち、局部断電再起動が必要となった場合、プログラム交換が失敗した場合、動作が不安定となった場合には、記憶ディスク装置内でプログラム単位に詳細にトレース管理することで、それぞれに対応したプログラム交換のリカバリーが可能となっている。突然の不具合とは、プログラム交換時の異常で交換ができなくなってしまったり、基幹入出力障害、あるいは顧客の不満を回避するためのプログラム交換のことで、適切な回避策を持ったロードプログラムを使うことで、遠隔地からのプログラム交換を可能とする。ハード系（局部断電→再起動）のエラーだけでなく、交換異常の原因は数限りがない。ここでいう不具合とは、ＤＢで回復可能なソフト系の回復対策である。世代間相性や相互間相性で発生するエラーや、並列処理で起こるエラー、潜在問題によるエラーのような、予想できないようなエラーが発生した場合でも、途中でプログラム交換を中止することなく自動的に続行するか、ブレイク確認画面を保守員に通知することで、続行するか否かを判断できるようにする。
【００７５】
最後に、最適化論理について説明すれば、この最適化論理は、プログラム交換の時だけでなく、自動監視／実行化することができる。Ｈｏｓｔ−ＡからＲＡＩＤ−Ａのみに最適化設定の指示を行うとする。自動化のスケジューリングの設定も行う。監視―Ａはその設定指示を受け取ると、各ＲＡＩＤの各プログラム単位に、図１２に示すようなプログラム最適環境関係表（ＤＢ）を作成し、ＲＡＩＤ―Ａに係る情報をマージ（合成）し、ＲＡＩＤ−Ａの環境／稼動状態／機能実力を監視し、最適なプログラムを選択しフレキシブルにインストールし、常に最大限の実力を発揮させるように環境を自動的に調整する。
【００７６】
以上、本発明について説明した。なお、特許請求の範囲に記載された発明以外の発明としては、以下のような発明も考えられる。
（１）：個々の記憶ディスク装置内に稼動実績データ／安定性／故障性／相性等の分析データを格納していくことで、最適なプログラム交換を可能とするプログラム交換管理システム。
（２）：前記システムにおいて、あらゆる状態に応じたロードプログラムを記憶ディスク装置内に持つことで、複雑な条件から順序性が必要なプログラム交換に適した最適なプログラム交換を可能とするプログラム交換管理システム。
（３）：前記システムにおいて、記憶ディスク装置に局部断電機能を持つことで、万が一、順序性が崩れたプログラム交換や一部のプログラムが失敗したときも人間の介入無く、自動的に回避できるプログラム交換管理システム。
（４）：前記システムにおいて、記憶ディスク装置内でプログラム単位に詳細に管理することで突然の不具合にも迅速に対応できるプログラム交換管理システム。
（５）：前記システムにおいて、ネット上に複数ＨＯＳＴと複数記憶ディスク装置と監視装置を設置することで、接続されたＨＯＳＴから監視装置に詳細なプログラム交換（装置／プログラム名／時間等）を指定することができるプログラム交換管理システム。
（６）：前記システムにおいて、ネット上に接続されたＨＯＳＴから監視装置を経由して複数の記憶ディスク装置に個々設定を同時に複雑な設定（最適化自動化指定や遅延指定）ができるプログラム交換管理システム。
（７）：前記システムにおいて、ネット上に接続された監視装置は、各記憶ディスク装置の構成情報、固有の実績データ、マイクロ交換進捗情報、障害情報等を参照し、対象の記憶ディスク装置環境の実力を最大限に発揮できる最適環境に自動的に変更することできるプログラム交換管理システム。
【００７７】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲内で種々変更可能であることはいうまでもない。
【００７８】
【発明の効果】
個々の記憶ディスク装置内に格納されている保守情報を分析し、その分析の結果や、記憶ディスク装置に局部断電・再起動機能を持たせる等することで、順序性が崩れたプログラム交換、または一部のプログラム交換の失敗にも容易に対処可能として、その記憶ディスク装置内でプログラム交換を自動的に行い得る。
【００７９】
また、保守員が顧客先に出向くこと不要として、即ち、遠隔からの指示により、記憶ディスク装置内でプログラム交換を自動的に行い得る。
【図面の簡単な説明】
【図１】本発明に係るプログラム交換システムの一例でのシステム構成を示す図である。
【図２】本発明に係るプログラム交換世代記録ＤＢ（その１）の一例を示す図である。
【図３】同じく、プログラム交換世代記録ＤＢ（その２）の一例を示す図である。
【図４】本発明に係るプログラム依存関係ＤＢ（その１）の一例を示す図である。
【図５】同じく、プログラム依存関係ＤＢ（その２）の一例を示す図である。
【図６】本発明のプログラム交換方法の概要を説明するための図である。
【図７】そのプログラム交換方法が実施される際での処理フロー例を示す図である。
【図８】本発明に係る一例でのプログラム世代関係表（ＤＢ）を示す図である。
【図９】本発明に係る一例でのプログラム相互相性関係表（ＤＢ）を示す図である。
【図１０】本発明に係る一例でのプログラム交換ロード表（ＤＢ）を示す図である。
【図１１】本発明に係る一例でのドライブＣＴＬ障害フローを示す図である。
【図１２】本発明に係る一例でのプログラム最適環境関係表（ＤＢ）を示す図である。
【符号の説明】
１，３，７…レイド、２，４…ホスト、５…顧客、６…監視装置。
【図１】
2004013524.tif 000003
【図２】
2004013524.tif 000004
【図３】
2004013524.tif 000005
【図４】
2004013524.tif 000006
【図５】
2004013524.tif 000007
【図６】
2004013524.tif 000008
【図７】
2004013524.tif 000009
【図８】
2004013524.tif 000010
【図９】
2004013524.tif 000011
【図１０】
2004013524.tif 000012
【図１１】
2004013524.tif 000013
【図１２】
2004013524.tif 000014