JP2016018350A - バッチサーバメンテナンス方法 - Google Patents

Abstract

【課題】バッチ業務や関連するオンライン業務への影響を最小限に抑えつつ、業務バッチプログラムが長時間稼働するバッチサーバに対するメンテナンスを行う。【解決手段】業務バッチプログラム１１が実行中であるバッチサーバに対してメンテナンスを行うバッチサーバメンテナンス方法であって、（ａ）メンテナンスプログラム１２が、バッチサーバに停止依頼フラグ１４を立てさせる工程と、（ｂ）業務バッチプログラム１１が、バッチサーバにチェックポイントＣＰのタイミング毎に停止依頼フラグ１４が立っているか否かを判定させ、立っている場合には停止完了フラグ１６を立てて実行を停止させる工程と、（ｃ）メンテナンスプログラム１２が、バッチサーバに業務バッチプログラム１１に係る停止完了フラグ１６が立っているか否かを判定させ、立っている場合にバッチサーバに対するメンテナンスを行わせる工程とを有する。【選択図】図１

Description

本発明は、サーバ機器の運用管理技術に関し、特に、長時間のバッチ処理を行うサーバ機器のメンテナンス方法に適用して有効な技術に関するものである。

サーバ機器を含んで構成される情報処理システムにおいて、システムの正常稼働を維持するには、サーバ機器に対するパッチやバグフィクス等の修正プログラムの適用やソフトウェアのバージョンアップ、定期的なリブートなどのメンテナンス処理が必要である。メンテナンス中のサーバは、基本的に業務処理を行うことができないため、全体的な業務の継続に影響を与えないようにするために種々の対策が講じられる。

例えば、特開２０１２−１７４２２０号公報（特許文献１）には、複数のサーバを備えるシステムにおいて、各サーバのリブートを管理するサーバ管理装置と、第１のサーバグループについてリブートを実行した後に第２のサーバグループについてリブートを実行するリブート順序の計画を立てるリブート計画部と、リブートを指示したサーバグループを構成するサーバについてリブートが完了しない場合、リブートが完了しないサーバを切り離してサーバグループの縮退運用が可能か否かを判定する縮退運用判定部と、第１のサーバグループを構成するサーバにリブートエラーがあっても、縮退運用判定部による第１のサーバグループの縮退運用が可能の判定をリブート完了とみなして、第２のサーバグループにリブート指示を行うリブート制御部とを有することで、保守担当者の負担を軽減しつつ、保守時間内のサーバのリブートを実行可能とする技術が記載されている。

また、特開２００３−１５８９４号公報（特許文献２）には、複数のコンピュータから構成されるクラスタを少なくとも一つ含むコンピュータシステムにおいて、総合監視装置が複数のコンピュータの構成情報等を管理し、その構成情報等に基づいて、パッチの適用スケジュールを決定することで、前記コンピュータシステム全体を停止することなく、前記コンピュータシステムを構成するそれぞれのコンピュータで動作するオペレーティングシステムに対してパッチの適用処理を行う技術が記載されている。

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

従来技術では、サーバのメンテナンスにおいて、同一の処理を行うことができるサーバが複数系統存在するサーバグループやクラスタの構成が前提とされ、一部のサーバ毎に順に保守のための停止時間を設けてその間に効率的にメンテナンス処理を行うものとされている。

上記のような手法は、オンライン業務を行うサーバ（以下では「業務サーバ」と記載する場合がある）については適用が可能であるが、バッチ業務を行うサーバ（以下では「バッチサーバ」と記載する場合がある）については適用が困難である。オンライン業務は、通常、処理が短時間で終了するトランザクションが多量に発生する特性を有することから、複数系統の業務サーバを起動して負荷分散による処理能力向上と可用性向上を図る構成がとられ、業務中にメンテナンス対象のサーバを切り離して停止させることは比較的容易である。

