JP2009230357A - ジョブ運用管理システム - Google Patents

Abstract

【課題】ジョブ定義の編集処理におけるオペレータによる誤操作を防ぐ。
【解決手段】オペレータが行う操作が“承認済”か否かを確認し（Ｓ５０２）、承認済みであれば、操作状況情報ＤＢの操作対象ジョブに関する情報を読み込み（Ｓ５０３）、操作対象のジョブに対して事前に他者が何らかの操作を行っていないかどうかの確認をし（Ｓ５０４）、他者が操作していない場合は、現在操作しようとしているオペレータの情報を操作状況情報ＤＢに格納し（Ｓ５０５）、ジョブ定義編集、ジョブ実行、ジョブ定義削除のいずれかの操作を実行し（Ｓ５０６）、操作内容が実行又は削除のいずれかであれば、承認状態を“完了”に書き換え、承認情報ＤＢを更新し（Ｓ５０８）、操作状況情報ＤＢに保存した情報を削除し（Ｓ５０９）、他者にジョブの操作を可能にする。編集の操作であれば、編集時に情報更新処理部で承認状態を”完了”に書き換え、操作状況情報を削除する。
【選択図】図５

Description

本発明は、ジョブ運用管理システムに関し、特に、ジョブの操作承認と操作履歴を管理するジョブ運用管理システムに関する。

情報システムの内部統制への対応が急務となっている今日では、ジョブ運用管理システムは、ジョブ定義の編集、および、ジョブの実行操作についての承認を、承認システムや正規の手続きにより、厳格に管理する必要がある。

ジョブ運用管理システムにおいて、システムに大きな影響を及ぼす操作、すなわち承認を必要とするような重要なジョブ操作としては、以下に示すものがある。
（１）ジョブ定義更新：誤った内容によるジョブ定義更新操作を行うと、システムに大きな影響を及ぼす。
（２）ジョブの実行：定義内容に誤りがあるジョブの実行を行うと、システムに大きな影響を及ぼす。
（３）ジョブを実行するタイミング：ジョブを実行するタイミングに誤りがあると、システムに大きな影響を及ぼしてしまう。
（４）ジョブ定義削除：誤ってジョブ定義を削除してしまうと、取り返しがつかなくなる。

しかしながら、システムに大きな影響を及ぼす操作は、実際には良く行われる操作であり、誤りがあるかどうかについての判断も難しく、これらの操作を把握するには大変な手間がかかる。

一般的に、管理者に承認されているジョブの実行は可能とし、承認されていないジョブの実行を不可能とすることで誤操作を防止する技術として以下の特許文献１に記載の技術が知られている。この技術は、ジョブシステムに必要なジョブ定義情報、ジョブ依存関係情報、スケジュール情報を記憶部に保存し、ジョブ定義情報の更新があった場合にはその差分を記憶部に保存し、更新差分情報を確認したシステム管理者が承認した、実行を許可する旨の情報を承認データベースに保存し、ジョブ実行時には、情報差分のチェック部は記憶部と承認データベースの情報とを比較し、一致する場合のみ実行可能とするものである。

特開２００７−２２６４７２号公報

上記ジョブ承認技術においては、システム管理者に承認されていないジョブの実行は防げるが、ジョブ定義の編集に関しては、編集という処理の性格上、何回にもわたって試行錯誤を繰り返すのが一般的である。従って、逐一、システム管理者に承認されていない状態でも編集処理を実行することを可能とする必要があるために、場合によっては、誤った内容でジョブ定義を編集し更新してしまうことがある。すると、ジョブ定義の回復処理が必要となり、システムの運用に大きな影響を及ぼしてしまうという問題がある。

本発明は、ジョブ定義の編集処理におけるオペレータによる誤操作を防ぐことを目的とする。

本発明は、ジョブ定義編集およびジョブ実行の一連の操作が、システム管理者に承認されているか確認することで、未承認操作を防止することを特徴とする。より具体的には、以下の通りである。

