JP2002503361A - データの仮想的変換システム - Google Patents

Abstract

(57)【要約】 任意のデータを仮想化し、所望のフォーマット以外のデータで動作するためのプログラムを許容するソフトウエア・システムである。該システムは、２００年以降の日付を処理するよう設計されていないソフトウエア・システム上で、世紀が急激に変化するときに生じる問題の新規な解決手段を提供する。データ項目は、データ・ファイル又はコンピュータ・スクリーン・メモリ等の、任意の形式のデータ・ソースから得られる。本発明は、プログラム変換プロセス（エレメント４４及び４６）とデータ・ファイル変換プロセスとにリンクを提供することによって、動作する。本発明は、変換済みプログラム（エレメント３０）が、未変換データ・ファイルのレコードを読出すか又は書込む度に、制御を行う。Ｉ／Ｏ動作中にレコードを変換することにより、変換済みプログラムが、未変換データ・ファイルに、該ファイルがあたかも変換済みであるかのようにアクセスすることができるようになる。本発明は、レコード中のデータ・ファイルを、プログラム上に通過させる前に、実行仕様の新しいフォーマット（エレメント４０）に変換する。変換済みプログラムにおいては、データは、該プログラムが見ることができる新しいフォーマットで規定される。未変換状態のプログラム（エレメント２８）は、実際の未変換データ・ファイル（エレメント３２）に対してアクセスし続ける。このようにして、本発明は、未変換データ・ファイルの仮想的変換形態を備えた、変換済みプログラムを提供し、また、本発明は、所定のフォーマットのデータを、未変換状態のデータ・ファイルにレコードを書込む前に、古いフォーマットのデータに変換する。

Description

