JPH04213126A - ソフトウェアテスト方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、複数の端末とセンタシ
ステムとからなるオンラインシステムにおけるアプリケ
−ションプログラムのテスト方式に関する。

【０００２】

【従来の技術】従来行われているオンライン系ソフトウ
ェアテスト方式では、公開特許公報昭和５８−１１４２
５４　　”会話型システムのテスト方法”に記載されて
いるように、ある会話型システムを新しくバ−ジョンｕ
ｐしようとしたとき、現在稼働中である旧会話型システ
ムにおいて、端末からの入力情報と、会話型システムの
出力情報を、それぞれ入力情報ファイル、出力情報ファ
イルに格納しておく。そして、新規会話型システムをテ
ストするとき、上記入力情報ファイルから端末入力情報
を読み出して、新規会話型システムに入力して実行させ
、新規会話型システムの出力情報と、出力情報ファイル
の内容をチェックしてテストを行っている。　　このよ
うに、オンライン系のプログラムのテストを実行する場
合には、予めセンタ内で、テスト入力用のデ−タをファ
イルに格納しておいて、テストシミュレ−タがファイル
から入力デ−タを取り出して、擬似的に端末入力メッセ
−ジを発生させテストを行うというのが一般的なテスト
方法である。

【０００３】上記、会話型システムの場合は、１つの入
力デ−タに基づいてある業務処理を実行し、その結果と
して１つの出力デ−タが送信されることが予め分かって
いるので、出力デ−タの判定処理を行った後に次の入力
デ−タを順次、新規会話型システムに入力している。

【０００４】しかしながら、実際のオンラインシステム
では、多数の端末から連続的にデ−タが入力され、又、
メッセ−ジ入出力の関係も会話型システムのように１入
力に対して１出力だけではなく、業務処理プログラムに
対応して種々のケ−スが存在する。そのため、テストシ
ミュレ−タでは、デ−タ入力のタイミングを意識しない
で、連続的にテスト用入力デ−タを擬似的に発生させて
いる。そして、出力デ−タをファイルに格納していき、
テスト終了後にファイルのデ−タをチェックしプログラ
ムのテストを行っている。

【０００５】又、テスト入力デ−タをある規則的なタイ
ミングで入力させようとした場合（例えば、テストプロ
グラムＡが問合せメッセ−ジを送信した後、テストプロ
グラＡに応答メッセ−ジを入力させたい場合など）は、
ＨＩＴＡＣマニュアル　　ＶＯＳ３　　ＤＣＣＭ３　　
ユ−ザアプリケ−ションプログラムテスタ　　ＤＣＣＭ
／ＡＴ３に記載されているように、端末からテスト用の
トランザクションを入力する際に、ユ−ザ自身がテスト
トランザクションを入力するタイミングを把握しておい
て、ユ−ザの指示により端末からテストトランザクショ
ンを入力している。そして、端末へのトランザクション
結果や、ユ−ザアプリケ−ションプログラムのトレ−ス
情報を取得してチェックしている。

【０００６】

【発明が解決しようとする課題】従来のオンライン系の
業務処理プログラムのテスト方法では、一端、オンライ
ン処理を停止させてから、プログラムのテストを行なう
ということが前提とされていた。そして、業務処理プロ
グラムへテストデ−タを入力する方法として、大きく以
下の２つがあった。

【０００７】 （１）テストのために用意した入力情報ファイルから順
次メッセ−ジを取り出し、入力するタイミングを意識し
ないで、シミュレ−タがテストプログラムに連続的にメ
ッセ−ジを入力していく方法と、 （２）通常オンライン時のタイミングで、デ−タをテス
トプログラムに入力していく方法。この場合、デ−タを
入力するシミュレ−タが、入力するためのシ−ケンスを
把握しておくか、テストを行うユ−ザ自身が入力メッセ
−ジと出力メッセ−ジの内容をチェックして、デ−タ入
力のタイミング指示を行うかの必要があった。

【０００８】上記（１）の方法では、入力するためのテ
ストデ−タをファイルに格納しておけば、自動的にデ−
タが入力され、テストを実行することが出来る。しかし
、テストプログラムの業務内容によっては、入力を意識
しないで連続的にデ−タが入力されてくるため、テスト
プログラムの実行される順序が崩れてしまい正常なテス
トを行なうことが出来ないという問題が生じてくる。 （この問題についてはあとで詳しく説明する）上記（２
）の方法においては、シミュレ−タがあるシ−ケンスに
従って自動的にデ−タを入力する場合には、ユ−ザが入
力タイミングのシ−ケンスを予め指示する必要が有り、
もう一方の場合には、デ−タ入力のたびにユ−ザが指示
をださなければならないといった問題があり時間がかか
ったり、ミスが発生しやすいという問題があった。

【０００９】上記（１）の方法における問題点を以下、
図２４を用いて具体的に説明する。今、オンライン問合
せ応答ＵＰと送信完了ＵＰが別タスクとして、一連の業
務処理を実行しているとする。初めに、問合せ応答ＵＰ
が端末からの問合せメッセ−ジ（Ａ）を受信する（処理
■）。そして、ファイルを参照し、端末に応答メッセ−
ジ（Ｂ）を送信した後（処理■）、該端末の状態テ−ブ
ルをＡＣＫ待ちにし（処理■）、再度、問合せ待ち状態
にもどる。

【００１０】端末は、正常に応答メッセ−ジを受信した
ことをＵＰに知らせるため、ＡＣＫを示すメッセ−ジ（
Ｃ）を送信する。送信完了ＵＰはこのメッセ−ジを受信
し（処理■）、問合せ応答ＵＰがセットした端末状態テ
−ブルを、ＡＣＫ待ちから、ＡＣＫ受信済みとする（処
理■）。これで、一連の業務処理が終了となり、再度Ａ
ＣＫメッセ−ジ受信待ちとなる。

【００１１】以上が、オンライン中の処理であるが、こ
の送信完了ＵＰへのＡＣＫメッセ−ジ受信（Ｃ）は、問
合せ応答処理ＵＰからの応答メッセ−ジ（Ｂ）送信後に
必ず行なわなければならない。

【００１２】次に、上記、オンライン問合せ応答ＵＰが
機能追加、あるいは、プログラムバグが発生したため、
修正プログラムのテストを実行したとする。機能追加さ
れた新規ＵＰについても、前規ＵＰがサポ−トしていた
入力デ−タについては同じ出力デ−タを返すものとし、
オンライン中に取得した入力デ−タを用いてテストが実
行されるとする。テスト入力デ−タとしてはオンライン
問合せＵＰへの問合せメッセ−ジ（Ａ）と、送信完了Ｕ
ＰへのＡＣＫメッセ−ジ（Ｃ）の２つであり、処理され
た順番に問合せメッセ−ジ（Ａ）、応答メッセ−ジ、（
Ｂ）ＡＣＫメッセ−ジ（Ｃ）の順でそれぞれファイルに
格納されている。

【００１３】以下、テスト処理の流れを示す。初めに、
問合せメッセ−ジ（Ａ）が入力され（処理（１））、問
合せ応答処理ＵＰの業務処理が実行されるが、続けて、
ＡＣＫメッセ−ジ（Ｃ）が入力されるため（処理（２）
）、すぐに送信完了ＵＰの業務処理が実行される。ここ
で、問合せ応答処理ＵＰの業務処理の方で先に端末状態
テ−ブルの更新処理が行なわれれば良いが、ＤＩＳＫア
クセス等で処理がおくれ、送信完了ＵＰの業務処理の方
で先に端末状態テ−ブルの更新処理が行われるというこ
とが発生する（処理（３））。そして、応答メッセ−ジ
送信、テ−ブルセットが処理（４），処理（５）となっ
ていまい、テ−ブルデ−タの誤りが生じてしまう。この
ように上記（１）の方法では、テストデ−タ入力のタイ
ミングがオンライン処理でのデ−タ入出力タイミングと
一致しないことがあり、テストが確実に行えないといっ
た問題があった。

【００１４】本方式の目的は、このような問題を解決し
て、実際のオンライン処理のタイミングにマッチしたテ
ストデ−タの入力処理を行うとともに、オンライン処理
を停止させずに、オンライン処理と並行して効率良くテ
ストを行なうことである。

【００１５】