本発明の一観点によれば、ジョブを一意に識別するためのジョブＩＤと、該ジョブＩＤで識別されるジョブのジョブ定義を操作する操作内容と、該操作内容に関する承認状態と、オペレータを一意に識別するオペレータＩＤと、の組を処理の進行に応じて追加しながら格納していく承認情報データベースと、システム管理者又はクライアントからの操作の承認依頼、システム管理者からの承認要求、却下要求を受付け、これに基づいて、前記ジョブＩＤを検索キーとして検索された前記承認情報データベース内における前記承認状態を書き換える更新処理部と、を有し、操作内容の承認状態が承認されている場合にのみ前記ジョブ定義に関する前記操作内容に応じた処理の実行を可能とすることを特徴とするジョブ運用管理システムが提供される。

上記システムによれば、要求された操作内容の許可を得るためにシステム管理者に承認を依頼し、該システム管理者がオペレータの承認依頼に対して承認可否の判定を行った結果として、承認状態の情報を所定の記憶部に保存し、所定の記憶部に保存されている承認状態を確認し、承認されている場合に限り、ジョブ定義編集、またはジョブ実行を可能となる。

さらに、少なくとも、現在実行中の前記ジョブＩＤと該ジョブＩＤと対応する前記操作内容と前記オペレータＩＤとを、操作の開始により発生し操作の終了により消去されるように一時的に格納する操作状況情報データベースを有し、該操作状況情報データベース内の操作状況情報に基づいて、対応するジョブの操作内容に関する処理を排他的に制限する承認状態確認処理部を有することが好ましい。このデータベースを参照することで、現在におけるジョブの名称と、操作内容とオペレータとを検知することが簡単になる。

前記ジョブ定義の編集内容を一時的に記憶する編集内容一時記憶部を有し、前記ジョブ定義の操作内容として編集処理を行った場合には、該ジョブ定義を格納するジョブ定義情報データベース内のジョブ定義を直接更新せずに、前記システム管理者が前記編集内容一時記憶部に保存されている編集内容を確認した結果として承認がなされている場合に限って、該編集内容で前記ジョブ定義情報を更新することが好ましい。

編集処理の場合には、１回の処理で終了せずに何回かにわたって処理を継続する必要がある場合が多いため、そのような場合でも、ジョブ定義が更新されるまでは承認状態を完了にしないことにより、複数回の編集が可能になる。

前記システム管理者が承認したタイミングを待ってから、前記編集内容一時記憶部に保存されている編集内容を読み込み、読み込んだ編集内容で前記ジョブ定義を更新し、前記承認状態を完了に変更することが好ましい。

ジョブ定義の編集により作成された編集内容を表示する表示部を有し、編集処理に基づく変更個所、追加個所、削除個所を強調して表示する機能を備えたことが好ましい。これにより、編集時の管理者による迅速な承認を促すことができる。

本発明により、次のような効果がある。
（１）ジョブ定義の編集について、システム管理者の承認を得てから編集可能とすることで、ユーザー名およびパスワードの不正利用による不正アクセスを防ぐことが可能になる。
（２）ジョブ定義の更新について、システム管理者の承認を得てから更新可能とすることで、不当な定義内容によるジョブ定義の更新を防ぐことが可能になる。
（３）ジョブ実行について、システム管理者の承認を得てから実行可能とすることで、不正に実行されることを防ぐことが可能になる。
（４）ジョブ定義の削除について、システム管理者の承認を得てから削除可能とすることで、不正に削除されることを防ぐことが可能になる。

以下、本発明を一実施の形態によるジョブ運用管理システムについて図面を参照しながら具体的に説明する。

