特許 5674974 圧縮データ処理プログラム、圧縮データ編集プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5674974

(24)【登録日】2015年1月9日

(45)【発行日】2015年2月25日

(54)【発明の名称】圧縮データ処理プログラム、圧縮データ編集プログラム

(51)【国際特許分類】

   G06F 12/00 20060101AFI20150205BHJP

【ＦＩ】

   G06F12/00 511A

【請求項の数】9

【全頁数】12

(21)【出願番号】特願2014-100197(P2014-100197)

(22)【出願日】2014年5月14日

(65)【公開番号】特開2015-35207(P2015-35207A)

(43)【公開日】2015年2月19日

【審査請求日】2014年5月14日

(31)【優先権主張番号】特願2013-142947(P2013-142947)

(32)【優先日】2013年7月8日

(33)【優先権主張国】JP

【早期審査対象出願】

(73)【特許権者】

【識別番号】591057256

【氏名又は名称】株式会社エクサ

(74)【代理人】

【識別番号】100091096

【弁理士】

【氏名又は名称】平木 祐輔

(74)【代理人】

【識別番号】100102576

【弁理士】

【氏名又は名称】渡辺 敏章

(74)【代理人】

【識別番号】100153903

【弁理士】

【氏名又は名称】吉川 明

(72)【発明者】

【氏名】阿部 俊雄

(72)【発明者】

【氏名】平澤 春樹

【審査官】 池田 聡史

(56)【参考文献】

【文献】 特開２００７−２８６６７２（ＪＰ，Ａ）

【文献】 特開平０８−３１４９５７（ＪＰ，Ａ）

【文献】 特表２０１０−５２２９１５（ＪＰ，Ａ）

【文献】 特開２００５−２１６２５１（ＪＰ，Ａ）

【文献】 特表２００１−５１１９２３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

ＪＳＴＰｌｕｓ（ＪＤｒｅａｍＩＩＩ）

(57)【特許請求の範囲】

【請求項1】

メインフレームにおいて圧縮された、索引を必要としないレコードシーケンシャルアクセス形式で記述されたレコードファイルを読み書きする処理をメインフレーム以外のコンピュータに実行させる圧縮データ処理プログラムであって、
前記レコードファイルは、
前記メインフレームが保持するレコード単位で記述されており、
各レコードにおいて、先行レコードと同じバイト列によって記述されている部分についてはその先行レコードのバイト列を指し示す代替符号に置き換えることによって圧縮されており、
同一レコード内において同じバイトが連続する部分についてはその繰り返し個数を示す繰返符号に置き換えることによって圧縮されており、
前記圧縮データ処理プログラムは、前記コンピュータに、
前記レコードファイルのレコード長またはレコード区切りを指定するパラメータ指定ステップ、
指定された前記レコード長またはレコード区切りにしたがって前記レコードファイルをレコード単位で読み込んで前記コンピュータ上のメモリに格納するレコード読込ステップ、
前記レコード読込ステップにおいて読み込んだ前記レコードのうち、前記代替符号によって記述されている部分については、その代替符号が指し示している先行レコードのバイト列が記述されているものとみなして読み込んだ前記レコードを置き換えて前記メモリに格納する代替符号処理ステップ、
前記レコード読込ステップにおいて読み込んだ前記レコードのうち、前記繰返符号によって記述されている部分については、その繰返符号が示している個数だけ同じバイトが連続しているものとみなして読み込んだ前記レコードを置き換えて前記メモリに格納する繰返符号処理ステップ、
前記レコード読込ステップにおいて読み込んだ前記レコードを更新すべき旨の指示を前記コンピュータが受け取った場合は、前記メモリ上に格納されている前記レコードを更新した上で、前記代替符号または前記繰返符号の少なくともいずれかを用いて更新後のレコードを前記メモリ上で圧縮するレコード更新ステップ、
前記メモリ上において更新された前記レコードを前記レコードファイルに対してレコード単位で書き込むレコード書込ステップ、
を実行させることを特徴とする圧縮データ処理プログラム。