【課題を解決するための手段】上記課題を解決するため
、複数の端末とセンタシステムからなるオンラインシス
テムにおいて、センタシステムが、少なくとも１つのア
プリケ−ションプログラム（ＡＰ）と、少なくとも１つ
の被テストプログラムと、上記端末と上記ＡＰとの間の
オンライン通信処理を制御するコントロ−ルプログラム
と、ジャ−ナルファイルを備え、上記コントロ−ルプロ
グラムが、 （１）各端末からのＡＰ実行要求メッセ−ジを、指定の
ＡＰに与え、ＡＰ実行結果の送信メッセ−ジを要求元の
端末に送信すると共に、これらのＡＰ実行要求メッセ−
ジ、送信メッセ−ジを上記ジャ−ナルファイルに記憶し
、 （２）被テストプログラムの実行要求をコンソ−ルから
受けたとき、上記、ジャ−ナルファイルから順次にメッ
セ−ジを読み出していき、これがＡＰ実行要求メッセ−
ジならば、メッセ−ジを被テストプログラムへ入力して
実行させ、送信メッセ−ジならば、被テストプログラム
からの送信メッセ−ジの受信を待って、次のメッセ−ジ
を読み出しにいくようにし、 （３）被テストプログラムが送信したメッセ−ジを、送
信要求元の端末に送信しないで、ファイルに格納するよ
うにした。

【００１６】

【作用】上記手段（１）より、テストのために入力する
入力情報、及び、入力情報のタイミングを決定するため
の出力情報がファイルに自動的に収集され、手段（２）
により、ファイルからテスト情報を読み出していき、入
力情報ならば被テストプログラムにメッセ−ジを入力し
てから次のメッセ−ジを読み出しにいき、出力情報なら
ば被テストプログラムのメッセ−ジ送信を待って、次の
メッセ−ジを読み出しにくことができ、又、手段（３）
により被テストプログラムが送信したメッセ−ジを送信
要求元端末に送信せず、ファイルに格納することができ
る。

【００１７】

【実施例】（実施例１） 以下、第１の実施例を図を用いて詳細に説明する。

【００１８】初めに、本特許が対象とするネットワ−ク
の全体構成を図２に示す。複数のノ−ドプロセッサ２０
１〜２０６が高速ＬＡＮ２０７によって接続されており
、各ノ−ドプロセッサには情報を格納するためのファイ
ル２０８，２０９や、通信回線２１０〜２１８を介して
複数の端末２２０〜２２８が接続されている。そして、
各ノ−ドプロセッサ、及び、各端末を識別するために、
各ノ−ドプロセッサにはそれぞれノ−ドＮｏが割り当て
られ、又、各ノ−ドプロセッサに接続される端末に対し
ては論理端末Ｎｏが割り当てられる。ここで、各ノ−ド
プロセッサには、業務処理プログラム（ユ−ザが作成す
るプログラムのことで以下、ＵＰと呼ぶ）のメッセ−ジ
受信要求、送信要求により、端末に対するメッセ−ジ送
受信処理を行うためのソフトウェア（ＯＣＰ：オンライ
ン　コントロ−ル　プログラム）が搭載されている。そ
して、ＵＰの要求によりノ−ド間メッセ−ジ通信（図２
の■）、ノ−ド間問合せ応答通信（図２の■）、端末へ
の一方向通信（図２の■）の３つのタイプの通信を行な
うことができる。ユ−ザは種々の業務処理プログラムを
作成することで、端末に対するメッセ−ジの集配信や、
端末からの問合せ応答処理などのサ−ビスを行うことが
できる。

【００１９】次に、本特許であるＵＰテスト機能の概略
処理について図１を用いて説明する。詳細については後
で記述する。

【００２０】ＵＰテスト機能を実施する場合、端末／Ｌ
ＡＮ等の回線からのメッセ−ジをテスト入力用に収集す
る必要がある。本方式では、オンライン中の受信メッセ
−ジだけでなく、送信メッセ−ジについても同一ファイ
ルに収集する。このファイルのことをＴＴＪ（Ｔｅｓｔ
　Ｔｒａｎｓａｃｔｉｏｎ　Ｊｏｕｒｎａｌ）、又は、
単にジャ−ナルと呼び、実際には後述するジャ−ナル取
得モ−ドであるオンラインＵＰがメッセ−ジ受信要求、
及び、送信要求を行った時にジャ−ナルの収集処理を行
う。図１のオンラインＵＰ１０１は端末からの問合せ応
答処理を行っている。オンラインＵＰはＯＣＰに対して
受信要求を発行し、端末からのメッセ−ジ受信待ち状態
になる。ＯＣＰ１０３は通信制御装置（ＣＣＵ）１０５
を介して端末１０７，１０９からメッセ−ジを受信する
と（図１の■）、ＵＰにメッセ−ジを渡すとともに、該
ＵＰがジャ−ナル取得モ−ドならば受信メッセ−ジをコ
ピ−し、入力を表す識別コ−ドを付加してジャ−ナル取
得ファイル１１０にメッセ−ジを格納する（図１の■）
。次に、オンラインＵＰは入力メッセ−ジを元に業務処
理を実行しＯＣＰに対して送信要求を発行する。ＯＣＰ
は端末への送信処理を実行するとともに（図１の■）、
該ＵＰが、ジャ−ナル取得モ−ドならば送信メッセ−ジ
のコピ−に出力を表す識別コ−ドを付加して、ジャ−ナ
ル取得ファイルにメッセ−ジを格納する（図１の■）。 このようにして、ＵＰの入出力メッセ−ジをジャ−ナル
取得ファイルに順次格納していく。テスト実行時は、被
テストＵＰ１１２をロ−ディングし、ＴＴＧタスク（Ｔ
ｅｓｔ　Ｔｒａｎｓａｃｔｉｏｎ　Ｇｅｎｅｒａｔｅ）
１１４を起動する。ここで、ＴＴＧタスクとは被テスト
ＵＰをオンライン処理と並行してテストを実行させるた
めのトランザクション生成タスクである。まず、ジャ−
ナル取得ファイルからメッセ−ジを読み出し（図１の■
）、そのメッセ−ジの識別コ−ドが入力ならば該メッセ
−ジを被テストＵＰに入力し（図１の■）、出力ならば
（図１の■）、被テストＵＰがメッセ−ジを送信するま
で待つ（図１の■）。そして、被テストＵＰが送信した
ら（図１の■）、その出力メッセ−ジをテスト結果出力
ファイル１１６に格納し（図１の（１０））、再び、ジ
ャ−ナル取得ファイルを読みに行く。ユ−ザはテスト結
果出力ファイルの内容をチェックしてＵＰテストをオン
ライン処理と並行して実行する。以上がＵＰテスト機能
の概略処理である。

【００２１】次に、図３〜図２０を用いて詳細について
示す。

【００２２】図３は、ノ−ドプロセッサ内のソフト構成
と、処理デ−タフロ−を示す図である。

【００２３】オンライン用バッファ３０１は、端末や他
ノ−ドプロセッサからの受信メッセ−ジを格納する受信
バッファと、ＵＰが作成する送信メッセ−ジを格納する
送信バッファから構成される。送信バッファと受信バッ
ファは同じ構成であり、図４に示す構成になっている。 即ち、バッファにはｃｃｕ（通信制御処理装置）で１回
の送受信処理で通信することができるメッセ−ジ最大長
の長さのエリア４０１〜４０９が複数個用意されている
。１エリアに対しては、固定的に１つのｍｃｂ（メッセ
−シ゛　コントロ−ル　フ゛ロック）が割り当てられて
おり、このｍｃｂが後述するトランザクション管理テ−
ブルの受信メッセ−ジのキュ−に接続される。ｍｃｂは
次に接続されるｍｃｂのアドレス、割り当てられている
バッファのアドレス、及び、格納されるメッセ−ジのデ
−タ長をセットするエリア４１０〜４１３で構成されて
いる。この割り当てバッファのアドレス（エリア４１２
）はＯＣＰイニシャル処理のテ−ブル生成時にセットさ
れる。本実施例では、端末回線、及び、ＬＡＮからのメ
ッセ−ジは複数に分割されて送信されることはなく、１
バッファエリアに１つのメッセ−ジが格納されるものと
する。

【００２４】テスト用バッファ３０３は、被テストＵＰ
と前述のＴＴＧタスクがテストメッセ−ジや、テスト結
果を送受するためのバッファであり、上記オンライン用
バッファ３０１と同一構造を持つ。

【００２５】オンライントランザクション管理テ−ブル
３０５は、端末やＬＡＮから受信したメッセ−ジをその
ｔｃｄ（情報の種類を表すコ−ド）毎に、ＦＩＦＯ（Ｆ
ｉｒｓｔ　Ｉｎ　Ｆｉｒｓｔ　Ｏｕｔ：先入れ先出し）
のキュ−にて管理するためのテ−ブルであり、図５に示
すように、ｔｃｄ毎に、受信メッセ−ジキュ−の先頭ポ
インタと最終ポインタ、登録メッセ−ジ数、起動タスク
Ｎｏ、及び、該タスクがメッセ−ジ受信待ち状態か業務
処理実行中かを識別するステ−タスフラグ（ｓｆフラグ
）を格納するエリア５０１〜５０５から構成されている
。ｔｃｄ毎にエントリ−を設ける理由は、ｔｃｄ対応に
メッセ−ジが引き渡されるＵＰが予め決められているか
らである。又、受信メッセ−ジキュ−にはｍｃｂが順次
ＦＩＦＯで接続されていく。

