JP2017049722A - ジョブ管理システム、ジョブ管理方法およびプログラム - Google Patents

Abstract

【課題】ジョブ管理システムにおいて、夜間に行うバッチ処理時、エラーなどが生じた場合にシステム管理者が設定しなくても、発生したイベントに対応した一時権限を付与するように制御する。【解決手段】複数のジョブを管理するジョブ管理システムにおいて、ジョブ実行中に所定の条件を検出する検出手段と、前記検出手段により検出された際に、操作者の権限を変更するアクセス権限変更手段と、前記アクセス権限変更手段により変更された操作者の権限の操作を受け付けるアクセス受付手段とを有することを特徴とする。【選択図】図３

Description

本発明は、コンピュータで実施されるジョブを管理するシステムに関する。

個人情報などの機密情報を管理する企業では情報漏えいを防止するため、ＤＢ（データベース）やファイルサーバなどに対して厳しく操作権限の設定が行われている。特にＤＢや様々な処理を行うバッチサーバなど、重要なデータを保持・処理するサーバは、厳重にセキュリティ管理するため各操作者へのアクセス権限などを詳細に設定している。

しかし、セキュリティ管理を厳重な中でサーバやＤＢでトラブルが発生した場合、急遽、通常の操作者のアクセス権限では操作できないコマンドやデータベース操作を実行しなければならない場合が生じる。

通常の操作者のアクセス権限では操作できないコマンドやデータベース操作を実行する場合、管理者が一時的にアクセス権限を広げて、操作者に操作させることが通常行われるが、従来技術においては、操作者のアクセス権限を管理者が一旦設定した場合、当該操作者のアクセス権限は常に同じ定義が利用され、アクセス権限を元の状態に戻す場合は、当該定義を管理者が再度変更する手続きをとる必要がありシステム管理者の運用負担を高めていた

特許文献１には、条件に応じてシステム操作者に特定範囲のシステム操作権限を一時的に許可し、条件を満たさなくなった場合、自動的に通常権限に戻す技術が開示されている。

特開２００４−２３４３７８号公報

しかしながら、特許文献１の場合でも、突発的な障害に対応した一時権限付与が難しいという問題点がある。特に夜間に行うバッチ処理でエラーが生じ、早急な対策を求められる場合、システム管理者が夜間に操作者のシステム操作権限を設定しなければならないという課題がある。

本発明の目的は、夜間に行うバッチ処理時、エラーなどが生じた場合にシステム管理者が設定しなくても、発生したイベントに対応した一時権限を付与するように制御することである。

本発明は、複数のジョブを管理するジョブ管理システムにおいて、ジョブ実行中に所定の条件を検出する検出手段と、前記検出手段により検出された際に、操作者の権限を変更するアクセス権限変更手段と、前記アクセス権限変更手段により変更された操作者の権限の操作を受け付けるアクセス受付手段とを有することを特徴とする。

本発明は、夜間に行うバッチ処理時、エラーなどが生じた場合にシステム管理者が設定しなくても、発生したイベントに対応した一時権限を付与するように制御できるという効果を有する。

本発明の実施形態に係るジョブ管理システムのシステム構成を示すブロック図である。 本発明の実施形態に係るバッチサーバ１００、ジョブ管理サーバ１０１、権限管理サーバ１０２、クライアント端末１０３ならびにＤＢサーバ１０４に適用可能な情報処理装置のハードウェア構成を示すブロック図である。 本発明の実施形態に係るジョブ管理システムの各サーバの処理の制御処理手順の一例を示す第一のフローチャートである。 本発明の実施形態に係るジョブ管理システムの各サーバの処理の制御処理手順の一例を示す第一のフローチャートである。 本発明の実施形態に係るジョブ情報の一例を示す模式図である。 本発明の実施形態に係るエラー検出時の出力されるエラー画面のイメージ図である。 本発明の実施形態に係るエラー処理対策後にユーザにより入力されたコマンド画面のイメージ図である。 本発明の実施形態に係るジョブ情報が正常に終了した場合の画面イメージである。 本発明の実施形態に係るアクセス権限管理テーブルの一例を示す模式図である。 本発明の実施形態に係るバッチサーバのアクセス権限の遷移を模式的に示した図である。