【請求項2】

前記パラメータ指定ステップにおいて、前記コンピュータに、
前記レコードを、前記代替符号、前記繰返符号、または前記代替符号と前記繰返符号をともに用いて前記レコードファイルを処理するか否かを指定するステップを実行させ、
前記代替符号処理ステップおよび前記繰返符号処理ステップにおいて、前記コンピュータに、
前記パラメータ指定ステップにおける指定にしたがって、前記レコード読込ステップにおいて読み込んだ前記レコードを、前記代替符号、前記繰返符号、または前記代替符号と前記繰返符号をともに用いて置き換え、または前記レコードを置き換えずに前記メモリに格納させ、
前記レコード更新ステップにおいて、前記コンピュータに、
前記パラメータ指定ステップにおける指定にしたがって、前記レコード読込ステップにおいて読み込んだ前記レコードを、前記代替符号、前記繰返符号、または前記代替符号と前記繰返符号をともに用いて置き換え、または前記レコードを置き換えずに前記レコードを更新させる
ことを特徴とする請求項１記載の圧縮データ処理プログラム。

【請求項3】

前記代替符号処理ステップおよび前記繰返符号処理ステップにおいて、前記コンピュータに、
前記メモリ内に格納されている前記レコードの文字コードを、前記メインフレーム上で使用される文字コードから前記コンピュータ上で使用される文字コードに変換する文字コード変換を実施させる
ことを特徴とする請求項１または２記載の圧縮データ処理プログラム。

【請求項4】

前記コンピュータに、前記レコードファイル内のフィールド区切りを指定する命令を受け取るステップを実行させ、
前記代替符号処理ステップおよび前記繰返符号処理ステップにおいて、前記コンピュータに、
前記フィールド区切りを指定する命令にしたがって、前記レコードファイル内のフィールド毎に前記文字コード変換を実施させる
ことを特徴とする請求項３記載の圧縮データ処理プログラム。

【請求項5】

前記コンピュータに、前記レコードファイル内のフィールド区切りについての指定を変更する命令を受け取るステップを実行させ、
前記代替符号処理ステップおよび前記繰返符号処理ステップにおいて、前記コンピュータに、
前記フィールド区切りについての指定を変更する命令にしたがって、フィールド区切りを変更した上で、前記レコードファイル内のフィールド毎に前記文字コード変換を実施させる
ことを特徴とする請求項４記載の圧縮データ処理プログラム。

【請求項6】

前記レコード更新ステップにおいて、前記コンピュータに、
前記レコードの文字コードを、前記メインフレーム上で使用される文字コードから前記コンピュータ上で使用される文字コードに変換した後において、文字単位で同じ文字が連続する部分については、文字コード変換後の文字単位で前記繰返符号を用いて圧縮させる
ことを特徴とする請求項３から５のいずれか１項記載の圧縮データ処理プログラム。

【請求項7】

前記レコード書込ステップにおいて、前記コンピュータに、前記レコードファイルに対して書き込むデータを暗号化させる
ことを特徴とする請求項１から６のいずれか１項記載の圧縮データ処理プログラム。

【請求項8】

請求項１から７のいずれか１項記載の圧縮データ処理プログラムを用いて前記レコードファイルを編集する処理を前記コンピュータに実行させる圧縮データ編集プログラムであって、
前記圧縮データ編集プログラムは、前記コンピュータに、
前記圧縮データ処理プログラムを用いて前記レコードファイルを読み出して前記コンピュータが備えるディスプレイ上に画面表示するステップ、
前記圧縮データ処理プログラムを用いて前記レコードファイルに対して前記レコードを書き込むステップ、
を実行させることを特徴とする圧縮データ編集プログラム。

【請求項9】