【発明の詳細な説明】 データの仮想的変換システム 発明の分野 本発明は、ソフトウェア・システムに関し、更に詳しくは、ソフトウェア・ システム・プログラム内の任意のデータとデータ・ファイルとを任意の所望のフ ォーマットに仮想化するソフトウェア・システムに関する。 発明の背景 ２０００年が近づいてくるにつれて、情報技術（ＩＴ）産業は、現在、巨大な 問題に直面している。この問題とは、（例えば、１９９６年とする代わりに９６ 年とするように）日付を表す際に２つの桁を用いて年を表しているプログラムや アプリケーションは、２０００年以降の日付の算術的演算、比較、ソートなどを 実行しようとすると、ブレークダウンするというものである。プログラムが１９ ９０年１月１日から１９９９年１２月３１日の範囲に含まれない日付を処理しよ うとすると、不正確な結果が得られる。２０００年の日付変更の範囲は非常に広 く、メインフレーム及びデスクトップ・コンピュータ上の、マイクロコードから アプリケーション・プログラム・コードまでを含む。また、この問題は、プログ ラムとデータベース・ファイルとの両方を含み、すべてのコンピュータ・プラッ トフォームに関係する。 ２０００年問題は、ほとんどが、年を表すのに４桁ではなく２桁を用いている アプリケーション・プログラムとそれに対応するデータとから生じる。非常に多 くのこのようなプログラムが、１９６０年代から１９７０年代にかけて、自分た ちの書いたソフトウェアが２０年も３０年も後の２０００年の時点で依然として 用いられているなど考えもしなかったアプリケーション・プログラマによって書 かれたのであ った。更に、これらのプログラムは、記憶装置のメモリ空間のどの１バイトもが 貴重であった時代に書かれたものであった。プログラムやデータベースの記憶装 置に対する要求を減少させるためには、あらゆる機会が利用されたのである。そ の結果として、２桁を用いて年のデータを表すことが広範囲に行われ、急速に、 この分野での慣行となった。時間が経過しても、ほとんどがメインフレームとミ ニコンピュータとのために書かれたこれらの非常に古い（ｌｅｇａｃｙ）プログ ラムは、廃棄されるのではなく、新たな特徴を追加し更新を行うことによって、 最新の状態に保たれてきた。 ２０００年問題は、２桁を用いて年を記憶していることの可能性のある波及効 果を考慮すると、更に深刻である。年のデータを減算する算術的計算は、どれも が、２０００年以降の年を用いるときには狂う危険がある。複数の日付が異なる 世紀に属する場合には、２桁の日付の情報を比較することはできない。更に、ソ ートのためのアルゴリズムは、２０００年以降の年を含むレコードを正しくソー トしない。例えば、０３で表される２００３年は、９６で表される１９９６年よ りも前のものとしてソートされてしまう。更に、うるう年やそれ以外の日、週、 月の計算がずれてしまう。例えば、２０００年は、うるう年であり、１９００年 はそうではない。また、例えば、２００１年と１９０１年とでは、週や月の日付 は等しくない。 この問題に対する解決策は、既にいくつか提案されている。１つの解決策とし て、日付のフィールドを、４桁の年フィールドを記憶するように拡張するという ものがある。これは、ソフトウェア・システムを２０００年対応とするための適 切な解決策であるように見える。プログラムのロジックに対しては、何の変更も 要求されず、単に、日付に関係する部分の明らかな変更だけでよい。このアプロ ーチは、エレガントではあるのだが、短所として、データ・フィールドの長さを 変更するには、プログラムとデータ・ファイルとの両方を同時に変換することが 要求される。変換されたデータ・ファイルを参照するソフト ウェア・プログラムもまた、すべて、４桁の年のフォーマットに変換されなけれ ばならない。典型的なデータ処理ショップが、合計で１万５千から３万ものモジ ュールとデータベース・ファイルとを有していることを考慮すると、これは、不 可能であるか、又は、実現が極端に困難であるかのいずれかである。従って、プ ログラムとデータ・ファイルとの間のリンクによって、変換及び実装が可能なプ ログラム及びデータ・ファイルの封止されたクラスタを、システム内の他のプロ グラムやファイルとは独立に作成することが必要となる。ほとんどのシステムは 性質的に相互関係を有しているので、これらのクラスタは、きわめて大きくなる 傾向があり、数千から数万のプログラム及びデータ・ファイルを含むこともあり 得る。 別の解決策としては、２桁の年を４桁表現に具体化するウインドウ処理技術を 用いることがある。この技術では、１００年の固定された又はロール形のウィン ドウを用いて、２桁の年が１９ｘｘであるのか２０ｘｘであるのかを判断する。 それぞれの世紀で用いられる年に関して、数字が特定される。例えば、００から ２０の数字は、２０００年から２０２０年を表す。従って、２１から９９の数字 は１９２１年から１９９９年を表す。この技術の長所は、２桁の年を４桁のフォ ーマットに拡張する必要がない点である。短所は、１００年の範囲を超える年が 必要となる場合には、問題が生じることである。更に、２桁の年をインデクスと して用いるデータベースは、どれも、２０から２１への不連続的なステップのた めに機能しない点である。９９から００についても同様である。 第３の解決策は、２桁の日付のフィールドを、４桁を保持できるように符号化 し圧縮することである。この解決策の長所は、２桁の年のデータ・フォーマット を４桁の年のフォーマットに拡張する必要がないことである。この解決策の短所 は、このデータ・ファイルにアクセスするすべてのプログラムが、圧縮され／符 号化された４桁の年のフォーマットを扱えるように修正されなければならないと いう点である。 従来技術を示す図１には、上述した従来技術における解決策のいくつかを用い る場合に生じうる潜在的な問題が図解されている。プログラムの小さなグループ が示され、プログラムＡ１２、Ｂ１４、Ｃ１６、Ｄ１８が、１又は複数の関係す るデータ・ファイルＡ２０、Ｂ２２、Ｃ２４、Ｄ２６にアクセスする様子が示さ れている。例えば、プログラムＡは、ファイルＡ、Ｂ、Ｃへのリンクを有するこ とが示されている。プログラムＡが４桁の年のフォーマットに変換される場合に は、リリースされ作成される前に、ファイルＡ、Ｂ、Ｃもまた変換されなければ ならない。さもなければ、プログラムＡは動作しない。しかし、プログラムＢは 、ファイルＡ、Ｃ、Ｄにアクセスするので、プログラムＡを変更することは、プ ログラムＢの動作にも影響することになる。従って、典型的な場合には、１つの プログラム又はデータ・ファイルの変換は、他のプログラム及び／又はデータ・ ファイルとは独立に行うことができない。相互に依存しているからである。 発明の概要 本発明は、データ・ファイルにおける任意のデータ・フィールドを任意の所望 のフォーマットを有するように提供することが可能となるように仮想化する機構 を与えることによって、従来技術に内在する問題を解決する。この機構は、上述 した２０００年データ問題に直接的に応用することができる。特に、２０００年 問題の関係では、本発明は、プログラム変換プロセスとデータ・ファイル変換プ ロセスとの間のリンクとして働くことにより機能する。本発明では、変換済みプ ログラムが未変換データ・ファイルのレコードを読出したり書込んだりする度に 、制御を行う。Ｉ／Ｏ動作の間にレコードを変換することによって、変換済みプ ログラムは、未変換データ・ファイルに、それが変換されているものとして、ア クセスすることが可能になる。本発明は、読出されたレコード内のデータ・フィ ールドを実装に特有な新たなフォーマットに変換してから、それをプログラムに 送る。変換済み プログラムでは、日付は、このプログラムが読出すことを予測している（例えば 、４桁の年のフォーマットの）新たなフォーマットで定義されている。未変換プ ログラムは、そのまま、実際の未変換データ・ファイルにアクセスし続ける。こ のようにして、本発明は、変換済みプログラムに、未変換データ・ファイルの仮 想的な変換済みの像を与える。本発明は、同様にして、新たなフォーマット（例 えば、４桁の年のフォーマットの日付）を有するデータを古いフォーマットに変 換してから、未変換データ・ファイルにレコードを書込む。 本発明を用いると、プログラムを、このプログラムによって用いられるファイ ルが変換される前に、変換し実装することができる。これにより、プログラムの 変換とデータ・ファイルの変換とを、相互に独立して行うことが可能になり、従 って、計画立案と管理とが、はるかに容易となる。このようにして、プログラム だけを含む小さくコンパクトなクラスタを構築できるようになる。これによって 、変換プロセスを、より完全にテストすることが可能になる。変換済みプログラ ムに問題が生じた場合には、その特定のプログラムの以前のバージョンに戻りそ れを用いることがはるかに容易になる。更に、より小さなセグメントを用いるこ とで、多くのプログラムを長期間に亘ってタイアップしておく必要がなくなる。 これにより、システム全体に対する混乱を減少させることになる。変換済みプロ グラムを転送している間に日々の業務が中断される可能性は、プログラム及びデ ータ・ファイルの大きなクラスタが転送される場合よりも、著しく少なくなる。 本発明は、このようにして、ソフトウェアの変換を、従来技術に基づく解決策の 場合よりも、より容易で、安価に、速く、そして最も重要なことであるが、より 安全なものにする。 従って、本発明の一つの特徴によれば、データ・ファイルの任意のデータ・フ ィールドを任意の所望のフォーマットでのデータ・ファイルで与えられるものと なるように仮想化するシステムが提供される。 本発明の別の特徴によれば、非常に古いアプリケーション・プログ ラムを２０００年問題に対応できるように適応させ、その際に、アプリケーショ ン・プログラムへの変換だけが要求され、データ・ファイルは、オリジナルの２ 桁の年のフォーマット・データのままで存続することを可能になる。 本発明の更に別の目標は、すべてのアプリケーション・プログラム及びデータ ・ファイルが新たな、例えば４桁の年のフォーマットに直ちに変換されなければ ならないという要求を不要とする。アプリケーションをまず変換した後に、デー タ・ファイルを変換すればよい。 このように、好適な実施の形態によれば、オリジナルのフォーマットを有する データ・ファイルの任意のデータ・フィールドを仮想化し、所望のフォーマット のデータを与えるデータ適応化システムが提供される。このシステムは、ユーザ によって適切に定義されるデータ変換定義を用いる。このデータ変換定義には、 データ・ファイルにおけるレコード形式と、そのレコード形式を識別するのに用 いられるレコード形式におけるフィールド及びその値と、仮想化されるデータに 対応するデータ・フィールド及びそれに対応するフォーマットとの指標が含まれ ている。 少なくとも１つの変換ルーチンが提供され、データ・ファイルのレコード内の データ・フィールドを新たなフォーマットにマッピングする。データ・アダプタ は、プログラムからの読出し要求をインターセプトし、変換ルーチンを用いて、 データ・ファイルから読出されたレコードにおいて、オリジナルのフォーマット を有するデータを所望のフォーマットを有するデータで置換すると共に、プログ ラムからの書込み要求をインターセプトし、変換ルーチンを用いて、データ・フ ァイルに書込まれたレコードにおいて、オリジナルのフォーマットを有するデー タで所望のフォーマットを有するデータを置換する。例えば、オリジナルのデー タ・フォーマットは２桁の年のフォーマットであり、所望のデータ・フォーマッ トは４桁の年のフォーマットである。 必要ならば、このシステムは、データ変換定義を用いた変換ルーチ ンを生成するプログラム・ジェネレータを含むこともできる。好適な実施の形態 では、このプログラム・ジェネレータは、第１の（例えば、高級言語による）プ ログラム・ジェネレータを含み、この高級言語によるプログラム・ジェネレータ は、データ変換定義を用いて、第１の（例えば、ハイ・レベルの）プログラムを 生成し、それによって、データ・ファイルにおけるデータ・フィールドのマッピ ング（例えば、長さ及びオフセット）が決定される。第２のプログラム・ジェネ レータはハイ・レベルのプログラムの出力を処理して、変換ルーチンを生成する 。 図面の簡単な説明 本発明は、例示の目的によってのみ、図面を参照して説明される。 図１は、複数のデータ・ファイルをアクセスする複数のアプリケーション・ プログラムを含むサンプル・シナリオの従来技術の説明図である。 図２は、サンプル・データ処理シナリオに対する本発明のデータ・アダプタ の適用を示すハイ・レベルのブロック図である。 図３は、サンプル・データ処理シナリオに適用される本発明のデータ・アダ プタ・システムを示すハイ・レベルのブロック図である。 図４は、本発明のデータ・アダプタ・システムを更に詳細に説明するハイ・ レベルのブロック図である。 図５は、本発明の初期化ルーチンを示すハイ・レベルのフロー図である。 図６は、本発明の、フックを「開く」ルーチンを示すハイ・レベルのフロー 図である。 図７は、本発明の入／出力（Ｉ／Ｏ）読出しルーチンを示すハイ・レベルの フロー図である。 図８は、本発明のＩ／Ｏ書込みルーチンを示すハイ・レベルのフロー図であ る。 図９は、本発明の変換ルーチン・ジェネレータを更に詳細に示すハイ・レベ ルのブロック図である。 図１０は、本発明のコボルプログラム・ジェネレータを更に詳細に示すハイ ・レベルのブロック図である。 図１１は、変換ルーチン・ジェネレータに関連して使用されるサンプル・デ ータ変換定義の内容である。 図１２は、４桁の年のフォーマットへのデータ・ファイルの変換に適用され るような本発明のデータ・アダプタ・システムを示すハイ・レベルのブロック図 である。 図１３は、オリジナルの６バイトの２桁の年のフォーマットに符号化され且 つ圧縮された４桁の年のフォーマット・データの８バイト表示を示すデータ図で ある。 本発明の詳細な説明 本発明の、符号１０で概略的に示されたデータ・アダプタのサンプル・デー タ処理シナリオへの適用を説明するハイ・レベルのブロック図は、図２に示され ている。本発明の原理を教示するために、前述の２０００年問題の例がこの開示 全般にわたって使用されている。２０００年問題を扱う本発明の説明は、本発明 の適合性を他の非データ関連のアプリケーションに限定するものでは決してない 。特に、本発明は、データ・ファイル、コンピュータ・スクリーン・メモリ、磁 気テープのようなデータ・ソースにおける任意のデータ・ファイルのフォーマッ ティングを仮想的に変更することが望ましいシステムに適用可能である。 ２０００年日付け問題に関連して、また図２を参照して、プログラムＡ２８ は未変換プログラムを示し、プログラムＢ３０は変換済みプログラムを示す。変 換の用語は、１つのタイプのフォーマットから別のタイプのフォーマットにデー タを変更するプロセスを意味している。２０００年問題の例においては、変換の 用語は、オリジナルのプ ログラム・ファイルにおける全ての２桁の年のレファレンスを４桁の年のフォー マットに変更するプロセスを意味している。これは、日付け、日付けの比較、１ またはそれ以上の日付けについての算術オペレーション等の参照を含む。未変換 データ・ファイル３２は、オリジナルの２桁の年のフォーマットを依然として保 持しているオリジナルの日付けファイルである。データ・アダプタ１０は、プロ グラムＢからの全てのＩ／Ｏ呼出しをインターセプトして、データ・フォーマッ トの仮想化を実行する。この例において、未変換データ・ファイル３２から得ら れた全ての２桁の年の日付けは、４桁の年のフォーマットの日付けで置換される 。このように、データ・アダプタ１０が全てのＩ／Ｏ呼出しをインターセプトす るという事実は、プログラムＢに対して透過的である。プログラムＢは、４桁の 年のフォーマット化情報を予期しかつ受取る。同様に、書込み時に、データ・ア ダプタ１０は、日付けデータをデータ・ファイルに実際に書込む前に、４桁の年 のフォーマットを２桁の年のフォーマットに変換する。このように、データ・ア ダプタは、依然として２桁の年のフォーマット・データを予期する未変換プログ ラムが４桁の年のフォーマット・データを処理するように既に変換されたプログ ラムと共に実行することを可能にする。 古いフォーマットを有するデータを新しい所望のフォーマットを有するデー タに仮想化する（例えば、全てのＩ／Ｏ要求をインターセプト又はフィルタリン グすることによって２桁の日付けと４桁の日付けとの間の変換を行う）ために、 データ・アダプタを使用することの利点は、データ・フォーマットの変更を扱う 権限を有する管理情報システム（ＭＩＳ）の人員または他の誰かに、彼ら自身の 判断でアプリケーション・プログラムの変換を可能にすることである。全てのプ ログラムとデータ・ファイルを同時に生成することは最早不要である。変換済み プログラムと未変換プログラムが同時に存在し得るので、変換プロジェクトは所 望のペースで進めることができる。しかしながら、変換されるべきデータ・ファ イルに対しては、当該特定のデータ・フ ァイルをアクセスする全てのプログラム・ファイルは、予め変換されていなけれ ばならない。 図３を参照すると、データ・アダプタ１０は所望の変換を定義する１つまた はそれ以上の変換ルーチンと協働する。データ・アダプタ１０と変換ルーチン４ ６は集合的にデータ・アダプタ・システム４２として参照されている。種々のフ ァイル・フォーマットの変換を容易にするために自由度があることが望ましいシ ステムにおいて、データ・アダプタ・システム４２は変換ルーチン・ジェネレー タ４４と適切に協働し、このジェネレータは、１つ又はそれ以上のデータ変換定 義（ルール）３８から１つ又はそれ以上の変換ルーチンを発生し、またユーザに よって提供される変換ヘッダの指標、例えば変換ヘッダ・ファイル４０を発生す るために使用される。データ変換定義（ルール）３８は、変換されるべき各デー タ項目フォーマットに対して与えられる。次に、変換ルーチン４６は、選択され たデータ項目（例えば、日付けデータ）を、第一の、例えば２桁の年のフォーマ ットと、第二の、例えば４桁の年のフォーマットへ、またそれらへ変換するため に、データ・アダプタ１０によって使用される。データ変換定義３８および変換 ヘッダ・ファイル４０は、変換ルーチン・ジェネレータ４４に入力される。オリ ジナルの未変換の日付けに対応するヘッダの指標、例えば古いヘッダ・ファイル ３４は、未変換データ・ファイル３２をアクセスする未変換プログラムに入力さ れる。データ・アダプタ１０は、変換プログラム４８からのＩ／Ｏ要求を受取る のに加えて、未変換データ・ファイル３２をアクセスする。変換ヘッダ・ファイ ル４０はまた、コンパイラへの入力として変換プログラムと共に使用される。 好適な実施の形態において、データ・アダプタ１０は、未変換データ・ファ イルとの間の実際のデータ変換を実行するのに１つ又はそれ以上の変換ルーチン を使用する。変換ルーチンは、データ変換定義３８および変換ヘッダ・ファイル ４０から、以下で詳述される変換ルーチン・ジェネレータ４４によって外部的に 発生され得る。変換ヘッ ダ・ファイル４０は、指示されたデータ項目が第一のフォーマットから第二のフ ォーマットに変換された後に、データ構造を定義し、例えば、４桁の年のフォー マットに拡張された日付け関連データと共にオリジナルのプログラムの全てのデ ータ宣言を含む。 また、データ・アダプタ・システム４２は、内部の（必須の）変換ルーチン ・ジェネレータ、或いは変換されるべきデータの形式に適したビルト・イン（例 えば、ハード・コード化）変換ルーチンを含むことができる。マニュアルで又は 他の自動化手段によって生成されるハード・コード化変換ルーチンの使用は、ア プリケーションに含まれる種々のデータ形式およびフォーマットが比較的数の上 で少なくかつ変化しない場合における特別なユティリティのものである。 変換済みプログラムおよび未変換プログラムは、同じ未変換データ・ファイ ル３２で一緒に動作可能である。第一の、例えば２桁の年の日付けフォーマット を使用する未変換プログラム２８は、通常、未変換データ・ファイルをアクセス する。しかしながら、変換済みプログラム４８は、第二のフォーマット、例えば ４桁の年のフォーマット化データ情報を扱うために既に変換されている。変換ル ーチン４６を使用して、データ・アダプタ１０は、各読出しオペレーションの一 部として第一のフォーマットから第二のフォーマットへの変換、および指示され たデータ項目を含む各書込みオペレーションの一部として第二のフォーマットか ら第二のフォーマットへの変換を有効に実行し、例えば、データ・ファイル読出 しで２桁から４桁への変換、およびデータ・ファイル書込みで４桁から２桁への 変換を実行する。 図４から図１３及び添付の記述は、ＩＢＭメインフレームの言語及びアーキテ クチャと、シーケンシャル・ファイルを用いるコボル・プログラミング言語とを 想定する。しかしながら、他のプラットフォーム、データベース及びプログラミ ング言語は、当業者により開示されているものの代わりに容易に適合されること ができる。 図４を参照すると、適切なデータ・アダプタ１０は、実行時データ・ アダプタ４７、変換ルーチン４６、フックを「開く」ルーチン５８及び初期化ル ーチン５６を備える。変換済みプログラム３０は、指定されたデータ項目が第１ のフォーマットから第２のフォーマットにすでに変換された、例えば、変換済み プログラム３０における全てのデータ参照が先に２桁の年のフォーマットから４ 桁の年のフォーマットに変換された一連の命令／ステートメントを備える。図４ は、第２のフォーマット・データ、例えば４桁の年のフォーマット・データを処 理するためすでに更新された変換済みプログラムで用いられる典型的な一連のコ ボル・ステートメントを示す。 好適な実施の形態において、変換済みプログラム３０は、アプリケーション・ プログラムの始めに加えられた初期化ルーチン５６に対する単一の呼出しを介し てデータ・アダプタ１０をトリガする。プログラム又はプログラムのジョブ制御 言語（ＪＣＬ）に対する他の変更は、データ・アダプタを始動する（ｌａｕｎｃ ｈ）ため必要とされない。一旦フラグが立てられると、データ・アダプタは、変 換済みデータ・ファイルについての全てのＩ／Ｏオペレーションを解釈し、変換 ルーチンを付勢する。単一の呼出しにより呼び込まれた変換済みプログラム３０ に対して外部の変換ロジックの使用は、さもなければ変換済みプログラム３０が 未変換データを受け入れることを可能にするのに必要とされるであろうプログラ ミングを単純化する傾向にある。 初期化ルーチン５６に対する呼出しは、変換されるべきファイルを識別し、そ れらファイルを対応する変換ルーチン４６と関連付ける。呼出しのパラメータは 、複数の一対のファイル名を含む。第１のファイル名は処理されるべきデータ・ ファイルの名前であり、第２のファイル名は第１のファイル名において指定され たデータ・ファイルと関連した変換ルーチンの名前である。２対以上の［データ ・ファイル、変換ルーチン］は、初期化ルーチン５６に対する呼出しにおいてリ ストされ得る。 データ・アダプタ１０の初期化ルーチン５６は、「開く」指令又は ステートメントに対するフッキング（ｈｏｏｋｉｎｇ）又はトラッピング（ｔｒ ａｐｐｉｎｇ）をセットアップするよう機能する。「開く」ステートメントに出 会うと、「開く」フック・ルーチン５８が実行される。以下でより詳細に記載さ れるフックを開くルーチンは、Ｉ／Ｏ読出し及び書込みに対する追加のフッキン グをセットアップするよう機能し、次いでオリジナルの「開く」ルーチンを呼び 出す。 読出し及び書込みステートメントに達すると、変換済みプログラム３０におい て、プログラム制御はデータ・アダプタ１０へ切り替えられる。データ・アダプ タは、オリジナルのフォーマットを有するデータを所望の新しいフォーマットを 有するデータに変換又は仮想化するのに変換ルーチン４６を利用する。特に、２ ０００年の例においては、２桁の年のデータが４桁の年のデータに変換され、ま たそれから逆に変換される。データ・アダプタはまた、オリジナルのＩ／Ｏルー チン６２を呼び出し、未変換データ・ファイル６４に対する読出し又はそれへの 書込みを実際に実行する。こうして、データは仮想化され、アプリケーション・ プログラムはデータが元は古いフォーマットを持っていたことを知らない。 変換済みプログラム３０と同時に共存する非変換プログラム２８は、未変換デ ータ・ファイル６４から２桁の年の情報を適切に且つ直接にアクセスする。 ここで図５を参照すると、初期化ルーチン５６に対する呼出しがなされると、 実行される第１のステップは、例えば、当業者には周知のＳＶＣスクリーニング 技術を用いてフック又はソフトウエア・トラッピングをインストールすることで ある(ステップ７２)。次に、変換ルーチンが、迅速なアクセスのためメモリにロ ードされる(ステップ７４)。 ここで図６を参照すると、変換済みプログラムが実行するにつれて、「開く」指 令に最終的に達すると、プログラム制御はフックされた「開く」ルーチン５８に渡 される。前述したように、フッキングは、初期 化ルーチン５６により実行される機能の一つである。ファイルからのデータ情報 の変換を開始するため、パラメータとして「開く」ステートメントに含まれたデ ータ・ファイルが初期化ルーチンに対する呼出しの中にリストされたデータ・フ ァイルの一つであるか否かについて決定される(ステップ８０)。ファイルが呼出 しステートメントに対するパラメータの組の中のファイルの一つでない場合、制 御はオリジナルの「開く」ルーチン６０に渡される。ファイルが呼出しステート メント・リスト上にある場合、データ・ファイルをデータ変換定義３８（図３） で変換するか否かの指示を適切に参照することにより、データ・ファイルがその 例えば日付及び年の情報を変換させるべきかを決定する(ステップ８２)。 変換済みプログラムと関連したデータ・ファイルの中の日付及び年の情報が第 １のフォーマットから第２のフォーマットに、例えば、２桁の年のフォーマット から４桁の年のフォーマットに変換された後ですら、関連のステートメント（即 ち、初期化を呼び出す、開く、等）を変換済みプログラムの中に保存しておくこ とが依然望ましい。年の情報をセットアップするため初めに必要とされるこれら のステートメントの除去は、追加のテスト及びメンテナンス時間を要するが、こ の特別のコードを必要としない数百のそのような変換済みプログラムがあり得る 。これは、全てのこれらの関連のデータ・ファイルが４桁の年のフォーマットに すでに変換されているからである。しかしながら、現在の作業データ・フィール ドが４桁の年のフォーマットにすでに変換されたにも拘わらず、歴史的データは 変換されない可能性が高い。多くのデータ処理ショップは、歴史的データ・ファ イルの全体数が膨大すぎるので完全な変換を試みることはできないことを知り得 る。こうして、データ・アダプタ１０の機構をトリガするための僅かな追加のコ ードが変換済みプログラムの中に残りそうであり、所与のデータ・ファイルを変 換するか否かを知るための機構が必要とされる。以下でより詳細に記載されるよ うに、一旦データ・ファイルが変換され ると、この事実をデータ変換定義３８において示すことは単純なことである。 コボル・システムの例示的な関係において、一旦所与のデータ・ファイルが変 換されると、次のステップは、レコード長のようなファイル属性を受け入れるよ う、アプリケーション・プログラムにより与えられたデータ制御ブロック（ＤＣ Ｂ）を修正することであり、その場合、実際の提示と仮想の提示とが異なるよう にすることである。更に、Ｉ／Ｏルーチン・フッキングは、ＤＣＢの中のアクセ ス方式ルーチンを修正することによりインストールされる(ステップ８４)。ＤＣ Ｂの出口はまた、適切にＩ／Ｏルーチン・フッキングをインストールするため修 飾される(ステップ８６)。一旦Ｉ／Ｏフッキングが適所にあると、オリジナルの 開くルーチン６０が実行される(ステップ８８)。 ここで実行時データ・アダプタ４７をより詳細に記載する。データ・アダプタ １０は、Ｉ／Ｏ読出しプロセス（図７）及びＩ／Ｏ書込みプロセス（図８）を備 える。ここで図４及び図７を参照すると、読出しステートメント／指令に変換済 みプログラム３０の中で出会うと、オリジナルのＩ／Ｏ読出しルーチン６２（図 ４）が初めに実行される。次に、先に発生されデータ・ファイルに対応する変換 ルーチン４６が呼び出され、実際の第１のフォーマットを第２のフォーマットに 、例えば、２桁の年のフォーマットを４桁の年のフォーマットに変換するのを実 行する(ステップ９２)。変換済みの、例えば、４桁の年のフォーマット・データ が、呼び出し側の変換済みアプリケーション・プログラム３０に渡される(ステ ップ９４)。 ここで図４及び図８を参照すると、書込みステートメント／指令に変換済みプ ログラム３０の中で出会うと、データ・ファイルに書込まれるべきレコードは図 ８のフックされたＩ／Ｏ書込みルーチンに渡される(ステップ１００)。データ・ ファイルの対応する変換ルーチン４６が呼び出され、実際の第２のフォーマット を第１のフォーマットに、例えば、４桁を２桁に変換することをレコード上で実 行する(ス テップ１０２)。一旦変換されると、オリジナルのＩ／Ｏルーチン６２（図４） は、レコードをデータ・ファイル３２に書込む。こうして、本発明のＩ／Ｏ読出 し及び書込みルーチンは、オリジナルの、例えば２桁の年のフォーマット・デー タを保持するデータ・ファイル３２が第２の、例えば４桁の年のフォーマットに 仮想的に変換されるのを可能にする。 前述したように、変換ルーチン４６は、内部の（一体の）変換ルーチン・ジェ ネレータによりハードーコード化され又は発生され得る。しかしながら、多数の 異なるデータ形式及びフォーマットがアプリケーションの中に含まれる、例えば アプリケーションが多数の異なるレコード・フォーマットを有するデータについ て処理する場合、変換ルーチン４６は、フレキシビリティを最大にするため、デ ータ・アダプタ１０に対して外部の変換ルーチン・ジェネレータ４４により発生 されるのが好ましい。ユーザの視点から見ると、変換ルーチン・ジェネレータの 使用は、変換する必要があるデータ・ファイル内のデータ・フィールドの長さ及 びオフセットを定義するタスクを極めて単純化する。ユーザは、一層暗号を用い たタイプの方法ではなく、アプリケーションの言語、例えばコボルにおいて長さ 及びオフセットを指定することができる。 図３及び図９を参照して、変換ルーチン・ジェネレータ４４をここでより詳細 に記載する。図３を参照すると、変換ルーチン・ジェネレータに対する入力はデ ータ変換定義３８（例えば、データ定義ファイル）であり、そして変換済みヘッ ダ・ファイル４０が変換ルーチン・ジェネレータ４４に対する入力として設けら れている。変換済みヘッダ・ファイル４０は、第２のフォーマット、例えば拡張 されたデータ・フィールド・サイズ（２桁の年のフィールドが４桁の年のフィー ルドに拡張された）に従って修正されたオリジナルのヘッダ・ファイルである。 データ変換定義３８の指標は、適切なプログラム・ジェネレータに対する入力で ある(ステップ１１０)。プログラミング言語コボ ルが、ここに記載の例示的な実施の形態において用いられるのが適当である。し かしながら、他のプログラミング言語も同様に働く。当業者は、本発明の教示を 実行するため他のプログラミング言語及び他のプラットフォームに代替し得る。 プログラム・ジェネレータ１１０の機能は、データ・ファイルのすべてのデー タ・フィールドに対して、変換ルーチンにおいて用いられる長さとバイトのオフ セットを決定すると共に、それらが変換されるべきか否か（例えば、４桁の年の データ）を決定するために使用できるプログラムを（例えば、コボルで）発生す ることである。 コボル・プログラム・ジェネレータからのコボル・プログラム・ソースの出力 は、標準のコボル・コンパイラ及びリンカ（Ｉｉｎｋｅｒ）を用いてコンパイル 及びリンクされる。変換されたヘッダ・ファイル４０は、コンパイル及びリンク のステップの間に入力として用いられる。変換されたヘッダ・ファイル４０は、 コボル・プログラムがデータ・ファイルにアクセスするために必要とするすべて のデータ・ファイル・データ定義（即ち、構造、アレイ、変数その他）を提供す る。出力オブジェクト・コードは次に実行される(ステップ１１４)。 実行されるプログラムは、好適には新規な技術を用いて、データ・ファイル内 のデータ・フィールド及び他の変数のオフセット、変移、サイズ及び形式を決定 する。この技術は、各バイトにおいて１６進数ＦＦを用いてレコードをファイル することを含む。次にデータは選択的にそのレコードに書込まれる。次にレコー ドはスキャンされ、非ＦＦデータの位置及び長さが判定される。非ＦＦデータは そのレコード内のデータ・フィールドに対応する。この技術は、コボル・プログ ラムに呼び出されたアセンブラ・ルーチンによって行われる。 コボルプログラムの２進数の長さ及びオフセット（変移）出力は、アセンブラ ・プログラム・ジェネレータへの入力である(ステップ１１６)。アセンブリ・プ ログラム・ジェネレータはコボル・プログラムの出力を用いて、変換ルーチンに 対するソース・コードを発生する。 アセンブリ・ソース・コードは次に、標準の開発ツールを用いてコンパイル（即 ち、アセンブル）及びリンクされる(ステップ１１８)。変換ルーチン・ジェネレ ータからのオブジェクト・コード出力は、実行可能な変換ルーチンである。 コボル・プログラム・ジェネレータをここでより詳細に説明する。コボル・プ ログラム・ジェネレータによって用いられるシンタックス構造を示すハイ・レベ ルのブロック図が、図１０に示されている。いったんシンタックス構造が定義さ れると、対応するコボル構造コードを発生するプロセスは当業者には簡単なもの である。図１０に示すシンタックス構造とコボル・ジェネレータ・ソース・コー ドとの間には１対１の関係が存在する。 データ・ファイルは、異なるフォーマットのレコード又は多種の情報を含むレ コードを含むことがある。データ変換定義３８は、多種の形式のレコード及び変 換に用いられる特定のロジックを識別するために必要な情報を含む。データ変換 定義３８はヘッダ定義１３２を適切に含み、それにボディ１４０が続く。 ヘッダ定義１３２は、ＦＩＬＥ−ＩＤ（ファイルＩＤ）構造１３４、デフォル ト・ステートメント１３６及び変換プロトコル１３８を適切に含む。２０００年 に関するアプリケーションの例示的な関係において、変換プロトコル１３８は、 最も低い日付を２０世紀であると推定し、それより前の全ての日付（より低い数 ）を２１世紀と推定するよう定義するウインドウ−年プロトコル・ステートメン トを適切に備える。 データ変換定義３８のボディ１４０は、単一形式レコード定義１４２又は複数 形式レコード定義１６２の何れかでよい。単一形式レコード１４２はレコード・ ステートメント１４４を適切に含み、それにデータ記述１４６が続く。データ記 述１４６は配列定義１４８でも、１つのデータ形式定義１５０（スター「＊」記 号で示される）でもよい。配列定義１４８は、配列ステートメント１５２、帰納 的データ記述１ ５４及び配列終了ステートメント１５６を適切に含む。データ形式定義１５０は 、データ項目、日付、（例えば、フォーマットＹＹＭＭＤＤの）形式名で適切に 開始し、それにこの形式データ名のリスト１６０が続く。所望される場合には、 ヘッダ定義１３２のステートメント１３８で指定されたプロトコルと異なる変換 プロトコルを、異なるデータ項目形式に対して用いることができる。そのような 場合には、データ形式プロトコル・ステートメント１６１、例えばウインドウ− 年プロトコルがデータ形式定義の一部として提供され得る。 複数形式レコード定義１６２は、（スター「＊」記号で示す）１又は複数のレ コード形式ステートメント１６３を適切に含む。各レコード形式ステートメント １６３は、レコード・ヘッダ・ステートメント１６４、帰納的ボディ１６６及び レコード形式終了ステートメント１６８を適切に含む。レコード・タイプ・ヘッ ダ１６４は、レコード形式ステートメント１６５又はデフォルト形式ステートメ ント１６７の何れかを適切に含む。複数形式レコード１６２は、多数のレコード 形式ステートメントと、この複数形式レコードに対する最後のレコード形式ヘッ ダとして１つのデフォルト形式ステートメントとを有し得る。 変換ルーチン・ジェネレータへの入力として用いられるデータ変換定義の例が 図１１に示されている。データ・アダプタを適用する最初のステップは、データ ・フィールドを定義することを必要とする。各データ・ファイルに対して、デー タ・ファイルのすべてのレコード形式が定義される。更に、レコード形式を識別 するために用いられるレコードのフィールド、及びレコード形式についてのそれ らに対応する値が定義される。レコード形式に対してのデータ・フィールド及び それらのフォーマットもまた定義される。これらの定義は、コボルのような組織 のプログラミング言語によって用いられるのと同じ変数名を受け入れる特別なシ ンタックスでデータ・アダプタに渡される。 図１０及び１１を参照すると、ＦＩＬＥ−ＩＤ１３４「ＢＡＮＫＩＮ」が、デ ータ・ファイル及びそれが発生した変数ルーチンへの参照 として用いられる。デフォルト・ステートメント１３６は、「ＤＥＦＡＵＬＴＳ 」の下で、データ・ファイルを変換し、古い出力フォーマッティングを使用する ためのものである。ウインドウ−年ステートメント１３８は２０年ウインドウを 示し、それは、日付００ないし２０が２０００ないし２０２０に、日付２１ない し９９が１９２１ないし１９９９に変換されることを意味する。「ＣＯＰＹ Ｂ ＡＮＫＩＮ」ステートメントは、「ＢＡＮＫＩＮ」データ・ファイルに関連する ブック又はヘッダ・ファイルをコピーするという内容を含むように機能する。レ コード形式ステートメント１６４「ＢＫ−ＲＥＣＯＲＤ−ＴＹＰＥ」はレコード 定義セクションに続く。次の４つのＴＹＰＥステートメント１４２は、「ＢＡＮ ＫＩＮ」データ・ファイルの多種の日付フィールドを記述する。最後のセタショ ンは、データ・フィールドが以前のＴＹＰＥステートメントの何れにも適合しな い場合に対する「ＤＥＦＡＵＬＴ−ＴＹＰＥ」ステートメントである。 日付フィールドを定義するためにこの技術を用いる利点は、その定義が簡単で 理解しやすいことである。更に、プログラミング言語データ名を用いて日付フィ ールドを指定するので、ユーザが手作業でフィールドの位置を計算することを不 要とし、それによって時間が節約でき、誤りが除かれる。更に、変換されたシス テムは「生き」ており、任意の時にレコード定義に変更を行うことができる。デ ータ・アダプタがこれらの変更を使用するために、データ定義ファイルのみが再 コンパイルされる必要があり、それらの変更は、変換ルーチン・ジェネレータに よって再構築された変換ルーチンにおいて自動的に反映される。 プログラム及びデータ・ファイルが変換された後でさえ、例えば、歴史的（例 えば、ア一カイブされた）ファイルにアクセスするために、変換能力を維持する ことがしばしば望ましい。図１２を参照すると、典型的なデータ・処理のシナリ オにおいて、変換ルーチン４６が変換ルーチン・ジェネレータ４４によって以前 に生成されており、例えば ２桁の年のフォーマット・データを有するもののような、未変換データ・ファイ ル３２のすべてのレコードを、変換済みみデータ・ファイル１７２に一度に変換 するために用いられている。いったん変換されると、未変換データ・ファイル１ ７０はもはや不要である。なぜなら、何れのプログラムもそのファイルにアクセ スする必要がないからである。いったん変換されると、変換済みプログラム１７ ４は、データ・アダプタ１０を必要とせずにデータ・ファイル１７２に直接アク セスする。変換プロセスは、データ変更定義においてＤＥＦＡＵＬＴステートメ ントを「ＣＯＮＶＥＲＴ ＮＯ」に変更することによってディスエーブルされる ことができる。この変更を行うことによって、データ・アダプタによるデータ・ ファイルへの処理を妨げ、プログラムは再コンパイルを全く必要とせずにレコー ドをファイルから直接に受け取る。もしプログラムが歴史的又はバックアップ・ ファイル１７６を用いて実行する必要があるならば、制御ステートメントをジョ ブ制御言語（ＪＣＬ）に付加することによって、データ・アダプタをその特定の 実行のためにトリガすることができる。 別の実施形態では、データ・アダプタは、第１のフォーマット及び第２のフォ ーマットを持つレコードを含むデータ・ファイルを選択的に変換することができ る。例えば、データがオンーザーフライで変換される場合などに、通常の動作で アクセスされるように、プログラムが変換済み及び未変換のデータの両方に処理 を行える能力を有することが望ましい。２０００年のアプリケーションとの関係 において、このようなファイルは２つの形式のレコード、即ち、オリジナルの２ 桁の年フォーマットの日付を有するレコードと、拡張された４桁の年フォーマッ トを有し、古い日付の代わりに記憶されていてレコード長が変更されていないレ コードとである。拡張日付情報は６バイト（１１桁）にパックされた１０進数と して適切に記憶される。パックされた６バイト・フォーマットに符号化及び圧縮 された４桁の年のフォーマット・データの８バイト表現を示すデータの図が、図 １３に示されて いる。データ・フィールド１８０は、オリジナルの未変換データの２桁の年のフ ォーマットである。データ・フィールド１８２は、オリジナル・データ・フィー ルドと同じ長さ（６バイト）のフィールドにパックされたフォーマットに記憶さ れたプログラムによって期待されるように、変換済みの４桁の年のデータに対応 している。即ち、データ・ファイルのフィールド長とレコード長とは変更されな いままでいる。データ・ファイルは両方の年のフォーマットを混合して含む。デ ータ・アダプタは、これら２タイプの内部的表現を用いてそれらを区別する。プ ログラムは常に拡張された４桁の年のフォーマット・データを受信し、それは、 日付が記憶される方法がプログラムに対して透過的であるからである。互換的に は、上述のように、データ・ファイル３２のレコードのすべてが一度に変換され てもよく、未変換データにアクセスする必要があるときのみ変換機能が活性化さ れるようにすればよい。 制限された数の実施の形態に関して本発明を説明したが、本発明の多数の変形 、変更及びその他の応用が可能なことが理解されるであろう。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＡＵ，ＢＲ，ＣＡ，Ｉ Ｌ，ＪＰ，ＫＰ，ＫＲ，ＭＸ 【要約の続き】 プログラムにおいては、データは、該プログラムが見る ことができる新しいフォーマットで規定される。未変換 状態のプログラム（エレメント２８）は、実際の未変換 データ・ファイル（エレメント３２）に対してアクセス し続ける。このようにして、本発明は、未変換データ・ ファイルの仮想的変換形態を備えた、変換済みプログラ ムを提供し、また、本発明は、所定のフォーマットのデ ータを、未変換状態のデータ・ファイルにレコードを書 込む前に、古いフォーマットのデータに変換する。