【００２６】テストトランザクション管理テ−ブル３０
７は、テスト入力メッセ−ジをＴＣＤ毎に、ＦＩＦＯの
キュ−にて管理するためのテ−ブルであり、上記、オン
ライントランザクション管理テ−ブルと同一の構成にな
っている。又、テスト結果トランザクション管理テ−ブ
ル３０９は、被テストＵＰの送信メッセ−ジをＦＩＦＯ
のキュ−にて管理するテ−ブルである。このテ−ブルの
構成は図５と同じ構成であるが１エントリ−である。こ
れは、被テストＵＰが送信するメッセ−ジは、全てＴＴ
Ｇタスクが受信するためであり、テスト結果トランザシ
ョン管理テ−ブルの起動タスクＮｏには、ＴＴＧタスク
のタスクＮｏがセットされる。

【００２７】このｍｃｂは、オンライン用とテスト用に
それぞれ送信バッファ用と受信バッファ用があるが、こ
れら全てのｍｃｂはシステム立ち上げ時、空きバッファ
管理テ−ブルにキュ−として登録されている。そして、
このキュ−からｍｃｂを取り出してバッファを確保し、
使用済みバッファのｍｃｂをキュ−に接続することによ
りバッファの解放が行われる。

【００２８】オンライン用空きバッファ管理テ−ブル３
１１は、オンライン用送受信バッファの空きエリアを管
理するためのテ−ブルであり、図６に示すように、空き
バッファｍｃｂの先頭ポインタと最終ポインタ、空きバ
ッファ個数をセットするエリア６０１〜６０３，６０４
〜６０６が２組設けられている。一方を送信バッファ空
きｍｃｂの管理に使用し、もう一方を受信バッファ空き
ｍｃｂの管理に使用する。

【００２９】テスト用空きバッファ管理テ−ブル３１３
は、テスト用送受信バッファの空きエリアを管理するた
めのテ−ブルであり、上記オンライン用空きバッファ管
理テ−ブル３１１と同一構造になっている。

【００３０】端末回線用ｃｃｕ送信管理テ−ブル３１５
、及び、ＬＡＮ用ｃｃｕ送信管理テ−ブル３１７は、オ
ンラインＵＰから送信要求されたメッセ−ジを管理する
ためのテ−ブルであり、図７に示すように、ＬＡＮ用の
場合には、送信先ノ−ドプロセッサのノ−ドＮｏ毎に、
端末回線用の場合には、送信先端末の論理端末Ｎｏ毎に
エントリ−が設けられている。各エントリ−には、送信
待ちメッセ−ジのキュ−先頭ポインタと最終ポインタ、
送信待ちメッセ−ジの数をセットするエリア７０１〜７
０３で構成されている。ＵＰからのメッセ−ジ送信要求
によってｃｃｕ送信管理テ−ブルのキュ−に送信メッセ
−ジのｍｃｂが登録され、送信処理が行われる。オンラ
インテ−ブル３４１、テストテ−ブル３４５は、それぞ
れオンラインＵＰ、テストＵＰが業務処理にて参照、更
新するテ−ブルである。

【００３１】ＵＰモ−ド管理テ−ブル３４３は、ＵＰ毎
に該ＵＰがオンラインＵＰか否か、及び、該ＵＰがジャ
−ナル取得中か否かを識別するためのキ−となるジャ−
ナルＮｏを管理するためのテ−ブルであり、図８に示す
ように、ＵＰタスクＮｏに対応して、ＵＰモ−ドフラグ
とジャ−ナルＮｏをセットするエリア８１，８２で構成
されている。ＵＰモ−ドフラグは当該ＵＰがオンライン
ＵＰか被テストＵＰかを識別するフラグ、ジャ−ナルＮ
ｏはジャ−ナルの種類を表すＮｏである。ジャ−ナルＮ
ｏは、業務処理単位に応じて割当てる番号であり、複数
のＵＰで１つの業務処理を実現する場合には、複数ＵＰ
間で同じジャ−ナルＮｏを持つことになる。これらＵＰ
モ−ドフラグ、ジャ−ナルＮｏは、ユ−ザがＵＰ登録時
にセットする。

【００３２】ジャ−ナル要求テ−ブル３４７は、上記Ｕ
Ｐモ−ド管理テ−ブルにてセットしたジャ−ナルＮｏに
対応して、ジャ−ナル取得要か否か、及び、ジャ−ナル
取得開始のタイミングを制御するためのテ−ブルである
。 即ち、図９に示すようにジャ−ナルＮｏに対応して、Ｔ
ＴＪ要求フラグ、ＴＴＪ取得フラグをセットするエリア
９１，９２で構成されている。ＴＴＪ要求フラグはジャ
−ナル取得要か否かを識別するフラグ、ＴＴＪ取得フラ
グはジャ−ナル取得状態か否かを識別するフラグである
。このように、ジャ−ナルＮｏ毎にエントリ−を設ける
のは、ユ−ザがジャ−ナル取得を要求するときに、ジャ
−ナルＮｏを指定して要求するからである。ジャ−ナル
取得管理テ−ブル３４９は、ジャ−ナル取得先ファイル
を管理するためのテ−ブルであり、図１０に示すように
、ジャ−ナル取得ファイルＩＤと、ファイルに取得する
ジャ−ナル取得数、ファイルに既に格納されているジャ
−ナル格納数、ファイル書き込みポインタ（ｗｐ）、読
み出しポインタ（ＲＰ）、オンラインＵＰの出力ジャ−
ナルと被テストＵＰの出力結果のマッチングを行うか否
かを識別する出力マッチングフラグを格納するエリア１
１〜１６で構成されている。

【００３３】ＴＣＤ取得管理テ−ブル３５１は、オンラ
インＵＰの入出力メッセ−ジのジャ−ナル取得と同期し
て、該ＵＰが参照、更新するオンラインテ−ブルのコピ
−（ＴＣＤ：Ｔｅｓｔ　Ｃｈｅｃｋｐｏｉｎｔ　Ｄｕｍ
ｐ）を取得するときに使用するテ−ブルであり、構成を
図１１に示す。テ−ブルの名称、テ−ブルエリアアドレ
ス、テ−ブルサイズをセットするエリア１１１〜１１３
で構成されている。ユ−ザは予め、各テ−ブルに対して
それぞれのエリアアドレスとサイズを登録しておく必要
がある。

【００３４】テスト結果出力ファイル３６１は、被テス
トＵＰが送信したメッセ−ジを格納するファイルである
。 ジャ−ナル取得ファイル３６３は、取得要求のあったＵ
Ｐのジャ−ナルを格納するファイル、ＴＣＤ取得ファイ
ル３６５は、ＴＣＤを格納するファイルである。

【００３５】ｃｃｕ受信処理タスク３７１、ＬＡＮ受信
処理タスク３７３は、それぞれ端末回線用ｃｃｕ３８１
、及び、ＬＡＮ用ｃｃｕ３８２からの受信メッセ−ジを
取り込み、上記オンライントランザクション管理テ−ブ
ルの受信メッセ−ジキュ−に登録する処理を行なう。又
、ｃｃｕ送信処理タスク３７５、ＬＡＮ送信処理タスク
３７７は、それぞれ上記、端末回線用ｃｃｕ送信管理テ
−ブル３１５、ＬＡＮ用ｃｃｕ送信管理テ−ブル３１７
の送信キュ−に登録されているメッセ−ジをｃｃｕ／ｔ
、及び、ｃｃｕ／ｌに出力する処理を行う。

【００３６】次に、図３を用いて端末からの問合せメッ
セ−ジをオンラインＵＰ３２１が受信し、業務処理を実
行後、その結果を応答メッセ−ジとして端末に送信する
場合の、端末／回線〜ＣＣＵ〜ＯＣＰ〜ＵＰ間の処理と
デ−タの流れを説明する。

【００３７】初めに、ＯＣＰはイニシャル処理で各種テ
−ブル，ファイルの生成後、全てのオンラインＵＰを起
動する。ここで、オンラインＵＰは、業務処理を実行す
るためＯＣＰに対してメッセ−ジ受信要求（ｇｅｔｒａ
ｎ）の発行を行う。

【００３８】ここで、ｇｅｔｒａｎは以下に示すインタ
フェ−スである。

