特許 6491438 マイグレーション支援装置

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

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

(11)【特許番号】6491438

(24)【登録日】2019年3月8日

(45)【発行日】2019年3月27日

(54)【発明の名称】マイグレーション支援装置

(51)【国際特許分類】

   G06F 8/51 20180101AFI20190318BHJP

   G06F 8/76 20180101ALI20190318BHJP

   G06F 17/22 20060101ALI20190318BHJP

【ＦＩ】

   G06F8/51

   G06F8/76

   G06F17/22 617

【請求項の数】2

【全頁数】13

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

(22)【出願日】2014年8月29日

(65)【公開番号】特開2016-51235(P2016-51235A)

(43)【公開日】2016年4月11日

【審査請求日】2017年8月18日

(73)【特許権者】

【識別番号】596127554

【氏名又は名称】株式会社日立社会情報サービス

(74)【代理人】

【識別番号】110001807

【氏名又は名称】特許業務法人磯野国際特許商標事務所

(72)【発明者】

【氏名】坂井 孝介

(72)【発明者】

【氏名】城代 佳範

(72)【発明者】

【氏名】粟河 厚志

【審査官】 坂庭 剛史

(56)【参考文献】

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

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

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

【文献】 安室浩和，ＡＰＩから知るＷｉｎｄｏｗｓの仕組み：第１６回 Ｕｎｉｃｏｄｅを利用して複数の言語に対応する，日経ソフトウエア，日本，日経ＢＰ社，２００３年 ９月２４日，第６巻，第１０号（通巻６５号），ｐ．１６０−１６８，ISSN 1347-4685

【文献】 ＣＯＢＯＬ２００２ユーザーズガイド 解説・手引書，日本，株式会社日立製作所，２００４年 ９月，第３版（3020-3-D42-10），ｐ．６８６−６８７

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

Ｇ０６Ｆ ８／５１

Ｇ０６Ｆ ８／７６

Ｇ０６Ｆ １７／２２

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

【請求項1】

第１のコンピュータから第２のコンピュータへのマイグレーションを支援するマイグレーション支援装置であって、
前記第１のコンピュータが有する第１の文書ファイル中の文字データに割り当てられた第１の文字コードを、記憶部が有する文字コード変換表を参照して、前記第２のコンピュータが有する第２の文書ファイル中の文字データに割り当てられた第２の文字コードに変換する文字コード変換部と、
前記第１のコンピュータが有する、前記第１の文書ファイルを処理するための第１のプログラムを、前記第２のコンピュータが有する、前記第２の文書ファイルを処理するための第２のプログラムに変換するプログラム変換部と、
前記第２の文字コードが割り当てられた文字データを前記第２のプログラムに読み込ませることで、前記読み込まれた文字データについて、前記第２のプログラムが指定するメモリ上のエリアの数を、前記文字データに割り当てられていた第１の文字コードを表現するバイト列のバイト数と同じに定める交換情報を生成する交換情報生成部と、
前記交換情報により定められた数からなる前記エリアに、前記読み込まれた文字データに割り当てられた１つの前記第２の文字コードを格納するエリア格納部と、を備える、
ことを特徴とするマイグレーション支援装置。

【請求項2】

前記文字データが半角英数文字、半角記号、または半角カナ文字の文字データである場合には、前記交換情報により定められた、前記エリアの数は１であり、
前記文字データが全角文字の文字データである場合には、前記交換情報により定められた、前記エリアの数は２である、
ことを特徴とする請求項１に記載のマイグレーション支援装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、いわゆるレガシーマイグレーション（以下、単に、「マイグレーション」と称する場合がある）の技術に関し、特に、文字コード体系の切り替えを伴うマイグレーションの技術に関する。

【背景技術】

【0002】

近年、これまで現行コンピュータで稼働してきた業務システム（レガシーシステム）を新規コンピュータに移行させるためのマイグレーションサービスを望む企業、自治体などが多い。マイグレーションの形態としては、例えば、汎用系のホストコンピュータ（または、オフコン）から、ＷＩＮＤＯＷＳ（登録商標）、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）などのＯＳ（Operating System）が稼働するオープン系のサーバコンピュータへのマイグレーション、という形態がある。なお、マイグレーションに関する技術は、数多く公開されており、例えば、特許文献１に公開されている。