図１は、本発明の一実施の形態によるジョブ運用管理システムの一構成例を示す機能ブロック図である。図１に示すように、破線で囲まれている構成が、プログラム制御により動作するコンピュータ101であり、ジョブ運用管理システムの中核部分である。このコンピュータ101と、図示しないが、管理者の端末やクライアントの端末が存在してシステムを構成する。図１に示すコンピュータ101は、ジョブ定義情報を格納するジョブ定義情報データベース（ＤＢ）109と、ジョブ関連情報を格納するジョブ関連情報データベース（ＤＢ）110と、スケジュール定義情報を格納するスケジュール定義情報データベース（ＤＢ）111と、承認情報を格納する承認情報データベース（ＤＢ）108と、編集内容を格納する編集内容データベース（ＤＢ）112と、ジョブの操作状況情報を格納するジョブの操作状況情報データベース（ＤＢ）113と、を有している。さらに、承認情報・ジョブ定義の各種情報を更新する更新処理部102と、各操作の承認状態確認を行う承認確認処理部103と、ジョブ定義編集を実施する定義編集処理部106と、ジョブの実行を実施する実行処理部104と、ジョブ定義削除を実施する削除処理部107と、ジョブ定義の編集内容を確認する編集内容確認処理部105（表示部などで確認することができる。）と、を備えている。

クライアント端末からの各操作の承認依頼、承認、却下要求Ｃ１は更新処理部102に入力され、クライアント端末からのジョブ定義編集、ジョブ実行、ジョブ定義削除の要求Ｃ２は承認確認処理部103に入力され、システム管理者の編集内容確認要求Ｃ３は編集内容確認処理部105に入力される。矢印は、データの流れ（方向）を示すものである。例えば、ジョブ定義編集処理部１０６により編集されたジョブ定義は、編集内容データベース（ＤＢ）112に一時的に格納され、更新処理部102と編集内容確認処理部105とに対して提供される。ジョブ定義情報データベース（ＤＢ）109と、ジョブ関連情報を格納するジョブ関連情報データベース（ＤＢ）110と、スケジュール定義情報を格納するスケジュール定義情報データベース（ＤＢ）111との内容が処理に基づいて更新されるようになっている。

尚、各データベースは、コンピュータ101内のハードディスク内に格納されるようになっていても良いし、外部に設けられたサーバに格納されるようになっていても良い。

図２は、承認情報を格納する承認情報データベース（ＤＢ）108内の承認情報の一構成例を示す図である。この承認情報データベース（ＤＢ）108内の承認情報は、ジョブ操作の承認状況を管理するための情報である。承認情報は、承認状態201と、ジョブを一意に識別するジョブ名202と、操作内容（種別）203と、編集種別204と、オペレータ名205と、承認期限206と、を有している。各設定内容について以下に示す。

承認状態201の欄には、承認の依頼中であることを示す“承認依頼”、承認済みであることを示す“承認済”、承認が却下されたことを示す“却下”、操作が完了したことを示す“完了”のうちのいずれかが格納される。太線で示したこの欄の情報のみが状況に応じて書き換えられ、他の欄は書き換えることができないようになっている。

ジョブ名202の欄には、編集、更新、実行、削除の操作対象となるジョブ名称（ＩＤ）を格納する。

操作内容203の欄には、ジョブに関する操作内容である、“編集”、“更新”、“実行”、“削除”のいずれかを格納する。

編集種別204の欄には、操作内容が“編集”の場合において、ジョブ定義の新規作成であれば“追加”が格納され、ジョブ定義の変更であれば“変更”が格納される。尚、この欄が未格納の状態であれば“変更”として扱う。新規追加の方が重要な処理となる場合が多いからである。尚、編集以外の操作内容では、編集種別の欄には記載されないようになっている。図２の承認状態201では、上の行から説明すると、ジョブ名“ＪＯＢ００１”のジョブを編集する操作に関するオペレータ名“ＡＡＡＡＡ”による追加編集の承認依頼があると、オペレータ名205の欄には、各操作を実施するオペレータ名を格納する。承認期限206の欄には、オペレータからの承認依頼に対して、システム管理者が承認を行う必要がある最終期限を格納する。システム管理者は、この承認期限206の欄を見ることで、承認期限までに承認または却下の決定をする必要があることを知ることができる。尚、承認情報108の更新と参照とは、それぞれ情報更新部102と承認確認部（表示ディスプレイなど）103で行うことが可能である。