以下、図面を参照して、本発明の実施形態を詳細に説明する。まず、図１を参照して、本発明のシステム構成を説明する。

図１は、本発明の実施形態に係るジョブ管理システムのシステム構成を示すブロック図である。バッチサーバ１００はＤＢサーバ１０４と接続可能なサーバであり、ＤＢサーバ１０４からデータを受信し、データの加工などの処理を行い、データの出力や加工データのＤＢへの保管などを行う。ジョブ管理サーバ１０１は、バッチサーバ１００内の複数のジョブ間の先行関係を定義しており、また、バッチサーバ１００での異常発生時の情報を権限管理サーバ１０２に送信する処理を行う。権限管理サーバ１０２は、異常発生時に権限管理サーバ１０２が有するアクセス権限管理テーブルの情報から、所定の操作者にバッチサーバ１００へのアクセス権限を付与する。

バッチサーバ１００へのアクセス権限を付与された操作者は、以上が発生したバッチサーバ１００のエラー原因を調査し、原因を除去した後、所定のコマンドでバッチサーバの異常が発生したジョブを再実行する。

バッチサーバ１００は、異常が発生したジョブを再実行後当該ジョブが正常終了すると、ジョブ管理サーバ１０１に正常終了したことを送信し、ジョブ管理サーバ１０１は、前記操作者へ付与したアクセス権限を剥奪する。

これらの処理により、異常発生時にシステム管理者への一時的なアクセス権限を付与する処理を省くことができる。

なお、本実施例では、バッチサーバ１００、ジョブ管理サーバ１０１、権限管理サーバ１０２、クライアント端末１０３ならびにＤＢサーバ１０４はそれぞれ別筐体として記載しているが、これらの幾つかはまとめて一つの筐体として形成されていてもよく、たとえば、バッチサーバ１００とＤＢサーバ１０４は、共通の筐体でも良いし、また権限管理サーバとジョブ管理サーバ１０１は共通の筐体でも良い。

次に、図２を参照して、本発明で利用する情報処理装置のハードウェア構成について説明する。

図２は、本発明の実施形態に係るバッチサーバ１００、ジョブ管理サーバ１０１、権限管理サーバ１０２、クライアント端末１０３ならびにＤＢサーバ１０４に適用可能な情報処理装置のハードウェア構成図である。

図２において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、画像管理を実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。

２０２はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０３あるいは外部メモリ２１１からＲＡＭ２０２にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。

また、２０５は入力コントローラで、キーボードやポインティングデバイス等の入力装置２０９からの入力を制御する。２０６はビデオコントローラで、ディスプレイ装置２１０等の表示器への表示を制御する。これらは必要に応じて操作者が使用するものである。

２０７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶するハードディスク（ＨＤ）や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

また、外部メモリ２１１のハードディスク（ＨＤ）は、情報処理装置１００において、録画された音声付動画や音声ファイルを記憶する大容量のメモリ領域を有している。

２０８は通信Ｉ／Ｆ（インタフェース）コントローラで、ネットワーク（例えば、無線ＬＡＮなど）を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ装置２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ装置２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

本発明を実現するための後述するフローチャートに示す各ステップの処理は、コンピュータで読み取り実行可能なプログラムにより実行され、そのプログラムは外部メモリ２１１に記録されている。そして、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイル及び各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明も後述する。

次に、図３〜図４のフローチャートを参照して、ジョブ管理システムがバッチサーバを制御する処理を説明する。

図３および図４は、本発明の実施形態に係るジョブ管理システムの各サーバの処理の制御処理手順の一例を示すフローチャートであり、それぞれの処理は各情報処理装置のＣＰＵ２０１により実行される。なお、Ｓ３０１〜Ｓ３１０、Ｓ４０１〜Ｓ４１１は各処理のステップを示す。

図３のフローチャートの処理は、ジョブ管理サーバ１０１が、一連のジョブを実行するために夜間にタイマー起動などで開始される。

まず、図３のステップＳ３０１において、ジョブ管理サーバ１０１のＣＰＵ２０１は、タイマーなどでジョブを起動する。起動するジョブの例を図５を参照して説明する。

図５は、本発明の実施形態に係るジョブ情報の一例を示す模式図である。