【0003】

しかし、所定の文字コード体系（例：ＥＢＣＤＩＫ（Extended Binary Coded Decimal Interchange Kana Code）、ＫＥＩＳ（Kanji processing Extended Information System）、ＪＩＳ８、ＳＪＩＳ（Shift JIS）。以下、「旧文字コード体系」と称する場合がある）でデータを取り扱っているホストコンピュータが、その文字コード体系にて標準では登録されていない外字を数多く登録していた場合（ホストコンピュータの外字エリアは9024文字分）がある。この場合、小さな外字エリアしか提供できないＯＳ（ＷＩＮＤＯＷＳが提供する外字エリアは1880文字分）が稼働するサーバコンピュータへのマイグレーションは実現できない。

【0004】

また、近年では、使用できる文字数が限られている現行コンピュータに対して、新規コンピュータでは、使用できる文字数を増やしてほしい、という要望が多くの企業、自治体などから出されている。具体的には、国際化に伴い、漢字だけでなく簡体字やハングル文字などの外国の文字も表現できるようにして欲しい、個人を正しく表記するために旧漢字も表現できるようにして欲しい、などの要望がある。

【0005】

そこで、これらの事情に対する対応策として、ＵＴＦ（Unicode Transformation Format）−８、ＵＴＦ−１６など、といったより大規模な文字コード体系を、新文字コード体系として取り扱う新規コンピュータへのマイグレーションが考えられる。

【0006】

マイグレーションでは、主に、（１）業務システム上の既存のデータの移行、および、（２）そのようなデータにアクセスする、業務システム上で動作する既存のプログラムの移行、がなされる。よって、移行する既存の文字データは、新文字コード体系に対応するように文字コードを変換する必要がある。また、既存のプログラム（例えば、ＣＯＢＯＬ言語で記述されたプログラム）は、文字コードを変換した文字データを読み込むことができるように変換する必要がある。

【0007】

しかし、従来技術では、文字データに割り当てられた文字コードの変換と比較して、プログラムの変換は、非常に煩雑かつ困難である、という問題点があった。この問題点は、旧文字コード体系と新文字コード体系との組み合わせによっては、同じ文字であっても、その文字を表現するバイト列のバイト数が両文字コード体系間で相違すること、既存のプログラムが文字のバイト列を格納するために指定するメモリ上のエリアの長さが固定長であること、に起因する。プログラムの変換の際は、これらの事情を考慮してプログラムの記述内容を適宜修正する必要がある（修正をしないと、文字データの溢れ、位置ずれなどが生じ、プログラムは、目的とする文字データとは異なる文字データを取得してしまう）。しかし、エリアに格納される文字のバイト列によって修正パターンが異なるため、修正は非常に煩雑かつ困難な作業となる。特許文献１の技術を含めた従来技術において、このような作業に対する改善策は何ら存在しない。

【先行技術文献】

【特許文献】

【0008】

【特許文献1】特許第４４０５５７１号公報

【発明の概要】

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

【0009】

そこで、本発明は、このような事情に鑑みてなされたものであり、異なる文字コード体系への切り替えが伴うマイグレーションにおいて、マイグレーションの対象となるプログラムの変換を容易にすることを目的とする。

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

【0010】

前記目的を達成するために、本発明は、
第１のコンピュータから第２のコンピュータへのマイグレーションを支援するマイグレーション支援装置であって、
前記第１のコンピュータが有する第１の文書ファイル中の文字データに割り当てられた第１の文字コードを、記憶部が有する文字コード変換表を参照して、前記第２のコンピュータが有する第２の文書ファイル中の文字データに割り当てられた第２の文字コードに変換する文字コード変換部と、
前記第１のコンピュータが有する、前記第１の文書ファイルを処理するための第１のプログラムを、前記第２のコンピュータが有する、前記第２の文書ファイルを処理するための第２のプログラムに変換するプログラム変換部と、
前記第２の文字コードが割り当てられた文字データを前記第２のプログラムに読み込ませることで、前記読み込まれた文字データについて、前記第２のプログラムが指定するメモリ上のエリアの数を、前記文字データに割り当てられていた第１の文字コードを表現するバイト列のバイト数と同じに定める交換情報を生成する交換情報生成部と、
前記交換情報により定められた数からなる前記エリアに、前記読み込まれた文字データに割り当てられた１つの前記第２の文字コードを格納するエリア格納部と、を備える、
ことを特徴とする。
その他の手段については後記する。