一方で、バッチ業務は、通常、即時性の要求が高くないことから、複数系統のバッチサーバを用意して処理能力と可用性を向上させるという対応がとられずにシングルサーバとして構成される場合が多く、また、大量のデータに対して一括して処理することから処理時間が長時間になる場合があり、処理中の業務バッチプログラムをメンテナンスのために所望のタイミングで停止させることは困難である。

そこで本発明の目的は、バッチ業務や関連するオンライン業務への影響を最小限に抑えつつ、業務バッチプログラムが長時間稼働するバッチサーバに対するメンテナンスを行うバッチサーバメンテナンス方法を提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態によるバッチサーバメンテナンス方法は、１つ以上のバッチプログラムが実行中であるバッチサーバに対してメンテナンスを行うバッチサーバメンテナンス方法であって、（ａ）前記バッチサーバに対するメンテナンスを行うために起動されたメンテナンスプログラムが、前記バッチサーバに停止依頼フラグを立てさせる工程と、（ｂ）前記各バッチプログラムが、前記バッチサーバに、実行中に所定の間隔で到来するチェックポイントのタイミング毎に、前記停止依頼フラグが立っているか否かを判定させ、前記停止依頼フラグが立っていない場合には実行を継続させ、前記停止依頼フラグが立っている場合にはそれぞれ停止完了フラグを立てて実行を停止させる工程と、（ｃ）前記メンテナンスプログラムが、前記バッチサーバに、前記各バッチプログラムに係る前記停止完了フラグが立っているか否かを判定させ、前記各停止完了フラグが全て立っている場合に、前記バッチサーバに対するメンテナンスを行わせる工程と、を有するものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、バッチ業務や関連するオンライン業務への影響を最小限に抑えつつ、業務バッチプログラムが長時間稼働するバッチサーバに対するメンテナンスを行うことが可能となる。

本発明の一実施の形態であるバッチサーバメンテナンス方法の例について概要を示した図である。 本発明の一実施の形態のバッチサーバメンテナンス方法が適用される情報処理システムの構成例について概要を示した図である。 本発明の一実施の形態における業務バッチプログラムの処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態におけるメンテナンスプログラムの処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態における業務サーバプログラムの処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態におけるバッチ管理テーブルのデータ構成の例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

上述したように、業務バッチプログラムが長時間稼働するバッチサーバは、処理中の業務バッチプログラムを停止させるのが困難であることから、メンテナンスのための停止時間を所望のタイミングで設けることが難しい。

また、業務バッチプログラムが稼働するバッチサーバの中には、他の業務サーバ等から、例えば、１５分毎に１回や、１０００件処理毎に１回などのタイミングでファイル転送によりデータが送信されるなど、所定の間隔でアクセスがされる場合がある。このような構成の場合に、例えば、業務サーバが、２４時間３６５日もしくはこれに類する程度の常時稼働のシステムである場合は特に、バッチサーバについても常に稼働可能とされている必要があり、メンテナンスのための停止時間を設けることは困難である。また、バッチサーバについてメンテナンスを行うにしても、その間は、他の業務サーバがファイル転送等を停止してバッチサーバにアクセスしてこないよう制御するなどの対応が必要となる。

そこで、本発明の一実施の形態であるバッチサーバメンテナンス方法は、業務バッチプログラムに一時停止可能なチェックポイントを所定の間隔で設けておき、業務バッチプログラムから参照可能な記憶領域において、メンテナンスジョブ等により停止依頼フラグが立てられている場合に、業務バッチプログラムが次のチェックポイントで自発的に一旦終了することで、その後、バッチサーバに対してメンテナンス処理（メンテナンスジョブの実行等）を行うことを可能とするものである。また、メンテナンスの完了後は、フラグを解除した上で一旦終了されていた業務バッチプログラムをチェックポイントから再開する。

これにより、業務バッチプログラムを通常通り稼働させつつ、メンテナンス処理が必要なタイミングで停止依頼フラグを立てることで、業務バッチプログラムを一旦終了させ、メンテナンスのための停止時間を確保することが可能となる。