また、ジョブ定義編集、実行、削除の操作を行っている間は、ジョブ定義の整合性を保つために、対象ジョブに対しては誰からも操作できないように制御されている。このため、操作対象のジョブ名、操作内容、オペレータ名を保持し、保持した情報を参照することで、対象ジョブの操作状況を確認できるようにする。

承認情報データベース（ＤＢ）108内には、同じジョブ名のジョブについて異なる操作内容が行われる毎に、行が追加されるようになっている。例えば、ジョブ名“ＪＯＢ００２”が、２行目において編集の変更操作が完了していることが示されている。次いで、３行目において、同じジョブ名“ＪＯＢ００２”の更新が承認済みになっている。さらに、５行目においては、同じオペレータ“ＢＢＢＢＢ”によるジョブ名“ＪＢ００２”の実行操作が承認済みになっている。このように、操作内容に応じて、承認情報データベース（ＤＢ）108内にログのように承認情報が順次記憶されていく。

一方、７行目において、例えば、ジョブ名“ＪＯＢ００５”が、編集の変更操作が承認済みになっており、次いで、８行目において、同じジョブ名“ＪＯＢ００５”の編集が承認済みになっている。このように、編集操作に関しては、更新が行われるまで編集を継続することができるようになっている。

上記制御を行うために、本実施の形態において新規に用いられるジョブの操作状況情報データベース（ＤＢ）113の一構成例について図３を参照しながら説明する。図３に示すように、本実施の形態によるジョブ運用管理システムのジョブの操作状況情報データベース（ＤＢ）113は、ジョブ名301と、操作内容302と、オペレータ名303と、から構成される。各設定内容について以下に説明する。図３に示すように、ジョブ名301の欄には、操作対象のジョブ名を格納する。操作内容302の欄には、ジョブの編集中であることを示す”編集”、ジョブの実行中であることを示す”実行”、ジョブ定義の削除中であることを示す”削除”のいずれかを格納する。オペレータ名303の欄には、ジョブを操作するオペレータ名を格納する。

ここで、操作状況情報データベース（ＤＢ）113の更新と参照とは、情報更新処理部102および承認確認処理部103において、それぞれ処理される。図３に示すジョブの操作状況情報は、現在行われているジョブ名と、その操作内容と、オペレータ名と、から構成されており、操作が終了すれば、操作状況情報データベース（ＤＢ）113からその操作内容・オペレータによるそのジョブの操作状況情報（１行）が消え、新たな操作が始まると、操作状況情報データベース（ＤＢ）113からその操作内容・オペレータによるそのジョブの操作状況情報（１行）が発生するようになっている。このデータベースＤＢを参照することで、現在におけるジョブの名称と、操作内容とオペレータとを検知することが簡単になる。

次に、情報更新処理部102における処理の流れについて、図４を参照しながら説明する。尚、システムに対する要求としては、１）承認依頼要求、２）承認要求、３）却下要求がある。１）の要求は、オペレータと管理者とのいずれもが可能であり、２）、３）の要求は、管理者のみが可能である。

処理が開始されると、はじめに要求内容がシステムに読み込まれ(ステップＳ401)、要求内容が確認される(ステップＳ402)。

ここで、要求内容が承認依頼であれば（ＹＥＳ）、承認情報データベース（ＤＢ）108内に、承認依頼内容（承認状態は“承認依頼”）が格納される(ステップＳ403)。要求内容が承認依頼でなければ（ＮＯ）、上記１）ではないため、管理者のみが対応できる、２）承認要求、３）却下要求のいずれかである。すなわち、要求内容には、”承認”または”却下”のいずれかがあり、システム管理者だけが要求できる。まず、システム管理者からの要求か否かを確認する(ステップＳ404)。ここで、システム管理者からの要求であれば（ＹＥＳ）、ステップＳ405に進み、一方、システム管理者からの要求でなければ（ＮＯ）、ステップＳ413において権限エラーとなり、処理が終了する。すなわち、オペレータが“承認要求”や“却下要求”を行った場合は権限エラーとして扱う。