【0011】

レガシーとしての第１のプログラムは、文字データのサイズ（項目の長さ）をバイト列のバイト数として扱い、バイト数と同じ数のエリアをメモリ上に指定して文字データのバイト列を格納していた。つまり、従来のように、第１のプログラムは、メモリ上に指定するエリアを、１バイトのデータを格納するためのエリアとし、バイト数単位で文字データを処理していた。また、第１のプログラムのソースコードの記述内容はその処理に対応したものとなっていた。
これに対し、変換した第２のプログラムは、文字コードの変換によって、１文字を表現するバイト列のバイト数が異なった文字データを処理する際、交換情報を参照することで、第１のプログラムが使用したエリアの数と同じ数のエリアを使用することができる。つまり、第２のプログラムは、メモリ上に指定するエリアを、１文字のデータを格納するための１または複数のエリアとし、文字数単位で文字データを処理することができる。よって、第２のプログラムで組まれたロジックを第１のプログラムで組まれたロジックと同じにすることができ、第２のプログラムのソースコードの記述内容のうち、ロジックに関する部分（例えば、ＣＯＢＯＬ言語における桁数）を修正する必要はない。
したがって、異なる文字コード体系への切り替えが伴うマイグレーションにおいて、マイグレーションの対象となるプログラムの変換を容易にすることができる。

【発明の効果】

【0012】

本発明によれば、異なる文字コード体系への切り替えが伴うマイグレーションにおいて、マイグレーションの対象となるプログラムの変換を容易にすることができる。

【図面の簡単な説明】

【0013】

【図1】本実施形態のマイグレーション支援装置の機能構成を示す図である。

【図2】交換情報のデータ構造を示す図である。

【図3】本実施形態のマイグレーション支援装置の処理を示すフローチャートである。

【図4】比較例として、ＥＢＣＤＩＫ＋ＫＥＩＳコードからＵＴＦ−８コードへの変換に合わせてＣＯＢＯＬ言語のプログラムを変換する際、ソースコードの記述内容の修正を必要とすることを説明するための図である。

【図5】本実施例として、ＥＢＣＤＩＫ＋ＫＥＩＳコードからＵＴＦ−８コードへの変換に合わせてＣＯＢＯＬ言語のプログラムを変換する際、ソースコードの記述内容の修正を不要とすることを説明するための図である。

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

【0014】

図１に示すように、作業用ＰＣ１は、現行コンピュータ２から新規コンピュータ３へのマイグレーションを担当する作業員が操作するコンピュータであって、本実施形態のマイグレーション支援装置である。作業用ＰＣ１は、現行コンピュータ２から入力ファイル２１および入力プログラム２２を取得し、所定の変換（詳細は後記する）をした後、出力ファイル３１および出力プログラム３２として新規コンピュータ３に出力する。

【0015】

現行コンピュータ２（第１のコンピュータ）は、汎用系のホストコンピュータである。
新規コンピュータ３（第２のコンピュータ）は、オープン系のサーバコンピュータである。

【0016】

入力ファイル２１（第１の文書ファイル）は、文字データを含む文書ファイルであって、現行コンピュータ２のレガシーである。入力ファイル２１中の文字データは、現行コンピュータ２が取り扱っている文字コード体系に従う。現行コンピュータ２が取り扱っている文字コード体系は、半角英数文字、半角記号、および半角カナ文字の文字データについてはＥＢＣＤＩＫであり、全角文字の文字データについてはＫＥＩＳである。本実施形態では、入力ファイル２１中の文字データに割り当てられた文字コードを「ＥＢＣＤＩＫ＋ＫＥＩＳコード」と称する場合がある。