図１は、本発明の一実施の形態であるバッチサーバメンテナンス方法の例について概要を示した図である。バッチサーバ上で稼働する業務バッチプログラム１１には、所定の間隔でチェックポイントＣＰが設けられており、業務バッチプログラム１１は、チェックポイントＣＰが到来する毎に、停止依頼フラグ１４が立っているか否かをチェックする。一方、メンテナンスプログラム１２は、例えば、メンテナンス処理の実行が必要となったタイミングで起動され、停止依頼フラグ１４を立てる（ＯＮに設定する）。

停止依頼フラグ１４がＯＮに設定されると、業務バッチプログラム１１は、次のチェックポイントＣＰのタイミングでこれを検知し、その後、停止完了フラグ１６を立てる（ＯＮに設定する）とともに異常終了する。メンテナンスプログラム１２は、停止完了フラグ１６がＯＮに設定されていること、すなわち、業務バッチプログラム１１が終了したことを確認した後、所望のメンテナンス処理を実行する。メンテナンス処理が完了すると、メンテナンスプログラム１２は、停止依頼フラグ１４および停止完了フラグ１６を解除する。その後、業務バッチプログラム１１は、前回異常終了したチェックポイントＣＰから処理を再開することができる。

＜システム構成＞
図２は、本発明の一実施の形態のバッチサーバメンテナンス方法が適用される情報処理システムの構成例について概要を示した図である。対象となる情報処理システムは、例えば、バッチサーバ１０と、１つ以上の業務サーバ２０とが、ＬＡＮ（Local Area Network）等のネットワーク３０を介して相互に通信可能なように接続された構成を有する。

バッチサーバ１０は、バッチ業務を行うサーバ機器であり、例えば、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）などのミドルウェア上で稼働するソフトウェアにより実装される１つ以上の業務バッチプログラム１１、およびメンテナンスプログラム１２などの各プログラムを有し、これらを手動もしくは自動により実行することができる。また、データベースやファイル、メモリテーブル等により実装されるバッチ管理テーブル１３、停止依頼フラグ１４、およびサーバリスト１５などの各データを有する。

業務バッチプログラム１１は、業務サーバ２０において実行されるオンライン業務と関連した業務処理を実行するバッチプログラムである。例えば、各業務サーバ２０における一定期間の業務処理により発生した複数件の処理依頼データやログファイル等をネットワーク３０を介して取得し、業務サーバ２０におけるオンライン業務とは非同期で、一括して登録等の処理を行うようなプログラムが想定される。

業務バッチプログラム１１は、上述したように、所定の間隔（例えば、１５分毎に１回や、１０００件処理毎に１回などのタイミング）で、自発的に一時停止可能なチェックポイントが実装されており、各チェックポイントにおいて後述する停止依頼フラグ１４がＯＮとなっている場合は、当該チェックポイントから再開可能なように必要な情報を記録した上で、一旦処理を異常終了するよう実装されているものとする。

メンテナンスプログラム１２は、バッチサーバ１０に対するメンテナンス処理を行うプログラムであり、メンテナンスを実行するタイミングで自動もしくは手動により起動される。メンテナンス処理としては、例えば、バッチサーバ１０のＯＳ等のミドルウェアや、業務バッチプログラムを含む他のソフトウェアに対するパッチの適用やバージョンアップ、バッチサーバ１０のリブートなど、業務バッチプログラム１１が処理を実行中の場合には実行できない内容の処理が含まれるものとする。

バッチ管理テーブル１３は、業務バッチプログラム１１の実行状況を管理するテーブルである。実行状況には、バッチサーバ１０のメンテナンスのためにチェックポイントで一旦終了している状況についても含まれる。バッチ管理テーブル１３の内容については後述する。

停止依頼フラグ１４は、バッチサーバ１０のメンテナンスを行うためにメンテナンスプログラム１２が起動された際に、業務バッチプログラム１１に対して停止を依頼するため、メンテナンスプログラム１２によりＯＮに設定されるフラグである。当該フラグは、例えば、各業務バッチプログラム１１から参照可能な図示しないメモリやＨＤＤなどの記憶装置上に設定することができる。バッチ管理テーブル１３やその他のデータベース上に設定、保持するようにしてもよい。