図５の５００はジョブネット情報であり、一連のジョブを定義した情報である。５００の場合は、ネット名として「ＡＡＡ１１１１」が定義されており、処理名として「ＸＸＸＸＸ処理」、「毎日」起動され、起動時間は「２１：００」というジョブネット情報である。

５１０には、ジョブネットの具体的なジョブ情報とその実行順序が登録されている。５１０の場合、最初に「ＡＡＪ１１１１」の「ＸＸＸＸ集計」処理を実施し、その後，「ＡＡＪ２２２２」の「ＸＸＸＸ削除」処理を実施、次に「ＡＡＪ３３３３」の「ＸＸＸＸ登録」処理を実施し、最後に「ＡＡＪ４４４４」の「ＸＸＸＸＣＬＯＳＥ」処理を実施する。これらの順番でそれぞれのジョブを実行する。図３のフローチャートの説明に戻る。

図３のステップＳ３０１においてジョブ管理サーバ１０１がジョブを起動すると、次のステップＳ３０２において、バッチサーバ１００のＣＰＵ２０１は、ジョブの実行命令を受け付け、それぞれのジョブを順番に開始する。図示していないが、このジョブが正常に終了すれば、バッチサーバ１００は、ジョブ管理サーバ１０１に結果を返し、次のジョブを取得して、次のジョブを実行する。これらの処理を図５の起動ジョブ情報が全て終了するまで繰り返す。

一方、ステップＳ３０２のジョブ実行時に、エラーが生じた場合、次のステップＳ３０３へと処理を移行する。

ステップＳ３０３において、バッチサーバ１００のＣＰＵ２０１は、ＤＢサーバ１０４やバッチサーバ１００が出力するエラーを検出する。検出した結果をジョブ管理サーバ１０１に送信する。

ステップＳ３０４において、ジョブ管理サーバ１０１のＣＰＵ２０１は、バッチサーバ１００から送信されたエラー検出結果を取得すると、エラーを検出したイベントとして、権限管理サーバ１０２にエラー検出イベントを送信する。

次に、ステップＳ３０５において、権限管理サーバ１０２のＣＰＵ２０１は、ジョブ管理サーバ１０１からエラー検出イベントを取得し、ステップＳ３０６において、エラー検出イベントに対応する一時権限付与をするか否かを判断する。一時権限を付与すると判断された場合は、ステップＳ３０７へと処理を遷移し、一時権限を付与しないと判断された場合はステップＳ３０９へと処理を遷移する。一時権限付与をするか否かは権限管理サーバ１０２が保持するアクセス権限管理テーブルに登録されているデータにより判断する。図９を参照して、アクセス権限管理テーブルの一例を説明する。

図９は、本発明の実施形態に係るアクセス権限管理テーブルの例を示す模式図である。

図９の９００は、アクセス権限管理テーブルの一例であり、９０１にはアクセス権限が付与されるユーザのＩＤ、９０２にはアクセス権限が付与されるサーバ、９０３には一時権限を付与するユーザかどうかのフラグである。このフラグ９０３により、一時権限付与をするかどうかを判断する。９０４〜９０５の列は条件区分であり、どのような条件の場合に一時権限を付与するかを定義した列である。図３のフローチャートの説明に戻る。

ステップＳ３０７へと遷移すると、権限管理サーバ１０２のＣＰＵ２０１は、設定された操作者に一時権限付与を行う。図３のフローチャートの場合、権限管理サーバ１０２は、エラー検出イベントを受信しているため、図９の条件区分９０４が「イベント」で、付与条件９０５が「バッチサーバ障害時」であるユーザＩＤが「１１１１１１」の操作者に対象サーバ９０２のサーバの一時権限付与を行う。同時にメールやメッセージ等で操作者に対して異常を通知すると、夜間などでも操作者が気付くため、なお良い。

次に、ステップＳ３０８において、バッチサーバ１００のＣＰＵ２０１は、権限管理サーバ１０２から受信した権限付与命令の通りアクセス権限を設定し、次のステップＳ３０９へと処理を移行する。

次に、ステップＳ３０９において、バッチサーバ１００のＣＰＵ２０１は、前記操作者からのログイン要求を受け付けるため、クライアント端末１０３に図示しないログイン画面を表示し、操作者から認証処理を受け付ける。

