JP2006134344A - 電子計算機間のジョブ転送方法およびジョブ転送システム - Google Patents

Abstract

【課題】
計算機間でジョブ転送する場合に、複数のスクリプトを転送すると同時に実行指示することができなかった。複数のスクリプトを事前に転送しておき、実行時には実行指示のみを行なうこともできるが、この方式では、実行コマンドが送られてくるまでスクリプト・ファイルの管理を行なわなければならず、そのバージョン管理などが煩雑で、転送を忘れると間違ったジョブを実行したり、実行の直前にスクリプトを作成または変更してジョブを実行させることができないという問題があった。
【解決手段】
第１の計算機から第２の計算機にリクエストを送ってジョブを登録し実行させるジョブ転送方法において、第２の計算機により前記ジョブを実行した結果作成される複数の結果ファイルを、第２の計算機から第１の計算機に送信するステップと、第１の計算機により、前記複数の結果ファイルを受信するステップとを備えようにする。
【選択図】 図９

Description

本発明は、電子計算機のジョブ転送方法およびシステムに関し、特に複数のスクリプトの転送を可能にしたジョブ転送方法およびシステムに関する。

従来より、あるコンピュータから別のコンピュータにバッチ・ジョブを投入し、当該コンピュータで当該バッチ・ジョブを実行し、その結果をジョブ転送元のコンピュータに返すジョブ転送方式が知られている。バッチ・ジョブは、ある業務を実行したいがその間に別の業務も実行したいときに有用である。ジョブ（ある業務）を投入すると、当該ジョブは一旦キューに登録され、この時点より次のジョブ（別の業務）が投入可能となる。登録されたジョブは、システムが順次取り出して実行する。データの集計処理などのように日次あるいは月次で実行する業務の定形化・自動化を実現するためには、このようなバッチ・ジョブの運用が必須である。

このようなジョブ転送方式としては各種の方式のものが知られているが、大別すると以下の３つのタイプがある。第１は、あるコンピュータから他のコンピュータにジョブ実行指示のみを行なうものである。後述するスクリプトの転送は行なわない。ジョブ実行指示を発行したコンピュータは、指示したジョブの実行状態および結果を、ジョブを実行したコンピュータからステータス情報として受け取る。第２は、あるコンピュータから他のコンピュータに対してジョブ実行指示を行なう直前に１つのスクリプトを転送するものである。この場合、指示したジョブの実行結果は１つの結果ファイルとして返される。スクリプトとは、ジョブを実行するコンピュータに与える複数のコマンドの集合であり、条件分岐などの簡単な制御を行なうことができるようにしたものもある。スクリプトを用いることにより、１回のジョブ投入で、複数のコマンドの一連の実行を行なわせることができる。第３は、ファイル転送またはファイル配布としてジョブの実行指示とは別に事前にスクリプトファイルを転送しておき、後でジョブ実行指示を行なうものである。

ジョブ転送において、転送先のコンピュータで１つのスクリプトから他のスクリプトを呼び出して実行させたい場合がよくある。この場合、１つのジョブが複数のスクリプトファイルから構成されることになるが、上述の第１〜第３の従来の方式では、何れも、複数のスクリプトを転送すると同時に実行指示することができなかった。このため、複数のスクリプトを事前に転送しておき、実行時には実行指示のみを行なう手法を採らざるを得ない。これは上述の従来技術の第３の方式と第１の方式を組み合わせたものである。しかし、この方式では、実行コマンドが送られてくるまでスクリプト・ファイルの管理を行なわなければならず、そのバージョン管理などが煩雑で、転送を忘れると間違ったジョブを実行したり、実行の直前にスクリプトを作成または変更してジョブを実行させることができないという問題があった。

本発明は、上述の従来技術における問題点に鑑み、電子計算機間のジョブ転送方式において、複数のスクリプトの転送を行なうと同時にジョブ実行指示を行なうことのできるジョブ転送方法およびシステムを提供することを目的とする。

上記目的を達成するため、請求項１に係る発明は、第１の計算機から第２の計算機にリクエストを送ってジョブを登録し実行させるジョブ転送方法において、第２の計算機により前記ジョブを実行した結果作成される複数の結果ファイルを、第２の計算機から第１の計算機に送信するステップと、第１の計算機により、前記複数の結果ファイルを受信するステップとを備えたことを特徴とする。

請求項２に係る発明は、第１の計算機から第２の計算機にリクエストを送ってジョブを登録し実行させるジョブ転送方法において、第２の計算機により前記ジョブを実行した結果作成される複数の結果ファイルの内容を含むレスポンス・データ・ストリームを作成するステップと、作成したレスポンス・データ・ストリームを、第２の計算機から第１の計算機に送信するステップと、第１の計算機により、前記レスポンス・データ・ストリーム中の複数の結果ファイルの内容を抽出して、各結果ファイルごとに格納するステップとを備えたことを特徴とする。

