(57)【要約】【課題】ローディングの効率化を図る。【解決手段】ジョブ処理装置は、外部デバイスに格納されたデータセットであって、ジョブを構成する各ジョブステップを実行するためのロードモジュールをメンバとして含むデータセット中のメンバ情報をメモリ領域上でジョブステップ毎に設けられた複数のメンバ情報格納領域に格納するメンバ情報取得部と、各ジョブステップの実行時に、実行対象のロードモジュールの情報を含むメンバ情報を検索するために前記複数のメンバ情報格納領域に対する並列検索を行う検索制御部と、検索されたメンバ情報を用いた前記実行対象のロードモジュールのローディングを行うローディング制御部とを含む。【選択図】図１
2010231333.tif 000002
【特許請求の範囲】
【請求項１】
外部デバイスに格納されたデータセットであって、ジョブを構成する各ジョブステップを実行するためのロードモジュールをメンバとして含むデータセット中のメンバ情報をメモリ領域上でジョブステップ毎に設けられた複数のメンバ情報格納領域に格納するメンバ情報取得部と、
前記各ジョブステップの実行時に、実行対象のロードモジュールの情報を含むメンバ情報を検索するために前記複数のメンバ情報格納領域に対する並列検索を行う検索制御部と、
検索されたメンバ情報を用いた前記実行対象のロードモジュールのローディングを行うローディング制御部と
を含むジョブ処理装置。
【請求項２】
前記各ジョブステップの実行前に、前記複数のメンバ情報格納領域に格納されたメンバ情報が前記外部デバイス上で更新されているか否かを判定する更新確認部をさらに含み、
前記メンバ情報取得部は、前記更新確認部によって更新されたメンバ情報が発見された場合に、この更新されたメンバ情報を前記外部デバイスから得て対応する前記メンバ情報格納領域に格納する
請求項１に記載のジョブ処理装置。
【請求項３】
前記メンバ情報取得部は、前記複数のジョブステップの実行順序を前記メモリ領域上に設けられた検索順序領域に格納し、
前記ローディング制御部は、前記複数のジョブステップの実行順序と合致するメンバ情報格納領域に格納されたメンバ情報を用いた前記実行対象のロードモジュールのローディングを行う
請求項１又は２に記載のジョブ処理装置。
【請求項４】
コンピュータに、
外部デバイスに格納されたデータセットであって、ジョブを構成する各ジョブステップを実行するためのロードモジュールをメンバとして含むデータセット中のメンバ情報をメモリ領域上でジョブステップ毎に設けられた複数のメンバ情報格納領域に格納するステップと、
前記各ジョブステップの実行時に、実行対象のロードモジュールの情報を含むメンバ情報を検索するために前記複数のメンバ情報格納領域に対する並列検索を行うステップと、
検索されたメンバ情報を用いた前記実行対象のロードモジュールのローディングを行うステップと
を実行させるプログラム。
【請求項５】
前記各ジョブステップの実行前に、前記複数のメンバ情報格納領域に格納されたメンバ情報が前記外部デバイス上で更新されているか否かを判定するステップと、
更新されたメンバ情報が発見された場合に、この更新されたメンバ情報を前記外部デバイスから得て対応する前記メンバ情報格納領域に格納するステップと
をさらにコンピュータに実行させる請求項４に記載のプログラム。
【請求項６】
前記複数のジョブステップの実行順序を前記メモリ領域上に設けられた検索順序領域に格納するステップと、
前記複数のジョブステップの実行順序と合致するメンバ情報格納領域に格納されたメンバ情報を用いた前記実行対象のロードモジュールのローディングを行うステップと
をさらにコンピュータに実行させる請求項４又は５に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ジョブ処理装置に関する。
【背景技術】
【０００２】
従来、オンラインシステムの初期設定処理で、このオンラインシステムで使用するアプリケーションプログラムの格納された外部記憶装置のディレクトリ部を読み込み、ディレクトリ部をアプリケーションプログラム名称の昇順に並べてメモリ内のシステム共通領域に確保したディレクトリ格納領域に設定する技術がある（例えば、特許文献１参照）。特許文献１記載の技術では、ロードモジュールのロード要求が発生した時、このディレクトリ格納領域を二分探索法により探索し、ロードモジュールのディレクトリ情報を求めてそれをローダーに渡す。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平５−１５８７０１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上述した従来技術では、以下の問題点があった。すなわち、第１に、ディレクトリ部がシステム共通領域に設定されるので、大量のディレクトリ部がシステム共通領域に設定された場合には、システム共通領域の容量が不足する可能性があった。第２に、アプリケーションプログラムが更新された場合に、人為的介入によるシステム共通領域上のディレクトリ部情報が更新されなければ、更新アプリケーションプログラムを適正にロードできない可能性があった。
【０００５】
本発明の一態様の目的は、ローディング効率化を図ることを可能にするジョブ処理装置を提供することである。
【課題を解決するための手段】
【０００６】
本発明の態様の一つは、ジョブ処理装置であって、外部デバイスに格納されたデータセットであって、ジョブを構成する各ジョブステップを実行するためのロードモジュールをメンバとして含むデータセット中のメンバ情報をメモリ領域上でジョブステップ毎に設けられた複数のメンバ情報格納領域に格納するメンバ情報取得部と、
前記各ジョブステップの実行時に、実行対象のロードモジュールの情報を含むメンバ情報を検索するために前記複数のメンバ情報格納領域に対する並列検索を行う検索制御部と、
検索されたメンバ情報を用いた前記実行対象のロードモジュールのローディングを行うローディング制御部とを含む。
【０００７】
本発明の他の態様は、ジョブ処理装置が上記したローディングに係る処理を行うローディング制御方法である。また、本発明の他の態様の一つは、コンピュータに上述したジョブ処理装置として処理を実行させるプログラム、或いは当該プログラムを記録したコンピュータ読み取り可能な記録媒体である。
【発明の効果】
【０００８】
本発明の一態様によれば、ローディングの効率化を図ることができる。
【図面の簡単な説明】
【０００９】
【図１】メインフレームコンピュータ上で実行されるオペレーティングシステム（ＯＳ）の構成例を模式的に示す図である。
【図２】ＤＡＳＤでのＰＯ（Partitioned Organization: 区分編成）データセット構造を示す。
【図３Ａ】ＯＳで使用されるメモリ領域、すなわち仮想メモリマップのデータ構造例を示す。
【図３Ｂ】図３Ａに示した検索順序領域を示す。
【図４】ジョブ管理部によるメンバ情報収集処理の例を示すフローチャートである。
【図５Ａ】タスク管理部による更新確認処理の例を示すフローチャートである。
【図５Ｂ】タスク管理部によるジョブステップ実行処理の例を示すフローチャートである。
【図５Ｃ】タスク管理部によるローディング処理の例を示すフローチャートである。
【図５Ｄ】タスク管理部１２によるファイルのアロケーション処理の例を示すフローチャートである。
【図６】ジョブ管理部によるバッチジョブ終了時の処理を示すフローチャートである。
【発明を実施するための形態】
【００１０】
以下、本発明の実施形態について説明する。下記の実施形態の構成は例示であり、本発明は、実施形態の構成に限定されない。
【００１１】
図１は、メインフレームコンピュータ上で実行されるオペレーティングシステム（ＯＳ）の構成例を模式的に示す図である。図示しないが、メインフレームコンピュータは、ＣＰＵのようなプロセッサ、ＲＡＭやＲＯＭを含む主記憶装置，周辺装置を備える。周辺装置は、ハードディスクドライブのような二次記憶装置，キーボードのような入力装置、ディスプレイのような出力装置、通信インタフェース回路を含む。主記憶装置及び二次記憶装置は、コンピュータ読み取り可能な記録媒体である。ＯＳ１０は、記録媒体上に格納されており、プロセッサによって実行される。
【００１２】
ＯＳ１０は、メインフレームコンピュータ上で実現されるジョブ処理装置として機能する。ＯＳ１０は、大略して、ジョブ管理部１１，タスク管理部１２及びデータ管理部１３を備えている。
【００１３】
ジョブ管理部１１は、処理プログラムの実行を「ジョブ」と呼ばれる単位で制御及び管理する。ジョブは、プログラムをＯＳ１０に入力する単位であるジョブステップの集合である。タスク管理部１２は、複数のプログラムを並行して実行させる、排他制御やエラー回復などの制御・管理を行う。データ管理部１３は、デバイス（ボリューム）、及びデータセットの制御と管理を司る。
【００１４】
メインフレームコンピュータは、ＪＯＢ、ＳＴＣのようなバッチ処理と、ＴＳＳ（タイム・シェアリング・システム）を使ったオンライン処理とを実行することができる。バッチ処理におけるＳＴＣは、イニシエータによらず、ＯＳ１０で直接実行されるスターテッドタスクである。ＳＴＣは、例えばコンソール１４から入力される。ＪＯＢは、ＪＥＳ（ジョブ入力サブシステム）によってスケジュールされ、イニシエータと呼ばれるジョブの実行を行うアドレス空間によって実行されるジョブであり、バッチジョブとよばれる。
【００１５】
バッチジョブは、ＪＣＬ（Job Control Language：ジョブ制御言語）で記述され、図示しないリーダ装置を介してＯＳ１０に入力（サブミット）されることで開始される。ＪＣＬはジョブ管理部１１に含まれるイニシエータ１１Ａにて解析される。この過程で、デー
タ管理部１３は使用可能な制御表を作成する。
【００１６】
ＪＣＬは、少なくとも、ＪＯＢステートメントと、ＥＸＥＣ（Execution）ステートメ
ントと、ＤＤ（Data Definition）ステートメントと、ＳＴＥＰＬＩＢ  ＤＤステートメ
ントとを含んでいる。ＪＯＢステートメントは、ジョブクラスなどを定義する。ＥＸＥＣステートメントは、ジョブステップの実行のためのプログラムを定義する。ＤＤステートメントは、プログラムの実行に際して利用すべき資源の割り当てを指定する。ＳＴＥＰＬＩＢ  ＤＤステートメントは、当該ＳＴＥＰＬＩＢ  ＤＤステートメントで指定された場所からプログラムを読み出すことを命令する。以下、ＳＴＥＰＬＩＢ  ＤＤステートメントを単に「ＳＴＥＰＬＩＢ」と表記する。
【００１７】
ＪＣＬのサブミットによってジョブが開始されると、ＤＤステートメントで指定された資源のアロケーション処理が実行され、プログラムの実行が開始される。最初に、ＯＳ１０は、ＥＸＥＣステートメントで指定されたプログラムを探索する。このとき、ＳＴＥＰＬＩＢで指定されたライブラリ上のデータセットからプログラム（ロードモジュール）を読み込む。ロードモジュールがライブラリから見つかると、ＯＳ１０はロードモジュールをメモリ上に読み込むローディングを行う。ローディング後、プログラム実行の制御に必要な制御表（コントロール・ブロック）が作られ、プログラムの実行が開始される。プログラムの実行を通じたジョブの結果は、バッチジョブ出力として出力される。
【００１８】
ＯＳ１０には、ジョブエントリーサブシステム（ＪＥＳ）がアドオンされている。ＪＥＳは、複数のジョブのスケジューリング及びスプーリングを司る。ＪＥＳは、ジョブ管理部１１に含まれるイニシエータ１１Ａを含んでいる。
【００１９】
イニシエータ１１Ａは、ジョブ（プログラムの実行）に必要な資源を割り振り、実行し、使い終わった資源を解放する。イニシエータ１１Ａは、ＪＣＬの解釈（interpretation）を行う。また、イニシエータ１１Ａは、資源の割り当て（Allocation）を行う。すなわち、イニシエータ１１Ａは、ＤＤステートメントで定義されたデータセット、ボリュームあるいはデバイスを探索し、プログラムで使用できるように準備する。このようなアロケーション処理は、ＥＸＥＣステートメントによるジョブステップ単位にステップ開始時に行われる。
【００２０】
また、イニシエータ１１Ａは、プログラムの実行（execution）を司る。資源の割り振
りが行われた後、イニシエータは、ＥＸＥＣステートメントで指定されたプログラムをメモリ上にロードして実行を開始する。このとき、イニシエータ１１Ａは、指定されたプログラムを独立した作業単位として実行するためにジョブ・ステップ・タスクと呼ばれるタスク（ＥＸＥＣステートメントで指定されたプログラム）を生成する。
【００２１】
さらに、イニシエータ１１Ａは、ターミネーション（Termination）処理を行う。すな
わち、ジョブ・ステップ・タスクが終了すると、イニシエータは、割り当て済みの資源を解放し、後続のジョブステップがあればそれを実行するために再びアロケーション処理から実行処理までを繰り返す。すべてのジョブステップが終了すると、次のジョブの実行待ち状態に入る。
【００２２】
イニシエータ１１Ａは、ＯＳに組み込まれたローダーや、アロケーションマクロのようなシステムマクロとして存在することができる。イニシエータ１１Ａの制御は、ジョブ管理部１１によって行われる。
【００２３】
外部記憶装置（ＤＡＳＤ：Direct Access Storage Device）群１５は、ＯＳからアクセスされる外部デバイスである。ＤＡＳＤ群は、ボリュームと呼ばれる論理的な管理単位で
管理される。ＤＡＳＤ群１５は、ジョブを一時的に格納しておくスプールボリュームと、システム情報が格納されたシステム・ボリュームと、データやユーザプログラムが格納されるユーザ・ボリュームとを備えている。
【００２４】
図２は、ＤＡＳＤでのＰＯ（Partitioned Organization: 区分編成）データセット構造を示す。ＰＯ（区分編成）とは、メンバ情報を保持しているデータセットを示す。物理的なＤＡＳＤ群１５は、論理的なボリューム単位で管理される。図２には、一つのボリューム２０が例示されている。ボリューム２０には、ボリューム管理のためのボリューム通番（serial number）が付与される。
【００２５】
ボリューム２０は、ボリューム目録（Volume Table Of Contents: VTOC）２１を備えている。ＶＴＯＣ２１は、ボリューム２０内で管理されるＰＯデータセットの索引簿であり、ＰＯデータセットのボリューム２０上の所在を表す。ボリューム２０上の所在は、シリンダ番号及びトラック番号で指定される。また、ＶＴＯＣ２１は、各ＰＯデータセットの更新時のタイムスタンプとシステムＩＤとを含む更新履歴情報を保持する。
【００２６】
ボリューム２０には、ＶＴＯＣ２１にＰＯデータセット名が登録された１以上のＰＯデータセット２２が格納される。以下、ＰＯデータセット２２は、「ジョブステップライブラリ」又は「ライブラリ」と呼ばれる。ＰＯデータセット２２は、ファイル管理システムにおけるディレクトリ部に相当し、ＰＯデータセット２２中のデータブロックは、データファイルに相当する。
【００２７】
図２に示す例では、ジョブを構成する３つのジョブステップに対応するＰＯデータセット（ライブラリ）２２がボリューム２０に格納されている。図２に示す例では、ジョブを構成するジョブステップは、“ＬＯＡＤＭＡＩＮ”，“ＬＯＡＤＳＵＢ１”及び“ＬＯＡＤＳＵＢ２”からなり、これらに対応するＰＯデータセット２２Ａ，２２Ｂ及び２２Ｃが格納されている。
【００２８】
ＰＯデータセット２２は、ＶＴＯＣ２１に登録されたボリューム内の格納位置に格納される。ＰＯデータセット２２は、メンバ部２３とデータ部２４とを有する。メンバ部２３は、データ部２４に格納されたデータ名（すなわち、メンバ名）及びメンバの格納位置（アドレス）を示すメンバ情報が格納される。
【００２９】
データ部２４には、メンバ部２３に格納されたメンバ名を有するデータブロック２５がメンバ部２３で指定された位置に格納される。データブロック２５として、ロードモジュールすなわちプログラムや、データを格納することができる。従って、データブロックがロードモジュールである場合には、メンバ名は、ロードモジュール名を指す。
【００３０】
図２に示す例では、ＰＯデータセット名（ライブラリ名）“ＬＯＡＤＭＡＩＮ”，“ＬＯＡＤＳＵＢ１”，及び“ＬＯＡＤＳＵＢ２”の所在位置（ポインタ）がＶＴＯＣ２１に登録されている。また、図２に示す例では、メンバ部２３には、メンバ名（ロードモジュール名）“Ａ”，“Ｍ”，“Ｐ”，“Ｑ”，“Ｒ”，“Ｓ”及び“Ｙ”に関するメンバ情報が格納されており、データ部２４には、上記したメンバ（データブロック２５）が格納されている。
【００３１】
図３Ａは、ＯＳ１０で使用されるメモリ領域、すなわち仮想メモリマップのデータ構造例を示す。図３Ｂは、図３Ａに示した検索順序領域を示す。図３Ａに示すように、メモリ領域３０は、例えば２ＧＢの容量を有し、１６ＭＢの基本領域３１と、残りの拡張領域３２を有する。基本領域３１には、複数のバッチジョブに対して共通に使用される共通領域３３と、バッチジョブに対して固有の空間領域３４Ａが作成される。さらに、拡張領域３
２にも、バッチジョブに対して固有の空間領域３４Ｂが作成される。また、拡張領域３２にも、共通領域３５が作成される。以下、基本領域３１上の固有空間領域を基本固有空間領域３４Ａと称し、拡張領域３２上の固有空間領域を拡張固有空間領域３４Ｂと称する。
【００３２】
図３Ａに示す例では、三つのバッチジョブ１〜３に対する基本固有空間領域３４Ａ及び拡張固有空間領域３４Ｂが作成される。また、オンラインシステムに関する基本固有空間領域３４Ａ及び拡張固有空間領域３４Ｂも作成される。
【００３３】
なお、基本共通領域３３の仮想空間領域の容量は、実メモリの容量と等しい。また、拡張共通領域３５の仮想空間領域の容量は、実メモリの容量と等しい。これに対し、各バッチジョブ及びオンラインシステムの空間領域（基本固有空間領域及び拡張固有空間領域）の仮想空間領域の容量は、仮想メモリの容量と等しい。
【００３４】
基本固有空間領域３４Ａには、バッチジョブ（図３Ａでは、「バッチジョブ１」）のローディング処理を司るシステムマクロであるローダー３８と、ローダー３８によるローディング対象のプログラム、すなわちロードモジュール３９が格納される。ローダー３８は、図１に示したイニシエータ１１Ａの機能である。
【００３５】
拡張固有空間領域３４Ｂには、バッチジョブに含まれる全てのジョブステップに対応するメンバ情報の格納領域である複数のメンバ情報格納領域３６と、各ジョブステップの検索順序を格納する検索順序領域３７が作成される。
【００３６】
図３Ａに示す例では、バッチジョブ１は、ジョブステップ“ＬＯＡＤＭＡＩＮ”，“ＬＯＡＤＳＵＢ１”及び“ＬＯＡＤＳＵＢ２”からなり、これらのジョブステップに対応するライブラリ上のメンバ情報が、ボリューム２０（図２）から読み出されてメンバ情報格納領域３６Ａ，３６Ｂ及び３６Ｃに格納されている。
【００３７】
検索順序領域３７は、ジョブステップ毎に作成される。図３Ｂに示すように、検索順序領域３７には、メンバ情報に対応する検索順位、発見情報、及びメンバ情報格納領域ポインタが登録される。さらに、検索順序領域３７には、メンバ情報に対応するシステムＩＤ及びタイムスタンプが格納される。
【００３８】
検索順位は、ＪＣＬ解釈に従って決まるジョブステップの実行順序によって決定される。この例では、ジョブステップの実行順序は、“ＬＯＡＤＭＡＩＮ”→“ＬＯＡＤＳＵＢ１”→“ＬＯＡＤＳＵＢ２”である。メンバ情報格納領域ポインタは、各ジョブステップのライブラリに対応するメンバ情報格納領域３６の拡張固有空間領域３４Ｂ上のアドレスを示す。発見情報は、メンバ情報格納領域に対する検索の状態又は結果を示す情報である。システムＩＤ及びタイムスタンプは、メンバ情報がメンバ情報格納領域３６に格納される時のシステムＩＤ及びタイムスタンプが格納される。
【００３９】
図３Ｂに示す例では、検索順序領域３７として、複数のステップジョブの第２ステップに該当する“ＬＯＡＤＳＵＢ１”に対応する検索順序領域が示されている。ここに、ジョブステップ“ＬＯＡＤＳＵＢ１”に対応するロードモジュール、すなわちメンバは、メンバ“Ｌ”である。
【００４０】
検索順位“１”に関する情報として、“ＬＯＡＤＭＡＩＮ”の領域には、ジョブステップ“ＬＯＡＤＳＵＢ１”に対応するロードモジュールが発見されなかったことを示す発見情報“ＦＦＦＦＦＦ”が格納される。これに対し、検索順位“２”に関する情報として、“ＬＯＡＤＳＵＢ１”の領域には、ジョブステップ“ＬＯＡＤＳＵＢ１”に対応するメンバ“Ｌ”が発見されたことを示す情報が格納される。また、検索が終了していない場合に
は、発見情報として、初期値としても使用可能なゼロ値“００００００”が格納される。
【００４１】
基本固有空間領域３４Ａのローダー３８にてローディングされるメンバ、すなわちロードモジュール“Ｌ”３９は、上記した検索順序領域３７内の情報を参照してボリューム２０にアクセスされ、ロードされる。
【００４２】
図４は、ジョブ管理部１１によるメンバ情報収集処理の例を示すフローチャートである。図４に示すメンバ情報収集処理は、イニシエータ１１ＡがＪＣＬの解釈を終了した時点でジョブ管理部１１により処理が開始される。
【００４３】
ステップＳ１（図４）では、拡張固有空間領域３４Ｂ、すなわちメンバ情報格納領域３６（図３Ａ）及び検索順序領域３７（図３Ｂ）の確保が行われる。すなわち、ジョブ管理部１１は、メモリ領域３０の拡張固有空間領域３４Ｂに、メンバ情報格納領域３６を確保する。このとき、ジョブ管理部１１は、ＪＣＬのＳＴＥＰＬＩＢで指定されたジョブステップライブラリ数と同数のメンバ情報格納領域３６を確保する。
【００４４】
但し、同一名称を有する複数のライブラリ名（ＰＯデータセット名）が指定された場合には、同一名称を有する複数のライブラリ名間で一つのメンバ情報格納領域３６が共有される。また、ジョブ管理部１１は、ライブラリ検索用の領域として、検索順序領域３７を確保する。
【００４５】
ステップＳ２（図４）では、ＳＴＥＰＬＩＢで指定されたライブラリ（ＰＯデータセット）のオープン処理が行われる。すなわち、ジョブ管理部１１は、ＳＴＥＰＬＩＢで指定された各ライブラリをイニシエータ１１Ａによって動的にアロケーションし、オープン処理を行う。
【００４６】
具体的には、ジョブ管理部１１は、制御表を用い、ＳＴＥＰＬＩＢで指定されたライブラリへのアクセス命令をデータ管理部１３に与える。データ管理部１３は、ＤＡＳＤ群１５中の各ライブラリが存するボリュームにアクセスする。
【００４７】
このとき、オープン処理時のライブラリ更新情報としてのタイムスタンプが保存される。また、ＤＡＳＤ群１５がシステム間で共用されている場合には、システムＩＤも保存される。なお、ステップＳ２において、オープン処理のエラーが発生しても、そのエラーは当該ジョブステップの開始時まで保留され、この時点でのエラー処理は実行されない。
【００４８】
ステップＳ３（図４）では、各ライブラリのメンバ情報の取り込みが行われる。すなわち、ジョブ管理部１１は、データ管理部１３を介して各ライブラリからメンバ情報を取り込み、取り込んだメンバ情報を、メンバ情報格納領域３６に格納する。このとき、ジョブ管理部１１は、ライブラリ更新情報として、メンバ情報の更新履歴情報（ＶＴＯＣ２１で保存）中のタイムスタンプ（現時刻）及びシステムＩＤを検索順序領域３７に保存する。
【００４９】
ステップＳ４（図４）では、ＳＴＥＰＬＩＢで指定された各ライブラリに対するクローズ処理が実行される。すなわち、ジョブ管理部１１は、イニシエータ１１Ａによって、各ライブラリに対する動的なアンアロケーション処理を行い、各ライブラリをクローズする。なお、ステップＳ４において、クローズ処理のエラーが発生しても、そのエラーは当該ジョブステップの開始時まで保留され、この時点でのエラー処理は実行されない。
【００５０】
ジョブ管理部１１による処理が終了すると、処理がタスク管理部１２による更新確認処理へ引き継がれる。このとき、ライブラリのオープン処理又はクローズ処理に関するエラーも引き継がれる。
【００５１】
図５Ａは、タスク管理部１２による更新確認処理の例を示すフローチャートである。図５Ａに示す処理は、イニシエータ１１Ａによるアロケーション処理が終了した時点でタスク管理部に制御が渡されることによって開始される。
【００５２】
ステップＳ１１（図５Ａ）では、タスク管理部１２は、ライブラリの更新情報の取り込みを行う。すなわち、タスク管理部１２は、ライブラリのオープン処理を行い、ライブラリのＶＴＯＣ２１（図２）から、更新履歴情報、すなわちライブラリ更新情報としてのタイムスタンプをデータ管理部を介して取り込む。
【００５３】
ステップＳ１２（図５Ａ）では、ライブラリの更新確認処理として、タスク管理部１２は、メンバ情報格納領域３６へのメンバ情報の格納時に検索順序領域３７に保存したシステムＩＤと、ステップＳ１１で取り込んだシステムＩＤ、すなわちジョブステップ実行時のシステムＩＤとが一致するか否かを判定する。システムＩＤが一致する場合には、処理がステップＳ１３に進み、システムＩＤが一致しない場合には、処理がステップＳ１４に進む。
【００５４】
ステップＳ１３（図５Ａ）では、ライブラリの更新確認処理として、タスク管理部１２は、メンバ情報格納領域３６へのメンバ情報格納時に検索順序領域３７に保存したタイムスタンプと、ステップＳ１１で取り込んだタイムスタンプ、すなわちジョブステップ実行時のタイムスタンプとが一致するか否かを判定する。タイムスタンプが一致する場合には、処理がジョブステップ実行処理へ進む。タイムスタンプが一致しない場合には、処理がステップＳ１４へ進む。
【００５５】
ステップＳ１４（図５Ａ）では、タスク管理部１２は、ステップＳ１４にてオープンしたライブラリのメンバ情報を取り込み、メンバ情報格納領域３６に保存（更新）する。具体的には、タスク管理部１２は、ステップＳ１１でオープンした時のライブラリ更新情報（タイムスタンプ）を取り込む。また、タスク管理部１２は、ライブラリがシステム間で共有されるＤＡＳＤに格納されている場合には、システムＩＤも取り込む。さらに、タスク管理部１２は、ライブラリ中の更新されたメンバ情報を取り込み、タイムスタンプ、システムＩＤ及びメンバ情報をメンバ情報格納領域３６及び検索順序領域３７に格納する。
【００５６】
その後、処理がジョブステップ実行処理へ進む。なお、上述したステップＳ１１〜Ｓ１４の処理は、ライブラリ毎に実行される。ジョブステップ実行処理に処理が進む際には、検索順序領域の発見情報に初期値であるゼロ値“００００００”を設定することで発見情報の初期化が行われる。
【００５７】
図５Ｂは、タスク管理部１２によるジョブステップ実行処理の例を示すフローチャートである。図５Ｂに示す処理は、ロードモジュール呼び出しが依頼された時点で、制御がタスク管理部１２に渡されることによって開始される。
【００５８】
ステップＳ２１（図５Ｂ）では、タスク管理部１２は、検索対象のジョブステップライブラリ数に対応する検索処理の準備を行う。図５Ｂに示す例では、“ライブラリ１（ＬＯＡＤＭＡＩＮ）”，“ライブラリ２（ＬＯＡＤＳＵＢ１）”，及び“ライブラリ３（ＬＯＡＤＳＵＢ２）”の３つのライブラリが検索対象であるので、これらのライブラリに対する検索処理が準備される。
【００５９】
なお、図５Ｂに示す例では、ライブラリ２に格納されているメンバ名“Ｌ”がジョブステップの実行に必要な呼び出し対象のロードモジュールであり、この“Ｌ”の呼び出しが依頼されていると仮定する。
【００６０】
ステップＳ２２，Ｓ２３及びＳ２４（図５Ｂ）において、タスク管理部１２は、ライブラリ１〜３に対する検索処理を並列に実行する。各ライブラリ１〜３に対する検索処理はほぼ同時に開始される。ライブラリに対する検索処理として、検索順序領域３７に格納されたメンバ情報格納領域ポインタ（図３Ｂ）にて指定（ポイント）されたメンバ情報格納領域３６（３６Ａ，３６Ｂ，３６Ｃ）が並列にメモリ検索される。この同時検索は、タスク管理部１２がイニシエータ１１Ａに実行させることができる。
【００６１】
メンバ情報格納領域３６から目的のメンバ名を発見できた場合には、発見情報として、発見されたメンバ名の情報（ここではメンバ名“Ｌ”）が検索順序領域３７に書き込まれ、検索処理が終了する。これに対し、メンバ情報格納領域３６から目的のメンバ名が発見されなかった場合には、検索終了標識、例えば“ＦＦＦＦＦＦ”が検索順序領域３７に書き込まれ、検索処理が終了する。検索処理の終了時には、完了事象として、発見正当性確認依頼が出力される。
【００６２】
タスク管理部１２は、各ライブラリの検索処理から発見正当性確認依頼を得る毎に、その発見の正当性を確認する（ステップＳ２５）。すなわち、タスク管理部１２は、発見正当性確認を依頼した検索処理に対応する発見情報の値を参照する。
【００６３】
このとき、タスク管理部１２は、検索順序領域３７に登録された検索順位に従って、検索が完了しているか否かを、各ライブラリの発見情報に基づいてチェックする。ここに、発見情報値“００００００”は、検索対象のライブラリに対する検索中であることを示す。これに対し、発見情報値“ＦＦＦＦＦＦ”は、検索対象のライブラリから目的のメンバ名が発見されることなく検索が終了したことを示す。発見情報値“メンバ名”は、検索対象のライブラリから目的のメンバ名が検出されたことを示す。
【００６４】
図３Ａに示す例では、ライブラリ１及び３に対応するメンバ情報格納領域３６Ａ，３６Ｃの検索結果を示す発見情報は、“ＦＦＦＦＦＦ”となる。これに対し、ライブラリ２に対応するメンバ情報格納領域３６Ｂの検索結果を示す発見情報は、メンバ名を示すメンバ情報“Ｌ”となる。よって、タスク管理部１２は、ライブラリ２のメンバ情報、すなわちメンバ名“Ｌ”をジョブステップの実行に必要な呼び出し対象のロードモジュールとして採用する。
【００６５】
なお、ライブラリ２の検索結果（発見情報）からメンバ名“Ｌ”が検出されたとしても、検索順位が上位であるライブラリ１の発見情報が“００００００”（検索中）である場合には、タスク管理部１２は、ライブラリ２の検索結果の採用を保留する。その後、タスク管理部１２は、ライブラリ１についての発見情報値が“ＦＦＦＦＦＦ”（検索終了且つ発見されず）を確認した時点で、ライブラリ２の検索結果を採用する。ステップＳ２５が終了すると、タスク管理部１２は、処理をローディング処理へ進める。
【００６６】
図５Ｃは、タスク管理部１２によるローディング処理の例を示すフローチャートである。ローディング処理は、呼び出し対象のロードモジュールのメンバ情報が取得された時点で開始される。
【００６７】
ステップＳ３１（図５Ｃ）では、タスク管理部１２は、呼び出し対象のロードモジュールのメンバ情報（この例では“Ｌ”）を、基本固有空間領域上のシステムマクロであるローダー３８（図３Ａ）、すなわちイニシエータ１１Ａに渡す。すなわち、タスク管理部１２は、ＤＡＳＤ群１５（ボリューム２０）上に存在するロードモジュール“Ｌ”をメモリ上に展開するために、システムマクロのローダー３８に処理を依頼する。このとき、タスク管理部１２は、ロードモジュール“Ｌ”のＤＡＳＤ群１５上の格納位置を示す情報とし
て、メンバ情報“Ｌ”をローダー３８に渡す。
【００６８】
ステップＳ３２（図５Ｃ）では、タスク管理部１２は、データ管理部１３との連携において、目的のロードモジュール（プログラム）“Ｌ”３９をメモリ領域３０上に展開する。すなわち、ＤＡＳＤ群１５上のロードモジュール“Ｌ”を取り込むために、データ管理部１３が有する入出力マクロ（ＥＸＣＰ）が実行されて、目的のロードモジュール“Ｌ”３９がメモリ領域３０の基本固有空間領域３４Ａ上に展開（読み込み）される。その後、制御がタスクの実行管理を司るディスパッチャに渡され、メモリ上に展開されたプログラムの実行が開始される。
【００６９】
図５Ｄは、タスク管理部１２によるファイルのアロケーション処理の例を示すフローチャートである。アロケーション処理は、ＤＡＳＤ群１５のような外部ユニット（外部デバイス）に対する入出力（Ｉ／Ｏ：例えば、オープン／クローズ処理，リード／ライト処理）を行う場合に必要な制御表の作成依頼を受け取った場合にタスク管理部１２が制御を受け取って開始される。
【００７０】
ステップＳ４１（図５Ｄ）では、アロケーション処理がシステムマクロ（すなわち、イニシエータ１１Ａ）に依頼される。アロケーション処理は、Ｉ／Ｏの準備作業として、ＪＣＬで解析された構文をデータ管理部が理解可能な制御表１２Ａに変換するために実行される。このため、タスク管理部１２は、システムマクロの一つであるアロケーションマクロ（イニシエータ１１Ａ）に対し、ＪＣＬの解析結果からデータ管理部の制御表１２Ａを作成する処理を依頼する。
【００７１】
アロケーションマクロ（イニシエータ１１Ａ）によってデータ管理部１３用の制御表１２Ａが作成されると、Ｉ／Ｏの準備が完了した状態となる。アロケーション完了状態は、いつでも、データセットのオープン／クローズ処理、データのリード／ライト処理を行う準備が完了した状態を示す。タスク管理部１２は、制御表１２Ａを使用してデータ管理部を制御することにより、ＤＡＳＤ群１５に対する入出力を行うことができる。
【００７２】
図６は、ジョブ管理部１１によるバッチジョブ終了時の処理を示すフローチャートである。図６において、ジョブ管理部１１は、バッチジョブ終了と判定すると（ステップＳ５１；ＹＥＳ）、バッチジョブの実行に使用されたデータセットが不要か否かを判定する（ステップＳ５２）。
【００７３】
このとき、データセットが不要でなければ（Ｓ５２；ＮＯ）、バッチジョブの終了処理が行われ、その結果が出力される。この場合、拡張固有空間領域３４Ｂ（図３Ａ）に対する特別な処理は行われない。これに対し、データセットが不要であれば（Ｓ５２；ＹＥＳ）、不要なデータセットに対応するメンバ情報格納領域３６及び検索順序領域３７が拡張固有空間領域３４Ｂから削除される（ステップＳ５３）。このとき、基本固有空間領域３４Ａ上のロードモジュールも削除される。この削除は、例えばイニシエータ１１Ａによって行われる。その後、バッチジョブの終了処理が行われる。
【００７４】
以上説明した情報処理装置（メインフレームコンピュータ）のＯＳ１０（バッチジョブ処理装置）によると、ＪＣＬの解釈結果に応じて、ＳＴＥＰＬＩＢで指定された、バッチジョブに含まれる全ジョブステップの実行に必要なライブラリのメンバ情報がメモリ領域３０の拡張固有空間領域３４Ｂに格納される。従って、従来技術のように、或るバッチジョブと無関係なメンバ情報を含む大量のメンバ情報がメモリ領域に格納されることが抑止される。従って、メンバ情報がメモリ領域の容量を圧迫することが回避され、システムの運営に障害が生じるのを抑えることができる。ジョブ管理部１１は、メンバ情報取得部に相当する。
【００７５】
また、メンバ情報がシステム共通領域（ＯＳの動作領域）ではなくバッチジョブの固有空間領域に格納される。これによって、メンバ情報が共通領域の容量を圧迫することを回避して、ＯＳ１０の動作に影響が生じるのを抑えることができる。
【００７６】
また、プログラムの実行開始前に、更新確認処理（図５Ａ）が実行され、メンバ（ロードモジュール）が更新されている場合には、メンバ情報の再取り込みが実行される。これによって、自動的に最新のロードモジュールを用いたジョブステップを実行することができる。タスク管理部１２は、更新確認部に相当する。
【００７７】
さらに、ジョブステップの実行にあたり、必要なロードモジュールをＤＡＳＤ群（ボリューム）から呼び出すために、拡張固有空間領域３４Ｂに格納された複数のメンバ情報格納領域が並列に検索される（同時検索される）。これによって、短い時間でローディングを終えることができる。また、検索対象がバッチジョブに含まれるメンバ情報だけである点でもローディングに必要な時間を短縮することができる。タスク管理部１２は、検索制御部に相当する。
【００７８】
また、検索順序領域に、ＳＴＥＰＬＩＢで指定された順序が格納され、この指定された順序でメンバ情報格納領域３６の検索結果が採用されるので、ロードモジュール、すなわちプログラムの実行順序を保証することができる。タスク管理部１２は、ローディング制御部に相当する。
【００７９】
さらに、バッチジョブ終了時において、不要なメンバ情報及びロードモジュールがメモリ領域３０から削除されるので、メモリ領域３０を有効に利用することが可能となる。ジョブ管理部１１は、削除制御部に相当する。
【００８０】
上述した実施形態におけるジョブ処理装置は、その目的を逸脱しない範囲で適宜変形が可能である。
【００８１】
上述した実施形態は、以下の発明を開示する。以下の発明は、その目的を逸脱しない範囲で適宜組み合わせることができる。
【００８２】
（付記１）
外部デバイスに格納されたデータセットであって、ジョブを構成する各ジョブステップを実行するためのロードモジュールをメンバとして含むデータセット中のメンバ情報をメモリ領域上でジョブステップ毎に設けられた複数のメンバ情報格納領域に格納するメンバ情報取得部と、
前記各ジョブステップの実行時に、実行対象のロードモジュールの情報を含むメンバ情報を検索するために前記複数のメンバ情報格納領域に対する並列検索を行う検索制御部と、
検索されたメンバ情報を用いた前記実行対象のロードモジュールのローディングを行うローディング制御部と
を含むジョブ処理装置。
【００８３】
（付記２）
前記メンバ情報取得部は、前記メモリ領域上でバッチジョブ毎に設けられたバッチジョブ固有領域上に前記複数のメンバ情報格納領域を確保する
付記１に記載のジョブ処理装置。
【００８４】
（付記３）
前記各ジョブステップの実行前に、前記複数のメンバ情報格納領域に格納されたメンバ情報が前記外部デバイス上で更新されているか否かを判定する更新確認部をさらに含み、
前記メンバ情報取得部は、前記更新確認部によって更新されたメンバ情報が発見された場合に、この更新されたメンバ情報を前記外部デバイスから得て対応する前記メンバ情報格納領域に格納する
付記１又は２に記載のジョブ処理装置。
【００８５】
（付記４）
前記メンバ情報取得部は、前記複数のジョブステップの実行順序を前記メモリ領域上に設けられた検索順序領域に格納し、
前記ローディング制御部は、前記複数のジョブステップの実行順序と合致するメンバ情報格納領域に格納されたメンバ情報を用いた前記実行対象のロードモジュールのローディングを行う
付記１乃至３のいずれか１項に記載のジョブ処理装置。
【００８６】
（付記５）
前記ジョブの終了時に削除されるべき前記複数のメンバ情報格納領域の少なくとも一つを削除する削除制御部をさらに含む
付記１から４のいずれか１項に記載のジョブ処理装置。
【００８７】
（付記６）
コンピュータに、
外部デバイスに格納されたデータセットであって、ジョブを構成する各ジョブステップを実行するためのロードモジュールをメンバとして含むデータセット中のメンバ情報をメモリ領域上でジョブステップ毎に設けられた複数のメンバ情報格納領域に格納するステップと、
前記各ジョブステップの実行時に、実行対象のロードモジュールの情報を含むメンバ情報を検索するために前記複数のメンバ情報格納領域に対する並列検索を行うステップと、
検索されたメンバ情報を用いた前記実行対象のロードモジュールのローディングを行うステップと
を実行させるプログラム。
【００８８】
（付記７）
前記メモリ領域上でバッチジョブ毎に設けられたバッチジョブ固有領域上に前記複数のメンバ情報格納領域を確保するステップをさらにコンピュータに実行させる
付記６に記載のプログラム。
【００８９】
（付記８）
前記各ジョブステップの実行前に、前記複数のメンバ情報格納領域に格納されたメンバ情報が前記外部デバイス上で更新されているか否かを判定するステップと、
更新されたメンバ情報が発見された場合に、この更新されたメンバ情報を前記外部デバイスから得て対応する前記メンバ情報格納領域に格納するステップと
をさらにコンピュータに実行させる付記６又は７に記載のプログラム。
【００９０】
（付記９）
前記複数のジョブステップの実行順序を前記メモリ領域上に設けられた検索順序領域に格納するステップと、
前記複数のジョブステップの実行順序と合致するメンバ情報格納領域に格納されたメンバ情報を用いた前記実行対象のロードモジュールのローディングを行うステップと
をさらにコンピュータに実行させる付記６から８のいずれか１項に記載のプログラム。
【００９１】
（付記１０）
前記ジョブの終了時に削除されるべき前記複数のメンバ情報格納領域の少なくとも一つを削除するステップをさらにコンピュータに実行させる付記６から９のいずれか１項に記載のプログラム。
【符号の説明】
【００９２】
１０・・・オペレーティングシステム（ジョブ実行装置）
１１・・・ジョブ管理部
１１Ａ・・・イニシエータ
１２・・・タスク管理部
１２Ａ・・・制御表
１３・・・データ管理部
１４・・・コンソール
１５・・・ＤＡＳＤ群
２０・・・ボリューム
２１・・・ＶＴＯＣ
２２・・・ＰＯデータセット（ライブラリ）
２３・・・メンバ部
２４・・・データ部
３０・・・メモリ領域
３１・・・基本領域
３２・・・拡張領域
３３・・・基本共通領域
３４Ａ・・・基本固有空間領域
３４Ｂ・・・拡張固有空間領域
３５・・・拡張共通領域
３６・・・メンバ情報格納領域
３７・・・検索順序領域
３８・・・ローダー
３９・・・ロードモジュール
【図１】
2010231333.tif 000003
【図２】
2010231333.tif 000004
【図３Ａ】
2010231333.tif 000005
【図３Ｂ】
2010231333.tif 000006
【図４】
2010231333.tif 000007
【図５Ａ】
2010231333.tif 000008
【図５Ｂ】
2010231333.tif 000009
【図５Ｃ】
2010231333.tif 000010
【図５Ｄ】
2010231333.tif 000011
【図６】
2010231333.tif 000012