ステップＳ３０９において、認証処理されると、次のステップＳ３１０において、バッチサーバ１００のＣＰＵ２０１は、クライアント端末１０３から操作者によるエラー原因の除去処理を受け付ける。エラーの際の画面イメージを図６を参照して説明する。

図６は、本発明の実施形態に係るエラー検出時の出力されるエラー画面のイメージ図である。

図６の６００は、エラー時のコマンド画面のイメージであり、操作者から６０１のように「ＥＲＲＯＲＬＩＳＴ」と入力されると、以降に表示されるように、処理結果を表示する。「ＪＯＢＬＩＳＴ」の中の「ＡＡＪ３３３３」の処理が「ＥＲＲＯＲ」となっており、図５の「ＡＡＡ１１１１」の起動ジョブ情報の中の「ＡＡＪ３３３３」の処理でエラーが生じていることがわかる。操作者はこれらの結果や、様々なログの出力結果からエラー原因を排除して、正常に終了するようにクライアント端末１０３からＤＢのデータ変更やプログラムの変更などを行う。これらの処理は本発明のポイントではないので、詳細な説明は省略する。図３のフローチャートに戻る。

図３のステップＳ３１０において、エラー原因除去処理を受け付けると、次に、図４のステップＳ４０１へと処理を移行する。

図４のステップＳ４０１において、バッチサーバ１００のＣＰＵ２０１は、操作者からのエラーで中断した処理の再実行命令を受け付け、その情報をジョブ管理サーバ１０１に送信する。図７を参照して、エラーで中断した処理の再実行命令の入力を受け付ける処理を説明する。

図７は、本発明の実施形態に係るエラー処理対策後にユーザにより入力されたコマンド画面のイメージ図である。

図７の７００は、エラーで中断した後でジョブを再実行する際のコマンド画面のイメージであり、操作者から７０１のように「ＲＥＥＸＥＣ ＡＡＡ１１１１」と入力されると、中断していた「ＡＡＡ１１１１」のジョブネットが再開命令がジョブ管理サーバ１０１に送信される。図４のフローチャートの説明に戻る。

次に、図４のステップＳ４０２において、ジョブ管理サーバ１０１のＣＰＵ２０１は、バッチサーバ１００からジョブ再実行命令を受信し、バッチサーバ１００に改めて、エラーで中断したジョブの再実行を命令する。

次に、ステップＳ４０３において、バッチサーバ１００のＣＰＵ２０１は、エラーで中断したジョブの再実行を開始する。この後、再びエラーが生じると、ステップＳ３０３へと遷移する。図４では、エラーで中断したジョブが正常に終了する場合の処理を説明する。

ステップＳ４０４において、該当ジョブが正常終了すると、正常終了通知をジョブ管理サーバ１０１に送信する。

次に、ステップＳ４０５において、ジョブ管理サーバ１０１のＣＰＵ２０１は、正常終了通知を受信すると、権限管理サーバ１０２に正常終了イベントを送信する。

正常終了イベント通知を受信した権限管理サーバ１０２のＣＰＵ２０１は、ステップＳ４０６において、正常終了（バッチサーバ障害復旧）イベントを受信し、ステップ４０７のイベントに対応する権限解除処理をするか否かを判断する。権限解除処理を実行すると判断された場合は、ステップＳ４０８へと処理を遷移し、権限解除処理を実行しないと判断された場合はステップＳ４１０へと処理を遷移する。権限解除処理を実行するか否かは権限管理サーバ１０２が保持するアクセス権限管理テーブルに登録されているデータにより判断する。図９を参照して、アクセス権限管理テーブルの一例を説明する。

図９の９００のアクセス権限管理テーブルの例であれば、９０４、９０６の列が権限解除処理の条件を登録した列であり、どのような条件の場合に権限解除処理を実行するかを定義した列である。図４のフローチャートの説明に戻る。

ステップＳ４０８へと遷移すると、権限管理サーバ１０２のＣＰＵ２０１は、設定された操作者のアクセス権限を解除するように、バッチサーバ１００に命令を送信する。図９の条件区分９０４が「イベント」で、解除条件９０６が「バッチサーバ障害復旧時」であるユーザＩＤは「１１１１１１」の操作者であるため、ユーザＩＤが「１１１１１１」の操作者へのアクセス権限を解除するような命令を送信する。