【００３９】ｇｅｔｒａｎ（ｔｃｄ，＆ｍｃｂ，ｃｐｆ
）；ｔｃｄは受信要求するメッセ−ジのｔｃｄであり、
ｍｃｂは受信したメッセ−ジのｍｃｂアドレスがセット
される。ｃｐｆ（チェックポイントフラグ）はトランザ
クションの同期点を通知するためのフラグである。 同期点は一連の業務処理が終了し、次の業務処理に移る
開始点のことである。本実施例では、ユ−ザから後述す
るジャ−ナル取得要求がきたときに、同期点の時点から
ジャ−ナルを取得するが、ＯＣＰでは同期点を知ること
は出来ないので、ユ−ザはメッセ−ジ受信要求と送信要
求において同期点を通知する必要がある。

【００４０】メッセ−ジ受信要求のフロ−を図１２に示
す。ＵＰよりｇｅｔｒａｎが発行されると、発行したＵ
ＰタスクＮｏを識別し、ＵＰモ−ド管理テ−ブルよりＵ
Ｐモ−ドフラグ、ジャ−ナルＮｏを読み込む。そして、
ＵＰモ−ドフラグより発行ＵＰがオンラインＵＰか被テ
ストＵＰかをチェックする。そして、オンラインＵＰな
らば、オンライントランザクション管理テ−ブルのメッ
セ−ジキュ−を、被テストＵＰならばテストトランザク
ション管理テ−ブルのメッセ−ジキュ−をチェックし、
ＵＰが要求した情報がキュ−に接続されているか否かを
確認する（処理１２０１）。キュ−に接続されていれば
、キュ−を取り外してメッセ−ジを取り出しＵＰに引き
渡す（ｇｅｔｒａｎのパラメ−タにてｍｃｂアドレスが
渡される）（処理１２０３）。キュ−に接続されていな
ければｗａｉｔ状態とする（処理１２０２）。このｗａ
ｉｔ状態はメッセ−ジが受信された後、受信処理タスク
よって再起動されるまでつづく。　　次に、ジャ−ナル
取得処理が行なわれる。ジャ−ナルＮｏよりジャ−ナル
要求テ−ブルを参照し、ＴＴＪ要求フラグと、ＴＴＪ取
得フラグをチェックする。 （処理１２０４，１２０５）。ＴＴＪ要求フラグがｏｆ
ｆならば処理を終了しＵＰに処理をもどす。ＴＴＪ要求
フラグとＴＴＪ取得フラグが共にｏｎならばＴＴＪ取得
処理を実行する（処理１２０６）。ＴＴＪ要求フラグが
ｏｎでＴＴＪ取得フラグｏｆｆならばｇｅｔｒａｎ発行
時のパラメ−タｃｐｆにて同期点指定があるか否かを識
別する（処理１２０７）。同期点指定がない場合は処理
を終了する。これら処理１２０４〜１２０７は、ユ−ザ
がジャ−ナル収集を要求した後、最初の同期点を検知し
てからＴＴＪを取得するためである。同期点指定がある
場合は、ＵＰモ−ド管理テ−ブルの取得フラグをｏｎに
し（処理１２０８）、ＴＴＪ取得処理（処理１２０９）
、及び、ＴＣＤ取得処理を実行し（処理１２１１）処理
を終了する。

【００４１】ＴＴＪ取得処理は、まず、ジャ−ナル取得
管理テ−ブル３４９を参照して、ジャ−ナル取得ファイ
ルＩＤ、書き込みポインタ（ｗｐ）を読み込み、ｗｐの
位置にジャ−ナルを書き込む。そして、ｗｐの位置を書
き込んだジャ−ナルのサイズ分ほど更新し、又、ジャ−
ナル取得管理テ−ブルのジャ−ナル格納数をインクリメ
ントする。ここで、ジャ−ナルファイルの構成とフォ−
マットを図１３に示す。即ち、ジャ−ナルファイルの１
レコ−ドはヘッダ部１３０１とデ−タ部１３０２からな
っている。 デ−タ部はＵＰに対して入出力したメッセ−ジである。 ヘッダ部はジャ−ナル種別、タスクＮｏ、トランザクシ
ョン通番、ｔｃｄ、ノ−ドＮｏ、論理端末Ｎｏ、取得時
刻、デ−タ長をセットするエリア１３０３〜１３１０で
構成されている。ジャ−ナル種別は、ＵＰがｇｅｔｒａ
ｎ発行時は入力トランザクション（ＩＮ）とし、後述す
るメッセ−ジ送信要求ｐｕｔｒａｎ発行時には引き数で
ある通信タイプで指定されたトランザクションとしてフ
ァイルに格納する。ｐｕｔｒａｎ発行時の通信タイプは
出力トランザクション（ＯＵＴ）か、問合せトランザク
ション（ＩＮＱ）のどちらかであり、ジャ−ナル種別と
してはＯＵＴかＩＮＱのどちらかがセットされる。また
、ｐｕｔｒａｎでＩＮＱを指定した場合の応答トランザ
クションについては応答トランザクション（ＲＳＰ）を
ジャ−ナル種別としてセットする。タスクＮｏには該処
理を発行したＵＰのタスクＮｏをセットする。トランザ
クション通番は、回線からセンタに受信されたメッセ−
ジ順序を表すものであり、第３の実施例で使用される。 ノ−ドＮｏ、論理端末Ｎｏは、メッセ−ジ受信要求のと
きには、メッセ−ジ送信元のアドレスを、受信要求のと
きには、メッセ−ジ送信先のアドレスをセットする。取
得時間はジャ−ナルをファイルに格納した時間である。

【００４２】ジャ−ナル格納後、ジャ−ナル取得数と格
納数が一致したならば、ジャ−ナル取得処理を終了させ
るため、ジャ−ナル要求テ−ブルをリセットする。

【００４３】次に、ＴＣＤ取得処理では、ＴＣＤ取得管
理テ−ブルよりテ−ブル毎に、格納エリア、デ−タサイ
ズを順次、読み取りＴＣＤ取得テ−ブルに格納していく
。そして、全エントリ−のテ−ブルのデ−タをＴＣＤ取
得ファイルに格納する。

【００４４】以上がメッセ−ジ受信要求のフロ−である
。

【００４５】さて、図３ではシステム立ち上げ後、最初
に受信要求が発行されたものとし、トランザクションは
発生しておらず、オンラインＵＰはｗａｉｔ状態となっ
ているものとする。このとき、端末回線／ＬＡＮからメ
ッセ−ジがくるとｃｃｕは、指定されているバッファエ
リアに受信メッセ−ジを格納した後、受信処理タスクに
メッセ−ジ受信割込み（ＲＩ）を通知する（図３の■）
。

【００４６】ここで、受信メッセ−ジのフォ−マットを
図１４に示す。このフォ−マットは、ＬＡＮを介した他
ノ−ド内のＵＰとの送受信メッセ−ジ、及び、自ノ−ド
内の送受信メッセ−ジにも適用される。エリア１４０１
はヘッダを含むメッセ−ジ長をセットし、エリア１４０
２と１４０３は送信先アドレス、送信元アドレスをセッ
トする。ここで、送信先アドレス、送信元アドレスはノ
−ドＮｏと論理端末Ｎｏをセットするエリア１４０７〜
１４１０で構成されている。エリア１４０４にはｔｃｄ
がセットされ、エリア１４０５には通信タイプがセット
される。以上がヘッダ情報であり、その後にデ−タがセ
ットされる（エリア１４０６）。通信タイプには、メッ
セ−ジが一方向か問合せ／応答かのどのタイプかをセッ
トする。

【００４７】ｃｃｕから受信割込みの通知を受けると、
受信処理タスクは図１５に示すフロ−を実行する。まず
、次に受信されるメッセ−ジの格納エリアをｃｃｕに通
知するため、オンライン用受信バッファ空き管理テ−ブ
ルより空きｍｃｂを取り出し（処理１５０１）、そのｍ
ｃｂに割り当てられているバッファのアドレスをｃｃｕ
に通知する（処理１５０２）。次に、受信したメッセ−
ジのｔｃｄを識別し、受信メッセ−ジのｍｃｂをオンラ
イントランザクション管理テ−ブルの処理待ちキュ−に
登録する（処理１５０３，１５０４）。この時、ｍｃｂ
のデ−タ長をセットするエリアに受信デ−タ長をセット
しておく。次に、トランザクション管理テ−ブルのｓｆ
をチェックし、起動タスクがメッセ−ジ受信待ちか処理
中かをチェックする（処理１５０５）。処理中ならばそ
のまま終了しｃｃｕからのＲＩ受信待ちとなる。メッセ
−ジ受信待ちならば該タスクを起動して終了する（処理
１５０６）。

【００４８】次に上記、受信処理タスクにおいて、当該
ＵＰが起動されると、メッセ−ジ受信処理（ｇｅｔｒａ
ｎ）内で、ＵＰへのメッセ−ジ引渡し処理、及び、ジャ
−ナル取得処理が行なわれる（図３の■）。

【００４９】該ＵＰがジャ−ナル取得モ−ドならば、ジ
ャ−ナルがジャ−ナル取得ファイル３６３に格納される
。