【0017】

なお、ＥＢＣＤＩＫは、半角英数文字、半角記号、および半角カナ文字については、１文字を１バイトで表現する（バイト数＝１）。ＫＥＩＳは、全角文字については、１文字を２バイトで表現する（バイト数＝２）。

【0018】

入力プログラム２２（第１のプログラム）は、入力ファイル２１を処理するためのプログラムであって、現行コンピュータ２のレガシーである。入力プログラム２２は、ＣＯＢＯＬ言語で記述されており、その記述内容は、ＥＢＣＤＩＫ兼ＫＥＩＳからなる文字コード体系に即している。

【0019】

出力ファイル３１（第２の文書ファイル）は、文字データを含む文書ファイルである。出力ファイル３１中の文字データは、新規コンピュータ３が取り扱っている文字コード体系に従う。新規コンピュータ３が取り扱っている文字コード体系は、半角英数文字、半角記号、半角カナ文字、および全角文字のいずれの文字の文字データについてもＵＴＦ−８である。本実施形態では、出力ファイル３１中の文字データに割り当てられた文字コードを「ＵＴＦ−８コード」と称する場合がある。

【0020】

なお、ＵＴＦ−８は、半角英数文字および半角記号については、１文字を１バイトで表現し（バイト数＝１）、半角カナ文字および全角文字については、１文字を３バイトで表現する（バイト数＝３）。

【0021】

出力プログラム３２（第２のプログラム）は、出力ファイル３１を処理するためのプログラムである。本実施形態では、出力プログラム３２は、ＣＯＢＯＬ言語で記述されているとする。しかし、周知の形式的な記述を施すことで、出力プログラム３２を、ＪＡＶＡ（登録商標）言語で記述することができる。

【0022】

なお、作業用ＰＣ１は、入力部、出力部、制御部、および記憶部といったハードウェアを含む。例えば、制御部がＣＰＵ（Central Processing Unit）から構成される場合、その制御部を含むコンピュータによる情報処理は、ＣＰＵによるプログラム実行処理で実現する。また、そのコンピュータが含む記憶部は、ＣＰＵが指令し、そのコンピュータの機能を実現するためのプログラムを記憶する。これによりソフトウェアとハードウェアの協働が実現される。前記プログラムは、記録媒体に記録したり、ネットワークを経由したりすることで提供される。

【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】

図４には、従来技術としての比較例を示す。図４（ａ）の上部には、変換前プログラムのソースコードのうちデータ部ワーキング節の記述例が示されている。集団項目DATA‐Aのなかに、DATA‐A1およびDATA‐A2という変数（項目）がこの順番で宣言されている。
DATA‐A1において、「PIC X」は、１文字１バイトのデータ（ＥＢＣＤＩＫ）格納エリアをメモリ上に確保することを表しており、「(03)」は、このエリアが３つあることを表している（桁数は３）。よって、DATA‐A1に（半角文字）３文字分のデータを入力できる。
DATA‐A2において、「PIC N」は、１文字２バイトのデータ（ＫＥＩＳ）格納エリアをメモリ上に確保することを表しており、「(03)」は、このエリアが３つあることを表している（桁数は３）。よって、DATA‐A2に（全角文字）３文字分のデータを入力できる。
なお、ＣＯＢＯＬ言語は、変数を固定長で宣言する。

【0048】

図４（ａ）の下部には、上記記述例を具現化したエリアの模式図が示されている。１つのエリアを１つのボックスで表わすと、このボックスは、１バイトのデータ格納エリアを表している。この模式図によれば、変換前プログラムは、DATA‐A1に対して３バイト分のエリアをメモリ上に指定することで、DATA‐A1に３文字分のデータを入力できる。また、DATA‐A2に対して６バイト（２バイト×３）分のエリアをメモリ上に指定することで、DATA‐A2に３文字分のデータを入力できる。このように、変換前プログラムは、従来のように、文字データのバイト列が格納されるエリアを１バイトごとに指定しており、バイト数単位で文字データを処理する（左から順番にボックス内のバイト列に１つずつアクセスする）。