請求項３に係る発明は、請求項２において、前記レスポンス・データ・ストリームは、テキストデータ形式であることを特徴とする。

請求項４に係る発明は、ジョブを登録して実行させるためのリクエストを第２の計算機に送信する第１の計算機と、第１の計算機から送信されるリクエストを受信しそのリクエストに基づいてジョブを登録し実行する第２の計算機とを含むジョブ転送システムにおいて、第２の計算機は、前記ジョブを実行した結果作成される複数の結果ファイルを、第２の計算機から第１の計算機に送信する手段を備え、第１の計算機は、前記複数の結果ファイルを受信する手段を備えたことを特徴とする。

請求項５に係る発明は、ジョブを登録して実行させるためのリクエストを第２の計算機に送信する第１の計算機と、第１の計算機から送信されるリクエストを受信しそのリクエストに基づいてジョブを登録し実行する第２の計算機とを含むジョブ転送システムにおいて、第２の計算機は、前記ジョブを実行した結果作成される複数の結果ファイルの内容を含むレスポンス・データ・ストリームを作成する手段と、作成したレスポンス・データ・ストリームを、第２の計算機から第１の計算機に送信する手段とを備え、第１の計算機は、前記レスポンス・データ・ストリーム中の複数の結果ファイルの内容を抽出して、各結果ファイルごとに格納する手段を備えたことを特徴とする。

請求項６に係る発明は、請求項５において、前記レスポンス・データ・ストリームは、テキストデータ形式であることを特徴とする。

以上説明したように、本発明によれば、１回のジョブ転送で複数のスクリプトの転送とその実行の指示を行なえるので、スクリプトの管理が不要になり、間違ったジョブを実行する誤りも無くなる。実行の直前にスクリプトを作成または変更してジョブを実行させることもできる。

以下、図面を用いて本発明の実施の形態を説明する。

図１は、本発明に係るジョブ転送方法を適用したシステムの全体構成例を示す。図１において、１０１〜１０３は、それぞれサーバとなる計算機を示す。１１１〜１１４はクライアントとなる計算機を示す。サーバ１０１〜１０３およびクライアント１１１〜１１４はネットワークに接続されており、各装置間で各種の情報を授受することができる。各クライアント１１１〜１１４からは、サーバ１０１〜１０３にジョブを登録し、各サーバで当該ジョブをバッチ的に実行させ、その結果を各クライアントに返す、という処理が行なえる。ジョブの登録とは、具体的には、所定のジョブ制御言語で記載されたプログラム実行指示をサーバに転送することである。この転送の際、転送データ中に、サーバで実行すべき複数のスクリプトを含めることができる。これにより、１回のジョブ登録で、複数のスクリプトの転送とその実行とを同時に指示することができ、サーバに複雑な処理を行なわせることができる。複数のスクリプトに分けて転送できるので、スクリプトの作成や管理が容易になる。実行の直前にスクリプトを作成または変更してジョブを実行させることもできる。

各サーバおよび各クライアントは、それぞれ独立のプラットフォーム（例えば、UNIX、メインフレーム、またはWindows NT（マイクロソフト社の商品名）など）を使用することができる。クライアントとしては、ジョブ・ランチャ・クライアント、ＷＷＷブラウザ・クライアントなどの各種の方式を用いることができ、また各種のユーザ・プログラムから所定のＡＰＩ（アプリケーション・プログラム・インターフェース）を用いてジョブ登録することも可能である。クライアントからサーバへジョブを登録する操作は、例えば、所定のコマンドを入力すること、あるいは所定のＧＵＩ（グラフィカル・ユーザ・インタフェース）を用いて指示することなどの操作による。サーバに登録したジョブは一旦キューに登録され、クライアントではサーバに問い合わせて当該キューの状態を表示したり、キューに登録したジョブの取り消しを行なうこともできる。クライアントとサーバとの間にサーバ・ゲートウェイを設けても良い。サーバ・ゲートウェイは、各クライアントからの各種リクエスト（要求）を受け付け、それらのリクエストをどのサーバに転送するかを判別し、当該リクエストをそのサーバに転送し、サーバからのリクエスト実行結果をレスポンスデータとして受け取ってまとめ、要求発行元のクライアントに返す、といった処理を行なうものである。

図２は、クライアントとサーバとの間の通信プロトコルの基本動作を説明するための図である。ここではクライアントとサーバとの間にサーバ・ゲートウェイを設ける例を示す。