【００５０】尚、このジャ−ナル取得モ−ドへの切替は
、ジャ−ナル収集コマンドによって実行され、ユ−ザは
このコマンドを発行することによりジャ−ナルの収集を
行なうことができる。以下に、インタフェ−スと処理内
容について示す。

【００５１】 ｇｅｔｔｔｊ　　ｊｎｏ，ｊｎｕｍ ｊｎｏは取得するジャ−ナルＮｏであり、ｊｎｕｍは取
得したいジャ−ナルの数である。このコマンドを発行す
ることにより、指定したジャ−ナルＮｏに対応するＴＴ
Ｊ要求管理テ−ブルテ−ブルのＴＴＪ要求フラグがｏｎ
され、又、ジャ−ナル取得管理テ−ブルのジャ−ナル取
得数がｊｎｕｍで指定された値となる。そして、ジャ−
ナル取得モ−ドとなったＵＰがメッセ−ジ受信要求、及
び、送信要求を行なうことによりジャ−ナルの収集が行
われる。

【００５２】さて、ＵＰはメッセ−ジ受信要求にて受信
メッセ−ジのｍｃｂアドレスが渡され、受信バッファア
ドレスが分かるので、直接受信バッファ内のメッセ−ジ
にアクセスし業務処理を実行する。そして、不要となっ
た受信バッファを解放し、送信メッセ−ジを作成するた
め送信バッファをオンライン用空きバッファ管理テ−ブ
ルのキュ−から確保し、確保した送信バッファ内のエリ
アに直接メッセ−ジを作成していく（図３の■）。次に
、送信メッセ−ジの編集終了後、ＵＰは以下に示すイン
タフェ−スに従って、メッセ−ジ送信要求（ｐｕｔｒａ
ｎ）を発行する。

【００５３】 ｐｕｔｒａｎ（ｔｃｄ，＆ｍｃｂ，ｌｔｎ，ｃｏｍｔｙ
ｐｅ，ｃｐｆ，ｒｍｃｂ）；ｔｃｄは送信要求するメッ
セ−ジのｔｃｄであり、ｍｃｂ，ｌｔｎ，ｃｏｍｔｙｐ
ｅには送信するメッセ−ジのｍｃｂアドレス、送信先論
理端末Ｎｏ、メッセ−ジの通信タイプをそれぞれセット
する。通信タイプには上述で述べたように、出力メッセ
−ジか、問合せメッセ−ジのどちらかをセットする。ｃ
ｐｆは同期点を通知するためのフラグである。ｒｍｃｂ
は通信タイプが問合せメッセ−ジの場合のみ有効であり
、受信した応答メッセ−ジのｍｃｂのアドレスがセット
される。このメッセ−ジ送信要求の処理フロ−を図１６
に示す。

【００５４】初めに、送信要求を発行したタスクＮｏを
識別しＵＰモ−ド管理テ−ブルを参照する。そして該Ｕ
Ｐが、オンラインＵＰか被テストＵＰかのチェックと、
ジャ−ナルＮｏをチェックする。

【００５５】処理１６０１〜１６０７は、メッセ−ジ受
信要求での処理１２０４〜１６１０と同じでありジャ−
ナルを取得する処理（図３の■）である。

【００５６】ジャ−ナル取得処理実行後、発行ＵＰがオ
ンラインＵＰか被テストＵＰかによって処理が異なる（
処理１６０８）。最初にオンラインＵＰの場合について
説明する。初めにメッセ−ジの通信タイプをチェックす
る（処理１６０９）。ここで、問合せメッセ−ジの場合
、オンライン問合せ応答処理を実行し（処理１６１１）
、ＴＴＪ取得フラグがｏｎならば応答メッセ−ジに対し
てＴＴＪ取得処理を実行して終了する（処理１６１２，
１６１３）。出力メッセ−ジの場合は、オンライン送信
処理を実行し終了する（処理１６１０）。次に、被テス
トＵＰの場合について説明する。初めに、通信タイプを
識別する（処理１６１４）。出力メッセ−ジならば、テ
スト結果トランザクション管理テ−ブルの処理待ちキュ
−に登録する（処理１６１５）。そして、ｓｆフラグを
チェックして（処理１６１６）、起動ＵＰ（ＴＴＧタス
ク）がメッセ−ジ受信待ちならば処理待ちタスクを起動
して終了する（処理１６１７）。処理１６１４で問合せ
メッセ−ジならば、問合せメッセ−ジをテスト結果トラ
ンザクション管理テ−ブルの処理待ちキュ−に登録し、
ＴＴＧタスクが受信待ちならば起動する（処理１６１８
〜１６２０）。そして、ＴＴＧタスクからの応答メッセ
−ジ受信待ちとなる。応答メッセ−ジが渡されると、被
テストＵＰが問合せメッセ−ジ送信要求（ｐｕｔｒａｎ
ライフ゛ラリ）にて指定した引き数であるｒｍｃｂ（応
答メッセ−ジｍｃｂのアドレス設定エリア）に、応答メ
ッセ−ジが格納されたｍｃｂアドレスをセットし（処理
１６２１）、ＵＰに処理を移す。ここで、オンライン送
信処理（処理１６１０）、オンライン問合せ処理（処理
１６１１）について引き数であるｒｍｃｂ（応答メッセ
−ジｍｃｂのアドレス設定エリア）に、応答メッセ−ジ
が格納されたｍｃｂアドレスをセットし（処理１６２１
）、ＵＰに処理を移す。ここで、オンライン送信処理（
処理１６１０）、オンライン問合せ処理（処理１６１１
）についてより詳細に説明する。

【００５７】オンライン送信処理は、まず、メッセ−ジ
の送信先論理端末Ｎｏを参照して、対応するｃｃｕ送信
管理テ−ブルのキュ−に送信要求のあったメッセ−ジの
ｍｃｂを登録する。そして、該メッセ−ジの他に送信待
ちメッセ−ジがあるか否かをチェックする。このとき、
送信先論理端末Ｎｏから、対象となるｃｃｕ送信管理テ
−ブルをチェックする。もし送信待ちメッセ−ジ１つも
なければ、送信メッセ−ジのアドレス、デ−タ長、送信
先を指定してｃｃｕに送信要求を行い処理を終了する。 送信待ちメッセ−ジが他にある場合は、ｃｃｕに送信要
求を行わず終了する。

【００５８】オンライン問合せ処理は、引き数で指定さ
れた問合せメッセ−ジをオンライン送信処理と同様の処
理で送信した後、応答メッセ−ジ受信待ちとなる。そし
て、応答メッセ−ジが受信されると、格納した応答メッ
セ−ジのｍｃｂのアドレスをパラメ−タにて引き渡し終
了する。

【００５９】以上のメッセ−ジ送信要求処理により、Ｕ
Ｐが送信要求を発行したときに、該ＵＰがジャ−ナル取
得状態ならば、ジャ−ナル取得処理が行なわれ、ジャ−
ナル取得ファイルに格納される。そして、送信要求を発
行したＵＰがオンラインＵＰならば、上記メッセ−ジ送
信要求処理にて、送信メッセ−ジｍｃｂがｃｃｕ送信管
理キュ−に登録され、他に送信待ちメッセ−ジがなけれ
ば、ｃｃｕに送信要求が発行され送信される（図３の■
）。送信待ちメッセ−ジが他にある場合は、該メッセ−
ジは一旦、送信待ちキュ−に接続された後、送信処理タ
スクによって、ｃｃｕに送出される。

【００６０】オンラインＵＰは受信した一問合せについ
て、以上に示した業務処理を終了すると、再度メッセ−
ジ受信待ちに戻り、繰り返し業務処理を実行する。この
とき、上記オンラインＵＰがジャ−ナル取得要ならば、
入力、出力メッセ−ジの順で繰り返しファイルに格納さ
れていく。

【００６１】次に、オンライン処理と並行して実行され
る被テストＵＰ３２３の処理について示す。この被テス
トＵＰは、上記オンラインＵＰのバ−ジョンアップされ
たものであり、オンラインＵＰが送受信した時に取得し
たジャ−ナルを用いてテストを行う。　　ＵＰテストの
開始は、後述するＵＰテスト起動コマンド（ｔｅｓｔｕ
ｐ）の発行により実行されるが、コマンドを発行する前
に、以下の準備が必要となる。　　被テストＵＰが業務
処理で使うテ−ブルをＴＣＤ取得ファイルからロ−ディ
ングしておき、その後、被テストＵＰをロ−ディングす
る。そして、テストモ−ドで初期起動する。被テストＵ
Ｐのロ−ディングにおいては、ＴＣＤからロ−ディング
したテ−ブルとのリンケ−ジも行う。