【0049】

ここで、マイグレーションにて文字コードを変換し、プログラムも変換する場合、１文字を表現するバイト列のバイト数が異なった文字データを間違いなく処理するために（目的とした文字データを確実に読み出すために）、従来技術では、変換後プログラムのロジックを手作業で修正する必要があった。

【0050】

図４（ｂ）の上部には、変換後プログラムのソースコードのうちデータ部ワーキング節の記述例が示されている。プログラムの変換前後でロジックを同じにするためには、図４（ａ）の記述例に対して図中の下線部で示したような記述を追加する修正が必要である。
前記修正として、DATA‐A1については、桁数を３から９に変更している。このように桁数を変更させる理由は、ＥＢＣＤＩＫが半角カナ１文字を１バイトで表現するのに対し、ＵＴＦ−８は半角カナ１文字を３バイトで表現するため、DATA‐A1に半角カナ３文字分のバイト列が入力された場合に対応できるように（データの溢れを防ぐように）、DATA‐A1に９バイト分のエリア（３バイト×３文字）を持たせるためである。
また、前記修正として、DATA‐A2については、桁数を３から５に変更している。このように桁数を変更させる理由は、ＫＥＩＳが全角文字１文字を２バイトで表現するのに対し、ＵＴＦ−８は全角文字１文字を３バイトで表現するため、DATA‐A2に全角文字３文字のバイト列が入力された場合に対応できるように、DATA‐A2に少なくとも９バイト分のエリア（３バイト×３文字）を持たせるためである。図４（ｂ）の例では、DATA‐A2の桁数を５にすることで、DATA‐A2に１０バイト分のエリアを持たせている。

【0051】

図４（ｂ）の下部には、上記修正がなされた記述例を具現化したエリアの模式図が示されている。図４（ｂ）に示すボックスは、図４（ａ）に示すボックス同様、１バイトのデータ格納エリアを表している。前記修正の結果、ボックスの数を増やすことで、DATA‐A1に３文字分のデータを入力できること、および、DATA‐A2に３文字分のデータを入力できること、という変換前プログラムの特性が変換後プログラムにおいても保持される。ただ、このようなボックスを増やすように、プログラムに組まれたロジックを修正することは、プログラム中のすべての変数に対して行う必要があるので、多大な作業量を必要とする。

【0052】

図５には、本実施例を示す。図５（ａ）は、図４（ａ）と同じである。つまり、変数DATA‐A1には３文字分のデータを入力でき、変数DATA‐A2には３文字分のデータを入力できる。
図５（ｂ）の上部には、変換後プログラムのソースコードのうちデータ部ワーキング節の記述例が示されている。本実施例にてプログラムを変換する場合、すでに説明した交換情報Ｅが用いられる。

【0053】

すでに説明したように、交換情報Ｅによって、変換後プログラムがメモリ上に指定するエリアは、１バイトのデータを格納するためのエリアではなく、１文字のデータを格納するためのエリアとして機能する。このことは、図５（ｂ）の下部に示すように、１つのボックスが、１つのエリアを半角英数記号カナ文字１文字のデータ格納エリアとして表すことと同義である。ここで、「半角英数記号カナ文字」という語は、半角英数文字、半角記号、および半角カナ文字をまとめた語である。半角英数記号カナ文字１文字のデータ格納エリアは、２つ並べると全角文字１文字のデータ格納エリアを表すことができる。

【0054】

したがって、図５（ｂ）の記述例において、DATA‐A1の「PIC X(03)」は、半角英数記号カナ文字１文字のデータ（ＵＴＦ−８）格納エリアをメモリ上に３つ確保することを表すことができる。このことは、図４（ｂ）のように桁数を増やさなくても（ロジックを修正しなくても）、変数DATA‐A1には３文字分のデータ（ＵＴＦ−８コードが割り当てられた文字データ）を入力できることを意味する。

【0055】