サーバリスト１５は、バッチサーバ１０のメンテナンス処理を行う際に、これを通知する（停止依頼を行う）必要がある業務サーバ２０の宛先情報などのリストを保持するデータである。通知対象となる業務サーバ２０は、上述したように、例えば、バッチサーバ１０に対して所定の間隔でファイル転送などのアクセスを行う業務サーバ２０であり、バッチサーバ１０のメンテナンス中に当該アクセスをさせないようにする必要があるものである。通知対象となる業務サーバ２０が固定されている場合には不要とすることも可能である。サーバリスト１５には、例えば、各業務サーバ２０のホスト名やＩＰアドレスなどのリストが保持され、メンテナンスプログラム１２は、この情報に基づいて、対象となる各業務サーバ２０に対して停止依頼を通知する。

業務サーバ２０は、図示しないクライアント端末等に対してネットワーク３０等を介してオンライン業務機能を提供するサーバ機器であり、例えば、図示しないＯＳやＤＢＭＳ、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアにより実装される業務サーバプログラム２１などを有する。また、データベースやファイル、メモリテーブル等により実装される停止依頼フラグ２２などのデータを有する。業務サーバプログラム２１の種類や内容が異なる複数の業務サーバ２０を有していてもよいし、１つの種類の業務サーバ２０が複数台並列に設けられ、負荷分散処理を行う構成であってもよい。

業務サーバプログラム２１は、クライアント端末等からの要求に基づいてオンライン業務処理を行うプログラムである。本実施の形態では、所定の間隔（例えば、１５分毎に１回や、１０００件処理毎に１回など）で、それまでに蓄積された複数件の処理依頼データやログファイル等をネットワーク３０を介してバッチサーバ１０にファイル転送し、業務バッチプログラム１１による一括処理を依頼する機能を有するものとする。このとき、後述する停止依頼フラグ２２がＯＮとなっている場合は、バッチサーバ１０へのファイル転送を行わない（例えば、フラグが解除されるまで待つ、もしくは保留して処理を継続する等）よう実装されているものとする。

停止依頼フラグ２２は、バッチサーバ１０においてメンテナンスプログラム１２が起動された際に、メンテナンスプログラム１２からの停止依頼の通知を受けてＯＮに設定されるフラグである。当該フラグは、例えば、業務サーバプログラム２１から参照可能な図示しないメモリやＨＤＤなどの記憶装置上に設定することができる。

＜処理の流れ＞
図３は、バッチサーバ１０上の業務バッチプログラム１１の処理の流れの例について概要を示したフローチャートである。業務バッチプログラム１１は、処理を開始すると、後述するバッチ管理テーブル１３に情報を登録した上で、各処理ステップについて順次処理を繰り返すループ処理を開始する（Ｓ０１〜Ｓ０５）。

各処理ステップでは、まず、チェックポイントが到来しているか否かを判定する（Ｓ０２）。チェックポイントは、上述したように、例えば、１５分毎に１回や、１０００件処理毎に１回などの所定の間隔で到来するよう実装してもよいし、業務バッチプログラムの一連の処理ステップの中で適切な場所に直接埋め込まれていてもよい。チェックポイントがまだ到来していない場合は、対象の処理ステップを通常通り実行し（Ｓ０４）、次の処理ステップに移ってループ処理を継続する（Ｓ０５、Ｓ０１）。全ての処理ステップの実行がされ、ループ処理を終了すると、正常終了として業務バッチプログラム１１を終了する（Ｓ０６）。

ステップＳ０２で、チェックポイントが到来している場合は、チェックポイント時の処理として、バッチサーバ１０上で停止依頼フラグ１４が立っている（ＯＮに設定されている）か否かを判定する（Ｓ０３）。停止依頼フラグ１４がＯＮに設定されていない場合は、ステップＳ０４に進んで対象の処理ステップの実行を継続する。