Claims (1)

1. 【特許請求の範囲】 １．第１のフォーマットを有するデータ・ソースからのデータをプログラムによ る使用のために第２のフォーマットへ変換するシステムにおいて、 ａ．前記第１のフォーマットをデータ変換定義にしたがって前記第２のフォー マットへマッピングするための少なくとも１つの変換ルーチンと、 ｂ．データ・アダプタであって、（ｉ）前記プログラムからの読出し要求をイ ンターセプトし、前記変換ルーチンを用いて、前記データ・ソースから読出され た前記第１のフォーマットのデータを前記第２のフォーマットを持つデータで置 換するよう、及び、（ii）前記プログラムからの書込み要求をインターセプトし 、前記変換ルーチンを用いて、前記データ・ソースに書かれたデータにおいて、 前記第１のフォーマットを有するデータで前記第２のフォーマットを有するデー タを置換するよう動作するデータ・アダプタと、 を具備するシステム。 ２．更に、データ変換ルーチンにしたがって、少なくとも１つの変換ルーチンを 生成するように動作する変換ルーチン・ジェネレータを備える、請求項１記載の システム。 ３．前記データ変換ルーチンが、フィールド長とデータをオリジナルのフォーマ ットから所望のフォーマットへ変換するためのオフセットとの指標を有する、請 求項１記載のシステム。 ４．前記オリジナルのデータ・フォーマットが第１のデータ・フォーマットであ り、前記所望のデータ・フォーマットが第２のデータ・フォーマットである、請 求項１記載のシステム。 ５．前記データ・フォーマットの一方が２桁の年のフォーマットであり、他方が ４桁の年のフォーマットである、請求項４記載のシステム。 ６．前記データ・フォーマットの一方が２桁の年のフォーマットであり、他方が ４桁のパックされた十進数の年のフォーマットである、請求項４記載のシステム 。 ７．前記データ・ソースがデータ・ファイルからなる、請求項１記載のシステム 。 ８．前記データ・ソースがコンピュータ・スクリーン・メモリからなる、請求項 １記載のシステム。 ９．前記データ変換定義が、 前記データ・ソースにおけるレコード形式と、 該レコード形式と識別フィールドにおける適切な値とを識別するのに用いられ るフィールドと、 前記システムによって仮想化されるべきデータ情報とそれに対応するフォーマ ットとに対応するフィールドと の指標からなる、請求項１又は２記載のシステム。 １０．前記変換ルーチン・ジェネレータが、 ａ．前記データ定義を用いて、前記データ・ソースにおける前記データ・フィ ールドの第２のフォーマットへのマッピングを決定するよう動作する第１のプロ グラムを生成する第１のプログラム・ジェネレータと、 ｂ．前記第１のプログラムの出力を処理して前記変換ルーチンを生成する第２ のプログラム・ジェネレータと、 を備える、請求項９記載のシステム。 １１．前記データ変換定義がヘッダとボディとを有し、該ヘッダがファイル構造 の指標を含み、前記ボディがレコード形式の指標を含み、前記レコード形式にお けるデータ・フィールドの指標が前記データ変換定義によって修正される、請求 項１記載のシステム。 １２．前記ヘッダが変換プロトコルを含む、請求項１１記載のシステム。 １３．前記ボディが、前記データ変換ルーチンによって修正されるべき前記レコ ード形式におけるデータ・フィールドの少なくとも１つ、即ち、変換プロトコル を更に含む、請求項１１又は１２記載のシステム。 １４．データ・ソースに含まれ且つ第１のフォーマットを有する任意のデータを 仮想化するためデータ変換定義を利用する方法であって、前記データ定義が、前 記データ・ソースにおけるレコード形式と、前記レコード形式を識別するのに用 いられる前記レコード形式におけるフィールド及びその適切な値と、仮想化され るべきデータに対応するデータ・フィールド及びそれに対応するフォーマットと の指標を含む方法において、 ａ．前記データ変換定義にしたがって、前記データ・ソースの前記レコード内 の第１のフォーマットのデータ・フィールドを第２のフォーマットへマッピング するために変換ルーチンを生成する段階と、 ｂ．前記プログラムからの読出し要求をインターセプトする段階と、 ｃ．前記変換ルーチンを用いて、前記データ・ソースから読出されたデータ項 目において、前記第２のフォーマットを有するデータで前記第１のフォーマット を有するデータを置換する段階と、 ｄ．前記プログラムからの書込み要求をインターセプトする段階と、 ｅ．前記変換ルーチンを用いて、前記データ・ソースに書込まれるべきデータ 項目において、前記第１のフォーマットを有するデータで前記第２のフォーマッ トを有するデータを置換する段階と、 を具備する方法。 １５．変換ルーチン・ジェネレータが、前記データ変換定義にしたがって複数の 変換ルーチンを発生する、請求項１４記載の方法。 １６．前記データ変換ルーチンが、フィールド長とオリジナルのフォーマットを 所望のフォーマットへデータを変換するためのオフセットとの指標を含む、請求 項１４記載の方法。 １７．前記第１のデータ・フォーマットが第１のデータ・フォーマットであり、 前記第２のデータ・フォーマットが第２のデータ・フォーマットである、請求項 １４記載の方法。 １８．前記データ・フォーマットの一方が２桁の年のフォーマットであり、他方 が４桁の年のフォーマットである、請求項１７記載の方法。 １９．前記データ・フォーマットの一方が２桁の年のフォーマットであり、他方 が４桁のパックされた十進数の年のフォーマットである、請求項１７記載の方法 。 ２０．前記データ・ソースがデータ・ファイルを含む、請求項１４記載の方法。 ２１．前記データ・ソースがコンピュータ・スクリーン・メモリを含む、請求項 １４記載の方法。 ２２．前記変換ルーチンを生成する段階が、 ａ．前記データ変換定義を用いてハイ・レベルなプログラムを生成する段階で あって、該ハイ・レベルなプログラムが前記データ・ソースにおける前記データ ・フィールドの前記第２のフォーマットへのマッピングを決定する段階と、 ｂ．前記ハイ・レベルなプログラムの出力を処理して前記変換ルーチンを生成 する段階と、 を具備する、請求項１４記載の方法。 ２３．前記データ変換定義が更に、前記データ変換ルーチンによって修正される べき前記データ・フィールドの少なくとも１つに対して変換プロトコルの指標を 有する、請求項１４記載の方法。