リクエスト発行側がクライアント２０１である。クライアント２０１では、コマンドの入力あるいはＧＵＩによる指示などに基づいて、サーバに対して各種のリクエストを発行するプログラムが動作する。このプログラムは、ユーザ指定のポートに接続し、各種のリクエストを発行し、接続を解除する、という手順で処理を行なう。発行するリクエストとしては、SUBMIT（ジョブの登録）、ALTER（ジョブの状態変更）、CANCEL（ジョブの削除要求）、ENUMRATE（キュー内にあるジョブの列挙）、およびGET（ジョブ情報の取得）などがある。これらのリクエストは、リクエスト・ブロック２０２と呼ばれるテキスト・ベースのリクエスト・データ・ストリームによってサーバ・ゲートウェイ２０３に転送される。

サーバ・ゲートウェイ２０３は、各クライアントから転送されるリクエスト・ブロック２０２を受信し、そのリクエストを解析し、どのサーバに転送するかを判断し、そのリクエストを当該サーバ２０４に転送し、サーバ２０４から転送されてくる実行結果を受け取ってレスポンスデータを作成し、レスポンス・ブロック２０５と呼ばれるテキスト・ベースのレスポンス・データ・ストリーム２０５を作成してリクエスト発行元のクライアント２０１に返送する。なお、これらのサーバ／クライアント間のコネクションは、リクエスト単位で接続／切断する。また、サーバ・ゲートウェイはサーバ本体と同一サーバ上にあってもよい。

なお、サーバ・ゲートウェイ２０３を設けずに、クライアント２０１とサーバ２０４との間でリクエスト・ブロック２０２およびレスポンス・ブロック２０５を用いて直接通信するようにしてもよい。ただし、サーバ・ゲートウェイ２０３を設ければ、ネットワーク上のリクエスト・ブロック２０２およびレスポンス・ブロック２０５を用いたプロトコル（さらに詳細は図３〜図６で説明する）をサーバ・ゲートウェイ２０３で変換し、サーバ２０４が従来より備えているプロトコルでサーバ２０４とサーバ・ゲートウェイ２０３との間の通信を行なえるので、サーバ２０４側で新たなプロトコルをサポートする必要はない。したがって、サーバ２０４側の修正が不要になるので便宜である。

図３は、ジョブ登録（SUBMIT）、状態変更（ALTER）、削除要求（CANCEL）、およびキュー列挙（ENUMRATE）のリクエストを発行する際の具体的な通信シーケンスを示す。サーバ３０１は、アクセプト命令accept()３１１でクライアント３０２からのコネクト要求を待つ。クライアント３０２は、コネクト命令connect()３２１を発行し、サーバ３０１との接続を確立する。接続確率後、クライアント３０２は、ライト命令write()３２２で、上述のジョブ登録（SUBMIT）、状態変更（ALTER）、削除要求（CANCEL）、およびキュー列挙（ENUMRATE）の何れかのリクエストを送信する。サーバ３０１は、リード命令read()３１２で当該リクエストを受信し、当該リクエストに応じて処理を行ない、その結果をwrite()３１３でクライアント３０２に返す。クライアント３０２は、read()３２３でその結果を受け取る。これらのreadおよびwriteは、データ量に応じて複数回繰り返される。これらの処理の後、サーバ３０１ではクローズclose()３１４を行ない、クライアント３０２ではクローズclose()３２４を行ない、通信シーケンスを終了する。

図４は、ジョブ情報取得（GET）のリクエストを発行する際の具体的な通信シーケンスを示す。ジョブ情報の取得（GET）では、大量のデータを送受信する場合があるので、一度に送受信するデータ量を制限して通信する。具体的には、seriesタグを用いてデータの継続および送受信終了を制御する。また、ジョブ情報取得（GET）では、サーバは取得条件（時刻範囲やジョブ名など）によるフィルタ機能を持つようにしてもよい。