前記圧縮データ編集プログラムは、前記コンピュータに、前記レコードファイルの文字コードを、前記メインフレームが用いる文字コードから前記コンピュータが用いる文字コードに変換させる
ことを特徴とする請求項８記載の圧縮データ編集プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、メインフレームにおいて圧縮されたレコードファイルをオープン環境において読み書きする技術に関する。

【背景技術】

【0002】

近年コンピュータが取り扱うデータ量は増大の一途をたどっており、データ伝送負荷などを軽減する観点から、データ圧縮技術が用いられている。データ圧縮技術を利用する場合、まずデータ送信元のコンピュータが送信しようとするデータを圧縮し、データ送信先のコンピュータが圧縮されたデータを受信して伸長する。これによりデータ伝送量を抑制することができる反面、送信元コンピュータにおけるデータ圧縮処理の負荷と送信先コンピュータにおけるデータ伸長処理の負荷が増大する。

【0003】

下記特許文献１は、データ圧縮技術に関する技術を記載している。同文献において、文字コード体系が異なるコンピュータ間で圧縮データを送受信する際に、受信側コンピュータは受信した圧縮データに対して文字コード変換を実施し、その後に圧縮データを復元している。これにより、いったん圧縮データを伸長してから文字コードを変換する場合と比較して、処理負荷を軽減することを図っている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００７−２８６６７２号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

上記特許文献１記載の技術においては、送信側コンピュータ１０は圧縮データを受信側コンピュータ２０に対して送信し、受信側コンピュータ２０が復元した圧縮データはデータベース３０にいったん格納され、その後に使用可能となる。すなわち、データベース３０に格納されているデータは伸長後のデータである。したがって、データベース３０が格納しているデータを改めて圧縮するためには、再度圧縮処理を実施する必要がある。

【0006】

一般にデータ圧縮処理は処理負荷が高いため、特許文献１記載の技術により文字コード変換に係る処理負荷を軽減することができたとしても、データ圧縮処理および伸長処理によってコンピュータには高い処理負荷がかかる。

【0007】

本発明は、上記のような課題に鑑みてなされたものであり、圧縮データを圧縮したままで読み書きする技術を提供することを目的とする。

【課題を解決するための手段】

【0008】

本発明に係る圧縮データ処理プログラムは、レコード単位で記述された圧縮レコードファイルのうち、先行レコードの内容を示す代替符号を用いて圧縮されている部分についてはその先行レコードによって記述されているものとみなしてレコード単位で読み込み、繰返符号を用いて圧縮されている部分についてはその繰返個数だけ同じバイト列が連続しているものとみなしてレコード単位で読み込む。レコードファイルを更新する場合は、レコード毎に更新を反映し、代替符号と繰返符号を用いてレコードを圧縮してレコードファイルに書き込む。

【発明の効果】

【0009】

本発明に係る圧縮データ処理プログラムによれば、圧縮レコードファイルをレコード単位で読み込み、圧縮部分を解釈した上で、レコード単位で再圧縮してレコードファイルに書き込むので、圧縮レコードファイル全体を伸長することなく、圧縮したままで読み書きすることができる。

【図面の簡単な説明】

【0010】

【図1】実施形態１に係る圧縮データ処理プログラムを実行するコンピュータ１００およびその周辺構成を示す図である。

【図2】圧縮レコードファイル１４１のフォーマットを例示する図である。

【図3】アプリケーション１２０をＣＯＢＯＬ言語によって記述した場合におけるサンプルコードの抜粋を示す図である。

【図4】アプリケーション１２０をＣ言語によって記述した場合におけるサンプルコードの抜粋を示す図である。

【図5】アプリケーション１２０内において記述することができる、圧縮レコードファイル１４１のフィールド定義を例示する図である。

【図6】実施形態５に係るアプリケーション１２０の画面イメージを示す図である。

【発明を実施するための形態】

【0011】

