(57)【要約】【課題】  システムの移行を行う場合に、システム全体を停止させずに、逐次移行していくための支援を行うことができるデータ処理装置、データ処理方法及びそのプログラムを提供する。【解決手段】  更新情報抽出処理部１４は、受信したインタフェース情報がデータベース群１３に対して更新処理を行うものであるか否かを判断する。次に、更新情報抽出処理部１４は、更新処理を行うものであると判断したインタフェース情報から更新処理に関する情報である更新情報を抽出して、バッファ１５に蓄積する。送受信処理部１６は、バッファ１５に蓄積された更新情報を、ネットワーク２経由でサーバ３へ送信する。これにより、新データベース３３に上記更新情報が反映される。【選択図】  図１
2006133999.tif 000002
【特許請求の範囲】
【請求項１】
第1のデータベースに対して管理コマンドを出力することで管理を行う管理手段を備え、第２のデータベースを管理する管理装置とネットワークで接続されたデータ処理装置であって、
前記管理手段が出力する前記管理コマンドを受信する受信手段と、
前記受信手段が受信した前記管理コマンドが前記第１のデータベースに対して更新処理を行うものであるか否かを判断する更新処理判断手段と、
前記更新処理判断手段が更新処理を行うものであると判断した管理コマンドから更新処理に関する情報である更新情報を抽出する抽出手段と、
前記抽出手段が抽出した前記更新情報を、前記ネットワーク経由で前記管理装置へ送信する送信手段と
を具備することを特徴とするデータ処理装置。
【請求項２】
前記抽出手段が抽出した複数の前記更新情報を一時的に保存する保存手段を更に具備し、
前記送信手段は、前記保存手段に保存された複数の前記更新情報をまとめて、前記ネットワーク経由で前記管理装置へ送信することを特徴とする請求項１に記載のデータ処理装置。
【請求項３】
前記管理手段が、アプリケーションプログラムからの指示情報に応じて複数の管理コマンドを出力する場合に、前記保存手段は、前記指示情報に応じて前記管理手段が出力する複数の管理コマンドから前記抽出手段が抽出した複数の更新情報をまとめて一時的に保存し、
前記送信手段は、前記保存手段がまとめて保存している前記複数の更新情報を、前記ネットワーク経由で前記管理装置へ送信することを特徴とする請求項１又は２に記載のデータ処理装置。
【請求項４】
前記第１のデータベースが複数あり、一部の第１のデータベースに対する管理コマンドのみを前記抽出手段の抽出対象とする場合に、前記更新処理判断手段が更新処理を行うものであると判断した管理コマンドに対して、更に前記一部の第１のデータベースに対する管理コマンドであるか否かを判断する判断手段を更に具備し、
前記抽出手段は、前記判断手段が前記一部の第１のデータベースに対する管理コマンドであると判断した管理コマンドに対して前記更新情報の抽出を行うこと
を特徴とする請求項１〜３のいずれか１項に記載のデータ処理処理装置。
【請求項５】
前記第１のデータベース、前記第２のデータベース、及び前記第２のデータベースを管理する前記管理装置が複数あり、前記第１のデータベースと前記第２のデータベースが対応付けられている場合に、前記送信手段は、前記対応付けに関する情報テーブルを備え、前記情報テーブルを参照して前記更新情報を、第１のデータベースに対応付けられた第２のデータベースを管理する管理装置へ送信することを特徴とする請求項１〜３のいずれか１項に記載のデータ処理処理装置。
【請求項６】
前記管理装置の稼動状況に関する情報を受信する稼動状況受信手段と、
前記稼動状況受信手段が受信した前記管理装置の稼動状況に応じて前記保存手段における前記更新情報の保存処理を制御する保存管理手段と
を更に具備することを特徴とする請求項１〜５のいずれか１項に記載のデータ処理処理装置。
【請求項７】
第1のデータベースに対して管理コマンドを出力することで管理を行う管理手段を備え、第２のデータベースを管理する管理装置とネットワークで接続されたデータ処理装置を利用したデータ処理方法であって、
前記管理手段が出力する前記管理コマンドを受信する受信ステップと、
前記受信ステップで受信した前記管理コマンドが前記第１のデータベースに対して更新処理を行うものであるか否かを判断する更新処理判断ステップと、
前記更新処理判断ステップで更新処理を行うものであると判断した管理コマンドから更新処理に関する情報である更新情報を抽出する抽出ステップと、
前記抽出ステップで抽出した前記更新情報を、前記ネットワーク経由で前記管理装置へ送信する送信ステップと
を有することを特徴とするデータ処理方法。
【請求項８】
第1のデータベースに対して管理コマンドを出力することで管理を行う管理手段を備え、第２のデータベースを管理する管理装置とネットワークで接続されたデータ処理装置を利用したデータ処理方法であって、
前記管理手段が出力する前記管理コマンドを受信する受信ステップと、
前記受信ステップで受信した前記管理コマンドが前記第１のデータベースに対して更新処理を行うものであるか否かを判断する更新処理判断ステップと、
前記更新処理判断ステップで更新処理を行うものであると判断した管理コマンドから更新処理に関する情報である更新情報を抽出する抽出ステップと、
前記抽出ステップで抽出した前記更新情報を、前記ネットワーク経由で前記管理装置へ送信する送信ステップと
をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システムの移行を補助するためのデータベース構築処理を行うデータ処理装置、データ処理方法及びそのプログラムに関するものである。
【背景技術】
【０００２】
従来、例えばメインフレームを中心に構築されているレガシーシステムは、長年の間個別のビジネスニーズに対応し逐次機能拡張を重ねた為、複雑なシステム構造となっている場合が多い。また、メインフレームのシステムとオープン系システム双方が共存し、双方の維持管理が必要なユーザも多く、システム維持コスト低減の阻害要因となっている。その為、ＴＣＯ（トータル  コスト  オブ  オーナーシップ）の削減や、ビジネスへの追従性の確保、より柔軟なシステムへの移行を目的とし、レガシーシステムからオープン系システムの移行のニーズが高まっている。このシステム移行に関しては、システムをマイグレーションする方法、または再構築する方法が取られる。
【０００３】
例えば、旧システムのデータベースを或る時点で一括して新システムのデータベースに移行した後、その後に旧システムのデータベースに発生した変更事項の差分を逐次的に新システムのデータベースに移行させていくようにしたデータ移行方法が開示されている（例えば、特許文献１参照。）。
【０００４】
【特許文献１】特開平４−２４３４３７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、従来の技術と同様に、メインフレームからオープン系システムへの移行に際しては、多くの場合、一気に移行を完了させるという方法が取られてきた。このような方法では、移行に際し、稼動中のシステムを停止させ、ソフトウェア及びハードウェア等を全て入れ替えるといった作業が必要である。例えば、製鉄所のシステム、特に操業系（工場の自動化機器のコントロール、プロセス制御等）のシステムなどは、システムを停止することは、操業そのものを停止せざるを得ないという問題がある。すなわち、可能な限りシステムを停止させない移行の方法が望まれてきた。これは、製鉄所（鉄鋼業）のシステムのみならず、金融や鉄道、流通などの業種で採用されているシステムにおいても大きな課題である。
【０００６】
本発明は、上述した事情を考慮してなされたもので、システムの移行を行う場合に、システム全体を停止させずに、逐次移行していくための支援を行うことができるデータ処理装置、データ処理方法及びそのプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
この発明は、上述した課題を解決すべくなされたもので、本発明によるデータ処理装置においては、第1のデータベースに対して管理コマンドを出力することで管理を行う管理手段を備え、第２のデータベースを管理する管理装置とネットワークで接続されたデータ処理装置であって、管理手段が出力する管理コマンドを受信する受信手段と、受信手段が受信した管理コマンドが第１のデータベースに対して更新処理を行うものであるか否かを判断する更新処理判断手段と、更新処理判断手段が更新処理を行うものであると判断した管理コマンドから更新処理に関する情報である更新情報を抽出する抽出手段と、抽出手段が抽出した更新情報を、ネットワーク経由で管理装置へ送信する送信手段とを具備することを特徴とする。
【０００８】
また、本発明によるデータ処理方法においては、第1のデータベースに対して管理コマンドを出力することで管理を行う管理手段を備え、第２のデータベースを管理する管理装置とネットワークで接続されたデータ処理装置を利用したデータ処理方法であって、管理手段が出力する管理コマンドを受信する受信ステップと、受信ステップで受信した管理コマンドが第１のデータベースに対して更新処理を行うものであるか否かを判断する更新処理判断ステップと、更新処理判断ステップで更新処理を行うものであると判断した管理コマンドから更新処理に関する情報である更新情報を抽出する抽出ステップと、抽出ステップで抽出した更新情報を、ネットワーク経由で管理装置へ送信する送信ステップとを有することを特徴とする。
【０００９】
また、本発明によるプログラムは、第1のデータベースに対して管理コマンドを出力することで管理を行う管理手段を備え、第２のデータベースを管理する管理装置とネットワークで接続されたデータ処理装置を利用したデータ処理方法であって、管理手段が出力する管理コマンドを受信する受信ステップと、受信ステップで受信した管理コマンドが第１のデータベースに対して更新処理を行うものであるか否かを判断する更新処理判断ステップと、更新処理判断ステップで更新処理を行うものであると判断した管理コマンドから更新処理に関する情報である更新情報を抽出する抽出ステップと、抽出ステップで抽出した更新情報を、ネットワーク経由で管理装置へ送信する送信ステップとをコンピュータに実行させるためのプログラムである。
【発明の効果】
【００１０】
本発明によるデータ処理装置、データ処理方法及びそのプログラムによれば、システムの移行を行う場合に、システム全体を停止させずに、逐次移行していくための支援を行うことができる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施の形態について説明する。
本発明の一実施形態におけるメインフレーム（データ処理装置）を含むデータ処理システムとして、製造ラインにおける操業オンラインデータ処理システムを例に説明を行う。図１は、本実施形態におけるメインフレームを含むデータ処理システムの概要を示す図である。図１において、１は、メインフレームであり、例えば製造ラインに設置された端末であるプロセスコンピュータ（プロコン）４から刻々と変化する製造情報を、ネットワーク５を介して受信してリアルタイムでデータ処理するシステムである。２は、高速ネットワークであり、メインフレーム１と後述するサーバＡ・３、サーバＢ・３、サーバＣ・３、…（以下、サーバ３とする。）とを接続する。サーバ３は、メインフレーム１からのデータを受信して新データベース３３に格納する。
【００１２】
本実施形態においては、旧システム（メインフレーム１）から新システム（例えばオープン系システム）への移行時に、旧システムにおいてリアルタイムで構築されるデータベース群１３の一部のデータの更新に応じて、リアルタイムで新データベース３３においてもデータ更新を実現する。これにより、新システムの構築において、リアルタイムでデータ更新される新データベース３３のデータを利用できるので、効率よく種々のアプリケーション開発を行うことができる。本実施形態では、旧システムであるメインフレーム１に、データベース群１３の一部のデータ更新に応じて、リアルタイムで新データベース３３をデータ更新するための更新情報を、新データベース３３へ送信する以下に示す機能を追加している。
【００１３】
すなわち、システム移行の間は、メインフレーム１の旧システムと、オープン系システムである新システムが並立することになる。そして、新システムにおけるアプリケーションやデータベースの再構築が完了するまでは、メインフレーム１上の旧システムが稼動し、新システムの構築が完了次第、そのまま新システムに移行するというシームレスな移行が可能となる。
【００１４】
次に、図１に示すメインフレーム１の内部構成について説明する。
１２は、オンラインコントロールプログラム（ＯＣＰ）であり、プロコン４が送信するトランザクションメッセージを受信して、当該トランザクションメッセージと紐つけられたＡＰ（アプリケーション）プログラム１１を起動する。尚、ＯＣＰ・１２は、例えば、ＤＣＭＳ（データ  コミニュケーション  マネージメント  システム）＋ＤＢＭＳ（データ  ベース  マネージメント  システム）及び自製ミドルウェアの機能を組み合わせることで実現される。
【００１５】
起動されたＡＰプログラム（トランザクションメッセージ処理プログラム：ＵＡＰ）１１は、ＯＣＰ・１２よりトランザクションメッセージを取得して、当該トランザクションメッセージのチェック、演算、各種ＤＢ（ファイル）のレコードの参照、更新、又は削除の他に、処理結果を端末（ここではプロコン４）に対して応答送信などの処理を行う。
【００１６】
製鉄所における操業オンラインデータ処理システムでは、このようなオンライントランザクション処理を行うＵＡＰが数千本以上の規模で存在しており、それぞれが異なった計算機処理を行っている。すなわち、ＡＰプログラム１１は、複数のＵＡＰを含む。尚、トランザクションメッセージには、上述した端末入力（プロコン４からの入力）の他に、各ＵＡＰから自身または他のＵＡＰを起動要求する内部発生型（ＡＰ−ＡＰ起動）のものもある。
【００１７】
１３は、データベース群であり、上記ＵＡＰにより参照、更新、削除などの処理が行われる複数のＤＢ（データベース）の集まりを示す。図３は、図１に示したデータベース群１３に含まれるＤＢのレコードの構造例を示す図である。図３に示すように、ＵＡＰが扱うＤＢには、ＤＢごとに複数のレコードを保有している。各レコードには、図３のキーＡ、キーＢ、キーＣ、…、キーＮに示すように、レコードごとにユニークなキー（レコードキー）を付加している。このキーは、データの重複排除と参照（検索）や更新時にキーを指定することにより対象レコードの抽出・特定化を可能としている。図３に示すようなレコード構造を有するＤＢをアクセスする機能は、例えばＯＣＰ・１２及び自製ミドルウェアでサポートしており、ＵＡＰからのレコード参照・更新を容易にしている。
【００１８】
尚、レコードキーとは、ＤＢ内のレコードの先頭から順に番号付けした相対レコード方式キーや製品製造番号などそのものを特定できるキー（製鉄所では厚板プレート番号、薄板コイル番号など種々あり）などの情報である。また、このレコードキーの位置と長さはＤＢごとに任意にＡＰプログラム１１で決めることができる。
【００１９】
また、ＵＡＰによるＤＢのデータレコードの更新処理について説明する。
それぞれのＵＡＰは、受信したトランザクションメッセージをチェック解析した後、そのプログラム中で定められたＤＢについてレコードの参照および更新を行い、処理結果を端末に応答送信する。
【００２０】
次に、ＵＡＰによるＤＢレコードの参照処理について説明する。
ＵＡＰは、ＯＣＰ・１２で用意されたＡＰＩ（インタフェース情報）中に参照したいキー情報（例えばキーＣ）を指定して、ＯＣＰ・１２に対して読み込み要求を行う。ＯＣＰ・１２では要求のあったＤＢのキー（キーＣ）を含むレコード（行）を読み込み、その結果をＵＡＰが用意した読み込みエリアに設定し、ＵＡＰに制御を戻す。尚、ここで、ＡＰＩ（インタフェース情報）とは、ＯＣＰ・１２とＵＡＰ間で授受する所定のデータ構造を有する情報である。
【００２１】
次に、ＵＡＰによるＤＢレコードの更新処理について説明する。
ＵＡＰは、参照したレコードに対して、各項目の内容の置換（例えばキーＣのデータ項目３の内容Ｃ１３をＣ２３に置換）や当該データレコードの削除、また新たなレコードの追加などを行う。この際、ＵＡＰは、いずれの処理を行う場合でもＡＰＩ（インタフェース情報）中にキー情報と更新データを指定して、ＯＣＰ・１２に書き込み要求を行う。ＯＣＰ・１２では要求のあったキーを含むレコードをＤＢに書き込み処理した後、ＵＡＰに制御を戻す。
【００２２】
以上に説明した参照・更新を繰り返し実行して１つのＵＡＰ処理が完結する。また、ＵＡＰの処理により、データベース群１３に含まれるＤＢはリアルタイムに更新される。
【００２３】
ここで、図１の説明にもどる。１４は、更新情報抽出処理部であり、ＯＣＰ・１２が出力するＤＢレコードの参照結果や更新結果を抽出する。この際、更新情報抽出処理部１４は、ＵＡＰ処理と同期して同一タスクで動作する。具体的には、ＵＡＰがＯＣＰ・１２からＤＢレコード参照、及び更新要求の結果を受け取る前に、ＯＣＰ・１２の制御を更新情報抽出処理部１４に移す。これにより、更新情報抽出処理部１４は、ＵＡＰの参照・更新情報を取得することができる。また、更新情報抽出処理部１４は、データベース群１３に含まれる更新処理の対象ＤＢの更新情報のみを抽出し、バッファ管理部１７を介して抽出した更新情報をＵＡＰ処理単位ごとにバッファ１５に蓄積（バッファリング）する。
【００２４】
バッファ管理部１７は、更新情報抽出処理部１４から受信したデータをバッファ１５に蓄積する処理の他に、バッファ１５のデータ蓄積量の管理や、バッファ１５に蓄積したデータを読み出して送受信処理部１６に渡す処理などを行う。また、バッファ管理部１７は、送受信処理部１６がサーバ３から受信したサーバ３の状態情報を基に、送信可能であるか否かを判断する処理も行う。
【００２５】
また、バッファ管理部１７においてバッファ１５のデータ容量が一杯（空きが無い）であると判断した場合、又はＵＡＰ処理完結（同期点）と判断した場合に、送受信処理部１６は、バッファ管理部１７を介してバッファ１５から更新レコードを読み出し、所定のサーバ３へ読み出した更新レコードをメッセージとして即時にネットワーク２を介して送信する。また、送受信処理部１６は、上述したように、データの送信先であるサーバ３の状態情報を受信する機能を有する。
【００２６】
以上により、メインフレーム１は、サーバ３との間で遅延時間なしの鮮度の高い更新情報授受を可能としている。尚、更新情報抽出処理部１４及びバッファ１５に関する処理については詳細を後述する。
【００２７】
次に、図１に示すサーバ３内の構成について説明する。送受信処理部３１は、ネットワーク２を介して更新情報を受信する。また、送受信処理部３１は、ネットワーク２を介して自身の状態情報（特に、データ受信可能な状態であるか否かを示す情報）を送信する。データ編集部３２は、受信処理部３１が受信した更新情報を新データベース３３に応じたデータ形式に編集する処理を行う。新データベース３３は、データ編集部３２が編集後の更新情報を格納する。以上により、サーバ３には、リアルタイムで更新される新データベース３３が構築される。
【００２８】
次に、図１に示した更新情報抽出処理部１４の機能構成について説明する。
図２は、図１に示した更新情報抽出処理部１４の機能構成例を示す図である。図２に示すように、更新情報抽出処理部１４は、ＯＣＰ・１２から受信した出力データ（インタフェース情報）を基に、各種処理を行う以下に示す機能を有する。尚、ＯＣＰ・１２が出力するインタフェース情報には、例えばＵＡＰ処理の終了要求などを定める呼び出し種別、ＵＡＰ名称、例えばＤＢに対する処理を定める機能コード、例えば処理対象となるＤＢを特定する資源名などが含まれている。このインタフェース情報の具体例については後述する。
【００２９】
ＵＡＰ終了判断部２１は、ＯＣＰ・１２から受信したインタフェース情報を基に、当該インタフェース情報が一連のＵＡＰ処理（ＵＡＰ処理単位）の終了を示す情報であるか否かを判断する。具体的には、ＵＡＰ終了判断部２１は、ＯＣＰ・１２から受信したインタフェース情報に含まれる呼出し種別を基に、当該インタフェース情報が一連のＵＡＰ処理（ＵＡＰ処理単位）の終了を示す情報を含むか否かを判断する。ＵＡＰ終了判断部２１は、インタフェース情報がＵＡＰ処理単位の終了を示す情報を含むと判断した場合には、終了信号を送受信処理部１６へ送信する。また、ＵＡＰ終了判断部２１は、インタフェース情報がＵＡＰ処理単位の終了を示す情報を含まないと判断した場合には、インタフェース情報を更新処理判断部２２へ渡す。
【００３０】
更新処理判断部２２は、ＯＣＰ・１２から受信したインタフェース情報を基に、当該インタフェース情報がＤＢの更新処理を示す情報であるか否かを判断する。具体的には、更新処理判断部２２は、ＯＣＰ・１２から受信したインタフェース情報に含まれる機能コードを基に、当該インタフェース情報がＤＢの更新処理を示す情報を含むか否かを判断する。
【００３１】
対象ＤＢ判断部２３は、ＯＣＰ・１２から受信したインタフェース情報を基に、当該インタフェース情報に含まれる更新情報はサーバ３へ送信する対象となるＤＢ（以下、処理対象ＤＢとする）を示す情報であるか否かを判断する。具体的には、対象ＤＢ判断部２３は、ＯＣＰ・１２から受信したインタフェース情報に含まれる資源名の情報と、サーバ３へデータを送信する対象となるＤＢに関する情報テーブルとを比較することで、インタフェース情報に含まれる資源名で特定されるＤＢが、処理対象ＤＢであるか否かを判断する。
【００３２】
蓄積処理部２４は、上述した更新処理判断部２２において更新処理を示す情報を含むと判断し、かつ、対象ＤＢ判断部２３において処理対象ＤＢを示す情報を含むと判断したインタフェース情報に含まれる情報の中から必要な情報（更新データ）のみをバッファ管理部１７へ出力する。これにより、バッファ管理部１７は、バッファ１５に更新データを蓄積する処理を行う。
【００３３】
次に、図１及び図２に示したメインフレーム１におけるサーバ３へのデータ送信処理について説明する。図４は、図１及び図２に示したメインフレーム１におけるサーバ３へのデータ送信処理を示すフロー図である。図４に示すように、まず、ステップＳ１において、更新情報抽出処理部１４は、ＯＣＰ・１２からインタフェース情報を受信する。以下に、本実施形態におけるインタフェース情報の具体例を説明する。
【００３４】
図５は、ＯＣＰ・１２がＵＡＰとの通信のため出力するインタフェース情報例を示す図である。図５に示すように、インタフェース情報は、「呼出し種別」、「ＵＡＰ名称」、「トランザクションコード」、「機能コード」、「資源名」、及び「データ」から構成されている。「呼出し種別」とは、ＵＡＰの終了処理の呼出しなど、呼出し処理の種類を特定する情報である。「機能コード」とは、例えばＤＢに対する追加、変更、削除などを指示する更新処理のファンクションを特定するコードである。「資源名」とは、例えば、トランザクションメッセージをメインフレーム１に送信するプロコン４の端末名や、サーバ３が備えるデータベース群１３に含まれるＤＢ名などの情報である。「データ」は、送受信メッセージ内容やＤＢレコード内容である。
【００３５】
次に、ステップＳ２において、ＵＡＰ終了判断部２１は、ステップＳ１で取得したインタフェース情報の「呼出し種別」がＵＡＰ処理の終了を要求するものであるか否かを判断する。ここで、ＵＡＰ処理の終了を要求しないものであると判断した場合（ステップＳ２のＮＯ）には、ステップＳ３に移行し、更新処理判断部２２は、インタフェース情報の「機能コード」がＤＢの更新処理を示すものであるか否かを判断する。
【００３６】
ここで、ＤＢの更新処理を示すものではないと判断した場合（ステップＳ３のＮＯ）には、ステップＳ１の処理に戻り、更新情報抽出処理部１４は、インタフェース情報の受信待ちの状態となる。また、ＤＢの更新処理を示すものであると判断した場合（ステップＳ３のＹＥＳ）には、ステップＳ４に移行し、対象ＤＢ判断部２３は、インタフェース情報の「資源名」で特定されるＤＢが、処理対象ＤＢであるか否かをテーブルを参照して判断する。
【００３７】
ここで、処理対象ＤＢではないと判断した場合（ステップＳ４のＮＯ）には、ステップＳ１の処理に戻り、更新情報抽出処理部１４は、インタフェース情報の受信待ちの状態となる。また、処理対象ＤＢであると判断した場合（ステップＳ４のＹＥＳ）には、ステップＳ５に移行して、蓄積処理部２４は、バッファ管理部１７を介してバッファ１５に更新処理に関する情報（以下、更新情報とする）を蓄積して、ステップＳ１に戻る。以上に示したステップＳ１〜Ｓ５までの処理を、ステップＳ２においてＵＡＰ処理の終了を検出するまで行うことで、例えば図６及び図７に示すようなデータがバッファ１５に蓄積される。尚、ステップＳ５の蓄積処理の詳細については後述する。
【００３８】
図６及び図７は、本実施形態のバッファ１５に蓄積される更新情報例を示す図である。図６に示すように、バッファ１５は、バッファ番号１〜ｎが付与されたバッファ１〜ｎにより構成されている。尚、図６に示すように、バッファ１６はバッファｍ・６０を含む（ｍは１〜ｎの間の任意の数）。また、図７に示すように、図６に示したバッファｍ・６０は、「共通ヘッダ」、「ヘッダ１」及び「更新レコード１」、「ヘッダ２」及び「更新レコード２」、…「ヘッダｎ」及び「更新レコードｎ」から構成されている。この更新レコード１〜ｎが上述した更新情報である。更に、更新レコード１は、「ＤＢ名称」、「ＦＵＮＣ」、及び「レコード内容」から構成されている。ここで、「ＤＢ名称」は、図５に示したインタフェース情報の「資源名」を抽出した情報である。また、「ＦＵＮＣ」は、図５に示したインタフェース情報の「機能コード」を抽出した情報である。また、「レコード内容」は、図５に示したインタフェース情報の「データ」を抽出した情報である。
【００３９】
ステップＳ２において、ＵＡＰ処理の終了を要求するものであると判断した場合（ステップＳ２のＹＥＳ）には、ステップＳ６に移行し、ＵＡＰ終了判断部２１は終了信号を送受信処理部１６へ送信し、これにより、送受信処理部１６は、バッファ１５に蓄積した更新情報を、バッファ管理部１７を介して読み出し送信する。
【００４０】
以上に示したように、本実施形態における更新情報抽出処理部１４は、メインフレーム１におけるＤＢ更新処理を抽出して、リアルタイムでサーバ３の新データベース３３における更新処理に利用することができる。これにより、システムの移行を行う場合に、システム全体を停止させずに、新データベース３３に逐次必要なデータを移行していくための支援を行うことができる。
【００４１】
また、ステップＳ４においてメインフレーム１におけるＤＢ更新処理が処理対象ＤＢに対する処理か否かをテーブルを参照して判断することで、処理対象ではないＤＢに対する更新情報をバッファ１５に蓄積してサーバ３へ送信してしまうという無駄な処理を回避することができる。更には、送受信処理部１６が、処理対象ＤＢ別に送信先のサーバ３を特定する情報テーブルを備えることで、処理対象ＤＢに応じた送信先に更新情報を送信することができる。尚、送信先は、処理対象ＤＢ別に限定されるものではなく、処理対象ＤＢが複数のグループに分類されている場合には、そのグループ別に送信先を定めてもよい。
【００４２】
また、ＵＡＰの終了を待ってＵＡＰ単位で、バッファ１５への蓄積やサーバ３への更新情報の送信を行うようにすることで、インタフェース情報を逐次処理して送信する場合と比べて、サーバ３との通信量を低減できるという効果と、ＵＡＰ処理が途中で異常終了した場合にそれまでバッファ１５に蓄積した更新情報の送信を中止するというような対応が可能であるという効果を得ることができる。
【００４３】
次に、図４に示したステップＳ５の蓄積処理の詳細について説明する。
図８は、図４に示したステップＳ５の蓄積処理の詳細を示すフロー図である。図８に示すように、ステップＳ５１において、蓄積処理部２４から蓄積指示を受けたバッファ管理部１７は、現在の蓄積処理対象であるバッファ１５内の一バッファ（以下、現在バッファとする）に対する編集処理（＝蓄積処理）が可能であるか否かを判断する。
【００４４】
ここで、現バッファに対する編集処理が不可能であると判断した場合（ステップＳ５１のＮＯ）には、ステップＳ５２に移行して、バッファ管理部１７は、次のバッファが有るか否かを判断する。ここで、次バッファがあると判断した場合（ステップＳ５２のＹＥＳ）には、バッファ管理部１７は、バッファ番号をインクリメントして、ステップＳ５５に移行する。また、次バッファがないと判断した場合（ステップＳ５２のＮＯ）には、バッファ管理部１７は、バッファ１５が一杯（空きなし）になったと判断して、バッファ１５の全バッファに蓄積されている更新情報を送信するよう送受信処理部１６に指示する。これにより、ステップＳ５３において、送受信処理部１６は、バッファ１５の全バッファに蓄積されている更新情報をサーバ３へ送信して、ステップＳ５５へ移行する。
【００４５】
また、ステップＳ５１において、現バッファに対する編集処理が可能であると判断した場合（ステップＳ５１のＮＯ）には、ステップＳ５５へ移行して、バッファ管理部１７は、現在バッファへの編集処理を行う。具体的には、バッファ管理部１７は、蓄積処理部２４から蓄積指示を受けた更新情報を現在バッファに格納する処理を行う。
【００４６】
次に、ステップＳ５６において、バッファ管理部１７は、送受信処理部１６を介してサーバ３から受信したサーバ３の稼動状況に関する情報（例えば出力キュー残数や送信抑止など）を基に、サーバ３に対してデータの送信が可能か否かを判断する。ここで、データの送信が可能と判断した場合（ステップＳ５６のＹＥＳ）には、ステップＳ５７に移行して、バッファ管理部１７は、特殊アプリケーションによる特殊トランザクションによるＤＢ更新情報であるか否かを判断する。また、データの送信が不可能と判断した場合（ステップＳ５６のＮＯ）には、ステップＳ５８に移行して、バッファ管理部１７は、現在バッファへの編集を取り消し、ステップＳ５の蓄積処理を終了する。
【００４７】
また、ステップＳ５７において、特殊トランザクションによるＤＢ更新情報であると判断した場合（ステップＳ５７のＹＥＳ）には、ステップＳ５９に移行して、バッファ管理部１７は、編集済みのバッファ１５内の更新情報を送信するよう送受信処理部１６に指示する。これにより、送受信処理部１６は、編集済みのバッファ１５内の更新情報をサーバ３へ送信して、ステップＳ５の蓄積処理を終了する。また、特殊トランザクションによるＤＢ更新情報ではないと判断した場合（ステップＳ５７のＮＯ）には、バッファ管理部１７は、ステップＳ５の蓄積処理を終了する。
【００４８】
以上に示したように、バッファ管理部１７の処理により、バッファ１５のデータ蓄積状況やサーバ３の稼動状況に応じて、図４に示したステップＳ２のＵＡＰ終了の判断の前に、適宜、バッファ１５に蓄積されている更新情報を送信することができる。図８のステップＳ５２及びＳ５３の処理によれば、バッファ１５が一杯になった場合には、ＵＡＰの終了を待たずにバッファ１５内の更新情報を送信することができる。また、図８のステップＳ５６及びＳ５８の処理によれば、送信先のサーバ３の稼動状況からサーバ３に対するデータ送信が不可能と判断した場合には、編集途中である現在バッファの編集を取り消すことができる。これにより、バッファ１５の記録容量を節約することができる。
【００４９】
また、上記サーバ３の稼動状況としては、例えば更新情報送信キューの滞留状態に関する情報などが適切であり、この滞留状態が死状態にある場合にはサーバ３への更新情報の送信を停止する。尚、この場合に、メインフレーム１は、サーバ３の異常を管制員へ通報する処理を行ってもよい。また、上述した実施形態においては、図１に示すようにＯＣＰ・１２とデータベース群１３の間の通信において、ＯＣＰ・１２が出力するＤＢレコードの参照結果や更新結果を示すインタフェース情報を抽出したが、この限りではなく、ＯＣＰ・１２とＡＰプログラム１１の間の通信において、同様のデータを抽出してもよい。
【００５０】
尚、上述した実施形態において、図１及び図２に示したメインフレーム１及び更新情報抽出処理部１４の各処理部は、ハードウェアとしてはメモリ及びＣＰＵ（中央演算装置）により構成され、各処理部の機能を実現する為のプログラムをメモリに読み込んでＣＰＵが実行することによりその機能を実現させるものである。また、これに限定されるものではなく、各処理部の一部の処理又は全部の処理を専用のハードウェアにより実現されるものであってもよい。
【００５１】
また、上記メモリは、ハードディスク装置や光磁気ディスク装置、フラッシュメモリ等の不揮発性のメモリや、ＣＤ−ＲＯＭ等の読み出しのみが可能な記録媒体、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）のような揮発性のメモリ、あるいはこれらの組合せによるコンピュータ読み取り、書き込み可能な記録媒体より構成されるものとする。
【００５２】
また、プログラムをコンピュータに供給するための手段、例えばかかるプログラムを記録したコンピュータ読み取り可能な記録媒体又はかかるプログラムを伝送する伝送媒体も本発明の実施形態として適用することができる。また、上記のプログラムを記録したコンピュータ読み取り可能な記録媒体等のプログラムプロダクトも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体及びプログラムプロダクトは、本発明の範疇に含まれる。
【００５３】
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。
【００５４】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
【００５５】
また、上記プログラムは、前述した機能の一部を実現する為のものであっても良い。さらに、前述した機能をコンピュータシステムに既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【００５６】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【図面の簡単な説明】
【００５７】
【図１】本実施形態におけるメインフレームを含むデータ処理システムの概要を示す図である。
【図２】図１に示した更新情報抽出処理部１４の機能構成例を示す図である。
【図３】図１に示したデータベース群１３に含まれるＤＢのレコードの構造例を示す図である。
【図４】図１及び図２に示したメインフレーム１におけるサーバ３へのデータ送信処理を示すフロー図である。
【図５】ＯＣＰ・１２がＵＡＰとの通信のため出力するインタフェース情報例を示す図である。
【図６】本実施形態のバッファ１５に蓄積される更新情報例を示す図である。
【図７】本実施形態のバッファ１５に蓄積される更新情報例を示す図である。
【図８】図４に示したステップＳ５の蓄積処理の詳細を示すフロー図である。
【符号の説明】
【００５８】
１        メインフレーム
２、５    ネットワーク
３        サーバＡ、サーバＢ、サーバＣ、…（サーバ３）
４        プロコン
１１      ＡＰプログラム
１２      コントロールプログラム
１３      データベース群
１４      更新情報抽出処理部
１５      バッファ
１６      送受信処理部
１７      バッファ管理部
２１      ＵＡＰ終了判断部
２２      更新処理判断部
２３      対象ＤＢ判断部
２４      蓄積処理部
３２      データ編集部
３３      新データベース
【図１】
2006133999.tif 000003
【図２】
2006133999.tif 000004
【図３】
2006133999.tif 000005
【図４】
2006133999.tif 000006
【図５】
2006133999.tif 000007
【図６】
2006133999.tif 000008
【図７】
2006133999.tif 000009
【図８】
2006133999.tif 000010