seriesタグを用いたジョブ情報取得（GET）の通信シーケンスについて説明する。図４において、サーバ４０１は、アクセプト命令accept()４１１でクライアント４０２からのコネクト要求を待つ。クライアント４０２は、コネクト命令connect()４２１を発行し、サーバ４０１との接続を確立する。接続確率後、クライアント４０２は、write()４２２でジョブ情報取得要求のリクエストを送信する。サーバ４０１は、read()４１２で当該ジョブ情報取得要求を受信し、当該リクエストに応じて応答すべきジョブ情報を用意する。この応答すべきジョブ情報は大量データであるので、その一部分をwrite()４１３でseries=1としてクライアント４０２に送信する。クライアント４０２は、read()４２３でそのジョブ情報を受信するが、series=1で送られてきているので、引き続き継続データを取得するための要求をwrite()４２４でseries=1として発行する。サーバ４０１は、read()４１４で当該ジョブ情報取得要求を受信し、当該要求に応じて、継続するジョブ情報をwrite()４１５でseries=1としてクライアント４０２に送信する。以上のようにして、必要な回数だけseries=1でwriteおよびread（４１５，４１６，４２５，４２６，…）を繰り返し、サーバ４０１から送るジョブ情報が最終データになったとき、write()４１７でseries=0として最終のジョブ情報を送信し、クライアント４０２ではread()４２７でそのジョブ情報を受信する。read()４２７ではseries=0として受信するので、クライアント４０２ではジョブ情報の最終データであることが分かる。これらの処理の後、サーバ４０１ではclose()４１８を行ない、クライアント４０２ではクローズclose()４２８を行ない、通信シーケンスを終了する。

図５は、図３や図４の通信シーケンスで各リクエストをサーバに送る際に、実際にreadおよびwriteされる通信データの形式を示す。クライアントからwriteされサーバでreadされるリクエスト・データ・ストリーム（図２の２０２）は、ヘッダ部５１０とボディ部５２０からなる。ヘッダ部５１０は、一般ヘッダ５１１およびリクエスト・ヘッダ５１２からなる。ボディ部５２０は、リクエスト・ボディ５２１からなる。サーバからwriteされクライアントでreadされるレスポンス・データ・ストリーム（図２の２０５）は、ヘッダ部５３０とボディ部５４０からなる。ヘッダ部５３０は、一般ヘッダ５３１およびレスポンス・ヘッダ５３２からなる。ボディ部５４０は、レスポンス・ボディ５４１からなる。これらのデータは、テキスト・ベースで「タグ名＝値；」の形式で記述される。タグ名と指定値の文字コードはすべてASCIIコードである。

一般ヘッダ５１１，５３１は、この通信シーケンスのプロトコルのバージョンなどの一般的な情報を含む。リクエスト・ヘッダ５１２は、サーバに対する要求（ジョブ登録（SUBMIT）、状態変更（ALTER）、削除要求（CANCEL）、キュー列挙（ENUMRATE）、あるいはジョブ情報取得（GET））を示す文字列や、ボディ部長さなどの当該リクエストに固有の情報を含む。レスポンス・ヘッダ５３２は、ボディ部長さなどの当該レスポンスに固有の情報を含む。リクエスト・ボディ５２１は、リクエストの内容（例えば、SUBMITであれば、ジョブを登録するキュー名、ジョブに付ける名称、ジョブとして実行するファイル名など）を含む。レスポンス・ボディ５４１は、レスポンスの内容を含む。

特に、リクエスト・ボディ５２１には複数のスクリプトを記述することができる。図６は、リクエスト・ボディ５２１中のスクリプトの記述例を示す。SENDSCRIPT=yes;は、この位置からスクリプトを転送するという宣言である。SCRIPTNAME=script/scripta;は、実際に転送するスクリプトのファイル名であり、ここではscriptaがそのファイル名である。SCRIPTLINES=4;はその後に続くスクリプトの内容の行数を示す。ここでは、SCRIPTLINES=4;の次からの４行分のSCRIPTBODY=…;の行が実際のscriptaの内容である。SUBSET=ENDでscriptaの終わりを示す。同様にして、次にscriptbが記述されている。これを繰り返すことにより、リクエスト・ボディ５２１に複数のスクリプトを記述できる。最後の(NULL)は、転送するリクエスト・データ・ストリームの終わりを示す。

図７は、クライアントがWindows NTである場合に上述した各種リクエストを発行するときに使用するジョブパラメタ定義ファイルを示す。クライアントからサーバにジョブを登録する場合、このような内容のジョブパラメタ定義ファイルを作成して、後述するコマンド解析部（図９の９１１）に渡すと、このコマンド解析部がこのジョブパラメタ定義ファイルを解析して上述したリクエスト・データ・ストリームを作成し、サーバに転送する。

図７のジョブパラメタ定義ファイルは、いわゆるINIファイル形式のテキスト・ベースのファイルである。その内容は、ユーザによるジョブ登録を受け付けるアプリケーション・プログラムで設定・編集するようにしてもよいし、各種のテキスト・エディタで設定・編集することもできる。ジョブパラメタ定義ファイル中、[Trans]で示す部分が、転送すべき複数のファイルを指定する部分である。これにより、複数のスクリプトを転送データ中に含ませることができる。具体的には、各スクリプトをそれぞれ１つのスクリプト・ファイルとして作成し、それらのスクリプト・ファイルを[Trans]の転送ファイルとして指定する。なお、スクリプトを１つ２つと数える単位はそのスクリプトを記述する文法によるものであるから、１つのスクリプト・ファイルに複数のスクリプトを記述することも可能であり、その場合はそのスクリプト・ファイルを[Trans]の転送ファイルとして指定すればよい。