ステップＳ405に進んだ場合には、要求内容が”承認”であるか否かを判定する。判定結果がＹＥＳであれば、要求内容が“承認”であるため、承認情報データベース（ＤＢ）108から承認対象の承認情報をジョブ名を検索キーとして検索し、該当する現在対象ジョブの承認状態を“承認済”に書き換え(ステップＳ406)、ステップＳ４０７に進む。一方、ステップＳ４０５において要求内容が“承認”でなければ、要求内容が”却下”であるか否かをステップＳ411において判定し、ＮＯであれば、要求不正としてステップＳ４１４で表示し、処理を終了する。ＹＥＳであれば、承認情報データベース（ＤＢ）108から却下対象の承認状態を“却下”に書き換えて、承認情報を更新する。

ステップＳ４０７において、承認対象の操作内容が編集内容の真の“更新”であれば、編集内容データベース（ＤＢ）112に保存されている内容で、ジョブ定義情報データベース（ＤＢ）109、ジョブ関連情報データベース（ＤＢ）110、スケジュール情報データベース（ＤＢ）111内のそれぞれの情報を更新し、更新後は、その処理が終了したので、一時的な情報データベースである編集情報データベース（ＤＢ）112から対象のジョブ定義情報を削除する(ステップＳ408)。この時、ジョブ定義編集時に使用した情報を承認情報データベース（ＤＢ）108から読み込み、その情報の承認状態を”完了”に書き換える(ステップＳ409：図２の２行目参照)。この処理は、ジョブ定義の編集処理については、ジョブ定義の規模が大きくなると、１回の編集操作で完了させることがオペレーションする上で困難なため、更新を行うまでの間は、複数回の編集を可能とする必要があるためである。編集以外のその他の操作については、操作を実施するたびに承認を必要とする。その他操作時の承認状態を”完了”に書き換える処理は、承認確認処理部103で行う。また、 (ステップＳ410)。ジョブ定義編集処理においては、編集が完了するまでの間、ジョブに対するその他の操作は抑止するように排他制御される。従って、ジョブ定義編集処理が終了した場合には、ジョブ定義編集時に使用した操作状況情報を操作状況情報データベース（ＤＢ）113から削除することにより、この操作を他人に開放することができる。ジョブの実行または削除については、完了するたびに操作状況情報を削除する。その他、操作時の操作状況情報を削除する処理は、承認確認処理部103で行う。

次に、承認確認処理部103における処理の流れについて図５を参照しながら説明する。オペレータがジョブ定義編集、ジョブ実行、ジョブ定義削除のいずれかの操作を行った場合に処理が開始され、承認情報データベース（ＤＢ）108から情報を読み込み(ステップＳ501)、そのオペレータが行おうとしている操作が“承認済”か否かを確認する(ステップＳ502)。オペレータが行おうとしている操作が承認済みであれば（ＹＥＳ）、操作状況情報データベース（ＤＢ）113において操作対象ジョブに関する情報を読み込む処理を行い(ステップＳ503)、操作対象のジョブに対して事前に他者が何らかの操作を行っていないかどうかの確認をする(ステップＳ504)。操作対象のジョブに対して事前に他者が何らかの操作を行っていないことは、操作対象ジョブに関する情報が存在しないことによって確認することができる。操作状況の情報から、他者が操作していない場合は（ＹＥＳ）、現在操作しようとしているオペレータの情報（オペレータ名、操作内容、ジョブ名）を操作状況情報データベース（ＤＢ）113に格納する(ステップＳ505)。これにより、当該ジョブ名に関するその他のオペレータによる処理を一時的に禁止する排他制御を行う。その後に、ジョブ定義編集、ジョブ実行、ジョブ定義削除のいずれかの操作を実行し(ステップＳ506)、ステップＳ507に進む。オペレータが行おうとしている操作が承認済みでない場合は（ＮＯ）、エラーにしても良いし、ステップＳ507に進むようにしても良い。ステップＳ507においては、操作内容は、実行又は削除のいずれかであるかどうかを判定する。実行又は削除のいずれかであれば（ＹＥＳ）、ステップＳ508に進む。ここで、承認情報データベース（ＤＢ）108の情報が“承認済”のままであると、ジョブに対する操作が何度でも可能となってしまう。これを防ぐため、各操作が完了した後には、承認状態を“完了”に書き換え、承認情報データベース（ＤＢ）108を更新する(ステップＳ508)。