【００６２】以上で示した手続きの後、ｔｅｓｔｕｐコ
マンドを発行する。このｔｅｓｔｕｐのインタフェ−ス
は以下に示すとおりである。

【００６３】 ｔｅｓｔｕｐ　　ｍｏｄｅ ここで、ｍｏｄｅには被テストＵＰの出力結果と、テス
ト結果出力ファイルに格納された出力メッセ−ジの比較
チェック（マッチング処理）を行うか否かのモ−ドを指
定する。

【００６４】このｔｅｓｔｕｐが発行されると、引き数
であるｍｏｄｅを読み込み出力マッチング指定があるか
否かを識別し、指定がある場合は、ジャ−ナル取得管理
テ−ブルの出力マッチングフラグをｏｎにする。そして
、ＴＴＧタスクが起動されＵＰテストを開始することが
出来る。

【００６５】ＴＴＧタスクの処理フロ−を図１７に示す
。

【００６６】イニシャル処理として、読み出しポインタ
（ＲＰ）をＴＴＪ取得ファイルの先頭アドレスにセット
する（処理１７０１）。そして、ＲＰが指すトランザク
ションを読み出す（処理１７０２）。次に、ノ−ドＮｏ
、論理端末Ｎｏ、ジャ−ナル種別をチェックする（処理
１７０３，１７０４）。そして、ジャ−ナル種別によっ
て処理が異なる。 初めにジャ−ナル種別が入力か応答トランザクションの
場合について述べる。先ず、テスト用の空き受信バッフ
ァを確保する（処理１７０５）。そして、確保した受信
バッファにメッセ−ジを格納する（処理１７０６）。そ
して、入力トランザクションの場合には、テストトラン
ザクション管理テ−ブルの処理待ちキュ−に格納した受
信バッファのｍｃｂを登録し、該メッセ−ジ起動タスク
が受信待ちならば起動する（処理１７０７，１７０８）
。応答トランザクションの場合には、応答メッセ−ジ受
信待ちである被テストＵＰにメッセ−ジを引渡す（被テ
ストＵＰの問合せメッセ−ジ送信要求（ｐｕｔｒａｎラ
イフ゛ラリ）処理内で引き渡される）（処理１７０７，
１７０９）。そして、ＲＰを次レコ−ドに更新し（処理
１７１０）、トランザクションがあるか否かをチェック
し（処理１７１１）ある場合は処理１７０２に戻り、な
い場合は処理を終了する。　　次に、ジャ−ナル種別が
、出力か、問合せトランザクションの場合について述べ
る。この場合は被テストＵＰがメッセ−ジを送信するの
で、ＴＴＧタスクはメッセ−ジ受信要求（ｇｅｔｒａｎ
）の受信処理（処理１２０１〜１２０３）と同様に、テ
スト結果トランザクション管理テ−ブルの処理待ちキュ
−をチェックし、接続されていればメッセ−ジを取りだ
し、接続されていなければｗａｉｔ状態とする。（処理
１７１２）。そして、メッセ−ジが受信されると、その
メッセ−ジをテスト結果出力ファイルに格納する（処理
１７１３）。次に、ジャ−ナル取得管理テ−ブルの出力
マッチングフラグをチェックする（処理１７１４）。出
力マッチングフラグがｏｆｆならば受信した送信メッセ
−ジのバッファを解放し（処理１７１６）、処理１７１
０に移る。ｏｎならば、受信したメッセ−ジと、ＲＰが
指す出力トランザクションが一致するかをチェックし一
致しない場合のみ、トランザクション不一致としてアラ
−ム表示する（処理１７１５）。そして、処理１７１６
を実行し、処理１７１０に移る。以上がＴＴＧタスクの
処理である。

【００６７】上記、ＴＴＧタスクの処理により、ジャ−
ナル取得ファイルから読み出したメッセ−ジの識別コ−
ドが、入力あるいは、応答メッセ−ジならば、テスト用
の受信バッファにメッセ−ジを格納し、被テストＵＰに
メッセ−ジを渡すことができ、識別コ−ドが出力、ある
いは、問合せならば、被テストＵＰがメッセ−ジを送信
するまで待って、次のメッセ−ジを読み出しに行くこと
ができる。

【００６８】ジャ−ナル取得ファイルの先頭には入力メ
ッセ−ジが格納されているので、ＴＴＧタスクは受信メ
ッセ−ジをバッファに格納し、処理待ちキュ−に登録す
る（図３の■）。受信メッセ−ジキュ−に登録されたメ
ッセ−ジは、メッセ−ジ受信要求を発行している被テス
トＵＰに渡される（図３の■）。被テストＵＰは業務処
理を実行後、不要となった受信バッファを解放する。そ
して、送信バッファを確保し送信メッセ−ジを作成した
後、メッセ−ジ送信要求を発行する（図３の■）。メッ
セ−ジ送信要求処理では、発行したＵＰが被テストＵＰ
ならば、テスト結果トランザクション管理テ−ブルの受
信メッセ−ジキュ−に登録する。

【００６９】一方、ＴＴＧタスクは、入力メッセ−ジを
被テストＵＰに引き渡した後、ジャ−ナル取得ファイル
から次メッセ−ジを読みだし、出力メッセ−ジであるの
で、被テストＵＰのメッセ−ジ送信待ち状態となってお
り、上記、被テストＵＰの送信メッセ−ジがテスト結果
トランザクション管理テ−ブルのキュ−に登録され時点
で、起動され、メッセ−ジをテスト結果出力ファイルに
格納する（図３の■）。以上が、ＯＣＰと、オンライン
ＵＰ、被テストＵＰとのメッセ−ジ送受信の流れである
。

【００７０】以上では端末からの問合せメッセ−ジに対
して、１つのＵＰが処理を行い応答を返す場合のジャ−
ナル取得とテストに対して示したが、以下では、端末問
合せ中継処理ＵＰと、端末メッセ−ジ送信完了処理ＵＰ
の２つのＵＰで、１つの業務処理を行っている場合につ
いて示す。ここで、端末問合せ中継処理ＵＰというのは
、端末からある種の問合せメッセ−ジがくると、自プロ
セッサでは業務処理が実行できないため、処理すること
ができる他ノ−ドプロセッサに対して問合せを行い、そ
の応答メッセ−ジを元に、送信メッセ−ジを作成し問合
せ端末に送信するというものである。又、端末メッセ−
ジ送信完了ＵＰは、端末側が応答メッセ−ジを正常受信
したことをノ−ドプロセッサに通知するため、ＡＣＫを
示すメッセ−ジを送信するが、このメッセ−ジを受信す
ることによって、業務処理が実行されるＵＰである。

【００７１】初めに、この端末問合せ中継処理ＵＰのフ
ロ−を図１８に示す。

【００７２】初めに、メッセ−ジ受信要求（ｇｅｔｒａ
ｎ）を発行して、端末からのメッセ−ジ受信待ち状態に
なる（処理１８０１）。尚、この受信処理は一業務処理
の開始点であるので同期点指定とする。メッセ−ジが受
信されると、ｇｅｔｒａｎでは、受信バッファのｍｃｂ
のアドレスをＵＰに引き渡す。ＵＰはｍｃｂのアドレス
を元に受信バッファアドレス、メッセ−ジ長を読み取り
、メッセ−ジの内容をチェックする（処理１８０２）。 そして、不要となったバッファを解放する（処理１８０
３）。次に、他ノ−ドプロセッサへの問合せメッセ−ジ
を作成するため、送信バッファを確保し、問合せメッセ
−ジを作成する（処理１８０４）。作成後、メッセ−ジ
送信要求（ｐｕｔｒａｎ）を発行する（処理１８０５）
。ここで、ｐｕｔｒａｎの引き数である通信タイプ（ｃ
ｏｍｔｙｐｅ）には、”問合せ”をセットする。これに
より、ｐｕｔｒａｎの処理で他ノ−ドに対して問合せメ
ッセ−ジ送信後、応答メッセ−ジ受信処理が行われる。 応答メッセ−ジが受信されると、ＵＰに応答メッセ−ジ
のｍｃｂアドレスが渡されるので、応答メッセ−ジを解
析し、受信バッファを解放する（処理１８０６，１８０
７）。次に、端末への出力メッセ−ジを作成するため送
信バッファを確保する。そして、確保したバッファエリ
アに、出力メッセ−ジを作成し（処理１８０８）、メッ
セ−ジ送信要求（ｐｕｔｒａｎ）にて問合せのあった端
末にメッセ−ジを送信する（処理１８０９）。送信後、
次の問合せ処理のため、処理１８０１に戻り、繰り返し
実行していく。