図８は、UNIXの場合のジョブ登録コマンドの例を示す。図８（ａ）に示すようにqsubコマンドでジョブを登録する。その際、オペランドに「-t 転送元ファイル名＝転送先ファイル名」と指定することにより（「＝転送先ファイル名」は指定しなくてもよい）、指定したファイルを転送することができ、これによりスクリプト・ファイルを転送できる。図８（ｂ）は、qsubコマンドでスクリプト・ファイルを転送する具体例である。unix上のスクリプト・ファイルtest.jclを転送先にOJE00001.JCL(JCL01)という名前で格納することを指示している。図８（ｃ）は、２つのスクリプト・ファイルを転送する例である。unix上のスクリプト・ファイルtest01.jclを転送先にOJE00001.JCL(JCL01)という名前で格納し、unix上のスクリプト・ファイルtest01.datを転送先にOJE00001.DATAという名前で格納する。

図９は、ジョブの登録および実行結果の応答に係るクライアントおよびサーバの内部構成を示す。クライアント９１０は、コマンド解析部９１１、登録部９１２、および状態表示部９１３を備えている。サーバ９２０は、リクエスト解析部９２１、ジョブキュー管理部９２２、ジョブキュー９２３、実行管理部９２４、実行部９２５、スクリプト・ファイル格納部９２６、および実行結果格納部９２７を備えている。

コマンド解析部９１１は、ユーザからの指示に基づいてリクエスト・データ・ストリームを作成する。例えば、クライアント９１０がWindows NTベースのマシンであれば、図７で説明したようなジョブパラメタ定義ファイルを作成してコマンド解析部９１１に渡すと、コマンド解析部９１１が当該ジョブパラメタ定義ファイルの内容に基づいて図５および図６で説明したようなリクエスト・データ・ストリームを作成する。クライアント９１０がUNIXベースのマシンであれば、図８で説明したようなqsubコマンドをコマンド解析部９１１に入力すると、コマンド解析部９１１が当該qsubコマンドの指定に基づいて図５および図６で説明したようなリクエスト・データ・ストリームを作成する。何れの場合も、複数のスクリプトを含めてジョブの登録を行なうことができる。

コマンド解析部９１１で作成されたリクエスト・データ・ストリームは、登録部９１２を経由して、サーバ９２０のリクエスト解析部９２１に入力する。このときのデータ授受のプロトコルは、図２〜図６で説明した通りである。サーバ９２０のリクエスト解析部９２１は、受信したリクエスト・データ・ストリームを解析し、当該リクエスト・データ・ストリーム中にスクリプトが含まれている場合は、そのスクリプトを抽出して、スクリプト・ファイル格納部９２６に格納する。その際、リクエスト・データ・ストリーム中に複数のスクリプトが含まれていた場合は、各スクリプトをそれぞれ１つのスクリプト・ファイルとしてスクリプト・ファイル格納部９２６に格納する。例えば、図６のようなデータ・ストリームが入力した場合は、scriptaとscriptbの２つのスクリプト・ファイルとしてスクリプト・ファイル格納部９２６に格納する。

図１０は、リクエスト解析部９２１におけるリクエスト・データ・ストリームの解析処理の一部であり、SENDSCRIPT=yes;を検出したときに実行されるスクリプト抽出処理の手順を示す。SENDSCRIPT=yes;を検出したとき、ステップ１００１で、次の行がSCRIPTNAME=の行か否か判別する。SCRIPTNAME=の行なら、ステップ１００２で、指定された名称のスクリプト・ファイルをスクリプト・ファイル格納部９２６に作成する。次にステップ１００３で、SCRIPTNAME=の行の次のSCRIPTLINESを読み出し、その行数分だけSCRIPTBODYを読み出し、前記スクリプト・ファイルに書き込む。ステップ１００４で当該スクリプト・ファイルをクローズし、ステップ１００１に戻って、次のSCRIPTNAME=があるか否かを判別する。以降は、同様の処理を繰り返し、リクエスト・データ・ストリーム中のすべてのスクリプトを抽出してスクリプト・ファイルに書き込む。これにより、スクリプト・ファイル格納部９２６には、送られてきたリクエスト・データ・ストリーム中のすべてのスクリプトが格納される。