但し、本実施の形態によるシステムでは、規模の大きなジョブ定義を編集する場合は、一回の編集操作で完了させるオペレーションは一般的には困難であることを考慮して、ここで承認状態を“完了”に書き換える対象操作は、ジョブの実行または削除の操作とのみとし、編集処理は対象外とする(ステップＳ507でＹＥＳ)。尚、ジョブ定義の編集については（ステップＳ507でＮＯ）、ジョブ定義を更新した場合において、情報更新処理部102で承認状態を”完了”に書き換える。このような仕組みにより、ジョブ定義の編集操作については、ジョブ定義が更新されるまでに複数回の編集が可能になる。

ジョブ実行またはジョブ定義削除が完了した後(ステップＳ508)に、操作状況情報データベース（ＤＢ）113に保存した情報を削除し(ステップＳ509)、他者にジョブの操作を可能にする。但し、ジョブ定義編集中のジョブについては、その他の操作を抑止する必要があるため、編集操作については、この時点で操作状況情報を削除しない。編集操作時は、承認状態と同様にジョブ定義の更新を行った時に、情報更新処理部102で操作状況情報を削除する。

尚、承認されていない操作（ステップＳ502でＮＯ）、または、他者が既に対象ジョブに対して何らかの操作を行っている場合は（ステップＳ504でＮＯ）、操作を行うことができないようにして、エラーとして処理する。

図５の処理は、さらに継続して行われ、図２に示すログが追加されるとともに、図３に示す一時的な記憶は適宜追加・消去されていく。

次に、定義編集処理部106における処理の流れについて図６を参照しながら説明を行う。処理が開始されると（開始）、定義編集処理部106は、承認確認処理部103で承認された編集操作と判断できた場合に、処理要求を受け付ける。まず、今回の要求が編集対象のジョブに対して、初回の編集か否かを確認する。この確認方法としては、編集内容データベース（ＤＢ）112に対象のジョブ定義情報が保存されているか否かを確認し、保存されていれば２回目以降の編集時であり（ＹＥＳ）、保存されていなければ初回の編集時である（ＮＯ）と判断する(ステップＳ601)。

編集対象のジョブに対して初回の編集時では（ＹＥＳ）、まず編集種別を確認する(ステップＳ602)。ステップＳ602において、編集種別が“変更”であれば（ＹＥＳ）、既にあるジョブ定義に対する編集とみなして、ジョブ定義情報データベース（ＤＢ）109、ジョブ関連情報データベース（ＤＢ）110、スケジュール情報データベース（ＤＢ）111から定義情報を読み込み(ステップＳ603)、読み込んだ定義情報に対して編集処理を行うことができるようにする(ステップＳ604)。編集種別が”追加”であれば（ステップＳ602でＮＯ）、そのまま編集処理を行う(ステップＳ604)。いずれの場合においても、編集処理後に、編集結果を編集内容データベース（ＤＢ）112内に格納する(ステップＳ605)。