また、DATA‐A2の「PIC N(03)」は、全角文字１文字のデータ（ＵＴＦ−８）格納エリアをメモリ上に３つ確保することを表すことができる。このことは、図４（ｂ）のように桁数を増やさなくても（ロジックを修正しなくても）、変数DATA‐A2には３文字分のデータ（ＵＴＦ−８コードが割り当てられた文字データ）を入力できることを意味する。

【0056】

すでに説明したように、１つまたは２つの半角英数記号カナ文字１文字のデータ格納エリアには、１つのＵＴＦ−８コードが格納される。よって、所定の業務処理の実行の際、変換後プログラムは、エリアに格納されたＵＴＦ−８コードに所定の順番でアクセスすれば、文字数単位で文字データを処理することができる。

【0057】

このように、交換情報Ｅを用いることで、変換後プログラムがメモリ上に指定するエリアの取り扱いを変えることで、プログラムに組まれたロジックを修正する、といった多大な作業量を無くすことができる。

【0058】

≪まとめ≫
本実施形態によれば、変換した出力プログラム３２は、文字コードの変換によって、１文字を表現するバイト列のバイト数が異なった文字データを処理する際、交換情報Ｅを参照することで、入力プログラム３２が使用したエリアの数と同じ数のエリアを使用することができる。つまり、出力プログラム３２は、メモリ上に指定するエリアを、１文字のデータを格納するための１または複数のエリアとし、文字数単位で文字データを処理することができる。よって、出力プログラム３２で組まれたロジックを入力プログラム３２で組まれたロジックと同じにすることができ、出力プログラム３２のソースコードの記述内容のうち、ロジックに関する部分を修正する必要はない。
したがって、異なる文字コード体系への切り替えが伴うマイグレーションにおいて、マイグレーションの対象となるプログラムの変換を容易にすることができる。

【0059】

≪その他≫
本実施形態では、ＥＢＣＤＩＫおよびＫＥＩＳを用いた文字コード体系から、ＵＴＦ−８を用いた文字コード体系への切り替えが伴うマイグレーションについて説明した。しかし、ＪＩＳ８およびＳＪＩＳを用いた文字コード体系から、ＵＴＦ−８を用いた文字コード体系への切り替えが伴うマイグレーションについても本発明を適用できる。

【0060】

なお、ＪＩＳ８は、半角英数文字、半角記号、および半角カナ文字については、１文字を１バイトで表現する（バイト数＝１）。ＳＪＩＳは、全角文字については、１文字を２バイトで表現する（バイト数＝２）。

【0061】

また、本実施形態では、エリア格納部１４が、出力プログラム３２が指定するメモリ上のエリアにＵＴＦ−８コードを格納していた。しかし、ＵＴＦ−８コードではなく、該当文字データを識別できる任意の形式のデータを格納することも可能である。

【0062】

また、本実施形態では、交換情報生成部１３が交換情報Ｅを生成する際、出力プログラム３２が読み込む、ＵＴＦ−８コードが割り当てられた文字データは、例えば、出力ファイル３１から抽出した文字データとした。しかし、例えば、作業用ＰＣ１が、所定の文字集合（例えば、ＵＴＦ−８を取り扱うオープン系サーバコンピュータへのマイグレーションの場合、現存するすべての文字からなる文字集合）に含まれるすべての文字について、交換情報Ｅを生成するために、ＵＴＦ−８コードが割り当てられた文字データを外部から事前に取得しておき、取得した文字データを出力プログラム３２に読み込ませてもよい。

【0063】

また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

【符号の説明】

【0064】

１ 作業用ＰＣ（マイグレーション支援装置）
１１ 文字コード変換部
１２ プログラム変換部
１３ 交換情報生成部
１４ エリア格納部
２ 現行コンピュータ（第１のコンピュータ）
２１ 入力ファイル（第１の文書ファイル）
２２ 入力プログラム（第１のプログラム）
３ 新規コンピュータ（第２のコンピュータ）
３１ 出力ファイル（第２の文書ファイル）
３２ 出力プログラム（第２のプログラム）
Ｔ 文字コード変換表
Ｅ 交換情報

【図1】

【図2】

【図3】

【図4】

【図5】