図９に戻って、リクエスト解析部９２１は、上記のようなスクリプトの抽出とともに、ジョブキュー管理部９２２を介して、ジョブキュー９２３にジョブを登録する。クライアントから送信されたリクエスト・データ・ストリームがスクリプトを含まず１つのコマンド（プログラム・ファイル）のみを実行するリクエストであった場合は、そのコマンドの実行命令がジョブキュー９２３に登録される。また、クライアントから送信されたリクエスト・データ・ストリームが１つのスクリプトを含むものであった場合は、そのスクリプトの実行命令がジョブキュー９２３に登録される。クライアントから送信されたリクエスト・データ・ストリームが複数のスクリプトを含むものであった場合は、それらのスクリプトのうち最初に実行すべきスクリプト（以下、メイン・スクリプトと呼ぶ）の実行命令がジョブキュー９２３に登録される。

なお、クライアントが作成してサーバに送るリクエスト・データ・ストリーム中には、サーバで最初に実行すべきファイル名が指定される。したがって、リクエスト・データ・ストリームがスクリプトを含まず１つのコマンド（プログラム・ファイル）のみを実行するリクエストであった場合は、リクエスト・データ・ストリーム中の最初に実行すべきファイル名としてそのコマンドのファイル名が指定されているはずである。同様に、リクエスト・データ・ストリームがスクリプトを含むものである場合は、リクエスト・データ・ストリーム中の最初に実行すべきファイル名として最初に実行すべきスクリプトのファイル名が指定されているはずである。言い替えると、クライアントから送られてくるリクエスト・データ・ストリームは最初に実行すべきコマンドやスクリプトの実行命令を含むものであるから、リクエスト・データ・ストリームからその実行命令を取り出してジョブキューに登録していると見なすことができる。

図１１は、実行管理部９２４の処理ルーチン（一部）を示す。実行管理部９２４は、まずステップ１１０１で、ジョブキュー９２３から次に実行すべきジョブを取り出す。次に実行すべきジョブがどれであるかの判断は、ＯＳ（オペレーティング・システム）の仕様に基づく。次に、ステップ１１０２で、取り出したジョブを実行９２５に渡して実行する。取り出したジョブが１つのコマンドのみの実行命令である場合は、そのコマンドを実行すればよい。取り出したジョブがスクリプトの実行命令である場合は、そのスクリプトを実行する。複数のスクリプトが送られてきているときは、メイン・スクリプトが実行される。メイン・スクリプト実行中に下位のスクリプトが呼び出されて実行される場合があるが、すべてのスクリプトは既に図１０の処理でスクリプト・ファイル格納部９２６に格納されているので、必要なスクリプトはスクリプト・ファイル格納部９２６から取り出して実行する。

次に、ステップ１１０３で、スクリプト（コマンドの実行のときはコマンド）の実行終了を待つ。終了したら、ステップ１１０４で、終了状態を実行結果格納部９２６にログとして記録し（実際には実行部９２５が記録する）、処理を終了する。ログとして記録するのは、例えば、ジョブ名、スクリプト名、結果ファイル名などである。結果ファイル名とは、ステップ１１０２で実行されたコマンド（スクリプトの実行の場合は、そのスクリプト中で実行された各コマンド）ごとに作成された結果ファイルの名称である。各コマンドを実行することにより、そのコマンドに特有の名称で結果ファイルが作成され、実行結果格納部９２７に格納される。したがって、スクリプトの実行により複数のコマンドが実行された場合（通常は、１つのスクリプトは複数のコマンドを含む）は、各コマンドの結果ファイルが作成される。

以上のようにして、バッチ・ジョブの登録と実行が行なわれる。さらにクライアント９１０は、状態表示部９１３を備えており、これにより、登録したジョブに関するジョブ情報取得（GET）を行なうことができる。すなわち、図９において、状態表示部９１３は、例えばユーザからの指示に基づいて、登録したジョブが現在どのような状態にあるかを問い合わせるジョブ情報取得（GET）のリクエストをサーバ９２０のリクエスト解析部９２１に発行する。このジョブ情報取得（GET）のリクエストは、ジョブ情報を取得する対象のジョブを特定するジョブ名などの情報を含む。リクエスト解析部９２１は、実行管理部９２４にジョブ情報取得を要求されたジョブを特定するジョブ名などの情報を渡し、ジョブ情報取得を指示する。

