JPH1049402A - プログラムパッチ方法およびシステム - Google Patents
プログラムパッチ方法およびシステムInfo
- Publication number
- JPH1049402A JPH1049402A JP8199331A JP19933196A JPH1049402A JP H1049402 A JPH1049402 A JP H1049402A JP 8199331 A JP8199331 A JP 8199331A JP 19933196 A JP19933196 A JP 19933196A JP H1049402 A JPH1049402 A JP H1049402A
- Authority
- JP
- Japan
- Prior art keywords
- patch
- area
- program
- size
- resident
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Landscapes
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Abstract
(57)【要約】
【課題】 パッチ領域のうち、実際に使用している領域
のみをプログラムと共に主記憶に常駐することにより、
パッチ処理の操作性を向上し、かつパッチ処理の時間を
短縮する。 【解決手段】 プログラムメイン部１に修正を実施する
場合に必要となる領域としてあらかじめ設けられている
パッチ領域３と、パッチ領域内３に設けられ、プログラ
ムメイン部１がパッチ領域を実際に必要としたサイズが
格納されるパッチサイズ格納域４と、プログラムメイン
部１より呼ばれ、プログラムメイン部１が動作する上で
最初に必要な各種初期化処理を行い、かつ、パッチ領域
３のうちパッチサイズ格納域４で指定されたサイズ分の
領域と、プログラムメイン部１とを主記憶に常駐するプ
ログラム初期化部２とを備える。
のみをプログラムと共に主記憶に常駐することにより、
パッチ処理の操作性を向上し、かつパッチ処理の時間を
短縮する。 【解決手段】 プログラムメイン部１に修正を実施する
場合に必要となる領域としてあらかじめ設けられている
パッチ領域３と、パッチ領域内３に設けられ、プログラ
ムメイン部１がパッチ領域を実際に必要としたサイズが
格納されるパッチサイズ格納域４と、プログラムメイン
部１より呼ばれ、プログラムメイン部１が動作する上で
最初に必要な各種初期化処理を行い、かつ、パッチ領域
３のうちパッチサイズ格納域４で指定されたサイズ分の
領域と、プログラムメイン部１とを主記憶に常駐するプ
ログラム初期化部２とを備える。
Description
【０００１】
【発明の属する技術分野】本発明は、プログラムパッチ
方法およびシステムに関し、特に主記憶を効率よく使用
するプログラムパッチ方法およびシステムに関するもの
である。
方法およびシステムに関し、特に主記憶を効率よく使用
するプログラムパッチ方法およびシステムに関するもの
である。
【０００２】
【従来の技術】従来のプログラムパッチ方法として、た
とえば、「特開平２−３５３３３号公報」および「特開
平２−２２４１２２号公報」に記載されている方法があ
る。
とえば、「特開平２−３５３３３号公報」および「特開
平２−２２４１２２号公報」に記載されている方法があ
る。
【０００３】次に、図６（ａ）を参照して、「特開平２
−３５３３３号公報」の境界情報定義方法について説明
する。この方法は、プログラムメイン部などが主記憶に
置かれる常駐モジュール７と、常駐モジュール７が緊急
修正などで必要とするためにあらかじめ設けられてい
る、ＺＡＰ領域の使用部８およびＺＡＰ領域の未使用部
９と、使用部８と未使用部９とを識別するための境界情
報記憶部１０と、プログラムメイン部が動作するうえで
必要な各種初期化処理を行い、その後、常駐モジュール
７とＺＡＰ領域の使用部８を常駐して終了する、システ
ム初期化用非常駐モジュール１１とを使用する。
−３５３３３号公報」の境界情報定義方法について説明
する。この方法は、プログラムメイン部などが主記憶に
置かれる常駐モジュール７と、常駐モジュール７が緊急
修正などで必要とするためにあらかじめ設けられてい
る、ＺＡＰ領域の使用部８およびＺＡＰ領域の未使用部
９と、使用部８と未使用部９とを識別するための境界情
報記憶部１０と、プログラムメイン部が動作するうえで
必要な各種初期化処理を行い、その後、常駐モジュール
７とＺＡＰ領域の使用部８を常駐して終了する、システ
ム初期化用非常駐モジュール１１とを使用する。
【０００４】境界情報記憶部１０では、通常使用される
ことのないコード列や、境界位置を示すポインタ情報な
どを格納している。通常、プログラムモジュールの緊急
修正などのために、固定的にあらかじめパッチ領域を確
保し、修正が発生した際、用意されたパッチ領域のうち
必要なだけを使用する。そのため、あらかじめ確保して
おいたパッチ領域が、必要とされるよりも大きくとられ
ている場合、必要としないパッチ領域の部分も主記憶に
残るために無駄が増える。しかし、確保するパッチ領域
が小さすぎると、必要なパッチができなくなる欠点があ
る。そのために、このようにパッチを使用している範囲
を識別可能にする方法がとられている。
ことのないコード列や、境界位置を示すポインタ情報な
どを格納している。通常、プログラムモジュールの緊急
修正などのために、固定的にあらかじめパッチ領域を確
保し、修正が発生した際、用意されたパッチ領域のうち
必要なだけを使用する。そのため、あらかじめ確保して
おいたパッチ領域が、必要とされるよりも大きくとられ
ている場合、必要としないパッチ領域の部分も主記憶に
残るために無駄が増える。しかし、確保するパッチ領域
が小さすぎると、必要なパッチができなくなる欠点があ
る。そのために、このようにパッチを使用している範囲
を識別可能にする方法がとられている。
【０００５】次に、図６（ｂ）を参照して、「特開平２
−２２４１２２号公報」のダイナミックリンク方法につ
いて説明する。この方法は、パッチデータを格納するパ
ッチデータファイル１５と、パッチデータがどこにマッ
ピングされるのかを示すマッピングテーブル１６と、パ
ッチデータファイルとマッピングテーブルにパッチデー
タ情報を登録する機能をもつパッチデータ登録機能１２
と、パッチデータファイルをパッチデータエリア１７お
よびマッピングテーブルにロードするパッチデータロー
ド機能１４と、ＯＳ・プログラム１８と、パッチデータ
エリアのアドレスを解決するためのアドレス解決機能１
３を使用する。ＯＳ・プログラム１８は、マッピングテ
ーブル１６をもとに、パッチデータをダイナミックにロ
ードしてパッチデータエリア１７に格納している。
−２２４１２２号公報」のダイナミックリンク方法につ
いて説明する。この方法は、パッチデータを格納するパ
ッチデータファイル１５と、パッチデータがどこにマッ
ピングされるのかを示すマッピングテーブル１６と、パ
ッチデータファイルとマッピングテーブルにパッチデー
タ情報を登録する機能をもつパッチデータ登録機能１２
と、パッチデータファイルをパッチデータエリア１７お
よびマッピングテーブルにロードするパッチデータロー
ド機能１４と、ＯＳ・プログラム１８と、パッチデータ
エリアのアドレスを解決するためのアドレス解決機能１
３を使用する。ＯＳ・プログラム１８は、マッピングテ
ーブル１６をもとに、パッチデータをダイナミックにロ
ードしてパッチデータエリア１７に格納している。
【０００６】
【発明が解決しようとする課題】上述した従来の技術の
第１の問題点は、パッチデータに関する管理が複雑であ
ることである。その理由は、従来の技術における境界情
報定義方法の場合、境界情報を検索するための検索処理
が必要であるからである。また、従来の技術におけるダ
イナミックリンク方法の場合、必要なパッチデータのみ
を主記憶に残すための管理、および管理をするための処
理が必要であるからである。
第１の問題点は、パッチデータに関する管理が複雑であ
ることである。その理由は、従来の技術における境界情
報定義方法の場合、境界情報を検索するための検索処理
が必要であるからである。また、従来の技術におけるダ
イナミックリンク方法の場合、必要なパッチデータのみ
を主記憶に残すための管理、および管理をするための処
理が必要であるからである。
【０００７】第２の問題点は、従来の技術において境界
情報定義方法、およびダイナミックリンク方法は、必要
なパッチデータのみを主記憶に残すための処理時間が多
くかかることである。その理由は、境界情報定義方法の
場合、境界情報はパッチデータ使用部と未使用部の間に
位置しているため、検索するためにはパッチ領域の先頭
（あるいは最後部）から順次サーチする必要があり、こ
の検索ロジック処理の追加が必要となるからである。ま
た、ダイナミックリンク方法は、対象モジュールと必要
なパッチデータとの関連づけをする機構が必要であり、
パッチをロードする処理時間も余計に費やすからであ
る。その他にも、パッチ領域を共有する方法などが考え
られるが、ファイル管理と似た管理機構が必要であり、
同様な問題が残るからである。
情報定義方法、およびダイナミックリンク方法は、必要
なパッチデータのみを主記憶に残すための処理時間が多
くかかることである。その理由は、境界情報定義方法の
場合、境界情報はパッチデータ使用部と未使用部の間に
位置しているため、検索するためにはパッチ領域の先頭
（あるいは最後部）から順次サーチする必要があり、こ
の検索ロジック処理の追加が必要となるからである。ま
た、ダイナミックリンク方法は、対象モジュールと必要
なパッチデータとの関連づけをする機構が必要であり、
パッチをロードする処理時間も余計に費やすからであ
る。その他にも、パッチ領域を共有する方法などが考え
られるが、ファイル管理と似た管理機構が必要であり、
同様な問題が残るからである。
【０００８】第３の問題点は、従来の境界情報定義方法
の場合、境界情報を厳密に区別することは実質不可能で
あることである。その理由は、ＺＡＰ領域の使用部８で
使用するパッチデータは、命令コードのみならずデータ
域として定義する場合もあるため、使用される値は任意
であり、ＺＡＰ領域の未使用部９との境界を示す境界情
報記憶部１０とパッチデータの一部が合致する可能性が
必ずあり、本来の境界と異なって判断されるからであ
る。
の場合、境界情報を厳密に区別することは実質不可能で
あることである。その理由は、ＺＡＰ領域の使用部８で
使用するパッチデータは、命令コードのみならずデータ
域として定義する場合もあるため、使用される値は任意
であり、ＺＡＰ領域の未使用部９との境界を示す境界情
報記憶部１０とパッチデータの一部が合致する可能性が
必ずあり、本来の境界と異なって判断されるからであ
る。
【０００９】第４の問題点は、パッチ領域の大きさによ
って、処理時間の遅延などの影響が発生することであ
る。その理由は、境界情報を定義する方法の場合、境界
情報をサーチするための検索処理時間はパッチ領域に比
例して多くなるからである。
って、処理時間の遅延などの影響が発生することであ
る。その理由は、境界情報を定義する方法の場合、境界
情報をサーチするための検索処理時間はパッチ領域に比
例して多くなるからである。
【００１０】本発明の目的は、パッチ領域のうち、実際
に使用している領域のみをプログラムと共に主記憶に常
駐することにより、パッチ処理の操作性を向上し、かつ
パッチ処理の時間を短縮することにある。
に使用している領域のみをプログラムと共に主記憶に常
駐することにより、パッチ処理の操作性を向上し、かつ
パッチ処理の時間を短縮することにある。
【００１１】
【課題を解決するための手段】本発明のプログラムパッ
チ方法は、プログラムの修正のために必要とされるパッ
チ領域内にパッチデータ格納域を設け、かつ、前記パッ
チデータ格納域内の実際にパッチデータが格納された領
域のサイズを示すパッチサイズ格納域を前記パッチ領域
に設け、実際にパッチデータが格納された領域を、プロ
グラムと共に主記憶に常駐する。
チ方法は、プログラムの修正のために必要とされるパッ
チ領域内にパッチデータ格納域を設け、かつ、前記パッ
チデータ格納域内の実際にパッチデータが格納された領
域のサイズを示すパッチサイズ格納域を前記パッチ領域
に設け、実際にパッチデータが格納された領域を、プロ
グラムと共に主記憶に常駐する。
【００１２】本発明のプログラムパッチシステムは、
（ａ）オペレーティングシステムよりロードされ、プロ
グラムの主要な処理を遂行し、最初に動作するプログラ
ムメイン部と、（ｂ）前記プログラムメイン部に修正を
実施する場合に、必要となる領域としてあらかじめ設け
られているパッチ領域と、（ｃ）前記パッチ領域内に設
けられ、前記プログラムメイン部がパッチ領域を実際に
必要としたサイズが格納される、パッチサイズ格納域
と、（ｄ）前記プログラムメイン部より呼ばれ、前記プ
ログラムメイン部が動作する上で最初に必要な各種初期
化処理を行い、かつ、前記パッチ領域のうち前記パッチ
サイズ格納域で指定されたサイズ分の領域と、前記プロ
グラムメイン部とを主記憶に常駐するプログラム初期化
部と、を備える。
（ａ）オペレーティングシステムよりロードされ、プロ
グラムの主要な処理を遂行し、最初に動作するプログラ
ムメイン部と、（ｂ）前記プログラムメイン部に修正を
実施する場合に、必要となる領域としてあらかじめ設け
られているパッチ領域と、（ｃ）前記パッチ領域内に設
けられ、前記プログラムメイン部がパッチ領域を実際に
必要としたサイズが格納される、パッチサイズ格納域
と、（ｄ）前記プログラムメイン部より呼ばれ、前記プ
ログラムメイン部が動作する上で最初に必要な各種初期
化処理を行い、かつ、前記パッチ領域のうち前記パッチ
サイズ格納域で指定されたサイズ分の領域と、前記プロ
グラムメイン部とを主記憶に常駐するプログラム初期化
部と、を備える。
【００１３】本発明の作用は以下のようである。
【００１４】パッチ領域内に実際に格納されているパッ
チデータの大きさを、パッチ領域内の最後部に有してい
る。このため、パッチデータがどこまで格納されている
かを検索などにより調べる必要がない。パッチ初期化部
にもつ常駐サイズ算出、および常駐終了手段において
は、［プログラムが常駐すべきサイズ］＝［プログラム
メインサイズ］＋［パッチ領域のうちパッチサイズ格納
域にあるパッチデータ量］であるため、これを算出し、
この部分のみ常駐させる。
チデータの大きさを、パッチ領域内の最後部に有してい
る。このため、パッチデータがどこまで格納されている
かを検索などにより調べる必要がない。パッチ初期化部
にもつ常駐サイズ算出、および常駐終了手段において
は、［プログラムが常駐すべきサイズ］＝［プログラム
メインサイズ］＋［パッチ領域のうちパッチサイズ格納
域にあるパッチデータ量］であるため、これを算出し、
この部分のみ常駐させる。
【００１５】
【発明の実施の形態】次に、本発明の実施の形態につい
て図面を参照して詳細に説明する。図１は、本発明の実
施の形態を示す構成図である。図１を参照すると、本発
明のプログラムパッチシステムは、プログラムメイン部
１と、プログラムメイン部１により最初に呼ばれるプロ
グラム初期化部２と、その間に位置するパッチ領域３と
からなり、さらに、パッチ領域３の最後部にはパッチデ
ータサイズを格納するパッチサイズ格納域４が設けられ
る。プログラムの緊急修正などで、プログラムメイン部
１の範囲内でパッチを行う場合もあるが、修正量が多く
なるとプログラムメイン部１だけでは修正ができないた
め、パッチ領域３をプログラムメイン部１の延長として
使用する。なお、パッチ領域３を使用する際は、先頭よ
り順次確保し、確保した領域の大きさがパッチサイズ格
納域４に登録される。プログラム初期化部２はプログラ
ムメイン部１より呼ばれ、プログラムメイン部１の初期
起動時に必要な処理を実行し、必要な処理が終われば、
常駐するのに必要な部分をオペレーティングシステムへ
報告する。
て図面を参照して詳細に説明する。図１は、本発明の実
施の形態を示す構成図である。図１を参照すると、本発
明のプログラムパッチシステムは、プログラムメイン部
１と、プログラムメイン部１により最初に呼ばれるプロ
グラム初期化部２と、その間に位置するパッチ領域３と
からなり、さらに、パッチ領域３の最後部にはパッチデ
ータサイズを格納するパッチサイズ格納域４が設けられ
る。プログラムの緊急修正などで、プログラムメイン部
１の範囲内でパッチを行う場合もあるが、修正量が多く
なるとプログラムメイン部１だけでは修正ができないた
め、パッチ領域３をプログラムメイン部１の延長として
使用する。なお、パッチ領域３を使用する際は、先頭よ
り順次確保し、確保した領域の大きさがパッチサイズ格
納域４に登録される。プログラム初期化部２はプログラ
ムメイン部１より呼ばれ、プログラムメイン部１の初期
起動時に必要な処理を実行し、必要な処理が終われば、
常駐するのに必要な部分をオペレーティングシステムへ
報告する。
【００１６】次に、図１の実施の形態の動作について図
２を参照して説明する。図２は、図１の実施の形態の動
作を示す説明図である。プログラムがオペレーティング
システムからロードされた直後、プログラムメイン部１
が動作する。プログラムメイン部１からは、まずプログ
ラム初期化部２を呼ぶ（図２（ａ））。
２を参照して説明する。図２は、図１の実施の形態の動
作を示す説明図である。プログラムがオペレーティング
システムからロードされた直後、プログラムメイン部１
が動作する。プログラムメイン部１からは、まずプログ
ラム初期化部２を呼ぶ（図２（ａ））。
【００１７】プログラム初期化部２では、プログラムメ
イン部１で必要な各種初期化処理が行われた後、主記憶
に常駐すべきサイズをチェックする。常駐サイズチェッ
クでは、パッチサイズ格納域４に格納されているパッチ
データサイズをもとに、パッチ領域３のうち、実際にパ
ッチデータが格納されている部分５（サイズをｎとす
る）とプログラムメイン部１の大きさ（サイズをｍとす
る）を合算し、ｍ＋ｎを先頭より常駐するようにする
（図２（ｂ））。
イン部１で必要な各種初期化処理が行われた後、主記憶
に常駐すべきサイズをチェックする。常駐サイズチェッ
クでは、パッチサイズ格納域４に格納されているパッチ
データサイズをもとに、パッチ領域３のうち、実際にパ
ッチデータが格納されている部分５（サイズをｎとす
る）とプログラムメイン部１の大きさ（サイズをｍとす
る）を合算し、ｍ＋ｎを先頭より常駐するようにする
（図２（ｂ））。
【００１８】その後、オペレーティングシステムに常駐
サイズを通知し、終了する。オペレーティングシステム
は指定されたサイズを主記憶に常駐し、それ以外は開放
する（図２（ｃ））。未使用パッチ領域６は開放された
部分である。
サイズを通知し、終了する。オペレーティングシステム
は指定されたサイズを主記憶に常駐し、それ以外は開放
する（図２（ｃ））。未使用パッチ領域６は開放された
部分である。
【００１９】次に、本発明の第１の実施例について図面
を参照して詳細に説明する。図３は、本発明の第１の実
施例を示す構成図である。図３を参照すると、プログラ
ムメイン部１はオペレーティングシステムよりロードさ
れ最初に動作する部分であり、プログラムの主要な動作
を行う。プログラム初期化部２はプログラムメイン部１
より呼ばれ、プログラムメイン部１が動作する上で最初
に必要な各種初期化処理を行うのと共に、初期化処理な
どは一度行えば不要となるので、不要となる部分を、終
了と同時に主記憶から開放する処理を最後に行う。プロ
グラムメイン部１で緊急修正が発生した際に、必要とな
る領域を設けているのがパッチ領域３である。パッチ領
域３は、不要な領域の開放の際に都合がよいように、プ
ログラムメイン部１とプログラム初期化部２の間に位置
している。またパッチ領域３の最後部には、パッチ領域
３に格納されたパッチデータの大きさを格納しておく、
パッチサイズ格納域４を設けている。パッチ領域３にパ
ッチデータを格納する時には、パッチデータを先頭より
必要なだけ埋めると共に、パッチサイズ格納域４にもパ
ッチデータを格納した大きさ（この場合、“０００
７”）を登録しておかなければならない。
を参照して詳細に説明する。図３は、本発明の第１の実
施例を示す構成図である。図３を参照すると、プログラ
ムメイン部１はオペレーティングシステムよりロードさ
れ最初に動作する部分であり、プログラムの主要な動作
を行う。プログラム初期化部２はプログラムメイン部１
より呼ばれ、プログラムメイン部１が動作する上で最初
に必要な各種初期化処理を行うのと共に、初期化処理な
どは一度行えば不要となるので、不要となる部分を、終
了と同時に主記憶から開放する処理を最後に行う。プロ
グラムメイン部１で緊急修正が発生した際に、必要とな
る領域を設けているのがパッチ領域３である。パッチ領
域３は、不要な領域の開放の際に都合がよいように、プ
ログラムメイン部１とプログラム初期化部２の間に位置
している。またパッチ領域３の最後部には、パッチ領域
３に格納されたパッチデータの大きさを格納しておく、
パッチサイズ格納域４を設けている。パッチ領域３にパ
ッチデータを格納する時には、パッチデータを先頭より
必要なだけ埋めると共に、パッチサイズ格納域４にもパ
ッチデータを格納した大きさ（この場合、“０００
７”）を登録しておかなければならない。
【００２０】次に、図３の実施例の動作について、図４
を参照して詳細に説明する。図４は、図３の実施例の動
作を示す説明図である。プログラムがオペレーティング
システムからロードされ、プログラムメイン部１が呼ば
れる。プログラムメイン部１では、まず、各種初期化処
理を行うためにプログラム初期化部２を呼ぶ（図４の
Ａ）。プログラム初期化部２では、プログラムメイン部
１が動作するうえで必要な各種初期化処理を実施する。
その後、プログラム全体の中で必要としなくなった部分
を開放する。開放する対象は、プログラム初期化部２自
身および、パッチ領域３のうち実際に使用されていない
部分とパッチサイズ格納域４である。パッチ領域３での
使用部分の大きさは、パッチサイズ格納域４に入ってい
るサイズ（図４の例では７バイトとなっている）を参照
し（図４のＢ）、パッチ領域３の先頭よりそのサイズ分
（図４の例では先頭から７バイト）までなので（図４の
Ｃ）、それ以降はすべて開放することになる。プログラ
ム初期化部２では、こうして得られたパッチ領域３の使
用部とプログラムメイン部１の大きさ（サイズｍとす
る）を合算したサイズ（図４の例ではｍ＋７バイト）
を、オペレーティングシステムに対し、主記憶常駐する
旨通知を行い、終了する。こうすることで、パッチ領域
３の未使用部分を常駐することなく、効率的に主記憶を
使用することが可能となる（図４のＤ）。
を参照して詳細に説明する。図４は、図３の実施例の動
作を示す説明図である。プログラムがオペレーティング
システムからロードされ、プログラムメイン部１が呼ば
れる。プログラムメイン部１では、まず、各種初期化処
理を行うためにプログラム初期化部２を呼ぶ（図４の
Ａ）。プログラム初期化部２では、プログラムメイン部
１が動作するうえで必要な各種初期化処理を実施する。
その後、プログラム全体の中で必要としなくなった部分
を開放する。開放する対象は、プログラム初期化部２自
身および、パッチ領域３のうち実際に使用されていない
部分とパッチサイズ格納域４である。パッチ領域３での
使用部分の大きさは、パッチサイズ格納域４に入ってい
るサイズ（図４の例では７バイトとなっている）を参照
し（図４のＢ）、パッチ領域３の先頭よりそのサイズ分
（図４の例では先頭から７バイト）までなので（図４の
Ｃ）、それ以降はすべて開放することになる。プログラ
ム初期化部２では、こうして得られたパッチ領域３の使
用部とプログラムメイン部１の大きさ（サイズｍとす
る）を合算したサイズ（図４の例ではｍ＋７バイト）
を、オペレーティングシステムに対し、主記憶常駐する
旨通知を行い、終了する。こうすることで、パッチ領域
３の未使用部分を常駐することなく、効率的に主記憶を
使用することが可能となる（図４のＤ）。
【００２１】さらに本発明の第２の実施例について、図
５を参照して説明する。図５は、本発明の第２の実施例
を示す構成図である。図５（ａ）の場合は、パッチサイ
ズをプログラム初期化部２にもつ形式である。この場
合、従来よりもパッチサイズ格納域４が追い出されてい
る分、パッチ領域３が広くなっているが、反面、パッチ
データを格納する際には、プログラム初期化部２のどの
位置にパッチサイズ格納域４が存在するかを知っておく
必要がある。
５を参照して説明する。図５は、本発明の第２の実施例
を示す構成図である。図５（ａ）の場合は、パッチサイ
ズをプログラム初期化部２にもつ形式である。この場
合、従来よりもパッチサイズ格納域４が追い出されてい
る分、パッチ領域３が広くなっているが、反面、パッチ
データを格納する際には、プログラム初期化部２のどの
位置にパッチサイズ格納域４が存在するかを知っておく
必要がある。
【００２２】図５（ｂ）の場合は、プログラム初期化部
２をプログラムメイン部１の一部として有する形式であ
る。プログラムの各種初期化処理がプログラムメイン部
１の処理と分離できない場合には、このような形をと
る。従来よりも、プログラム初期化部２が開放できない
分だけ主記憶に常駐するサイズは大きくなる。
２をプログラムメイン部１の一部として有する形式であ
る。プログラムの各種初期化処理がプログラムメイン部
１の処理と分離できない場合には、このような形をと
る。従来よりも、プログラム初期化部２が開放できない
分だけ主記憶に常駐するサイズは大きくなる。
【００２３】図５（ｃ）の場合は、パッチ領域３以外を
すべてプログラムメイン部１に有する形式である。プロ
グラムの各処理が分離しない分、処理間のつながりは明
確化されやすいが、反面、図５（ｂ）以上に、主記憶に
常駐するサイズは大きい。
すべてプログラムメイン部１に有する形式である。プロ
グラムの各処理が分離しない分、処理間のつながりは明
確化されやすいが、反面、図５（ｂ）以上に、主記憶に
常駐するサイズは大きい。
【００２４】上述したように、作成するプログラムによ
って、さまざまな構成をもつことが可能である。
って、さまざまな構成をもつことが可能である。
【００２５】
【発明の効果】第１の効果は、パッチデータに関する複
雑な管理が不要であるということである。その理由は、
実際にパッチデータが格納されている大きさを知るため
に、検索処理などを使用せず、あらかじめその大きさを
登録しているからである。
雑な管理が不要であるということである。その理由は、
実際にパッチデータが格納されている大きさを知るため
に、検索処理などを使用せず、あらかじめその大きさを
登録しているからである。
【００２６】第２の効果は、パッチデータを常駐するま
での処理が短時間で行われるということである。その理
由は、常駐する大きさは単純な加算処理（プログラムメ
イン部の大きさ＋パッチサイズ格納域にあるサイズ）で
済むためである。
での処理が短時間で行われるということである。その理
由は、常駐する大きさは単純な加算処理（プログラムメ
イン部の大きさ＋パッチサイズ格納域にあるサイズ）で
済むためである。
【００２７】第３の効果は、実際にパッチデータが格納
されている領域を厳密に判別可能であるということであ
る。その理由は、従来のようなパッチデータ使用域と未
使用域の境界を示す境界情報はパッチデータの一部と重
複する可能性があったが、パッチデータサイズ格納を有
した本方法はその可能性がないからである。
されている領域を厳密に判別可能であるということであ
る。その理由は、従来のようなパッチデータ使用域と未
使用域の境界を示す境界情報はパッチデータの一部と重
複する可能性があったが、パッチデータサイズ格納を有
した本方法はその可能性がないからである。
【００２８】第４の効果は、パッチ領域の大きさに関す
る制限が無いことである。その理由は、パッチ領域を大
きくすることによって、上述したような検索処理による
時間の遅延などの要因がないからである。
る制限が無いことである。その理由は、パッチ領域を大
きくすることによって、上述したような検索処理による
時間の遅延などの要因がないからである。
【図１】本発明の実施の形態を示す構成図である。
【図２】図１の実施の形態の動作を示す説明図である。
【図３】本発明の第１の実施例を示す構成図である。
【図４】図３の実施例の動作を示す説明図である。
【図５】本発明の第２の実施例を示す構成図である。
【図６】従来の技術を示す説明図である。
１ プログラムメイン部 ２ プログラム初期化部 ３ パッチ領域 ４ パッチサイズ格納域 ５ 実際にパッチデータが格納されている部分 ６ 未使用パッチ領域 ７ 常駐モジュール ８ ＺＡＰ領域の使用部 ９ ＺＡＰ領域の未使用部 １０ 境界情報記憶部 １１ システム初期化用非常駐モジュール １２ パッチデータ登録機能 １３ アドレス解決機能 １４ パッチデータロード機能 １５ パッチデータファイル １６ マッピングテーブル １７ パッチデータエリア １８ ＯＳ・プログラム
Claims (2)
- 【請求項１】 プログラムの修正のために必要とされる
パッチ領域内にパッチデータ格納域を設け、かつ、前記
パッチデータ格納域内の実際にパッチデータが格納され
た領域のサイズを示すパッチサイズ格納域を前記パッチ
領域に設け、実際にパッチデータが格納された領域を、
プログラムと共に主記憶に常駐することを特徴とするプ
ログラムパッチ方法。 - 【請求項２】（ａ）オペレーティングシステムよりロー
ドされ、プログラムの主要な処理を遂行し、最初に動作
するプログラムメイン部と、（ｂ）前記プログラムメイ
ン部に修正を実施する場合に、必要となる領域としてあ
らかじめ設けられているパッチ領域と、（ｃ）前記パッ
チ領域内に設けられ、前記プログラムメイン部がパッチ
領域を実際に必要としたサイズが格納される、パッチサ
イズ格納域と、（ｄ）前記プログラムメイン部より呼ば
れ、前記プログラムメイン部が動作する上で最初に必要
な各種初期化処理を行い、かつ、前記パッチ領域のう
ち、前記パッチサイズ格納域で指定されたサイズ分の領
域と、前記プログラムメイン部とを主記憶に常駐するプ
ログラム初期化部と、を有することを特徴とするプログ
ラムパッチシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP08199331A JP3105791B2 (ja) | 1996-07-29 | 1996-07-29 | プログラムパッチシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP08199331A JP3105791B2 (ja) | 1996-07-29 | 1996-07-29 | プログラムパッチシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH1049402A true JPH1049402A (ja) | 1998-02-20 |
| JP3105791B2 JP3105791B2 (ja) | 2000-11-06 |
Family
ID=16406026
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP08199331A Expired - Fee Related JP3105791B2 (ja) | 1996-07-29 | 1996-07-29 | プログラムパッチシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3105791B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004302747A (ja) * | 2003-03-31 | 2004-10-28 | Oki Electric Ind Co Ltd | パッチ処理方法および伝送装置 |
-
1996
- 1996-07-29 JP JP08199331A patent/JP3105791B2/ja not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004302747A (ja) * | 2003-03-31 | 2004-10-28 | Oki Electric Ind Co Ltd | パッチ処理方法および伝送装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP3105791B2 (ja) | 2000-11-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6976221B2 (en) | System and method for flexible software linking | |
| US8037292B2 (en) | Method for accelerating BIOS running | |
| US6374353B1 (en) | Information processing apparatus method of booting information processing apparatus at a high speed | |
| US7055146B1 (en) | Method and system for dynamically inserting modifications for identified programs | |
| US7917723B2 (en) | Address translation table synchronization | |
| US7203831B2 (en) | System and method for performing remote BIOS updates | |
| US6332172B1 (en) | Method and system for virtual memory compression in an embedded system | |
| US7882198B2 (en) | Shared JAVA JAR files | |
| JP3209793B2 (ja) | データ処理装置 | |
| JPH0644085A (ja) | アクセスを実行する方法及び装置並びにコンピュータシステム | |
| US8788799B2 (en) | Server computer, computer system, and file management method | |
| JP2005063449A (ja) | オブジェクトからオブジェクトへのＪａｖａネイティブインタフェースマッピングの方法及び装置 | |
| JP2010526364A (ja) | 記憶装置およびデータスマグリングの方法 | |
| US7100172B2 (en) | System and method for changing operation of an application without recompiling | |
| KR100494499B1 (ko) | 실행중인 파일에 대한 실시간 데이터 수정 방법 및 이를이용한 바이러스 치료방법 | |
| US20060129520A1 (en) | System and method for automatically updating a program in a computer | |
| JP2000242484A (ja) | 制御プログラムの変更方法 | |
| JP3105791B2 (ja) | プログラムパッチシステム | |
| US6718405B2 (en) | Hardware chain pull | |
| CN114090502A (zh) | 一种资源管理方法、装置、设备及存储介质 | |
| JP2856152B2 (ja) | カーネルデバッガにおけるソフトウェアブレークポイント管理方式 | |
| JP3425724B2 (ja) | システム無中断プログラム切替え方法 | |
| CN117234953B (zh) | 一种基于影子代码缓存的内核调试方法 | |
| JP2002024037A (ja) | ダイナミック・リンク・ライブラリ・ファイルの更新方法 | |
| US20060020834A1 (en) | Accessing information associated with an advanced configuration and power interface environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20000801 |
|
| LAPS | Cancellation because of no payment of annual fees |