＜実施の形態１＞
図１は、本発明の実施形態１に係る圧縮データ処理プログラムを実行するコンピュータ１００およびその周辺構成を示す図である。コンピュータ１００は、メインフレーム２００が圧縮した圧縮レコードファイル１４１をメインフレーム２００から受け取り、記憶部１４０に格納する。

【0012】

コンピュータ１００はＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１０を備え、ＣＰＵ１１０はアプリケーション１２０と圧縮データ処理プログラム１３０を実行する。これらの詳細については後述する。以下では便宜上、各プログラムを動作主体として説明する場合があるが、実際にこれらプログラムを実行するのはＣＰＵ１１０であることを付言しておく。メモリ１５０は、ＣＰＵ１１０が一時的に使用するデータを格納する記憶装置である。

【0013】

図２は、圧縮レコードファイル１４１のフォーマットを例示する図である。比較のため図２（ａ）に圧縮前のレコードファイルのフォーマットを示す。図２（ｂ）は図２（ａ）に示すレコードファイルを圧縮した後のフォーマットを示す。ここでは３つのフィールドを有する固定長３８バイトの７レコードを例示した。

【0014】

図２（ｂ）１行目は圧縮レコードファイルであることを示すヘッダ部分である。図２（ｂ）各レコードの先頭部分［ＬＬＺＺ］は、各レコードが圧縮されていることを示す。以下その他の部分について説明する。

【0015】

図２（ａ）に示す圧縮前のレコードファイルにおいて、各レコード内のＮｏ．フィールドは数字０およびスペース符号「 」が繰り返し用いられている。メインフレーム２００は、この繰り返し部分を［繰○］で表される繰返符号に置き換えることにより、当該繰り返し部分を圧縮する。○は繰り返すバイト数を表す数値である。

【0016】

図２（ｂ）３行目に記載している［繰６］は、その直後に記載されている数値「０」を６回繰り返すことを示している。同様に図２（ｂ）の２行目に記載している［繰１６］は、その直後に記載されているスペース「 」を１６回繰り返すことを示している。

【0017】

図２（ｂ）に示す符号［直○］は、上記繰返符号および以下に説明する代替符号によって圧縮しないユニークバイト列を表す符号である。例えば図２（ｂ）８行目に記載している［直４］は、その直後に４バイト分の当該レコード固有のバイト列「３３０２」が記載されていることを示す。メインフレーム２００は、各レコード固有のバイト列については同符号を用いて圧縮せずに記述する。

【0018】

図２（ａ）に示す圧縮前のレコードファイルにおいて、文字列「江草」「新」「郎」「技野」「１９８７１００１」「０１」「２００２０１０１」「２０１００４０１」は、それぞれ直前の先行レコードと同一である。メインフレーム２００は、この同一部分を［同○］で表される代替符号に置き換えることにより、当該同一部分を圧縮する。○は先行レコードと同一であるバイト数を表す数値である。

【0019】

図２（ｂ）２行目において、［直３］によって３バイト分の文字列が指定され、その後に［繰７］によって７個のスペースが指定されている。したがって、２つ目のフィールド「Ｎａｍｅ」の前までに、１０バイト分の文字列が存在することになる。

【0020】

図２（ｂ）３行目において、［繰６］によって６個の数値「０」が指定され、さらに［直１］によって１バイト分の文字列「１」が指定されている。Ｎａｍｅフィールドの前までには１０バイト分の文字列が存在するので、文字列「１」の後には３個のスペースが配置されることになるが、この部分のバイト列は直前の先行レコードと同じである。したがって、［同３］により、先行レコードの対応位置から開始して３バイト分は同じバイト列であることを示している。

【0021】

同様に図２（ｂ）４行目において、文字列「花子」の後は先行レコードと同じであるため、［同１８］によって当該レコードの残り１８バイトが先行レコードと同じであることを示している。

【0022】

次に、コンピュータ１００において圧縮レコードファイル１４１を読み書きする処理について説明する。アプリケーション１２０の開発者は、アプリケーション１２０内の処理において圧縮レコードファイル１４１を圧縮したまま読み書きする場合、アプリケーション１２０の内部で圧縮データ処理プログラム１３０を呼び出す処理を記述する。