ステップＳ０３で、停止依頼フラグ１４がＯＮに設定されている場合は、業務バッチプログラム１１の処理を一時停止する。すなわち、一時停止後に当該チェックポイントから処理を再開するために必要な情報を記録し（Ｓ０７）、停止完了フラグ１６をＯＮに設定した上（Ｓ０８）、異常終了として業務バッチプログラム１１を終了する（Ｓ０９）。なお、停止完了フラグ１６は、本実施の形態では、後述するバッチ管理テーブル１３上に業務バッチプログラム１１毎に設定するものとしている。

以上の処理により、業務バッチプログラム１１は、各チェックポイントにおいて、停止依頼フラグ１４がＯＮに設定されている場合には、自発的に一時停止（本実施の形態ではサスペンドではなく異常終了）することが可能となる。

図４は、バッチサーバ１０上のメンテナンスプログラム１２の処理の流れの例について概要を示したフローチャートである。メンテナンスプログラム１２は、バッチサーバ１０においてパッチ適用などのメンテナンスジョブを実行する必要が生じた際に起動される。起動されると、まず、バッチサーバ１０上で、業務バッチプログラム１１を一時停止させるための停止依頼フラグ１４をＯＮに設定する（Ｓ１１）。

その後、関連する業務サーバ２０に対しても、バッチサーバ１０へのアクセスを停止するよう、停止依頼を通知する（Ｓ１２）。関連する業務サーバ２０の情報は、例えば、サーバリスト１５を参照して取得することができる。なお、本実施の形態では、バッチサーバ１０から各業務サーバ２０に対して停止依頼の情報を通知するＰＵＳＨ型の通知としているが、各業務サーバ２０が適宜バッチサーバ１０に停止依頼フラグ１４の状況を問い合わせるＰＵＬＬ型の通知としてもよい。

その後、業務バッチプログラム１１が全て停止したか否かを判定する（Ｓ１３）。すなわち、対象の全ての業務バッチプログラム１１が停止完了フラグ１６をＯＮに設定しているか否かを判定する。本実施の形態では、上述したように、各業務バッチプログラム１１についての停止完了フラグ１６の状況は、バッチ管理テーブル１３上で管理される。業務バッチプログラム１１のみに限らず、ステップＳ１２で停止依頼を通知した全ての業務サーバ２０がバッチサーバ１０へのアクセスを停止したことも併せて確認するようにしてもよい。

ステップＳ１３で、業務バッチプログラム１１が全て停止していない場合は、一定時間Ｗａｉｔした後（Ｓ１４）、ステップＳ１３に戻って再度業務バッチプログラム１１の停止を確認する。業務バッチプログラム１１が全て停止した場合は、所望のメンテナンス処理を実行する（Ｓ１５）。ここでは、メンテナンスプログラム１２自身が、バッチサーバ１０のＯＳ等に対してパッチ適用等の処理を行ってもよいし、メンテナンス処理が実行可能な状態になったことをシステム管理者等に通知することで、手動でのメンテナンスを促すようにしてもよい。

メンテナンス処理が終了すると、メンテナンスプログラム１２は、停止フラグを全てＯＦＦに設定して解除し（Ｓ１６）、処理を終了する。なお、停止フラグには、バッチサーバ１０上の停止依頼フラグ１４や業務サーバ２０上の停止依頼フラグ２２、およびバッチ管理テーブル１３上の停止完了フラグ１６などが含まれる。

以上の処理により、メンテナンスプログラム１２（もしくはシステム管理者等）は、長時間稼働する業務バッチプログラム１１を全て一時停止させて作業時間枠を強制的に形成した上でメンテナンス処理を実行することができる。

図５は、業務サーバ２０上の業務サーバプログラム２１の処理の流れの例について概要を示したフローチャートである。業務サーバプログラム２１は、処理を開始すると、各処理ステップについて順次処理を繰り返すループ処理を開始する（Ｓ２１〜Ｓ２７）。