編集対象のジョブに対する２回目以降の編集時には（ステップＳ601でＮＯ）、前回編集時の編集結果を、編集内容データベース（ＤＢ）112から読み込み(ステップＳ606)、この編集結果に対して編集を行う(ステップＳ604)。編集処理後に、編集結果を編集内容112に格納する(ステップＳ605)。

オペレータが編集した内容については、更新可否を判断するためシステム管理者は、編集内容を確認する必要がある。この確認を行う編集内容確認処理部105の処理動作について図７を参照しながら説明を行う。処理が開始されると、まず、システム管理者からの要求か否か（操作者はシステム管理者か否か）を確認する(ステップＳ701)。ここで、オペレータからの要求であれば（ＮＯ）エラーとして扱う（ステップＳ707）。システム管理者が操作者であった場合は（ＹＥＳ）、編集内容データベース（ＤＢ）112から情報を読み込む(ステップＳ702)。この後、確認対象のジョブが、変更したジョブであるか新規に追加したジョブであるかを確認する(ステップＳ703)。

変更したジョブ定義の場合（ＹＥＳ）には、ジョブ定義情報データベース（ＤＢ）109、ジョブ関連情報データベース（ＤＢ）110、スケジュール情報データベース（ＤＢ）111のそれぞれから情報を読み込み、編集内容データベース（ＤＢ）112から読み込んだ情報と比較して、両者の差分を求める(ステップＳ704)。これにより、変更したジョブ定義の内容のみをピックアップすることができる。この際、変更内容を確認しやすくするために、求めた差分を使用し変更点を強調して表示するようにしても良い(ステップＳ705)。

図８は、１つのジョブ定義単位で、編集された内容の表示例を符号ＡからＩまでによって模式的に示した概念図である。追加８０１、変更８０２、削除８０３のそれぞれの個所については強調して表示し、変更箇所８０２については変更前後の内容（８０２ａ・８０２ｂ）についても表示するようにできる。これにより、オペレータが編集した内容を、システム管理者が確認作業する際の負担を軽減することができる。特に、変更前８０２ａと変更後８０２ｂとを対比させることが容易にできるため、変更箇所を把握しやすい。従って、システム管理者の承認時における負担を軽減し、かつ、システム管理者の誤承認を防止することができる。

追加したジョブ定義８０１の場合は、差分は存在しないため、変更時とは異なり強調表示は行う必要はないが、視覚的に識別可能な形態で追加したジョブであることがわかるように表示するのが好ましい(ステップＳ706)。削除した場合も、実体は存在しないわけであるが、削除した箇所がわかりやすいように、階調が薄い字で表示するようにしても良い。変更・追加・削除が混在している場合には、それらが区別できるようにわかりやすく表示することが好ましい。

ジョブ実行を制御する実行処理部104は、承認確認処理部103でジョブ実行操作に対して承認済みであると判明し、また対象ジョブに対して他者が操作していないことが判明すると、実行処理部104においてジョブ実行を行うことができる。ジョブ実行を制御する実行処理部104は、承認確認処理部103でジョブ実行操作に対して承認済みであると判明し、また対象ジョブに対して他者が操作していないことが判明するまでは、ジョブの実行が抑止されるように制御することが好ましい。

ジョブ定義の削除を制御する削除処理部107は、承認確認処理部103において、ジョブ定義削除操作に対して承認済みと判明し、また対象ジョブに対して他者が操作していないと判明すると、削除処理部104でジョブ定義削除を行う。ジョブ定義の削除を制御する削除処理部107は、承認確認処理部103において、ジョブ定義削除操作に対して承認済みと判明し、また対象ジョブに対して他者が操作していないと判明するまでは、削除処理部104でジョブ定義削除を行われるのが抑止されるように制御することが好ましい。

