(57)【特許請求の範囲】
【請求項１】
コンピュータシステム内で再始動することなく、旧ソフトウェアバージョンを新ソフトウェアバージョンと交換する方法であって、旧ソフトウェアバージョンはタイプと、旧信号インターフェイスと、データをアクセスするための旧変数構造を含む旧ブロック属性を持ち、新ソフトウェアバージョンはタイプと、新信号インターフェイスと、データをアクセスするための新変数構造を含む新ブロック属性を持ち、該方法は、
前記新ソフトウェアバージョンを前記コンピュータシステムにロードするステップと、
旧ブロックと新ブロックのタイプが同じであり、旧信号インターフェイスと新信号インターフェイスがコンパチブルであり、旧変数構造と新変数構造がコンパチブルであると判断した場合に新ソフトウェアバージョンを登録するステップと、
前記新ソフトウェアバージョンの登録に続いて、前記旧ソフトウェアバージョンを不活性化するステップと、
前記旧ソフトウェアバージョン不活性化時に、前記登録された新ソフトウェアバージョンを活性化するステップとからなるソフトウェア交換方法。
【請求項２】
請求項１記載の方法であって、該方法はさらに、
前記活性化された新ソフトウェアバージョンが正しく動作することを確認するステップを含むソフトウェア交換方法。
【請求項３】
請求項２記載の方法であって、
前記確認された新ソフトウェアバージョンを検定することによって、ソフトウェアヴァージョンの変更を完了するステップをさらに含むソフトウェア交換方法。
【請求項４】
請求項２記載の方法であって、前記検定ステップは、
前記不活性化された旧ソフトウェアバージョンを前記コンピュータシステムから除去するステップを含むソフトウェア交換方法。
【請求項５】
コンピュータシステム内で再始動することなく、旧ソフトウェアバージョンを新ソフトウェアバージョンと交換する装置であって、旧ソフトウェアバージョンはタイプと、旧信号インターフェイスと、データをアクセスするための旧変数構造を含む旧ブロック属性を持ち、新ソフトウェアバージョンはタイプと、新信号インターフェイスと、データをアクセスするための新変数構造を含む新ブロック属性を持ち、該装置は、
前記新ソフトウェアバージョンを前記コンピュータシステムにロードする手段と、
旧ブロックと新ブロックのタイプが同じであり、旧信号インターフェイスと新信号インターフェイスがコンパチブルであり、旧変数構造と新変数構造がコンパチブルであると判断した場合に新ソフトウェアバージョンを登録する手段と、
前記新ソフトウェアバージョンの登録に続いて、前記旧ソフトウェアバージョンを不活性化する手段と、
前記旧ソフトウェアバージョン不活性化時に、前記登録された新ソフトウェアバージョンを活性化する手段とからなるソフトウェア交換装置。
【請求項６】
請求項５記載の装置であって、
前記活性化された新ソフトウェアバージョンが正しく動作することを確認する手段をさらに含むソフトウェア交換装置。
【請求項７】
請求項５記載の装置であって、
前記確認された新ソフトウェアバージョンを検定することによって、ソフトウェアヴァージョンの変更を完了する手段をさらに含むソフトウェア交換装置。
【請求項８】
請求項５記載の装置であって、前記検定する手段が、前記不活性化された旧ソフトウェアバージョンを前記コンピュータシステムから除去する手段を含むソフトウェア交換方法。
【発明の詳細な説明】
本特許文献の開示の一部に著作権保護がなされている資料が含まれている。著作権保有者は、特許庁の特許ファイルや記録に載っている、特許文献や開示を誰かがファクシミリで再生することは拒絶しないが、それ以外のあらゆる権利を保有している。
発明の背景
発明の技術分野
本発明は一般的に電気通信交換機内でソフトウェアを更新することに関連している。特に、本発明は電気通信交換機を再始動させることなく旧ソフトウェアバージョンを新ソフトウェアバージョンと交換することにより旧ソフトウェアバージョンを更新する方法およびシステムに関連している。
関連技術の説明
モダンな電気通信産業では、電気通信交換機内で呼を処理するさまざまな局面においてしばしばコンピュータソフトウェア（ソフトウェア）が使用される。残念ながら、電気通信ソフトウェアおよびその他のソフトウェアはエラーや不要な応答を含む場合が多い、エラーや不要な応答は通常欠陥バージョンと置換されるソフトウェアの新しいバージョンにより修正される。
スタンドアロンもしくはバッチ処理システム等のある種のコンピューティングシステムでは、旧ソフトウェアを新バージョンと交換するのにいくつかの障害がある。典型的には、１日の中でアクティビティが殆ど無く保守要員を容易に呼べる期間にコンピュータシステムが完全に閉鎖される。次に旧ソフトウェアを単純に除去して新バージョンと置換される。その後コンピューティングシステムが再始動されてその後のデータ処理は全てソフトウェアの新バージョンにより行われる。
モダンな蓄積プログラム制御（ＳＰＣ）電気通信交換システム（業界では単に“交換機”と呼ばれる）等の他種のコンピューティングシステムでは、システムのソフトウェアを交換することはスタンドアロンバッチ処理システムほど単純ではない。
コミュニティ内の通信サービスに対する連続的なニーズに対処するために電気通信交換機は中断することなく運用されるように設計され計画されている。すなわち、１日の閑散時や夜間でも電気通信トラフィックの連続フローが処理されている。したがって、交換機のどのような運転中断によっても内部の電気通信トラフィックの中断を生じる。このような中断は電気通信産業では極めて望ましくないものである。
電気通信交換機のリアルタイム要求により交換機が処理している既存の電気通信トラフィックを中断させることなくソフトウェアの旧バージョンをエラー修正すなわち“バグフィクス(bug fixes)”を含むソフトウェアの新バージョンと交換することに厳しい制約が課される。電気通信産業では、いかなるダウンタイムも必要とすることなく、運転中に交換機内のソフトウェアを交換する能力を提供する方法およびシステムを有することが極めて望ましい。
したがって、電気通信交換機内で進行中の電気通信トラフィックを中断させることなく交換機の実際の運転中にソフトウェアを交換することは電気通信産業において極めて有用なことである。本発明によりこのような方法およびシステムが提供される。
発明の要約
本発明の目的は電気通信交換機を再始動させることなく交換機内の旧ソフトウェアバージョンを新ソフトウェアバージョンと交換する方法およびシステムを提供することである。
１つの局面において、本発明は電気通信交換機を再始動させることなく交換機内の旧ソフトウェアバージョンを新ソフトウェアバージョンと交換する方法である。交換機はメモリ、ソフトウェアローディングサブシステム、データベース管理サブシステム、およびプログラム交換サブシステムを含んでいる。この方法はソフトウェアローディングサブシステムにより新ソフトウェアバージョンをメモリへロードするステップと、データベース管理サブシステムにより新ソフトウェアバージョンをプログラム交換サブシステムに登録するステップとを含んでいる。この方法はさらにプログラム交換サブシステムにより旧ソフトウェアバージョンを不活性化するステップと、プログラム交換サブシステムにより登録された新ソフトウェアバージョンを活性化するステップとを含んでいる。
別の局面において、本発明は電気通信交換機を再始動させることなく交換機内の旧ソフトウェアバージョンを新ソフトウェアバージョンと交換する方法である。交換機はメモリ、ソフトウェアローディングサブシステム、データベース管理サブシステム、およびプログラム交換サブシステムを含んでいる。この方法はソフトウェアローディングサブシステムにより新ソフトウェアバージョンをメモリへロードするステップと、データベース管理サブシステムを使用して新ソフトウェアバージョンをプログラム交換サブシステムに登録するステップとを含んでいる。この方法はさらにプログラム交換サブシステムにより登録された新ソフトウェアバージョンを活性化するステップと、プログラム交換サブシステムにより旧ソフトウェアバージョンを不活性化するステップとを含んでいる。この方法はまたプログラム交換サブシステムにより活性化された新ソフトウェアバージョンを確認するステップと、プログラム交換サブシステムにより確認された新ソフトウェアバージョンを検定するステップとを含んでいる。
【図面の簡単な説明】
当業者であれば明細書と共に以下の図面を参照すれば本発明をさらに良く理解することができさまざまな目的や利点が一層明白になるものと思われ、ここに、
第１図は本発明の実施例に使われた電気通信交換機とコンピュータシステムを示すブロック図。
第２図は本発明の実施例に従った第１図の電気通信交換機のメモリのプログラム格納エリアａ，参照格納エリアａ，およびデータ格納エリアの構造および内容を詳細に示すブロック図。
第３図は本発明の実施例に従った第１図の電気通信交換機内のプログラム交換（ＰＸＣＰ）サブシステムの構成要素とそれらのソフトウェアローディングサブシステムおよびローディング中央処理装置サブシステムの構成要素とのインタラクションを示すブロック図。
第４図は本発明の実施例に従った第１図の交換機内で旧ソフトウェアユニットを新ソフトウェアユニットと交換するプログラム交換方法のステップを一般的に示すフロー図。
第５図は本発明の実施例に従った第４図の新ソフトウェアユニットの登録ステップを詳細に示すフロー図。
第６Ａ図、第６Ｂ図は本発明の実施例に従った第４図の新ソフトウェアユニットの活性化ステップを詳細に示すフロー図。
第７図は本発明の実施例に従った第４図の新ソフトウェアユニットの確認ステップを詳細に示すフロー図。
第８Ａ図、第８Ｂ図は本発明の実施例に従った第４図の新ソフトウェアユニットの検定ステップを詳細に示すフロー図。
第９Ａ図、第９Ｂ図は本発明の実施例に従った第４図の新ソフトウェアユニットの不活性化ステップを詳細に示すフロー図。
第１０Ａ図、第１０Ｂ図は本発明の実施例に従った第４図の新ソフトウェアユニットの除去ステップを詳細に示すフロー図。
第１１図は本発明のプログラム交換方法を進行させる際の新ソフトウェアユニットのさまざまなプログラム交換状態を示すブロック図。
第１２図は本発明のプログラム交換方法において新旧ソフトウェアユニットが進行するさまざまな段階の例を示すブロック図。
実施例の詳細な説明
次に第１図を参照して、本発明の実施例で使われた電気通信交換機１０４およびコンピュータシステム１０２を例示するブロック図を示す。交換機１０４は記憶装置１１０、ソフトウェア１０８、ハードウェア１０６、メモリ１２２、およびデータベース管理システム（ＤＢＳ）１２４を具備している。交換機１０４は、例えば、スエーデンのＴｅｌｅｆｏｎａｋｔｉｅｂｏｌａｇｅｔ  ＬＭエリクソン社製ＡＸＥ１０等の蓄積プログラム制御交換機とすることができる。蓄積デバイス１１０は、例えば、フロッピードライブ、ハードドライブ、磁気テープドライブ、もしくは光ドライブとすることができる。
第２図に詳細に示すように、メモリ１２２はデータ格納（ＤＳ）エリア２０６、参照格納（ＲＳ）エリア２０４、およびプログラム格納（ＰＳ）エリア２０２へ分割されている。ソフトウェア１０８は記憶装置１１０からメモリ１２２へロードされ、ＰＳ２０２，ＤＳ２０６，ＲＳ２０４の各エリア内に常駐する。ソフトウェア１０８は通信パス１１２，１１４（第１図）を介してハードウェア１０６を制御するのに使用される。コンピュータシステム１０２は通信パス１１６を介して交換機１０４と連絡されている。コンピュータシステム１０２は、例えば、個別のパーソナルコンピュータシステム、オペレーションおよびメインテナンスセンターシステム、網マネジャーセンターシステム、もしくは他の同種のシステムとすることができる。ＤＢＳ１２４は、例えば、セミリレーショナルデータベース管理システムとすることができる。
次に第２図を参照して、本発明の好ましい実施例に従った第１図のメモリ１２２のＰＳ２０２，ＲＳ２０４，およびＤＳ２０６の各格納エリアの構造および内容を詳細に例示するブロック図を示す。プログラム格納（ＰＳ）エリア２０２は各々が一意的な識別番号により識別される複数の機能ブロックを格納するのに使用される。ＰＳ２０２エリア内に格納される各機能ブロックはそれらに関連する変数等のデータを有することができる。ＰＳ２０２エリア内に格納された機能ブロックにより参照される任意の変数がＤＳエリア２０６内に別々に格納される。ＤＳエリア２０６内に格納された各変数も一意的な変数識別番号により識別することができる。参照格納（ＲＳ）２０４エリアはＰＳエリア２０２内に格納された機能ブロックの位置およびＤＳエリア２０６内に格納された関連する変数を決定するのに使用される。
ＲＳエリア２０４は複数の参照テーブルおよびベーステーブルを利用してＰＳエリア２０２内に格納された機能ブロックの位置およびＤＳエリア２０６内に格納された関連する変数を追跡するのに使用される。ＰＳエリア２０２内に格納された各機能ブロックはＲＳエリア２０４内に関連する参照テーブルを有しそれは機能ブロックの一意的な識別番号に従って索引付けされる。ＰＳエリア２０２内の特定の機能ブロックにより使用される各変数はベースアドレステーブル（ＢＡＴ）に指定されたＤＳエリア２０６内にその位置を有している。参照テーブルはプログラム開始アドレス（ＰＳＡ）、およびベース開始アドレス（ＢＳＡ）からなっている。ＰＳＡはＰＳエリア２０２内に格納された関連する機能ブロックの開始アドレスを示す。ＢＳＡはＲＳエリア２０４内に格納された、機能ブロックに関連する、ＢＳＡの位置を示す。
信号分布テーブル（ＳＤＴ）がＰＳエリア２０２内に格納された各機能ブロックの開始アドレスに存在している。ＳＤＴは機能ブロック内のタスク（手順／機能）の位置を指定する。機能ブロック２０８とその関連するテーブルおよび変数も第２図に示されている。機能ブロック２０８はＰＳエリア２０２内に格納されており、機能ブロック番号０１（Ｎｏ．０１）により識別することができる。ＳＤＴ２１０が機能ブロック２０８の開始アドレスに配置され、機能ブロック２０８内の特定のタスクを見つけるのに使用される。機能ブロック２０８はＲＳエリア２０４内に関連する参照テーブル２１２を有している。参照テーブル２１２にはＲＳエリア２０４内で機能ブロック番号Ｎｏ．０１が付けられている。参照テーブル２１２はＰＳＡ２２０およびＢＳＡ２２２からなっている。ＰＳＡ２２０は機能ブロック２０８の開始アドレスを識別する。ＢＳＡ２２２はＲＳエリア２０４内に格納されたＢＡＴ２２４の位置を識別する。ＢＡＴ２２４は機能ブロック２０８により使用される変数の位置を識別する。変数は、例えば、変数状態２１４、Ｄｉｓｔｃｎｔ２１６、およびＭｕｐ２１８とすることができる。
以下の説明は機能ブロック２０８内の特定のタスクをいかに呼び出すかを示す例である。最初に、ＲＳエリア２０４がアクセスされ機能ブロック番号Ｎｏ．０１を付けた任意の参照テーブルが探索される。この実施例では、参照テーブル２１２が探索と一致する。次に、ＰＳＡ２２０を使用して機能ブロック２０８の開始アドレスがつきとめられる。開始アドレスは特定のタスクと結合してＳＤＴ２１０へアクセスし特定のタスクを呼び出すのに使用される。特定タスクの実行中に、機能ブロック２０８は変数状態２１４，Ｄｉｓｔｃｎｔ２１６，もしくはＭｕｐ２１８の使用を要求することができる。機能ブロック２０８が変数の使用を要求すると、機能ブロック２０８はＢＡＴ２２４を使用してＢＡＴ２２４へアクセスしＤＳエリア２０６内の位置を決定する。
次に第３図を参照して、本発明の好ましい実施例に従った第１図の交換機内のサブシステムプログラム交換機（ＰＸＣＰ）３９４の構成要素およびそれらのソフトウェアローディングサブシステム（ＣＰＳ）３９０、ローディング中央処理装置サブシステム（ＬＯＣＰ）３９２の構成要素とのインタラクションを例示するブロック図を示す。ＰＸＣＰ３９４は下記の構成要素を含んでいる、プログラム交換アドミニストレータ（ＰＸＺＡ）３２０、プログラム交換データ差ハンドラー（ＰＸＺＤ）３１８、プログラム交換信号差ハンドラー（ＰＸＺＳ）３１６、およびプログラム交換マシン依存ルーチン（ＰＸＺＭＤ）３１４。ＰＸＣＰ３９４は下記のＣＰＳ３９０構成要素と連絡されている、監査機能コントローラ（ＡＦＣＯ）３０２、プログラムテストモニター（ＴＥＭ）３０４、ローディングアドミニストレータ参照情報ハンドラー（ＬＡＲＩ）３０８、およびシステムイベント情報ブロードキャスタ（ＫＥＥＤ）３０６。ＰＸＣＰ３９４は下記のＬＯＣＰ３９２構成要素とも連絡されている、ローディング管理コントローラ（ＬＡＣＯ）３１０、およびローディング管理記号ハンドラー（ＬＡＳＹＭＢ）３１２。ＰＸＣＰ３９４の各構成要素とそれらのＣＰＳ３９０およびＬＯＣＰ３９２の構成要素とのインタラクションについて簡単に説明する。
ＰＸＺＡ３２０はプログラム交換インプリメンテーションを調整する。ＰＸＺＡ３２０はＰＸＺＤ３１８，ＰＸＺＳ３１６，ＫＥＥＤ３０６，およびＬＡＣＯ３１０とそれぞれ双方向論理パス３２４，３２６，３４８，および３２２を介して連絡されている。ＰＸＺＤ３１８は新旧ソフトウェアユニットについて格納されたデータ変数間のコンパチビリティを検証し、プログラム交換中に新しいソフトウェアユニットに必要なＲＳ２０４およびＤＳ２０６エリアの量を最適化する。ＰＸＺＤ３１８はＰＸＺＡ３２０，ＬＡＣＯ３１０，およびＬＡＲＩ３０８とそれぞれ双方向論理パス３２４，３３４，および３３０を介して連絡されている。ＰＸＺＳ３１６は新旧ソフトウェアユニットに対する信号イーターフェイス間のコンパチビリティを検証し、信号イーターフェイス間の任意の差に関する情報を格納する。ＰＸＺＳはＰＸＺＡ３２０およびＬＡＲＩ３０８とそれぞれ通信パス３２６および３３２を介して連絡されている。ＰＸＺＭＤ３１４はアセンブリルーチンを使用してプログラム交換を実行し新ソフトウェアユニットに対する参照テーブルおよびＢＡＴを直接更新する。実質的に同じ機能を実施するＰＸＺＭＤの異なるバージョンがＡＸＥ１０交換機で使用される異なる各ハードウェアプラットフォームに必要である。ＰＸＺＭＤ３１４はＡＦＣＯ３０２，ＴＥＭ３０４，ＬＡＳＹＭＢ３１２，ＬＡＣＯ３１０，およびＰＸＺＡ３２０とそれぞれ双方向通信パス３４２，３４４，３４０，３３８，および３２８を介して連絡されている。
プログラム交換方法の間に各論理パス３２４，３２６，３３０，３３２，３３４，３３８，３４０，３４２，３４４，および３４８を進行する通信信号を付録Ａに示す。
ＬＡＣＯ３１０はプログラム交換のためにソフトウェアユニットがロードされている時をＰＸＣＰ３９４へ知らせ、ＰＸＣＰ３９４とＣＰＳ３９０の格納機能間のイーターフェイスとして作用する。ＬＡＳＹＭＢ３１２は交換される新旧ソフトウェアユニットの信号および変数名記号を管理する。
ＡＦＣＯ３０２はＰＸＣＰ３９４とＣＰＳ３９０の監査機能間のイーターフェイス機能を実施する。ＴＥＭ３０４はプログラムテストシステムの中央機能を含んでいる。ＬＡＲＩ３０８はマシン依存性であり、交換機１０４（第１図）のオペレーティングシステムにより使用される参照情報を読み取り更新する複数のサービスルーチンを含んでいる。
第４図を参照して、本発明の好ましい実施例に従った第１図の交換機１０４内の旧ソフトウェアユニット（機能ブロック）を新ソフトウェアユニットと交換するプログラム交換方法のステップを例示するフロー図を示す。この方法はステップ４０２で開始されてステップ４０４へ進みそこで旧ソフトウェアユニットと交換される新ソフトウェアユニットが交換機１０４（第１図）のメモリ１２２へロードされる。次にステップ４０６へ進みそこで新ソフトウェアユニットが登録され、続いてステップ４０８へ進みそこでソフトウェアユニットが活性化される。新ソフトウェアユニットが活性化された後で、ステップ４１０へ進んで新ソフトウェアユニットが確認される。次にステップ４１２へ進みそこで新ソフトウェアユニットが適切に作動しているかどうか確認される。新ソフトウェアが適切に作動していることが確認されると、ステップ４１８へ進む。新ソフトウェアが適切に作動していないことが確認される場合には、ステップ４１４へ進む。ステップ４１４において、新ソフトウェアユニットは不活性化され、次にステップ４１６へ進みそこで不活性化された新ソフトウェアユニットは交換機１０４から除去され、ステップ４４２へ進んで終りとなる。ステップ４１８において新ソフトウェアユニットが検定され、続いてステップ４２０へ進みそこで旧ソフトウェアユニットが交換機１０４（第１図）のメモリ１２２から除去され、次にステップ４２２へ進んで終りとなる。第４図の前記ステップについて詳細に説明する。
本発明の好ましい実施例ではＤＢＳ１２４（第１図）内のコマンドトランザクションを使用して各々が関連する旧ソフトウェアユニットと置換される複数の新ソフトウェアユニットを指定することができる。
第４図のステップ４０４において、新ソフトウェアユニットが交換機１０４のメモリ１２２（すなわち、ＰＳ２０２，ＲＳ２０２およびＤＳ２０６）内へロードされる。新ソフトウェアユニットがプログラム交換のためにうまくロードされた後で、ＤＢＳ１２４はＬＡＣＯ３１０を介してＰＬＥＸ−ＳＱＬ（ＤＢＳ）ステートメントを使用してＰＸＰＲＯＧＲＡＭデータベーステーブルへ交換情報を挿入する。交換情報には、例えば、新ソフトウェアユニットのブロック名、新旧ソフトウェアユニットのブロック名、新旧ソフトウェアユニットの製品番号、および新旧ソフトウェアユニットのＲ−ＳＴＡＴＥを含むことができる。ＰＸＰＲＯＧＲＡＭテーブルへ交換情報をロードすることによりステップ４０６において新ソフトウェアユニットが登録される。
次に第５図を参照して、本発明の好ましい実施例に従った第４図のステップ４０６における新ソフトウェアユニットの登録の詳細を例示するフロー図を示す。新ソフトウェアユニットの登録はステップ５００において開始されてステップ５０４へ進みそこでＰＸＰＲＯＧＲＡＭテーブルへのテーブルローの挿入が許可されるかどうか確認される。テーブルローはオペレータではなくプログラム交換サブシステム（ＰＸＣＰ）３９４によりＰＸＰＲＯＧＲＡＭへ挿入しなければならない。テーブルローの挿入が許可されることが確認されると、ステップ５０６へ進む。テーブルローの挿入が許可されないことが確認されると、ステップ５１４へ進む。
ステップ５０６において、新ソフトウェアユニットが旧ソフトウェアユニットとコンパチブルであるかどうかが確認される。新ソフトウェアユニット内に下記の事柄が存在する場合新ソフトウェアユニットは旧ソフトウェアユニットとコンパチブルである、ブロックタイプおよびブロックタイプ−Ｅｘｔｅｒｎａｌが旧ソフトウェアユニットのブロックタイプおよびブロックタイプ−Ｅｘｔｅｒｎａｌと同じであり、修正エリア内に修正は存在せず、信号インーターフェイスは旧ソフトウェアユニットの信号インーターフェイスとコンパチブルであり、変数の構造は旧ソフトウェアユニットの変数の構造とコンパチブルである。ＰＸＺＳ３１６は新旧ソフトウェアユニットの信号インーターフェイスがコンパチブルであるかどうかの確認を行う。信号インーターフェイスは同一であればコンパチブルである。ＰＸＺＤ３１８も新旧ソフトウェアユニットの変数の構造がコンパチブルであるかどうかを確認する。ＰＸＺＤ３１８はＤＢＳ１２４（第１図）内のＶＡＲＩＡＢＬＥＤＩＦＦデータベーステーブルに任意のコンパチブル変数差を格納する。新ソフトウェアユニットはコンパチブルであることが確認されると、ステップ５０８へ進む。新ソフトウェアユニットはコンパチブルではないことが確認されると、ステップ５１０へ進む。
ステップ５０８において、現在旧ソフトウェア内に存在する新ソフトウェアユニット内の同一変数が新ソフトウェアユニットから除去される。新ソフトウェアユニットは旧ソフトウェアユニットの変数を受け継ぐため、同一変数を除去してＤＳエリア２０６（第２図）のスペースを節約することができる。新ソフトウェアユニットから同一変数が除去された後で、新ソフトウェアユニットのＢＡＴを圧縮して付加、変更もしくは削除される各変数について１つの位置しか存在しないようにされる。新ソフトウェアユニットのＢＡＴが圧縮された後で、ＶＡＲＩＡＢＬＥＤＩＦＦテーブルを更新して圧縮されたＢＡＴ内の変数と旧ソフトウェアユニットのＢＡＴ内の変数の位置間のマッピングが定義される。次にステップ５１２へ進む。ステップ５１０において、新ソフトウェアユニットが旧ソフトウェアユニットとコンパチブルではないことを示す変数ｒｅｓｕｌｔ＿ｃｏｄｅが設定され、ステップ５１２へ進む。ステップ５１４において、有効なテーブルオペレーションが実施されたかどうかが確認される。有効なテーブルオペレーションが実施されたことが確認されると、ステップ５１２へ進む。有効なテーブルオペレーションが実施されないことが確認されると、ステップ５１６へ進む。
ステップ５１６において、有効ではないテーブルオペレーションが実施されたことを示す故障がＤＢＳ１２４（第１図）へ戻され、ステップ５１８へ進んで終りとなる。ステップ５１２において、ＬＡＣＯ３１０（第３図）内の機能が呼び出され、ステップ５１８へ進んで終りとなる。ＬＡＣＯ３１０の呼び出された機能により新ソフトウェアユニットの登録が終了される。
第６Ａ図−第６Ｂ図は本発明の好ましい実施例に従った第４図のステップ４０８における新ソフトウェアユニットの活性化の詳細を示すフロー図である。新ソフトウェアユニットの活性化はＰＸＺＡ３２０（第３図）により実施される。新ソフトウェアユニットの活性化は新ソフトウェアユニットを実行可能とするジェネリックＤＢＳコマンドにより開始される。プログラム交換プロセス中に交換機１０４のシステム再始動が行われる場合には、“ＡＣＴＩＶＥ”である新ソフトウェアユニットが不活性化される。その後、不活性化された項を使用して実行可能ではあるが許可されないソフトウェアが定義される。
次に第６Ａ図を参照して、ＰＸＰＲＯＧＲＡＭ内に指定された新ソフトウェアユニットの活性化がステップ６００において開始されステップ６０４へ進んでシステム参照情報の更新許可がＬＡＣＯ３１０から与えられているかどうかが確認される。ＬＡＣＯ３１０が許可を与えていることが確認されると、ステップ６１０へ進む。ＬＡＣＯ３１０が許可を与えないことが確認されると、ステップ６０６へ進みそこでＤＢＳ１２４（第１図）へ機能故障コードが報告され、ステップ６５２へ進んで終りとなる。
ステップ６１０において、ＰＸＰＲＯＧＲＡＭテーブルがアクセスされてそこに指定された新旧ソフトウェアユニットが選択され、選択された新旧ソフトウェアユニットについてプログラム交換状態が有効であるかどうかが確認される。新ソフトウェアユニットのプログラム交換状態はそれが“ＡＣＴＩＶＥ”に等しければ有効である。旧ソフトウェアユニットのプログラム交換状態はそれが“ＩＮＡＣＴＩＶＥ”に等しければ有効である。選定された新旧ソフトウェアユニットについてプログラム交換状態（ＰＸＳＴＡＴＥｓ）が有効であることが確認されると、ステップ６１４へ進む。選定された新旧ソフトウェアユニットについて交換状態が有効ではないことが確認されると、ステップ６２４へ進む。ステップ６２４において、ＤＢＳ１２４（第１図）へ故障コードが戻され、ステップ６２６へ進んで選定された新旧ソフトウェアユニットは各々の前の状態へロールバックされ、次にステップ６４２へ進む（第６Ｂ図）。
ステップ６１４において、選定された新旧ソフトウェアユニットの信号インーターフェイスがコンパチブルであるかどうかが確認される。新旧ソフトウェアユニットの信号インーターフェイスはさまざまな理由でコンパチブルにならないことがある。例えば、新ソフトウェアユニットのローディングと不活性化との間に存在することがある期間中に旧ソフトウェアユニット（すなわち、“ＡＣＴＩＶＥ”ユニット）に信号修正を挿入することができる。プログラム交換中に信号リンキング情報は更新されないため、選定された新旧ソフトウェアユニットの信号インーターフェイス間の差は許されない。選定された新旧ソフトウェアユニットの信号インーターフェイスのコンパチビリティの確認はＰＸＺＳ３１６（第３図）において実施される。選定された新旧ソフトウェアユニットの信号インーターフェイスはコンパチブルであることをＰＸＺＳ３１６が確認すると、ステップ６１６へ進む。信号インーターフェイスはコンパチブルではないことをＰＸＺＳ３１６が確認すると、ステップ６２８へ進む。ステップ６２８において、ＤＢＳ１２４（第１図）へ故障コードが戻され、ステップ６３０へ進んで選定された新旧ソフトウェアユニットがそれぞれ前の状態へロールバックされ、次にステップ６４２へ進む（第６Ｂ図）。
ステップ６１において、プログラム交換の準備が行われる。それには選定された新旧ソフトウェアユニットのブロック番号をＰＸＺＡ３２０からＰＸＺＭＤ３１４（第３図）へ送ることが含まれる。次にＰＸＺＭＤ３１４は参照テーブル位置、ベースアドレステーブル位置、および変換エリア情報語に関する情報を集め、それはプログラム交換中に更新される。次にステップ６１８へ進み、そこでプログラム交換準備が成功したかどうかが確認される。プログラム交換準備が成功したことが確認されると、ステップ６２０へ進む。プログラム交換準備が成功しなかったことが確認されると、ステップ６３２へ進む。ステップ６３２において、ＤＢＳ１２４（第１図）へ故障コードが戻され、ステップ６３４へ進んで選定された新旧ソフトウェアユニットがそれぞれ前の状態へロールバックされ、次にステップ６４２へ進む（第６Ｂ図）。
ステップ６２０において、ＰＸＺＡ３２０（第３図）は選定された新ソフトウェアユニットについてプログラム交換状態（ＰＸＳＴＡＴＥ）を“ＡＣＴＩＶＥ”に設定し、ステップ６２２へ進む。ＤＢＳコマンドトランザクションに指定される新ソフトウェアユニットの数が多すぎる場合には指定された新ソフトウェアユニットの活性化は終止される。ステップ６２２において、活性化するように指定されている新ソフトウェアユニットが他にもＰＸＰＲＯＧＲＡＭ内にあるかどうかが確認される。活性化するように指定されている新ソフトウェアユニットが他にもＰＸＰＲＯＧＲＡＭテーブルにあることが確認されると、ステップ６１０へ戻り別の選定された新旧ソフトウェアユニットについて前記したステップが繰り返される。活性化するように指定されている新ソフトウェアユニットが他にはＰＸＰＲＯＧＲＡＭテーブルにないことが確認されると、ステップ６３６へ進む（第６Ｂ図）。
次に第６Ｂ図を参照して、ステップ６３６において、ＰＸＰＲＯＧＲＡＭテーブルに指定された新旧ソフトウェアユニットが交換される。置換する旧ソフトウェアユニットの既存の変数の他にも変数を有する指定された新ソフトウェアユニットのベースアドレステーブルのサイズの増大をＰＸＺＡ３２０（第３図）が命令して交換が開始される。これに対して、ＰＸＺＡ３２０は置換する旧ソフトウェアユニットの既存の変数に較べて変数の数が少ない指定された新ソフトウェアユニットについてはベースアドレステーブルのサイズの減少を命令する。
ＰＸＺＡ３２０はプログラム交換の“低レベル”（コンピュータプラットフォーム依存）インプリメンテーションを実施する信号をＰＸＺＭＤ３１４へ送ってプログラム交換を進める。信号に応答して、ＰＸＺＭＤ３１４はプログラム交換される指定されたソフトウェアユニットについて設定されていることがある任意のトレース処置(trace measures)を除去する。次にＰＸＺＭＤ３１４は高優先順位割り込みをディセーブルしてプログラム交換を進める。高優先順位割り込みがディセーブルされる期間中に、ＰＸＺＭＤ３１４は参照テーブル、ＢＡＴ、からのデータおよび指定された各旧ソフトウェアユニットの変数を置換する各新ソフトウェアユニットへコピーする。次にＰＸＺＭＤ３１４は高優先順位割り込みを再度イネーブルし、指定された新旧ソフトウェアユニットについてプログラム格納チェックサムを切り替えるようＡＦＣＯ３０２（第３図）へ命令する。ＰＸＺＭＤ３１４はまた指定された新旧ソフトウェアユニットについて変数記号情報を切り替えるようＬＡＳＹＭＢ３１２へ命令する。
ステップ６３８において、変数ｒｅｓｕｌｔ＿ｃｏｄｅを調べてプログラム交換が成功したかどうかが確認される。プログラム交換が成功したことを変数ｒｅｓｕｌｔ＿ｃｏｄｅが示していることが確認されると、ステップ６４０へ進む。プログラム交換が成功しなかったことを変数ｒｅｓｕｌｔ＿ｃｏｄｅが示していることが確認されると、ステップ６４４へ進む。ステップ６４４において、ＰＸＰＲＯＧＲＡＭテーブルがアクセスされそこに活性化するように指定されている新ソフトウェアユニットが選定される。選定された新ユニットのプログラム交換状態（ＰＸＳＴＡＴＥｓ）が“ＩＮＡＣＴＩＶＥ”に等しく設定され、ステップ６４６へ進む。ステップ６４６において、活性化するように指定されている新ソフトウェアユニットが他にもＰＸＰＲＯＧＲＡＭテーブルに存在するかどうかが確認される。活性化するように指定されている新ソフトウェアユニットが他にもＰＸＰＲＯＧＲＡＭテーブルに存在することが確認されると、ステップ６４４へ進み選定された別の新ソフトウェアユニットについて前記したステップが繰り返される。活性化するように指定されている新ソフトウェアユニットが他にはＰＸＰＲＯＧＲＡＭテーブルに存在しないことが確認されると、ステップ６４８へ進む。ステップ６４８において、ＤＢＳ１２４（第１図）へ機能故障コードが戻され、ステップ６４２へ進む。
ステップ６４０において、トランザクションは成功であったことを示す報告がＤＢＳ１２４（第１図）へ戻されてステップ６４２へ進みそこでシステム参照情報を更新する許可が断念され、ステップ６５２へ進んで終りとなる。
次に第７図を参照して、本発明の好ましい実施例に従った第４図のステップ４１０における新ソフトウェアユニットの確認の詳細を例示するフロー図を示す。新ソフトウェアユニットの確認はステップ７００において開始されてステップ７０４へ進みそこでシステム参照情報へのアクセスが許可されるかどうかが確認される。システム参照テーブルへ再度アクセスするために、ＰＸＺＡ３２０（第３図）は許可を求める信号をＬＡＣＯ３１０（第３図）へ送る。ＬＡＣＯ３１０から許可が下りるとステップ７０８へ進む。ＬＡＣＯ３１０から許可が下りなければ、ステップ７０６へ進みそこでＤＢＳ１２４（第１図）へ故障コードが報告され、ステップ７３０へ進んで終りとなる。
ステップ７０８において、ＰＸＰＲＯＧＲＡＭテーブルがアクセスされ確認するように指定されている新ソフトウェアユニットが選定され、選定された新ソフトウェアユニットのプログラム交換状態（ＰＸＳＴＡＴＥ）は有効であるかどうか確認される。選定された新ソフトウェアユニットのＰＸＳＴＡＴＥは“ＡＣＴＩＶＥ”に等しければ有効である。選定された新ソフトウェアユニットのＰＸＳＴＡＴＥは有効ではないことが確認されたら、ステップ７１０へ進む。選定された新ソフトウェアユニットのＰＸＳＴＡＴＥは有効であることが確認されたら、ステップ７１４へ進む。ステップ７１０において、ＤＢＳ１２４（第１図）へ機能故障コードが戻され、ステップ７１２へ進んで選定された新ソフトウェアユニットはその前の状態へロールバックされる。次にステップ７２８へ進む。
ステップ７１４において、ＤＢＳコマンドトランザクション内で確認するように指定されている新ソフトウェアユニットの数が多すぎないかどうか確認される。確認するように指定されている新ソフトウェアユニットの数は多すぎることが確認されると、ステップ７１６へ進む。プログラム交換するように指定されている新ソフトウェアユニットの数が容認できるものであれば、ステップ７２２へ進む。ステップ７１６において、ＤＢＳ１２４（第１図）へ機能故障コードが戻され、ステップ７１８へ進んで選定された新ソフトウェアユニットがその前の状態へロールバックされ、次にステップ７２８へ進む。
ステップ７２２において、選定された新ソフトウェアユニットのプログラム交換状態が“ＣＯＮＦＩＲＭ”に等しく設定され、ステップ７２４へ進んで確認するように指定されている新ソフトウェアユニットが他にもＰＸＰＲＯＧＲＡＭテーブルに存在するかどうか確認される。新ソフトウェアユニットが他にもＰＸＰＲＯＧＲＡＭテーブルに存在することが確認されると、ステップ７０８へ戻って別の新ソフトウェアユニットについて前記したステップが繰り返される。確認するように指定されている新ソフトウェアユニットが他にＰＸＰＲＯＧＲＡＭテーブルにはないことが確認されると、ステップ７２６へ進みそこでトランザクションは成功であったという報告がＤＢＳ１２４（第１図）へ戻され、ステップ７２８へ進んでシステム参照情報の更新許可は断念され、ステップ７３０へ進んで終りとなる。
次に第８Ａ図−第８Ｂ図を参照して、本発明の好ましい実施例に従った第４図のステップ４１８における新ソフトウェアユニットの検定の詳細を例示するフロー図を示す。検定プロセスは１つ以上の確認された新ソフトウェアユニットを検定して、ソフトウェアユニットの関連する旧バージョンをシステムから除去する。指定された新ソフトウェアユニットが検定されていると、検定された新ソフトウェアユニットや置換される旧ソフトウェアユニットがロールバックされる可能性はない。しかしながら、置換された旧ソフトウェアユニットは交換機１０４（第１図）から除去して確認された新ソフトウェアユニットとプログラム交換するために再ロードすることができる。また交換機に早期システムバックアップを再ロードすることができる。
検定方法はステップ８００において開始されてステップ８０４へ進みそこでシステム参照情報へのアクセスが許可されるかどうか確認される。ＰＸＺＡ３２０（第３図）はシステム参照情報の更新許可を要求する信号をＬＡＣＯ３１０（第３図）へ送る。ＬＡＣＯ３１０が許可しなければ、ステップ８０６へ進む。ＬＡＣＯ３１０が許可を下せば、ステップ８１０へ進む。
ステップ８０６において、ＤＢＳ１２４（第１図）へ故障コードが戻され、ステップ８４２へ進んで終りとなる。ステップ８１０において、ＰＸＰＲＯＧＲＡＭテーブルがアクセスされ検定するように指定されている新ソフトウェアユニットが選定され、選定された新ソフトウェアユニットのプログラム交換状態（ＰＸＳＴＡＴＥ）は有効であるかどうか確認される。選定された新ソフトウェアユニットのＰＸＳＴＡＴＥは“ＣＥＲＴＩＦＹ”に等しければ有効である。選定された新ソフトウェアユニットのＰＸＳＴＡＴＥは有効であることが確認されたら、ステップ８１６へ進む。新ソフトウェアユニットのＰＸＳＴＡＴＥは有効ではないことが確認されたら、ステップ８１２へ進む。ステップ８１２において、ＤＢＳ１２４（第１図）へ機能故障コードが報告され、ステップ８１４へ進んで選定された新ソフトウェアユニットはその前の状態へロールバックされ、次にステップ８３８（第８Ｂ図）へ進む。
ＤＢＳコマンドトランザクションにおいて検定するように指定されている新ソフトウェアユニットの数が多すぎないかどうかがステップ８１６において確認される。検定するように指定されている新ソフトウェアユニットの数は多すぎることが確認されると、ステップ８１８へ進む。検定するように指定されている新ソフトウェアユニットの数は容認できることが確認されると、ステップ８２２へ進む。
ステップ８１８において、ＤＢＳ１２４（第１図）へ故障コードが戻され、ステップ８２０へ進んで選定された新ソフトウェアユニットがその前の状態へロールバックされ、次にステップ８３８（第８Ｂ図）へ進む。ステップ８２２において、ＰＸＺＡ３２０（第３図）は選定された新ソフトウェアユニットのプログラム交換状態（ＰＸＳＴＡＴＥ）を“ＣＥＲＴＩＦＹ”に等しく設定し、ステップ８２４へ進む。ステップ８２４において、検定するように指定されている新ソフトウェアユニットが他にもＰＸＰＲＯＧＲＡＭテーブルに存在するかどうか確認される。検定するように指定されている新ソフトウェアユニットが他にもＰＸＰＲＯＧＲＡＭテーブルに存在することが確認されると、ステップ８１０へ戻って別の新ソフトウェアユニットについて前記したステップが繰り返される。検定するように指定されている新ソフトウェアユニットが他にはＰＸＰＲＯＧＲＡＭテーブルに存在しないことが確認されると、ステップ８２６（第８Ｂ図）へ進む。
次に第８Ｂ図を参照して、ステップ８２６において、ＰＸＺＡ３２０は除去されるように指定されている旧ソフトウェアユニットのブロック名をＬＡＣＯ３１０（第３図）へ送る。次にＰＸＺＡ３２０は各プログラム交換ブロック番号に配置されている指定された旧ソフトウェアユニットを除去するようＬＡＣＯ３１０へ命令する。またＰＸＺＡ３２０はＬＡＣＯ３１０により連続的に除去されるように指定されている各旧ソフトウェアユニットについてＰＸＰＲＯＧＲＡＭテーブルからプログラム交換情報を除去する。
ステップ８２８において、指定されている全ての旧ソフトウェアユニットがうまく除去されたかどうか確認される。指定されている全ての旧ソフトウェアユニットがうまく除去されたことが確認されると、ステップ８３６へ進む。指定されているいずれかの旧ソフトウェアユニットがうまく除去されていないことが確認されると、ステップ８３０へ進む。ステップ８３０において、検定するように指定されている新ソフトウェアユニットがＰＸＰＲＯＧＲＡＭテーブルから選定され、選定された新ソフトウェアユニットのプログラム交換状態が“ＣＯＮＦＩＲＭ”に等しく設定される。次にステップ８３２へ進みそこで検定するように指定されている新ソフトウェアユニットが他にもＰＸＰＲＯＧＲＡＭテーブルに存在するかどうか確認される。検定するように指定されている新ソフトウェアユニットが他にもＰＸＰＲＯＧＲＡＭテーブルに存在することが確認されると、ステップ８３０へ戻って別の新ソフトウェアユニットについて前記したステップが繰り返される。検定するように指定されている新ソフトウェアユニットが他にはＰＸＰＲＯＧＲＡＭテーブルに存在しないことが確認されると、ステップ８３４へ進みそこでＤＢＳ１２４（第１図）へ故障コードが報告され、次にステップ８３８へ進む。
ステップ８３６において、ＤＢＳ１２４（第１図）へ検定は成功であったという表示が戻され、ステップ８４０へ進んでシステム参照情報の更新許可が断念され、ステップ８４２へ進んで終りとされる。
次に第９Ａ図−第９Ｂ図を参照して、本発明の好ましい実施例に従った第４図のステップ４１４における新ソフトウェアユニットの不活性化の詳細を例示するフロー図を示す。不活性化方法はステップ９００で開始されてステップ９０２へ進みそこでＰＸＺＡ３２０はシステム参照情報の更新許可を要求する信号をＬＡＣＯ３１０へ送る。ＬＡＣＯ３１０が許可を下せば、ステップ９０６へ進む。ＬＡＣＯ３１０が許可しなければ、ステップ９０４へ進んでＤＢＳ１２４（第１図）へ故障コードが戻され、ステップ９４２へ戻って終りとなる。
ステップ９０６において、ＰＸＰＲＯＧＲＡＭがアクセスされ不活性化するように指定されている新ソフトウェアユニットおよびその関連する旧ソフトウェアユニットが選定され、選定された新旧ソフトウェアユニットについてプログラム交換状態は有効であるかどうか確認される。選定された新ソフトウェアユニットのプログラム交換状態は“ＩＮＡＣＴＩＶＥ”に等しければ有効である。選定された旧ソフトウェアユニットのプログラム交換状態は“ＡＣＴＩＶＥ”もしくは“ＣＯＮＦＩＲＭ”に等しければ有効である。選定された新旧ソフトウェアユニットが有効なプログラム交換状態であれば、ステップ９１２へ進む。選定された新もしくは旧ソフトウェアユニットのいずれかのプログラム交換状態が有効でなければ、ステップ９０８へ進んでＤＢＳ１２４（第１図）へ故障コードが戻され、次にステップ９１０へ進む。ステップ９１０において、選定された新旧ソフトウェアユニットはそれぞれ前の状態へロールバックされ、ステップ９４２（第９Ｂ図）へ進む。
ステップ９１２において、選定された新旧ソフトウェアユニットの信号インターフェイスはコンパチブルであるかどうか確認される。プログラム交換中にＰＸＣＰ３１８は信号リンキング情報を更新しないため信号インターフェイスの差は許されない。ＰＸＺＡ３２０はコンパチビリティ検証を実施するようＰＸＺＳ３１６へ命令する。信号インターフェイスはコンパチブルであることが確認されると、ステップ９１８へ進む。信号インターフェイスはコンパチブルではないことが確認されると、ステップ９２２へ進みそこでＤＢＳ１２４（第１図）へ故障コードが報告され、次にステップ９２４へ進む。ステップ９２４において、選定された新旧ソフトウェアユニットはそれぞれ前の状態へロールバックされ、次にステップ９４２（第９Ｂ図）へ進む。
ステップ９１８において、プログラム交換の準備がなされる。選定された旧ソフトウェアユニットが置換する新ソフトウェアユニットの既存の変数の他にも変数を有する場合には、ＰＸＺＡ３２０（第３図）が選定された旧ソフトウェアユニットのベースアドレステーブルの増大を命令して準備が開始される。これに対して、選定された旧ソフトウェアユニットの有する変数が置換する新ソフトウェアユニットの既存の変数よりも少ない場合には、ＰＸＺＡ３２０は選定された旧ソフトウェアユニットのベースアドレステーブルの減少を命令する。プログラム交換の準備がなされた後で、ステップ９２０へ進みそこで準備は成功であったかどうか確認される。準備は成功であったことが確認されると、ステップ９２６（第９Ｂ）へ進む。準備は成功ではなかったことが確認されると、ステップ９２２へ進みそこでＤＢＳ１２４（第１図）へ故障コードが戻され、次にステップ９２４へ進む。ステップ９２４において、選定された新旧ソフトウェアユニットはそれぞれ前の状態へロールバックされ、次にステップ９４２（第９Ｂ図）へ進む。
次に第９Ｂ図を参照して、ステップ９２６において、選定された新ソフトウェアユニットのプログラム交換状態（ＰＸＳＴＡＴＥ）が“ＩＮＡＣＴＩＶＥ”へ変えられ、ステップ９２８へ進む。ステップ９２８において、不活性化するように指定されている新旧ソフトウェアユニット対が他にもＰＸＰＲＯＧＲＡＭテーブルに存在するかどうか確認される。指定されている新旧ソフトウェアユニット対がＰＸＰＲＯＧＲＡＭテーブルに存在することが確認されると、ステップ９０６へ戻って、別の新旧ソフトウェアユニット対について前記したステップが繰り返される。指定されている新旧ソフトウェアユニット対がＰＸＰＲＯＧＲＡＭテーブルにはないことが確認されると、ステップ９３０へ進む。ステップ９３０において、不活性化するように指定されている新旧ソフトウェアユニット対の交換が実施される。指定されている新旧ソフトウェアユニットに対して設定されていることがある任意のトレース測度をＴＥＭ３０４が除去するようＰＸＺＭＤ３１４へ命令することにより交換が実行される。またＰＸＺＭＤ３１４はトラフィックハンドリングレベル（ＴＨＬ）等の高優先順位割り込みをディセーブルする。高優先順位割り込みがディセーブルされる期間中に、ＰＸＺＭＤ３１４（第３図）は指定されている新ソフトウェアユニットの各参照テーブル、ＢＡＴ、からのデータおよび変数を新ソフトウェアユニットと置換する関連する旧ソフトウェアユニットへコピーする。次にＰＸＺＭＤ３１４は高優先順位割り込みを再度イネーブルして、指定されている新旧ソフトウェアユニットについてＡＦＣＯ３０２にＰＳチェックサムを切り替えるよう命令し、ＬＡＳＹＭＢ３１２に変数記号情報を切り替えるよう命令する。また変数ｒｅｓｕｌｔ＿ｃｏｄｅはプログラム交換が成功であったかどうかを示す値に等しく設定される。次にステップ９３２へ進み、そこで変数ｒｅｓｕｌｔ＿ｃｏｄｅを分析してプログラム交換は成功であったかどうか確認される。変数ｒｅｓｕｌｔ＿ｃｏｄｅはプログラム交換が成功であったことを示すことが確認されると、ステップ９３８へ進む。変数ｒｅｓｕｌｔ＿ｃｏｄｅはプログラム交換が不成功であったことを示すことが確認されると、ステップ９３４へ進む。
ステップ９３４において、ＰＸＰＲＯＧＲＡＭテーブルがアクセスされ不活性化するように指定されている新旧ソフトウェアユニットが選定される。さらに、選定された新ソフトウェアユニットのプログラム交換状態が“ＡＣＴＩＶＥ”に等しく設定され、ステップ９３６へ進む。ステップ９３６において、不活性化するように指定されている新旧ソフトウェアユニット対が他にもＰＸＰＲＯＧＲＡＭテーブルにあるかどうか確認される。指定された新旧ソフトウェアユニット対が他にもＰＸＰＲＯＧＲＡＭテーブルにあることが確認されると、ステップ９３４へ戻って別の新ソフトウェアユニットについて前記したステップが繰り返される。指定された新旧ソフトウェアユニット対が他にはＰＸＰＲＯＧＲＡＭテーブルにないことが確認されると、ステップ９４０へ進む。ステップ９４０において、ＤＢＳ１２４（第１図）へ故障コードが戻され、次にステップ９４２へ進む。ステップ９３８において、プログラム交換が成功であったという表示がＤＢＳ１２４（第１図）へ戻され、ステップ９４２へ進む。ステップ９４２において、システム参照情報テーブルの更新許可が断念され、ステップ９４４へ進んで終りとなる。
次に第１０Ａ図−第１０Ｂ図を参照して、本発明の好ましい実施例に従った第４図のステップ４１６における新ソフトウェアユニットの除去の詳細を例示するフロー図を示す。新ソフトウェアユニットの除去方法はステップ１０００で開始されてステップ１００２へ進む。ステップ１００２において、ＰＸＺＡ３２０はシステム参照情報の更新許可を要求する信号をＬＡＣＯ３１０（第３図）へ送る。ＬＡＣＯ３１０が許可を下せば、ステップ１００６へ進む。ＬＡＣＯ３１０が許可しなければ、ステップ１００４へ進みそこでＤＢＳ１２４（第１図）へ故障コードが戻され、ステップ１０３２へ進む。
ステップ１００６において、ＰＸＰＲＯＧＲＡＭテーブルがアクセスされて除去するように指定されている新ソフトウェアユニットが選定され、選定された新ソフトウェアユニットのプログラム交換状態（ＰＸＳＴＡＴＥ）が“ＩＮＡＣＴＩＶＥ”に等しいかどうか確認される。選定された新ソフトウェアユニットのＰＸＳＴＡＴＥが“ＩＮＡＣＴＩＶＥ”に等しいことが確認されると、ステップ１０１２へ進む。選定された新ソフトウェアユニットのプログラム交換状態が“ＩＮＡＣＴＩＶＥ”に等しくないことが確認されると、ステップ１００８へ進みそこでＤＢＳ１２４（第１図）へ故障コードが戻される。次にステップ１０１２へ進んで選定された新ソフトウェアユニットはその前の状態へロールバックされ、ステップ１０３０（第１０Ｂ図）へ進む。
ステップ１０１２において、ＤＢＳコマンドトランザクション内で除去するように指定されている新ソフトウェアユニットの数が多すぎないかどうか確認される。除去するように指定されている新ソフトウェアユニットの数が多すぎると確認されると、ステップ１０１４へ進む。除去するように指定されている新ソフトウェアユニットの数が容認できると確認されると、ステップ１０１８へ進む。ステップ１０１４において、ＤＢＳ１２４（第１図）へ故障コードが戻されて、ステップ１０１６へ進みそこで選定された新ソフトウェアユニットはその前の状態へロールバックされ、次にステップ１０３０（第１０Ｂ図）へ進む。ステップ１０１８において、選定された新ソフトウェアユニットのブロック番号がＰＸＰＲＯＧＲＡＭテーブルの関連するローから記録され、ステップ１０２０へ進む。ステップ１０２０において、除去するように指定されている新ソフトウェアユニットが他にもＰＸＰＲＯＧＲＡＭテーブルに存在するかどうか確認される。除去するように指定されている新ソフトウェアユニットが他にもＰＸＰＲＯＧＲＡＭテーブルに存在することが確認されると、ステップ１００６へ進み、別の新ソフトウェアユニットについて前記したステップが繰り返される。除去するように指定されている新ソフトウェアユニットが他にＰＸＰＲＯＧＲＡＭテーブルには存在しないことが確認されると、ステップ１０２２（第１０Ｂ図）へ進む。
次に第１０Ｂ図を参照して、ステップ１０２２において、インアクティブなソフトウェアユニット（すなわち、インアクティブな新ソフトウェアユニット）の除去が実施される。除去はインアクティブなソフトウェアユニットのブロック名をＬＡＣＯ３１０へ送るＰＸＺＡ３２０（第３図）により実行される。またＰＸＺＡ３２０は各プログラム交換番号でロードされるインアクティブソフトウェアユニットを除去するようにＬＡＣＯ３１０へ命令する。次にＰＸＺＡ３２０はＬＡＣＯ３１０によりうまく除去された各インアクティブソフトウェアユニットのＰＸＰＲＯＧＲＡＭテーブルからプログラム交換情報を除去し、ステップ１０２４へ進む。
ステップ１０２４において、指定されている全ての除去がうまく実施されたかどうか確認される。指定されている除去がうまく実施されたことが確認されると、ステップ１０２８へ進む。指定されている除去のいずれかがうまく実施されていないことが確認されると、ステップ１０２６へ進む。ステップ１０２６において、ＤＢＳ１２４（第１図）へ故障コードが報告されて、ステップ１０３０へ進む。ステップ１０２８において、指定されているインアクティブソフトウェアユニットの除去は不成功であったという表示がＤＢＳ１２４へ報告され、ステップ１０３０へ進む。ステップ１０３０において、システム参照情報の更新許可が断念され、ステップ１０３２へ進んで終りとなる。
インアクティブソフトウェアユニットを除去するための前記したステップは、前記したように各ソフトウェアユニットのルールを逆にする点を除けば、第４図のステップ４２０において旧ソフトウェアユニットを除去するステップと実質的に同じである。
ＰＸＺＭＤ３１４はまた交換機内の再始動作用により中断されるプログラム交換を回復することもできる。ＰＸＺＭＤ３１４はＬＡＣＯ３１０からシステム参照情報の更新許可を得て回復を実行し、必要に応じて、再始動時に更新された参照情報を回復する。次にＰＸＺＭＤ３１４は中断されたプログラム交換内の全ての未処理ソフトウェアユニットに対して参照情報を交換する。またＰＸＺＭＤ３１４は選定された新旧ソフトウェアユニットに対してＰＳ２０２エリア（第２図）ＣＨＥＣＫＳＵＭおよび変数記号情報を交換する。
プログラム交換方法により導入される新ソフトウェアユニットの変更もしくは修正の程度は制約される。この制約により交換機１０４内で進行中のトラフィックを妨害することなく新ソフトウェアユニットを旧ソフトウェアユニットと交換することができ、システムを再始動させる必要が無くなる。
新ソフトウェアユニットの制約には下記の事柄が含まれる。ブロック特性は旧ソフトウェアユニットと同じでなければならない、信号インターフェイスは旧ソフトウェアユニットの信号インターフェイスと同じでなければならない、ＳＴＡＴＩＣマークの無い任意の変数を含む既存のサイズ変更不能データファイルのレコード構造には変化が無い、およびＳＴＡＴＩＣマークの無い任意の変数を含むサイズ変更不能データファイルの初期サイズには変化が無い。またＳＴＡＴＩＣマークの無い変数の下記のいずれの属性にも変化が無いことも制約に含まれる、変数長、索引付き変数の数、ポインタインジケータ、サブレコード数、データファイル番号、およびバッファー特性。
次に第１１図を参照して、本発明のプログラム交換方法に従って旧ソフトウェアユニットと交換される時の新ソフトウェアユニットのさまざまなプログラム交換状態を例示するブロック図を示す。新ソフトウェアユニットは交換機へロードされる時に１１０２に示すような“ＩＮＡＣＴＩＶＥ”のプログラム交換状態である。新ソフトウェアユニットの実行中に、そのプログラム交換状態はオペレータにより１１０４に示すように“ＡＣＴＩＶＥ”へ変えられる。新ソフトウェアユニットは適切に作動していることが検証されると、１１０６に示すようにそのプログラム交換状態がオペレータにより“ＣＯＮＦＩＲＭＥＤ”へ変えられる。最後に、新ソフトウェアユニットの交換が完了すると、１１０８に示すように新ソフトウェアユニットのプログラム交換状態はオペレータにより“ＣＥＲＴＩＦＩＥＤ”へ変えられる。
詳細例
次に第１２図を参照して、本発明のプログラム交換方法に従って新旧ソフトウェアユニットが進行するさまざまな段階を例示するブロック図を示す。この例では、旧ソフトウェアユニットはＣ７ＴＳＴとアドレスされ、以後Ｃ７ＴＳＴＲ１Ａと呼ぶ、Ｒ１ＡのＲ−ＳＴＡＴＥを有し新ソフトウェアユニットはＣ７ＴＳＴとアドレスされ、以後Ｃ７ＴＳＴＲ１Ｂと呼ぶ、Ｒ１ＢのＲ−ＳＴＡＴＥを有している。新旧ソフトウェアユニットに対する第１２図に示す各遷移はＤＢＳ１２４（第１図）を使用してオペレータにより実施される。
この例では、旧ソフトウェアユニットＣ７ＴＳＴＲ１Ａが最初に交換機内で実行されており、１２０２のステージ１に示すように“ＡＣＴＩＶＥ”の状態を有している。１２０４のステージ２において、新ソフトウェアユニットＣ７ＴＳＴＲ１Ｂがロードされ“ＩＮＡＣＴＩＶＥ”のプログラム交換状態を有している。この期間中に、旧ソフトウェアユニットＣ７ＴＳＴＲ１Ａはまだ実行されており、したがって、“ＡＣＴＩＶＥ”の状態にとどまる。プログラム交換のこの段階において、オペレータは新ソフトウェアユニットを交換機から除去して、プログラム交換を終止することができる。１２０６のステージ３において、オペレータにより新ソフトウェアユニットが活性化されてそのプログラム交換状態は“ＡＣＴＩＶＥ”へ変わり旧ソフトウェアユニットのプログラム交換状態は“ＩＮＡＣＴＩＶＥ”へ変わる。１２０６のステージ３における新旧ソフトウェアユニットの前記したプログラム交換状態はオペレータが新ソフトウェアユニットの不活性化を選択するか、もしくはプログラム交換中にシステム再始動が生じる場合には逆となる。
１２０８のステージ４において、オペレータはＤＢＳコマンドを使用して新ソフトウェアユニットのプログラム交換状態を“ＣＯＮＦＩＲＭ”へ変える。プログラム交換のこの段階において、オペレータは新ソフトウェアユニットを不活性化しかつ旧ソフトウェアユニットを活性化することができ、１２０４のステージ２へ戻る。１２１０のステージ５において、旧ソフトウェアユニットＣ７ＴＳＴＲ１Ａが交換機から除去される。
前記説明から本発明の動作および構造は明らかであるものと信じる。図示して説明してきた方法は好ましい方法ではあるが、請求の範囲に明記された本発明の精神および範囲を逸脱することなくさまざまな変更や修正を行えることが容易にお判りと思われる。
付録Ａ
0003667340.tif 000002
0003667340.tif 000003
0003667340.tif 000004
0003667340.tif 000005
【図１】
0003667340.tif 000006
【図２】
0003667340.tif 000007
【図３】
0003667340.tif 000008
【図４】
0003667340.tif 000009
【図５】
0003667340.tif 000010
【図６Ａ】
0003667340.tif 000011
【図６Ｂ】
0003667340.tif 000012
【図７】
0003667340.tif 000013
【図８Ａ】
0003667340.tif 000014
【図８Ｂ】
0003667340.tif 000015
【図９Ａ】
0003667340.tif 000016
【図９Ｂ】
0003667340.tif 000017
【図１０Ａ】
0003667340.tif 000018
【図１０Ｂ】
0003667340.tif 000019
【図１１】
0003667340.tif 000020
【図１２】
0003667340.tif 000021