【0023】

図３は、アプリケーション１２０をＣＯＢＯＬ言語によって記述した場合におけるサンプルコードの抜粋を示す図である。比較のため図３（ａ）において、圧縮データ処理プログラム１３０を使用しない従来のコード例を示した。図３（ｂ）は圧縮データ処理プログラム１３０を使用する場合におけるコード例を示す。

【0024】

図３（ｂ）の先頭部分において、圧縮レコードファイル１４１の属性を定義する。例えばレコード長、繰返符号［繰○］を使用するか否かの指定（横圧縮指定）、代替符号［同○］を使用するか否かの指定（縦圧縮指定）、レコード編成方式などを指定する。レコード編成方式としては、固定データ長（Ｆ）、可変データ長（Ｖ）、テキストデータ（Ｔ）から選択することができるが、ここでは図２で説明した固定データ長（Ｆ）を指定したものと仮定する。

【0025】

圧縮データ処理プログラム１３０は、ＣＯＢＯＬ言語から呼び出すことができるモジュールとして実装されている。圧縮データ処理プログラム１３０は、ＣＯＢＯＬ言語におけるファイルＯＰＥＮ、ファイルＲＥＡＤ、ファイルＷＲＩＴＥ、ファイルＣＬＯＳＥそれぞれのファイル命令に対応するモジュールを提供しており、各命令に対応するモジュールを呼び出すことにより、各命令に相当する処理を圧縮データ処理プログラム１３０に実行させることができる。圧縮データ処理プログラム１３０が圧縮レコードファイル１４１に対してアクセスする手順は、例えばシーケンシャルアクセスでもよいしランダムアクセスでもよい。

【0026】

圧縮データ処理プログラム１３０は、指定されたレコード長にしたがって、圧縮レコードファイル１４１をレコード単位で読み込む。図２に示した例においては、図２（ｂ）の各行に記載されているレコードを１つずつ読み込む。ただし必ずしも全レコードを一括して読み込む必要はなく、アプリケーション１２０内において読み込むよう指定されているレコードのみを読み込めばよい。

【0027】

アプリケーション１２０が、圧縮レコードファイル１４１内のレコードを読み込む処理を記述している場合（ＲＥＡＤ命令が記述されている場合）は、圧縮データ処理プログラム１３０は、圧縮レコードファイル１４１の各レコードを読み込み、図２において説明した規則にしたがって各レコードを解釈し、その結果をコンピュータ１００が備えているメモリ１５０に格納する。例えば圧縮レコードファイル１４１内において代替符号が指定され、先行レコードを未だ読み込んでいない場合などは、必要に応じて先行レコードを読み込むようにしてもよい。アプリケーション１２０は、メモリ１５０に格納されているレコードを読み取ることにより、圧縮前のレコードを取得することができる。

【0028】

アプリケーション１２０が、圧縮レコードファイル１４１内のレコードを更新する処理を記述している場合（ＷＲＩＴＥ命令が記述されている場合）は、圧縮データ処理プログラム１３０は当該レコードを上記手順にしたがって読み取ったうえでメモリ１５０に格納し、メモリ１５０上でアプリケーション１２０からの指示にしたがって当該レコードを更新する。圧縮データ処理プログラム１３０は、メモリ１５０上で更新されたレコードを図２で説明した規則にしたがって圧縮する。圧縮データ処理プログラム１３０は、遅くともアプリケーション１２０が圧縮レコードファイル１４１を閉じる前（ＣＬＯＳＥ命令を発行する前）に、メモリ１５０上で更新および圧縮されたレコードを圧縮レコードファイル１４１に対して書き込む。

【0029】