以上に説明したように、本実施の形態によるジョブ管理運用システムによれば、ジョブに関する一連の操作を制限するだけではなく、誰がどのジョブに対して、どんな操作をしたのかを履歴として蓄積でき、システム運用の統制ができる。特に、編集処理の場合には、編集処理の種別が多く、１回の処理で終了せずに何回かにわたって処理を継続する必要がある場合が多いが（例えば図８における追加、変更、削除の各処理）、そのような場合でも、ジョブ定義が更新されるまでは承認状態を完了にしないことにより、複数回の編集が可能になるという利点がある。

本発明はジョブ運用システムに利用可能である。

本発明の一実施の形態によるジョブ管理運用システムの一構成例を示す機能ブロック図である。 承認情報データベース（ＤＢ）の一構成例を示す図である。 操作状況情報データベース（ＤＢ）の一構成例を示す図である。 承認情報およびジョブ定義一連の情報更新処理部における処理の流れを示すフローチャート図である。 承認状態を確認する承認確認処理部における処理の流れを示すフローチャート図である。 ジョブの定義編集を実施する定義編集処理部における処理の流れを示すフローチャート図である。 ジョブ定義の編集内容を確認する編集内容確認処理部における処理の流れを示すフローチャート図である。 ジョブ定義変更時の編集内容の表示例を概念的に示す図である。

符号の説明

１０１…コンピュータ、１０２…更新処理部、１０３…承認確認処理部、１０６…定義編集処理部、１０４…実行処理部、１０７…削除処理部、１０５…編集内容確認処理部、１０８…承認情報データベース、１０９…ジョブ定義情報データベース、１１０…ジョブ関連情報データベース、１１１…スケジュール定義情報データベース、１１２…編集内容データベース、１１３…操作状況情報データベース。

Claims (5)

1. ジョブを一意に識別するためのジョブＩＤと、該ジョブＩＤで識別されるジョブのジョブ定義を操作する操作内容と、該操作内容に関する承認状態と、オペレータを一意に識別するオペレータＩＤと、の組を処理の進行に応じて追加しながら格納していく承認情報データベースと、
   システム管理者又はクライアントからの操作の承認依頼、システム管理者からの承認要求、却下要求を受付け、これに基づいて、前記ジョブＩＤを検索キーとして検索された前記承認情報データベース内における前記承認状態を書き換える更新処理部と、を有し、
   操作内容の承認状態が承認されている場合にのみ前記ジョブ定義に関する前記操作内容に応じた処理の実行を可能とすることを特徴とするジョブ運用管理システム。
2. さらに、少なくとも、現在実行中の前記ジョブＩＤと該ジョブＩＤと対応する前記操作内容と前記オペレータＩＤとを、操作の開始により発生し操作の終了により消去されるように一時的に格納する操作状況情報データベースを有し、
   該操作状況情報データベース内の操作状況情報に基づいて、対応するジョブの操作内容に関する処理を排他的に制限する承認状態確認処理部を有することを特徴とする請求項１に記載のジョブ運用管理システム。
3. 前記ジョブ定義の編集内容を一時的に記憶する編集内容一時記憶部を有し、
   前記ジョブ定義の操作内容として編集処理を行った場合には、該ジョブ定義を格納するジョブ定義情報データベース内のジョブ定義を直接更新せずに、前記システム管理者が前記編集内容一時記憶部に保存されている編集内容を確認した結果として承認がなされている場合に限って、該編集内容で前記ジョブ定義情報を更新することを特徴とする請求項１又は２に記載のジョブ運用管理システム。
4. 前記システム管理者が承認したタイミングを待ってから、前記編集内容一時記憶部に保存されている編集内容を読み込み、読み込んだ編集内容で前記ジョブ定義を更新し、前記承認状態を完了に変更することを特徴とする請求項３に記載のジョブ運用管理システム。
5. ジョブ定義の編集により作成された編集内容を表示する表示部を有し、
   編集処理に基づく変更個所、追加個所、削除個所を強調して表示する機能を備えたことを特徴とする請求項１から４までのいずれか１項に記載のジョブ運用管理システム。

Images