図１２は、リクエスト解析部９２１からの指示に基づいて実行管理部９２４が行なうジョブ情報のGET処理の手順を示す。ステップ１２０１で、ジョブキュー９２３を参照し、指定されたジョブがキュー９２３内にあるか否か判別する。キュー９２３内にあれば、現在実行待ちあるいは実行中であるということだから、その状態を要求発行元のクライアント９１０の状態表示部９１３に返す。指定されたジョブがキュー９２３内にないときは、既に実行終了しているということだから、実行結果格納部９２７に格納されているログを参照し、ログの内容のうち返すべき情報を、レスポンスデータとしてまとめ、状態表示部９１３に返す。

特にこの実施の形態では、スクリプトを実行することにより複数の結果ファイルが実行結果格納部９２７に格納されるので、ジョブ情報取得（GET）では複数の結果ファイルをまとめてクライアントに返せるようにしている。すなわち、図９のクライアント９１０の状態表示部９１３からジョブ情報取得（GET）を発行するとき、そのリクエスト中に、返してもらいたい結果ファイルの名称を複数指定しておき、ステップ１２０３では、実行管理部９２４がそれら指定された名称の複数の結果ファイルを集め、それらの結果ファイルの内容を含むレスポンス・データ・ストリーム（図６）を作成し、図２および図４で説明したような通信シーケンスで状態表示部９１３に返す。

なお、複数の結果ファイルの内容を含むレスポンス・データ・ストリームを作成して状態表示部９１３に送り、状態表示部９１３でそれら複数の結果ファイルを再現するため、実行管理部９２４は複数の結果ファイルの内容を含むレスポンス・データ・ストリームを作成する機能を備え、状態表示部９１３は受信したレスポンス・データ・ストリーム中からそれら複数の結果ファイルを再現する機能を備えている。具体的には、実行管理部９２４は、図５で説明したような複数のスクリプト・ファイルの内容を含むリクエスト・データ・ストリームを作成するのと同様にして、結果ファイルを送ることを宣言するタグでその宣言をし、結果ファイルの名称を指定するタグで結果ファイル名を指定し、ライン数のタグで結果ファイルのライン数を指定し、その後に結果ファイルの内容を並べ、SUBSET=ENDで結果ファイルの終わりを指定し、以上の結果ファイル名の指定からSUBSET=ENDまでを繰り返すことにより任意の数の結果ファイルの内容を含めたレスポンス・データ・ストリームを作成する。また、そのようなリクエスト・データ・ストリームを受信した状態表示部９１３は、図１０で複数のスクリプトを抽出してそれぞれファイルに再現したのと同様にして、リクエスト・データ・ストリーム中から複数の結果ファイルを再現する。

図１３は、クライアント９１０におけるジョブ登録画面の例を示す。ユーザは予めテキスト・エディタなどを用いてスクリプト・ファイルtest01.jclとtest01.datを作成しておく。ジョブを登録するときには、図１３の画面を表示させ、スクリプト転送定義１３０１で指定１３０２をチェックしてスクリプト転送を指定できる。スクリプト・ファイルの指定領域１３０３には、サーバに転送すべき複数のスクリプト・ファイルを記載することができる。図１３の画面で各種情報を設定し、了解ボタン１３０４をオンすることにより、例えば図８（ｃ）で説明したqsubコマンドが図９のコマンド解析部９１１に入力し、上述したように複数のスクリプトを含むジョブ登録を行なうことができる。

図１４は、図９の状態表示部９１３によるジョブ状態表示の例である。状態表示部９１３は、所定時間間隔でジョブ情報取得（GET）を発行し、上述したようにジョブの現在の状態や結果ファイルを取得し、それらを図１４のように一覧表示する。１４０１はジョブの連番、１４０２は当該ジョブの現在の状態が「実行中」であることを示す表示、１４０３は当該ジョブのジョブ名称を示す。１４０４は当該ジョブに含まれるスクリプト・ファイルの名称を示す。ジョブが複数のスクリプトを含む場合は、それら複数のスクリプト・ファイル名がすべて表示される。１４０５はジョブJob2が既に終了状態にあることを示す「終了」の表示である。１４０６は当該ジョブが終了した結果、サーバから受け取っている結果ファイルのファイル名を示す。複数の結果ファイルを受け取っている場合は、それらすべてのファイル名が表示される。

なお、上記実施の形態では、クライアントからサーバにジョブを登録する例で説明したが、同様にして、サーバから別のサーバにジョブを登録して実行させる際にも上述のプロトコルを利用して複数スクリプトを転送することができる。UNIXではサーバ／サーバ間でジョブ転送して負荷分散するのが通常であるので、UNIXベースのクライアントからのジョブの登録は、当該クライアントの側にあるサーバを一旦経由して、ネットワークを介して別のサーバに登録することになる。その場合は、サーバ／サーバ間で上述のプロトコルを利用した通信が行なわれる。