【００７３】次に、端末メッセ−ジ送信完了ＵＰの処理
フロ−を図１９で説明する。メッセ−ジ受信要求（ｇｅ
ｔｒａｎ）を発行して、端末からのＡＣＫメッセ−ジ受
信待ちになる（処理１９０１）。メッセ−ジが受信され
ると、メッセ−ジの内容をチェックし業務処理を実行す
る（処理１９０２）。 そして、不要となったバッファを開放し（処理１９０３
）、処理１９０１に戻る。

【００７４】ここで、あるタイミングでユ−ザから端末
問合せ中継処理ＵＰと端末メッセ−ジ送信完了ＵＰに対
して、ジャ−ナル収集コマンド（ｇｅｔｔｔｊ）が発行
されたとする。すると、同期点通知時点で、ジャ−ナル
が収集され、又、ＴＣＤ取得処理が実行される。その後
、メッセ−ジ受信要求（ｇｅｔｒａｎ）、メッセ−ジ送
信要求（ｐｕｔｒａｎ）にてジャ−ナルが収集されてい
き、ユ−ザが要求した件数ほどジャ−ナルが格納されて
いく。

【００７５】このジャ−ナル収集の様子を図２０に示す
。図中の番号はメッセ−ジが発生した順番を示している
。端末Ａからの問合せメッセ−ジ■、他ノ−ドプロセッ
サへの問合せメッセ−ジ■と、応答メッセ−ジ■、端末
への出力メッセ−ジ■がそれぞれ、入力トランザクショ
ン（ＩＮ）、問合せトランザクション（ＩＮＱ）応答ト
ランザクション（ＲＳＰ）、出力トランザクション（ｏ
ｕｔ）としてジャ−ナル取得ファイルに格納され、次に
、端末Ｂから問合せメッセ−ジを受信し■、それから端
末Ａからメッセ−ジ送信完了ＵＰの受信メッセ−ジ■が
、入力トランザクション（ＩＮ）として格納される。

【００７６】次に、問合せ応答中継処理ＵＰと、送信完
了処理ＵＰをそれぞれバ−ジョンアップしたものを被テ
ストＵＰとしてコ−ディングし、起動しておきテストを
行なう。そのため、ＵＰテスト起動コマンドが出力マッ
チング指定で発行され、ＴＴＧタスクが起動されたとす
る。

【００７７】ＴＴＧタスクは、ジャ−ナル取得ファイル
に格納されている最初のトランザクションを読み出す。 入力トランザクションであるので、問合せメッセ−ジを
作成して、テスト用トランザクション管理テ−ブルに登
録する。そして、２番目のトランザクションを読み出す
。問合せトランザクションであるので、被テストＵＰが
メッセ−ジを送信するまで待つ。メッセ−ジが送信され
るとメッセ−ジを取り出し、ジャ−ナル取得ファイルの
２番目のトランザクションと一致するかをチェックする
とともに、送信メッセ−ジをテスト結果出力ファイルに
格納する。次に、３番目のトランザクションを読みだす
。応答トランザクションであるので被テストＵＰに引渡
し、４番目のトランザクションを読みだす。出力である
ので被テストＵＰが送信したメッセ−ジを取り出し、上
記４番目のトランザクションと一致するかをチェックす
るとともに、テスト結果出力ファイルに格納する。次に
、５番目のトランザクションを取りだし、入力であるの
で入力メッセ−ジを作成してテスト用トランザクション
管理テ−ブルに登録する。又、次の６番目のトランザク
ションが入力であるので、続けて、入力メッセ−ジを作
成して、テスト用トランザクション管理テ−ブルに登録
する。このように、ＴＴＧタスクは収集したジャ−ナル
がなくなるまで処理を実行していく。ユ−ザは、マッチ
ング処理結果、及び、テスト結果出力ファイルをチェッ
クすることにより被テストＵＰのテストを行っていく。

【００７８】上記のようにＴＴＧタスクは、ジャ−ナル
取得ファイルから順次読み出していき、出力メッセ−ジ
、あるいは、問合せメッセ−ジならば、被テストＵＰが
送信するまで待って、次入力メッセ−ジあるいは、問合
せメッセ−ジを被テストＵＰに渡すので、オンライン処
理のときと同様のタイミングで、メッセ−ジを被テスト
ＵＰに渡すことができる。

【００７９】（実施例２） 以下、第２の実施例について説明する。

【００８０】第１の実施例ではオンライン中に取得した
入力メッセ−ジをそのまま被テストＵＰに入力している
が、ＵＰのテストでは、処理対象である全てのパタ−ン
の入力メッセ−ジと、エラ−処理等のチェックをするた
め、通常では入力されない異常メッセ−ジをＵＰに入力
してテストする必要がある。そのため、本実施例ではテ
ストのためにユ−ザが入出力メッセ−ジを編集できる機
能を追加する。

【００８１】ジャ−ナル（オンライン入出力メッセ−ジ
）の収集処理は第１の実施例と同じであり、ユ−ザは、
ジャ−ナル編集作業を始める前に、ｇｅｔｔｔｊコマン
ドをコンソ−ルより入力して、必要なジャ−ナルを予め
収集しておく必要がある。

【００８２】ジャ−ナル収集処理が完了し、ジャ−ナル
編集処理の開始は、ユ−ザがｊｅｄｉｔコマンドをコン
ソ−ルより入力することにより実行される。

【００８３】このｊｅｄｉｔコマンドの処理フロ−を図
２１に示す。初めに、読み出しポインタ（ｒｐ）を収集
したジャ−ナルの先頭レコ−ドにセットする（処理２１
０１）。そして、ｒｐからヘッダをサ−チし、メッセ−
ジ長を読み取り、１メッセ−ジ分をコンソ−ルディスプ
レイに表示する（処理２１０２，２１０３）。次に、ユ
−ザから該メッセ−ジの編集要求があるか否かをユ−ザ
のキ−入力より確認し（処理２１０４）、編集要求が要
ならば、スクリ−ンイメ−ジでユ−ザに編集させる。ユ
−ザはディスプレイに表示されているメッセ−ジに対し
て、編集が必要なデ−タの位置にカ−ソルを移動させ、
キ−入力で編集することにより行うことができる。ユ−
ザより編集終了の指示がくると、ディスプレイより編集
メッセ−ジを読み出す（処理２１０５，２１０６）。そ
して、ジャ−ナル取得管理ファイルに格納されている編
集前メッセ−ジをユ−ザが編集した編集後メッセ−ジに
書き変る（処理２１０７）。以上で、１メッセ−ジつい
ての編集処理が完了する。処理２１０４で、ユ−ザから
該メッセ−ジの編集要求がなければ、処理２１０８に移
る。次に、編集続行か否かをユ−ザに確認し（処理２１
０８）、続行ならばｒｐを次レコ−ドに更新して（処理
２１０９）、処理２１０２に移る。編集終了ならば処理
を終了する。

【００８４】上記処理より、オンライン処理で取得した
入出力メッセ−ジを編集する。

【００８５】被テストＵＰのテスト方法は、第１の実施
例と同じであり、ジャ−ナル収集処理完了後、ｔｅｓｔ
ｕｐコマンドを実行することによりテストを行なうこと
ができる。

【００８６】上記処理より、ユ−ザがテストのために編
集した入力メッセ−ジを被テストＵＰに入力し、テスト
を行なうことができる。

【００８７】（実施例３） 第３の実施例について説明する。

【００８８】第１の実施例でのジャ−ナル収集処理は、
オンラインＵＰが発行したメッセ−ジ入力要求処理、及
び、出力要求処理の中でジャ−ナル取得ファイルに収集
しており、収集したメッセ−ジの順で、被テストＵＰに
メッセ−ジを入力している。しかし、このメッセ−ジの
順序は、実際に回線から受信されたメッセ−ジの順序と
異なっている。これは、複数のＵＰが存在する場合、Ｏ
Ｓの平行スケジュ−リングのために、メッセ−ジが実際
にＵＰに入力される順番がメッセ−ジの受信順序と異な
り、そのため、ジャ−ナルファイルへの格納順序がずれ
てしまうからである。この順序のくるいはＵＰのテスト
には影響しないが、回線からのメッセ−ジ受信処理のチ
ェックにおいては、実際の回線から入ってきた順番でメ
ッセ−ジを入力してやる必要がある。例えば、端末から
のメッセ−ジが、分割され複数のメッセ−ジで受信され
てくるときなど、メッセ−ジ組立処理を行なうサブル−
チンをユ−ザが作成し、上記受信処理タスク内に組み込
む必要がある。このユ−ザが組み込んだサブル−チンの
テストを行なう場合は、回線から入力されてきたメッセ
−ジの順に、センタ内の受信処理タスクにメッセ−ジを
引き渡す必要があり、以下、その方法について示す。

【００８９】まず、ＯＣＰシステム内でトランザクショ
ン通番を一括して管理する。

【００９０】そして、メッセ−ジ単位にトランザクショ
ン通番を付加するため、図２２に示すようにｍｃｂにト
ランザクション通番をセットするエリア２２０４を追加
する。