なお、アプリケーション１２０の先頭部分において、縦圧縮指定、横圧縮指定、またはこれら双方が指定されていない場合は、圧縮データ処理プログラム１３０は各指定にしたがって、代替符号、繰返符号、またはこれら双方を使用せずに圧縮レコードファイル１４１を読み書きする。したがってアプリケーション１２０および圧縮データ処理プログラム１３０は、図２で説明した規則にしたがって圧縮されていない通常のレコードファイルを取り扱うこともできる。

【0030】

図４は、アプリケーション１２０をＣ言語によって記述した場合におけるサンプルコードの抜粋を示す図である。アプリケーション１２０をＣ言語によって記述する場合、圧縮データ処理プログラム１３０はＣ言語の関数としてその機能を提供する。具体的には、アプリケーション１２０をコンパイル・リンクするときにアプリケーション１２０へ組み込むリンクライブラリなどの形態で、圧縮データ処理プログラム１３０の機能を提供することができる。

【0031】

ＣＯＢＯＬ言語、Ｃ言語いずれの場合においても、概ね同様のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）によって、圧縮データ処理プログラム１３０の機能を呼び出すことができるように構成されている。

【0032】

上記例においては圧縮レコードファイル１４１が固定長レコードによって構成されていることを説明したが、可変長レコードである場合は、例えば各レコードの先頭においてレコード長を示すヘッダを付与しておくとよい。これにより圧縮データ処理プログラム１３０は、圧縮レコードファイル１４１を上記と同様にレコード単位で読み書きすることができる。圧縮レコードファイル１４１がテキストファイルである場合は、例えば１行を１レコードとみなすことにより、可変長レコードファイルと同様に処理することができる。この場合は、改行コードをレコード区切りとして自動的に指定するようにすればよい。

【0033】

上記例においては圧縮レコードファイル１４１が文字列によって記述されているデータ例を説明したが、バイナリ列によって記述されている場合であっても、図２と同様の処理規則を適用することができる。ただしバイナリ列内に［同○］［繰○］のような文字列が突然登場すると違和感が生じる可能性もあるので、その場合はこれら文字列による符号に代えてバイト列によって表した代替符号と繰返符号を用いることもできる。圧縮レコードファイル１４１が文字列によって記述されている場合においても同様である。

【0034】

＜実施の形態１：まとめ＞
以上のように、本実施形態１に係る圧縮データ処理プログラム１３０は、圧縮レコードファイル１４１をレコード単位で読み込み、代替符号または繰返符号によって圧縮されている部分についてはその符号にしたがって圧縮部分を解釈した上でメモリ１５０にその結果を格納する。アプリケーション１２０は、メモリ１５０上に格納されている伸長後のデータを読み込みまたは更新し、圧縮データ処理プログラム１３０は更新後のデータを圧縮レコードファイル１４１に対して書き込む。これによりアプリケーション１２０は、圧縮レコードファイル１４１を圧縮したままで読み書きすることができる。

【0035】

＜実施の形態２＞
実施形態１〜２においては、メインフレーム２００が作成した圧縮レコードファイル１４１をコンピュータ１００上で読み書きすることを説明した。メインフレーム２００とコンピュータ１００が同一の文字コードを用いている場合は特段の処理は必要ないが、例えばメインフレーム２００がＥＢＣＤＩＣコードを使用し、コンピュータ１００がそれ以外の文字コード（例えばＡＳＣＩＩ、ＳＪＩＳ、ＥＵＣなど）を使用している場合、文字コードを変換する必要がある。そこで本発明の実施形態２では、メインフレーム２００とコンピュータ１００の間で文字コードを変換する動作例について説明する。

【0036】

本実施形態２において、圧縮データ処理プログラム１３０は、圧縮レコードファイル１４１を読み込んだ後、メインフレーム２００上で使用されている文字コードをコンピュータ１００上で使用されている文字コードに変換した上で、メモリ１５０に格納する。これにより、コンピュータ１００上で更新された圧縮レコードファイル１４１は、コンピュータ１００上で使用される文字コードを用いて記述されることになる。