各処理ステップでは、まず、処理内容がバッチサーバ１０へのアクセス（本実施の形態ではファイル転送）であるか否かを判定する（Ｓ２２）。ファイル転送でない場合は、対象の処理ステップを通常通り実行し（Ｓ２３）、次の処理ステップに移ってループ処理を継続する（Ｓ２７、Ｓ２１）。全ての処理ステップの実行がされ、ループ処理を終了すると、業務サーバプログラム２１を終了する。

ステップＳ２２で、処理ステップがファイル転送である場合は、業務サーバ２０上で停止依頼フラグ２２が立っている（ＯＮに設定されている）か否かを判定する（Ｓ２４）。上述したように、ローカルの停止依頼フラグ２２の状態を確認するのに代えて、バッチサーバ１０に対して停止依頼フラグ１４の状態を問い合わせるようにしてもよい。停止依頼フラグ２２がＯＮに設定されていない場合は、通常通りバッチサーバ１０へのファイル転送処理を実行し（Ｓ２５）、次の処理ステップに移ってループ処理を継続する（Ｓ２７、Ｓ２１）。

一方、ステップＳ２４で、停止依頼フラグ２２がＯＮに設定されている場合は、一定時間Ｗａｉｔした後（Ｓ２６）、ステップＳ２４に戻って再度停止依頼フラグ２２の状態を確認する。すなわち、停止依頼フラグ２２がＯＦＦに設定される（解除される）まで、バッチサーバ１０へのファイル転送を一時的に留保する。

なお、図５の例では、バッチサーバ１０へのファイル転送を留保している間、通常の処理ステップについても処理が停止することになる。ここで、業務サーバプログラム２１が画面等のユーザインタフェースをクライアント端末等に対して提供する構成の場合、ユーザに対する画面を介した通知として、例えば、バッチサーバ１０上で停止依頼フラグ１４が立っているのみの場合は「処理に時間がかかる可能性があります」などのメッセージを表示し、停止完了フラグ１６が立っている場合は「処理完了まで○○分程度お待ちください」などのメッセージを表示するようにしてもよい。また、可能な場合には、ファイル転送を通常の処理ステップとは非同期とし、ファイル転送のみ留保して通所の処理ステップは継続されるようにしてもよい。

以上の処理により、業務サーバプログラム２１は、バッチサーバ１０がメンテナンス処理を行っている間は、バッチサーバ１０へのファイル転送等によるアクセスを停止することができる。

＜データ構成＞
図６は、バッチサーバ１０上のバッチ管理テーブル１３のデータ構成の例について概要を示した図である。バッチ管理テーブル１３は、業務バッチプログラム１１の実行状況を管理するテーブルであり、例えば、プログラム名、起動日時、停止完了フラグ、チェックポイント、停止日時、再開日時、および終了日時などの各項目を有する。

プログラム名の項目は、対象の業務バッチプログラム１１を一意に特定する名称やＩＤ等の情報を保持する。起動日時の項目は、対象の業務バッチプログラム１１が起動した時点のタイムスタンプの情報を保持する。停止完了フラグの項目は、対象の業務バッチプログラム１１が、停止依頼フラグ１４がＯＮに設定されているのに基づいて処理を一時停止したことを示すフラグの情報を保持する。チェックポイントの項目は、対象の業務バッチプログラム１１が一時停止した時点のチェックポイントを特定する情報を保持する。当該チェックポイントは、対象の業務バッチプログラム１１を再実行する際の開始ポイントとなる。

停止日時の項目は、対象の業務バッチプログラム１１が一時停止（本実施の形態では、上述したようにサスペンドではなく異常終了）した時点のタイムスタンプの情報を保持する。再開日時の項目は、対象の業務バッチプログラム１１が一時停止した後再実行された時点のタイムスタンプの情報を保持する。終了日時の項目は、対象の業務バッチプログラム１１が処理を完了した時点のタイムスタンプの情報を保持する。