次に、ステップＳ４０９において、バッチサーバ１００のＣＰＵ２０１は、権限管理サーバ１０２から受信した権限解除命令の通りアクセス権限を解除し、次のステップＳ４１０へと処理を移行する。

ステップＳ４１０において、ジョブ管理サーバ１０１のＣＰＵ２０１は、ステップＳ４０１で指定されたジョブが正常終了し、操作者のアクセス権限が解除されると、後続のジョブの起動命令を送信し、ステップＳ４１１において、バッチサーバ１００のＣＰＵ２０１は、後続のジョブを再開する。

以上の処理により、夜間に行うバッチ処理時にエラーなどが生じた場合にシステム管理者が設定しなくても、発生したイベントに対応した一時権限を付与することができ、またエラーの原因を除去しエラーが発生していたジョブが終了すると、一時権限を解除でき、システム管理者の煩わしい処理を減らすことができる。

上記実施形態では、複数台の情報処理装置に適用する場合を説明したが、１台で動作する情報処理装置であっても良いし、ネットワーク上のバッチサーバ１００、ジョブ管理サーバ１０１、権限管理サーバ１０２、クライアント端末１０３ならびにＤＢサーバ１０４などの処理主体を共通にしてもよい。

なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバ−ジョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インスト−ルするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図３および図４に示す機能が外部からインスト−ルされるプログラムによって、ホストコンピュ−タにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコ−ドを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュ−タ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコ−ドを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラムコ−ド自体が本発明の新規な機能を実現することになり、そのプログラムコ−ドを記憶した記録媒体は本発明を構成することになる。

プログラムコ−ドを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テ−プ，不揮発性のメモリカ−ド，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。

また、コンピュ−タが読み出したプログラムコ−ドを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコ−ドの指示に基づき、コンピュ−タ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムコ−ドが、コンピュ−タに挿入された機能拡張ボ−ドやコンピュ−タに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコ−ドの指示に基づき、その機能拡張ボ−ドや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベ−ス等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１００ バッチサーバ
１０１ ジョブ管理サーバ
１０２ 権限管理サーバ
１０３ クライアント端末
１０４ ＤＢサーバ
１０５ ＬＡＮ

Claims (8)

1. 複数のジョブを管理するジョブ管理システムにおいて、
   ジョブ実行中に所定の条件を検出する検出手段と、
   前記検出手段により検出された際に、操作者の権限を変更するアクセス権限変更手段と、
   前記アクセス権限変更手段により変更された操作者の権限の操作を受け付けるアクセス受付手段と
   を有することを特徴とするジョブ管理システム。
2. 前記検出手段は、ジョブ実行中のエラーを検出するエラー検出手段であって、
   前記エラー検出手段で検出されたエラーが解除された場合、前記アクセス権限変更手段で変更された操作者の権限を解除するアクセス権限変更解除手段と、
   を有することを特徴とする請求項１に記載のジョブ管理システム。
3. 前記エラー検出手段によりエラーが検出されたジョブの再実行を行うジョブ再実行手段と、
   前記アクセス権限変更解除手段は、前記ジョブ再実行手段によりエラーが検出されたジョブの再実行され、当該ジョブが終了したと判断された場合に、変更された操作者の権限を解除することを特徴とする請求項２に記載のジョブ管理システム。
4. 前記ジョブ再実行手段は、前期エラー検出手段により検出されたエラーが復旧した後で再実行されることを特徴とする請求項３に記載のジョブ管理システム。
5. 前記エラー検出手段によりエラーが検出されると、前記実行中のジョブを中断することを特徴とする請求項２乃至４に記載のジョブ管理システム。
6. 前記アクセス権限変更手段は、ジョブ管理システムにおけるサーバ毎に操作者の権限を変更する事を特徴とする請求項１乃至５に記載のジョブ管理システム。
7. 複数のジョブを管理するジョブ管理システムにおけるジョブ管理制御方法であって、
   ジョブ実行中に所定の条件を検出する検出工程と、
   前記検出工程により検出された際に、操作者の権限を変更するアクセス権限変更工程と、
   前記アクセス権限変更工程により変更された操作者の権限の操作を受け付けるアクセス受付工程と
   を有することを特徴とするジョブ管理制御方法。
8. バッチサーバおよび権限管理サーバを請求項７に記載された制御方法のように実行させるためのプログラム。

Images