以上説明した実施の形態によれば、ジョブ転送のプロトコルとしてプレーン・テキストのデータ・ストリームを用いているので、ネットワークの種類に依存することなく実装が容易である。また、プレーン・テキスト中でタグを用いた表現で各種のパラメータを指定するので、プロトコルの拡張が容易にできる。プロトコルが拡張され、上位バージョンではタグの種類が増えている場合でも、下位バージョンのシステムが知らないタグを無視することでバージョンが異なるシステム間でも相互接続が可能になる。ユーザインターフェースや実装方法は、システムの事情により種々のバリエーションで実現できる。

本発明に係るジョブ転送方法を適用したシステムの全体構成例を示す図 クライアントとサーバとの間の通信プロトコルの基本動作を説明する図 リクエストを発行する際の具体的な通信シーケンスを示す図 ジョブ情報取得）のリクエストを発行する際の具体的な通信シーケンスを示す図 通信データの形式を示す図 リクエスト・ボディ中のスクリプトの記述例を示す図 ジョブパラメタ定義ファイルの内容を示す図 ジョブ登録コマンドの例を示す図 ジョブの登録および実行結果の応答に係るクライアントおよびサーバの内部構成図 スクリプト抽出処理の手順を示すフローチャート図 実行管理部の処理ルーチン（一部）を示すフローチャート図 ジョブ情報のGET処理の手順を示すフローチャート図 ジョブ登録画面の例を示す図 ジョブ状態表示の例を示す図

符号の説明

１０１〜１０３…サーバ計算機、１１１〜１１４…クライアント計算機、２０１…クライアント、２０２…リクエスト・ブロック（リクエスト・データ・ストリーム）、２０３…サーバ・ゲートウェイ、２０４…サーバ、２０５…レスポンス・ブロック（レスポンス・データ・ストリーム）、９１０…クライアント、９１１…コマンド解析部、９１２…登録部、９１３…状態表示部、９２０…サーバ、９２１…リクエスト解析部、９２２…ジョブキュー管理部、９２３…ジョブキュー、９２４…実行管理部、９２５…実行部、９２６…スクリプト・ファイル格納部、９２７…実行結果格納部。

Claims (6)

1. 第１の計算機から第２の計算機にリクエストを送ってジョブを登録し実行させるジョブ転送方法において、
   第２の計算機により前記ジョブを実行した結果作成される複数の結果ファイルを、第２の計算機から第１の計算機に送信するステップと、
   第１の計算機により、前記複数の結果ファイルを受信するステップと
   を備えたことを特徴とするジョブ転送方法。
2. 第１の計算機から第２の計算機にリクエストを送ってジョブを登録し実行させるジョブ転送方法において、
   第２の計算機により前記ジョブを実行した結果作成される複数の結果ファイルの内容を含むレスポンス・データ・ストリームを作成するステップと、
   作成したレスポンス・データ・ストリームを、第２の計算機から第１の計算機に送信するステップと、
   第１の計算機により、前記レスポンス・データ・ストリーム中の複数の結果ファイルの内容を抽出して、各結果ファイルごとに格納するステップと
   を備えたことを特徴とするジョブ転送方法。
3. 前記レスポンス・データ・ストリームは、テキストデータ形式である請求項２に記載のジョブ転送方法。
4. ジョブを登録して実行させるためのリクエストを第２の計算機に送信する第１の計算機と、第１の計算機から送信されるリクエストを受信しそのリクエストに基づいてジョブを登録し実行する第２の計算機とを含むジョブ転送システムにおいて、
   第２の計算機は、前記ジョブを実行した結果作成される複数の結果ファイルを、第２の計算機から第１の計算機に送信する手段を備え、
   第１の計算機は、前記複数の結果ファイルを受信する手段を備えた
   ことを特徴とするジョブ転送システム。
5. ジョブを登録して実行させるためのリクエストを第２の計算機に送信する第１の計算機と、第１の計算機から送信されるリクエストを受信しそのリクエストに基づいてジョブを登録し実行する第２の計算機とを含むジョブ転送システムにおいて、
   第２の計算機は、
   前記ジョブを実行した結果作成される複数の結果ファイルの内容を含むレスポンス・データ・ストリームを作成する手段と、
   作成したレスポンス・データ・ストリームを、第２の計算機から第１の計算機に送信する手段と
   を備え、
   第１の計算機は、
   前記レスポンス・データ・ストリーム中の複数の結果ファイルの内容を抽出して、各結果ファイルごとに格納する手段を
   備えたことを特徴とするジョブ転送システム。
6. 前記レスポンス・データ・ストリームは、テキストデータ形式である請求項５に記載のジョブ転送システム。

Images