なお、図６で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。

以上に説明したように、本発明の一実施の形態であるバッチサーバメンテナンス方法によれば、業務バッチプログラム１１に一時停止可能なチェックポイントを所定の間隔で設けておき、業務バッチプログラム１１から参照可能な記憶領域において、メンテナンスプログラム１２により停止依頼フラグ１４が立てられている場合に、業務バッチプログラム１１が次のチェックポイントで自発的に一旦終了する。また、停止依頼フラグ１４を立てる際に、関連する業務サーバ２０に対しても停止依頼を行うことで、業務サーバ２０上の業務サーバプログラム２１は、バッチサーバ１０へのアクセスを停止する。

これらの処理により、業務バッチプログラム１１を通常通り稼働させつつメンテナンスのための停止時間を確保し、バッチサーバ１０に対してメンテナンス処理を行うことが可能となる。また、メンテナンスの完了後は、フラグを解除した上で一旦終了されていた業務バッチプログラム１１をチェックポイントから再開することができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

本発明は、長時間のバッチ処理を行うサーバ機器のメンテナンス方法に利用可能である。

１０…バッチサーバ、１１…業務バッチプログラム、１２…メンテナンスプログラム、１３…バッチ管理テーブル、１４…停止依頼フラグ、１５…サーバリスト、１６…停止完了フラグ、
２０…業務サーバ、２１…業務サーバプログラム、２２…停止依頼フラグ、
３０…ネットワーク、
ＣＰ…チェックポイント

Claims (4)

1. １つ以上のバッチプログラムが実行中であるバッチサーバに対してメンテナンスを行うバッチサーバメンテナンス方法であって、
   （ａ）前記バッチサーバに対するメンテナンスを行うために起動されたメンテナンスプログラムが、前記バッチサーバに停止依頼フラグを立てさせる工程と、
   （ｂ）前記各バッチプログラムが、前記バッチサーバに、実行中に所定の間隔で到来するチェックポイントのタイミング毎に、前記停止依頼フラグが立っているか否かを判定させ、前記停止依頼フラグが立っていない場合には実行を継続させ、前記停止依頼フラグが立っている場合にはそれぞれ停止完了フラグを立てて実行を停止させる工程と、
   （ｃ）前記メンテナンスプログラムが、前記バッチサーバに、前記各バッチプログラムに係る前記停止完了フラグが立っているか否かを判定させ、前記各停止完了フラグが全て立っている場合に、前記バッチサーバに対するメンテナンスを行わせる工程と、
   を有する、バッチサーバメンテナンス方法。
2. 請求項１に記載のバッチサーバメンテナンス方法において、
   前記（ａ）工程では、さらに、前記メンテナンスプログラムが、前記バッチサーバに、当該バッチサーバに対してアクセスし得る他のサーバに対して停止依頼を通知させ、
   さらに、（ｄ）前記バッチサーバから前記停止依頼の通知を受けた前記他のサーバが、前記バッチサーバに対するアクセスを停止する工程、を有する、バッチサーバメンテナンス方法。
3. 請求項１に記載のバッチサーバメンテナンス方法において、
   さらに、（ｅ）前記メンテナンスプログラムが、前記バッチサーバに、前記バッチサーバに対するメンテナンスが完了した後、前記停止依頼フラグおよび前記停止完了フラグを解除させる工程と、
   （ｆ）再起動された前記バッチプログラムが、前記バッチサーバに、前記（ｂ）工程において実行を停止された際の前記チェックポイントから実行を再開させる工程と、
   を有する、バッチサーバメンテナンス方法。
4. 請求項２に記載のバッチサーバメンテナンス方法において、
   さらに、（ｇ）前記他のサーバが、前記バッチサーバ上に前記停止依頼フラグもしくは前記停止完了フラグが立っている場合に、クライアント端末に対して、処理に時間を要する旨を通知する画面を表示させる工程、を有する、バッチサーバメンテナンス方法。