【0037】

図５は、アプリケーション１２０内において記述することができる、圧縮レコードファイル１４１のフィールド定義を例示する図である。１バイト文字と２バイト文字が混在しているレコードに対して文字コード変換を実施するためには、レコード内の各フィールドの区切りを明確に定義することが望ましい。そこでアプリケーション１２０の開発者は、図５（ａ）に例示するようなフィールド定義をアプリケーション１２０内に記述し、圧縮データ処理プログラム１３０を呼び出す際にそのフィールド定義を引き渡してその定義にしたがって文字コード変換を実施させることができる。

【0038】

図５（ａ）の１行目は、フィールド「ＩＤ−ＮＯ」が各レコードの１バイト目から開始し、フィールド長７バイトのＡＳＣＩＩ文字列であることを示している。図５（ａ）の３行目は、フィールド「ＮＡＭＥ−Ｋ」が各レコードの１１バイト目から開始し、フィールド長２０バイトの漢字文字列であることを示している。

【0039】

図５（ｂ）は、同一のレコードファイル内で複数のフィールド定義を用いる場合において、所定のバイト列が見つかった時点でフィールド定義を切り替えるためのコード例を示している。同図に示すコード例を用いると、１６進数のバイト列「Ｄ５７７４Ｂ４０４０４０４０」が出現した時点において、フィールド定義を｛｝内のものに切り替える。すなわち以後のレコードは、各レコードの１バイト目から開始し、フィールド長２５０バイトのＡＳＣＩＩ文字列であるフィールド「ＨＤＲ−ＲＥＣ」として処理される。

【0040】

＜実施の形態２：まとめ＞
以上のように、本実施形態２に係る圧縮データ処理プログラム１３０は、アプリケーション１２０が指定するフィールド定義にしたがって、圧縮レコードファイル１４１内の各レコードの各フィールドを識別し、各フィールドに対して文字コード変換を実施する。これにより、メインフレーム２００とコンピュータ１００が異なる文字コードを用いる場合においても、コンピュータ１００のユーザが圧縮レコードファイル１４１内の各レコードを容易に視認することができる。

【0041】

＜実施の形態３＞
実施形態１〜２においては、代替符号と繰返符号を用いてレコードファイルを圧縮することを説明した。この手法は、データ圧縮においては有効であるが、各レコード固有の部分は圧縮されず元のバイト列がそのまま残っているため、例えばテキストエディタなどを用いて圧縮レコードファイル１４１を閲覧すると、その主要部分については閲覧できてしまう可能性がある。

【0042】

そこで圧縮データ処理プログラム１３０は、メモリ１５０上に格納している各レコードを圧縮レコードファイル１４１に対して書き込む際に、各レコードを適当な暗号化手法によって暗号化することもできる。これにより圧縮されていない部分も容易に閲覧することはできなくなるので、セキュリティの観点から望ましい。

【0043】

さらに、図２で説明した例においては先行レコードと同一の部分および繰り返し部分をそれぞれ代替符号と繰返符号によって置き換えることにより圧縮することを説明した。しかし、多バイト文字コードを用いて記述された同じ文字が連続している場合は、１バイト単位で連続性を判定すると、同じ文字として認識されない場合がある。例えばＳＪＩＳコードにおける２バイトスペース文字は文字コード「０ｘ８１４０」で表されるが、仮にこの２バイトスペース文字が複数連続していたとしても、１バイト単位で文字の連続性を判定すると、同じ文字の繰り返しとみなされない。

【0044】

そこで圧縮データ処理プログラム１３０は、多バイト文字コードを用いて記述されている部分については、文字単位で連続性を判定し、連続している部分については実施形態１で説明した繰返符号を用いて圧縮する。これにより、１バイト単位で連続性を判定すると連続しているとみなされない文字列についても、実施形態１と同様の規則にしたがって圧縮することができる。

【0045】