【００９１】このトランザクション通番のセットは受信
処理タスクで行われる。即ち、ｃｃｕからメッセ−ジが
受信され、受信メッセ−ジｍｃｂをトランザクション管
理テ−ブルに接続するとき、ＯＣＰシステム内で管理し
ているトランザクション通番を読み取り、ｍｃｂ内のセ
ットエリアにトランザクション通番をセット後、処理待
ちキュ−に接続する。そして、ＯＣＰ内で管理している
トランザクション通番を更新する。上記処理によって、
トランザクション通番と、回線からのメッセ−ジ入力順
番が一致するようになる。トランザクション通番のセッ
トと、トランザクション通番の更新処理以外は第１の実
施例と同じであり省略する。

【００９２】さらに、第１の実施例のＴＴＪ取得処理に
おいて、受信メッセ−ジのコピ−をジャ−ナルファイル
に格納するときのヘッダ部作成処理において、トランザ
クション通番をセットする処理を追加する。

【００９３】さて、ユ−ザからジャ−ナル収集コマンド
（ｇｅｔｔｔｊコマンド）が起動されると、上記で述べ
たような理由で、ジャ−ナル取得ファイルにはトランザ
クション通番とは異なる順番で入力メッセ−ジが格納さ
れている。

【００９４】このジャ−ナルを用いてテストするときは
、まず、ジャ−ナルソ−トコマンド（ｊｓｏｒｔ）を発
行して、順番通りに並び変えを行う。

【００９５】ｊｓｏｒｔコマンドは、ジャ−ナル取得フ
ァイルから、受信メッセ−ジ（入力、応答トランザクシ
ョン）のトランザクション通番を順次チェックしていき
、トランザクション通番の小さいものから順に、ソ−ト
結果ファイルに格納していき、並び変えをおこなってい
く。

【００９６】そして、ｊｓｏｒｔコマンド実行後、ソ−
トしたソ−ト結果ファイルから１メッセ−ジづつ取り出
していき、受信バッファを確保した後、バッファ内にメ
ッセ−ジを格納し、図２３に示した受信処理を起動させ
る。この処理をファイル内メッセ−ジがなくなるまで繰
返し、実行していく。これにより、回線から入力したメ
ッセ−ジの順で受信処理タスクに、メッセ−ジを渡すこ
とができる。

【００９７】

【発明の効果】本発明によれば、実際のオンライン処理
のタイミングと同じタイミングで被テストプログラムに
自動的にデ−タが入力されるので、新しく更新した被テ
ストプログラムやバグ修正プログラムのテストを効率良
く実行することが出来る。例えば、プログラムが異常終
了したときなど、異常終了時のデ−タで、再起動させる
ことにより原因究明などのテストを繰返し行うことがで
き、修正したプログラムのテストにおいても、異常終了
が起こったときと同一環境下でテストすることができる
ので、ユ−ザが確実にテストできる環境を提供すること
が出来る。

【図面の簡単な説明】

【図１】ＵＰテスト処理の概略図

【図２】システム全体の構成図

【図３】ＯＣＰのテ−ブル、ファイル構成、及びデ−タ
フロ−を示す図

【図４】バッファの構成図

【図５】トランザクション管理テ−ブルの構成図

【図６
】空きバッファ管理テ−ブルの構成図

【図７】ｃｃｕ送
信管理テ−ブルの構成図

【図８】ＵＰモ−ド管理テ−ブ
ルの構成図

【図９】ジャ−ナル要求テ−ブルの構成図

【
図１０】ジャ−ナル取得管理テ−ブルの構成図

【図１１
】ＴＣＤ取得管理テ−ブルの構成図

【図１２】メッセ−
ジ受信要求処理のフロ−を示す図

【図１３】ジャ−ナル
フォ−マット

【図１４】メッセ−ジのフォ−マット

【図１５】受信処理タスクのフロ−を示す図

【図１６】
メッセ−ジ送信要求処理のフロ−を示す図

【図１７】Ｔ
ＴＧタスクのフロ−を示す図

【図１８】問合せ中継処理
ＵＰのフロ−を示す図

【図１９】送信完了処理ＵＰのフ
ロ−を示す図

【図２０】問合せ中継処理ＵＰと送信完了
処理ＵＰのジャ−ナル取得図

【図２１】第２の実施例のｊｅｄｉｔコマンドの処理フ
ロ−を示す図

【図２２】第３の実施例のｍｃｂの構成図

【図２３】第
３の実施例の受信処理のフロ−を示す図

【図２４】発明
の解決しようとする課題における従来問題点の説明図

Claims (7)

【特許請求の範囲】
1. 【請求項１】複数の端末とセンタシステムからなるオン
   ラインシステムにおいて、センタシステムが、少なくと
   も１つのアプリケ−ションプログラム（ＡＰ）と、少な
   くとも１つの被テストプログラムと、上記端末と上記Ａ
   Ｐとの間のオンライン通信処理を制御するコントロ−ル
   プログラムと、ジャ−ナルファイルを備え、上記コント
   ロ−ルプログラムが、各端末からのＡＰ実行要求メッセ
   −ジを、指定のＡＰに与え、ＡＰ実行結果の送信メッセ
   −ジを要求元の端末に送信すると共に、これらのＡＰ実
   行要求メッセ−ジ、送信メッセ−ジを上記ジャ−ナルフ
   ァイルに記憶し、被テストプログラムの実行要求をコン
   ソ−ルから受けたとき、上記、ジャ−ナルファイルから
   順次にメッセ−ジを読み出していき、これがＡＰ実行要
   求メッセ−ジならば、メッセ−ジを被テストプログラム
   へ入力して実行させ、送信メッセ−ジならば、被テスト
   プログラムからの送信メッセ−ジの受信を待って、次の
   メッセ−ジを読み出しにいくようにし、被テストプログ
   ラムが送信したメッセ−ジを、送信要求元の端末に送信
   しないで、ファイルに格納するようにしたことを特徴と
   するソフトウェアテスト方式。
2. 【請求項２】特許請求項第１項記載のソフトウェアテス
   ト方式において、コントロ−ルプログラムは、ジャ−ナ
   ルファイルにメッセ−ジを格納する時、ＡＰ実行要求メ
   ッセ−ジには入力を表すコ−ドを付加し、送信メッセ−
   ジには出力を表すコ−ドを付加して格納しておき、ジャ
   −ナルファイルからメッセ−ジを読み出すとき、該コ−
   ドを識別して被テストプログラムのテストを行うように
   したことを特徴とするソフトウェアテスト方式。
3. 【請求項３】特許請求項第１項記載のソフトウェアテス
   ト方式において、コントロ−ルプログラムは、被テスト
   プログラムがメッセ−ジ送信を行なった時、該メッセ−
   ジとジャ−ナルファイルに格納されている送信メッセ−
   ジの内容が一致するか否かをチェックし、その結果をユ
   −ザに通知することを特徴とするソフトウェアテスト方
   式。
4. 【請求項４】特許請求項第１項記載のソフトウェアテス
   ト方式において、コントロ−ルプログラムはユ−ザから
   指定されたＡＰに対するＡＰ実行要求メッセ−ジ、及び
   、送信メッセ−ジをジャ−ナルファイルに格納するよう
   にし、この収集するＡＰを少なくとも一つ以上指定でき
   ることを特徴とするソフトウェアテスト方式。
5. 【請求項５】特許請求項第１項記載のソフトウェアテス
   ト方式において、アプリケ−ションプログラムが、コン
   トロ−ルプログラムに対して、メッセ−ジ受信要求、及
   び、メッセ−ジ送信要求を行なうとき、該要求が一連の
   業務処理の開始点であることを指定できるようにし、コ
   ントロ−ルプログラムは、ＡＰ実行要求メッセ−ジ、送
   信メッセ−ジの格納処理をユ−ザから要求されたとき、
   アプリケ−ションプログラムから指定された業務処理の
   開始点から、ジャ−ナルファイルへの格納を開始するよ
   うにしたことを特徴とするソフトウェアテスト方式。
6. 【請求項６】特許請求項第１項記載のソフトウェアテス
   ト方式において、ジャ−ナルファイルに格納したメッセ
   −ジを被テストプログラムの処理に合わせて修正、編集
   できるようにしたことを特徴とするソフトウェアテスト
   方式。
7. 【請求項７】特許請求項第１項記載のソフトウェアテス
   ト方式において、コントロ−ルプログラムは、回線から
   メッセ−ジを受信した時点で、受信メッセ−ジに対して
   受信した順序を表す通番を付加しておき、被テストプロ
   グラムを実行させるとき、ジャ−ナルファイルの入力メ
   ッセ−ジを通番の順で並び変えてからテストを開始する
   ことを特徴とするソフトウェアテスト方式。