上記多バイト文字列の圧縮手順は、文字コードを変換することによってバイト単位の連続性が消失する場合において特に有効である。例えばメインフレーム２００においてよく用いられているＥＢＣＤＩＣコードにおいては、２バイトスペース文字は文字コード「０ｘ４０４０」「０ｘＡ１Ａ１」などを用いて表されることが多いため、１バイト単位で連続性を判定しても連続文字列としてみなされる。しかしこれを文字コード変換してＳＪＩＳコードに置き換えると上述のように「０ｘ８１４０」となり、１バイト単位で連続性を判定すると連続文字列とはみなされない。このような場合には、上記多バイト文字列の圧縮手順が有用である。

【0046】

＜実施の形態４＞
実施形態１〜３においては、メインフレーム２００が圧縮した圧縮レコードファイル１４１をコンピュータ１００上で読み書きすることを説明した。これは特に、コンピュータ１００がメインフレーム以外のコンピュータ（例えばＷｉｎｄｏｗｓ（登録商標）コンピュータなどのオープン環境）である場合において有効である。

【0047】

すなわち、オープン環境においてはメインフレーム上のレコードファイルを効率よく処理するアプリケーションが提供されていない場合があるので、本発明に係る圧縮データ処理プログラム１３０を用いてこれを処理することにより、オープン環境においてもメインフレーム環境と同様に効率よくこれらレコードファイルを処理することができる。例えば実施形態３で説明したように、メインフレーム２００上では特段意識しなくとも圧縮される文字列がオープン環境上では圧縮されない場合があるので、このようなレコードファイルを効率よく処理することができる。

【0048】

＜実施の形態５＞
図６は、本発明の実施形態５に係るアプリケーション１２０の画面イメージを示す図である。本実施形態５において、アプリケーション１２０は、圧縮レコードファイル１４１を画面表示し、または画面上で編集して更新後の内容を圧縮レコードファイル１４１へ反映する、編集アプリケーションとして構成されている。アプリケーション１２０は、コンピュータ１００が備えるディスプレイ上に図６のような編集画面を表示し、ユーザは同画面を用いて圧縮レコードファイル１４１を編集する。

【0049】

アプリケーション１２０は、実施形態１〜４で説明したように内部的に圧縮データ処理プログラム１３０を用いるので、圧縮レコードファイル１４１を圧縮したままで読み書きすることができる。また、圧縮レコードファイル１４１を単なるバイナリデータとしてではなくレコード単位に記述されたデータファイルとして編集することができる。

【0050】

圧縮レコードファイル１４１は、メインフレーム２００が作成したデータファイルであるため、メインフレーム２００が使用する文字コードを用いて記述されているのが通常である。そこでアプリケーション１２０は、圧縮レコードファイル１４１の文字コードを、コンピュータ１００のＯＳ（オペレーティングシステム）が使用する文字コードに変換した上で、画面上に表示してもよい。圧縮レコードファイル１４１を更新する場合は、メインフレーム２００が使用する文字コードを用いて全体を上書きしてもよいし、コンピュータ１００のＯＳが使用する文字コードを用いて全体を上書きしてもよい。同様の処理をアプリケーション１２０に代えて圧縮データ処理プログラム１３０が実施してもよい。

【0051】

以上の実施形態１〜５において、アプリケーション１２０と圧縮データ処理プログラム１３０は、一体的に構成することもできるし、これらを別モジュールとして構成した上でアプリケーション１２０から圧縮データ処理プログラム１３０を呼び出すように構成してもよい。前者の場合は、例えば圧縮データ処理プログラム１３０を静的リンクライブラリとして構成することができる。後者の場合は、例えば圧縮データ処理プログラム１３０を動的リンクライブラリとして構成することができる。

【符号の説明】

【0052】

１００：コンピュータ、１１０：ＣＰＵ、１２０：アプリケーション、１３０：圧縮データ処理プログラム、１４０：記憶部、１４１：圧縮レコードファイル、２００：メインフレーム。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】