(57)【要約】  方法は、ジョブ制御マネージャにおいて、バッチ・アプリケーションの実行を指定するコマンドを受信することを含む。方法は、ジョブ制御マネージャにおいて、バッチ・アプリケーションに関連付けられたコミット・カウントを受信すること、および、バッチ・アプリケーションがレコードのグループを処理するとともに、バッチ・アプリケーションを開始することをさらに含む。方法は、バッチ・アプリケーションがレコードのグループ内の最終レコードの処理を完了しない限り、バッチ・アプリケーションはレコードのグループ内の第１のレコードをロック解除しないという条件で、第１のレコードがバッチ・アプリケーションによって処理されることに応答して、第１のレコードをロックすることも含む。さらに方法は、バッチ・アプリケーションがレコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、バッチ・アプリケーションの実行の結果としてロックされたレコードのグループのすべてのレコードをコミットすることを含む。
2021501936.tif 000002
【特許請求の範囲】
【請求項１】
方法であって、
データ・システムのジョブ制御マネージャにおいて、バッチ・アプリケーションの実行を指定するコマンドを受信すること、
前記ジョブ制御マネージャにおいて、前記バッチ・アプリケーションに関連付けられたコミット・カウントを受信すること、
前記バッチ・アプリケーションを開始することであって、前記バッチ・アプリケーションはレコードのグループを処理する、前記開始すること、
前記バッチ・アプリケーションが前記レコードのグループ内の最終レコードの処理を完了しない限り、前記バッチ・アプリケーションは前記レコードのグループ内の第１のレコードをロック解除しないという条件で、前記第１のレコードが前記バッチ・アプリケーションによって処理されることに応答して、前記第１のレコードをロックすること、および、
前記バッチ・アプリケーションが前記レコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのすべてのレコードをコミットすることであって、ｎは前記コミット・カウントに等しい、前記コミットすること、
を含む、方法。
【請求項２】
前記バッチ・アプリケーションが前記レコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量を追跡すること、
をさらに含む、請求項１に記載の方法。
【請求項３】
前記バッチ・アプリケーションが前記レコードのグループのうちの少なくとも最小数のレコードの処理を完了したこと、および、前記レコード・ロック要求の量がしきい値を超えた旨の決定に応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットすること、
をさらに含み、前記最小数のレコードは前記コミット・カウントよりも少ない、
請求項２に記載の方法。
【請求項４】
前記しきい値は１つのレコード・ロック要求である、請求項３に記載の方法。
【請求項５】
前記レコードのグループのうちの前記ｎ番目のレコードが処理されることに応答して、前記バッチ・アプリケーションの開始から、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットするまでに経過する時間の量を決定することをさらに含む、請求項１に記載の方法。
【請求項６】
前記バッチ・アプリケーションの開始から、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットするまでに経過する前記時間の量は、
前記レコードのグループのうちの前記ｎ番目のレコードが処理されたこと、および、
前記バッチ・アプリケーションの開始後に、前記レコードのグループ内のどのレコードについても保留中のレコード・ロックが発見されなかったこと、
の両方の決定に応答して決定される、
請求項５に記載の方法。
【請求項７】
前記ジョブ制御マネージャにおいて、第２のバッチ・アプリケーションの実行を指定する第２のコマンドを受信すること、
前記第２のバッチ・アプリケーションを開始することであって、前記第２のバッチ・アプリケーションは、第２のレコードのグループを処理する、前記開始すること、
前記第２のバッチ・アプリケーションが前記第２のレコードのグループ内の最終レコードの処理を完了しない限り、前記第２のバッチ・アプリケーションは前記１つまたは複数のレコードをロック解除しないという条件で、前記１つまたは複数のレコードが前記第２のバッチ・アプリケーションによって処理されることに応答して、前記第２のレコードのグループのうちの１つまたは複数のレコードをロックすること、
前記バッチ・アプリケーションが前記第２のレコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量を追跡すること、
前記バッチ・アプリケーションが前記第２のレコードのグループのうちのｍ番目のレコードの処理を完了したこと、および、前記第２のレコードのグループのうちの前記ｍ番目のレコードの処理を完了した後、最短のタイムアウトの前に前記レコード・ロック要求の量が処理されることになる旨の決定に応答して、前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理が完了した後に、前記第２のバッチ・アプリケーションの実行の結果としてロックされた前記第２のレコードのグループのうちのすべてのレコードをコミットすることであって、ｍは前記コミット・カウントに等しい、前記コミットすること、ならびに、
前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理を完了した後、前記最短のタイムアウトの前に前記レコード・ロック要求の量が処理されない旨の決定に応答して、前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理を完了する前に、前記第２のバッチ・アプリケーションの実行の結果としてロックされた前記第２のレコードのグループのすべてのレコードをコミットすること、
をさらに含む、請求項５に記載の方法。
【請求項８】
前記コミット・カウントは、
コミットの前に処理されるべきレコードの最小数、および、
前記コミットの前に処理されるべきレコードの最大数、
という、２つの値を含み、
前記コミットの前に処理されるべき前記レコードの最小数が、前記コミットの前に処理されるべき前記レコードの最大数に等しい旨の決定に応答して、前記バッチ・アプリケーションが前記レコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量は追跡されない、
請求項１に記載の方法。
【請求項９】
具体化されたプログラム命令を有するコンピュータ可読記憶媒体を含む、コンピュータ・プログラム製品であって、前記コンピュータ可読記憶媒体は、一過性信号それ自体ではなく、前記具体化されたプログラム命令は、
データ・システムのジョブ制御マネージャにおいて、バッチ・アプリケーションの実行を指定するコマンドを、処理回路によって受信すること、
前記ジョブ制御マネージャにおいて、前記バッチ・アプリケーションに関連付けられたコミット・カウントを、前記処理回路によって受信すること、
前記バッチ・アプリケーションを前記処理回路によって開始することであって、前記バッチ・アプリケーションはレコードのグループを処理する、前記開始すること、
前記バッチ・アプリケーションが前記レコードのグループ内の最終レコードの処理を完了しない限り、前記バッチ・アプリケーションは前記レコードのグループ内の第１のレコードをロック解除しないという条件で、前記第１のレコードが前記バッチ・アプリケーションによって処理されることに応答して、前記第１のレコードを、前記処理回路によってロックすること、および、
前記バッチ・アプリケーションが前記レコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのすべてのレコードを、前記処理回路によってコミットすることであって、ｎは前記コミット・カウントに等しい、前記コミットすること、
を、前記処理回路に実行させるために、前記処理回路によって実行可能である、
コンピュータ・プログラム製品。
【請求項１０】
前記具体化されたプログラム命令は、
前記バッチ・アプリケーションが前記レコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量を、前記処理回路によって追跡すること、
を、前記処理回路に実行させるために、前記処理回路によってさらに実行可能である、請求項９に記載のコンピュータ・プログラム製品。
【請求項１１】
前記具体化されたプログラム命令は、
前記バッチ・アプリケーションが前記レコードのグループのうちの少なくとも最小数のレコードの処理を完了したこと、および、前記レコード・ロック要求の量がしきい値を超えた旨の決定に応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードを、前記処理回路によってコミットすること、
を前記処理回路に実行させるために、前記処理回路によってさらに実行可能であり、前記最小数のレコードは前記コミット・カウントよりも少ない、
請求項１０に記載のコンピュータ・プログラム製品。
【請求項１２】
前記具体化されたプログラム命令は、
前記レコードのグループのうちの前記ｎ番目のレコードが処理されることに応答して、前記バッチ・アプリケーションの開始から、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットするまでに経過する時間の量を、前記処理回路によって決定すること、
前記ジョブ制御マネージャにおいて、第２のバッチ・アプリケーションの実行を指定する第２のコマンドを、前記処理回路によって受信すること、
前記第２のバッチ・アプリケーションを、前記処理回路によって開始することであって、前記第２のバッチ・アプリケーションは第２のレコードのグループを処理する、前記開始すること、
前記第２のバッチ・アプリケーションが前記第２のレコードのグループ内の最終レコードの処理を完了しない限り、前記第２のバッチ・アプリケーションは前記１つまたは複数のレコードをロック解除しないという条件で、前記１つまたは複数のレコードが前記第２のバッチ・アプリケーションによって処理されることに応答して、前記第２のレコードのグループのうちの１つまたは複数のレコードを、前記処理回路によってロックすること、
前記バッチ・アプリケーションが前記第２のレコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量を、前記処理回路によって追跡すること、
前記バッチ・アプリケーションが前記第２のレコードのグループのうちのｍ番目のレコードの処理を完了したこと、および、前記第２のレコードのグループのうちの前記ｍ番目のレコードの処理を完了した後、最短のタイムアウトの前に前記レコード・ロック要求の量が処理されることになる旨の決定に応答して、前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理が完了した後に、前記第２のバッチ・アプリケーションの実行の結果としてロックされた前記第２のレコードのグループのうちのすべてのレコードを、前記処理回路によってコミットすることであって、ｍは前記コミット・カウントに等しい、前記コミットすること、ならびに、
前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理を完了した後、前記最短のタイムアウトの前に前記レコード・ロック要求の量が処理されない旨の決定に応答して、前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理を完了する前に、前記第２のバッチ・アプリケーションの実行の結果としてロックされた前記第２のレコードのグループのすべてのレコードを、前記処理回路によってコミットすること、
を、前記処理回路に実行させるために、前記処理回路によってさらに実行可能である、請求項９に記載のコンピュータ・プログラム製品。
【請求項１３】
前記バッチ・アプリケーションの開始から、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットするまでに経過する前記時間の量は、前記レコードのグループのうちの前記ｎ番目のレコードが処理されたこと、および、前記バッチ・アプリケーションの開始後に、前記レコードのグループ内のどのレコードについても保留中のレコード・ロックが発見されないこと、の両方の決定に応答してのみ決定される、請求項１２に記載のコンピュータ・プログラム製品。
【請求項１４】
前記コミット・カウントは、
コミットの前に処理されるべきレコードの最小数、および、
前記コミットの前に処理されるべきレコードの最大数、
という、２つの値を含み、
前記コミットの前に処理されるべき前記レコードの最小数が、前記コミットの前に処理されるべき前記レコードの最大数に等しい旨の決定に応答して、前記バッチ・アプリケーションが前記レコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量は追跡されない、
請求項９に記載のコンピュータ・プログラム製品。
【請求項１５】
システムであって、
処理回路、
メモリ、および、
前記メモリに記憶されるロジック、
を備え、前記ロジックは前記処理回路によって実行されると、
データ・システムのジョブ制御マネージャにおいて、バッチ・アプリケーションの実行を指定するコマンドを受信すること、
前記ジョブ制御マネージャにおいて、前記バッチ・アプリケーションに関連付けられたコミット・カウントを受信すること、
前記バッチ・アプリケーションを開始することであって、前記バッチ・アプリケーションはレコードのグループを処理する、前記開始すること、
前記バッチ・アプリケーションが前記レコードのグループ内の最終レコードの処理を完了しない限り、前記バッチ・アプリケーションは前記レコードのグループ内の第１のレコードをロック解除しないという条件で、前記第１のレコードが前記バッチ・アプリケーションによって処理されることに応答して、前記第１のレコードをロックすること、および、
前記バッチ・アプリケーションが前記レコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのすべてのレコードをコミットすることであって、ｎは前記コミット・カウントに等しい、前記コミットすること、
を、前記処理回路に実行させる、
システム。
【請求項１６】
前記ロジックは、
前記バッチ・アプリケーションが前記レコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量を追跡すること、
を、前記処理回路にさらに実行させる、請求項１５に記載のシステム。
【請求項１７】
前記ロジックは、
前記バッチ・アプリケーションが前記レコードのグループのうちの少なくとも最小数のレコードの処理を完了したこと、および、前記レコード・ロック要求の量がしきい値を超えた旨の決定に応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットすること、
を、前記処理回路にさらに実行させ、
前記最小数のレコードは前記コミット・カウントよりも少なく、
前記しきい値は１つのレコード・ロック要求である、
請求項１６に記載のシステム。
【請求項１８】
前記ロジックは、
前記レコードのグループのうちの前記ｎ番目のレコードが処理されること、および、
前記バッチ・アプリケーションの開始後に、前記レコードのグループ内のどのレコードについても保留中のレコード・ロックが発見されなかったこと、
の両方の決定に応答して、
前記バッチ・アプリケーションの開始から、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットするまでに経過する時間の量を決定すること、
前記ジョブ制御マネージャにおいて、第２のバッチ・アプリケーションの実行を指定する第２のコマンドを受信すること、
前記第２のバッチ・アプリケーションを開始することであって、前記第２のバッチ・アプリケーションは第２のレコードのグループを処理する、前記開始すること、
前記第２のバッチ・アプリケーションが前記第２のレコードのグループ内の最終レコードの処理を完了しない限り、前記第２のバッチ・アプリケーションは前記１つまたは複数のレコードをロック解除しないという条件で、前記１つまたは複数のレコードが前記第２のバッチ・アプリケーションによって処理されることに応答して、前記第２のレコードのグループのうちの１つまたは複数のレコードをロックすること、
前記バッチ・アプリケーションが前記第２のレコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量を追跡すること、
前記バッチ・アプリケーションが前記第２のレコードのグループのうちのｍ番目のレコードの処理を完了したこと、および、前記第２のレコードのグループのうちの前記ｍ番目のレコードの処理を完了した後、最短のタイムアウトの前に前記レコード・ロック要求の量が処理されることになる旨の決定に応答して、前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理が完了した後に、前記第２のバッチ・アプリケーションの実行の結果としてロックされた前記第２のレコードのグループのうちのすべてのレコードをコミットすることであって、ｍは前記コミット・カウントに等しい、前記コミットすること、ならびに、
前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理を完了した後、前記最短のタイムアウトの前に前記レコード・ロック要求の量が処理されない旨の決定に応答して、前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理を完了する前に、前記第２のバッチ・アプリケーションの実行の結果としてロックされた前記第２のレコードのグループのすべてのレコードをコミットすること、
を、前記処理回路にさらに実行させる、請求項１５に記載のシステム。
【請求項１９】
前記ロジックは、
前記バッチ・アプリケーションが前記レコードのグループのうちの少なくとも最小数のレコードの処理を完了したこと、および、前記レコード・ロック要求の量が第１のしきい値を超えた旨の決定に応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットすること、
を、前記処理回路にさらに実行させ、前記最小数のレコードは前記コミット・カウントよりも少ない、請求項１８に記載のシステム。
【請求項２０】
前記コミット・カウントは、
コミットの前に処理されるべきレコードの最小数、および、
前記コミットの前に処理されるべきレコードの最大数、
という、２つの値を含み、
前記コミットの前に処理されるべき前記レコードの最小数が、前記コミットの前に処理されるべき前記レコードの最大数に等しい旨の決定に応答して、前記バッチ・アプリケーションが前記レコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量は追跡されない、
請求項１５に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、レコード・ロック管理に関し、より詳細には、他のトランザクションに影響を与える、トランザクションの長期実行がレコード・ロックを長期間保持することの防止に関する。
【背景技術】
【０００２】
データ・システム内で、レコードは、コンピュータ可読媒体に記憶され、データ・システムの１人または複数のユーザによりアクセスされる可能性がある。レコードがアクセスされるたびに、他のユーザが同じレコードにアクセスするのを防ぐレコード・ロックが発行される。個々のレコードに対するこれらのレコード・ロックは、明示的に解除されるまで保持される可能性がある。多くの異なるレコードにアクセスするバッチ・ジョブは、長期間レコード・ロックを保持する可能性があり、レコード・ロックまたは他のレコード・ロック・リソースあるいはその両方に関連付けられた下位のレコードを待機している他のトランザクションをタイムアウトさせる可能性がある。この問題は、財務記録や簿記記録などのトランザクションを追跡するレコードを利用するトランザクション・データ環境において、特に明白である。
【０００３】
トランザクション・データ環境において、レコード・ロックは、レコード・ロックを要求したバッチ・アプリケーションによって明示的な同期（ｓｙｎｃ）ポイント（一般的に、コミットまたはバックアウトと呼ばれる）が発行されるまで、または、タスク終了（ＥＯＴ）と呼ばれる、バッチ・アプリケーションの終わりに暗黙的なｓｙｎｃポイントが発行されるまで、保持される。トランザクション・データ操作を使用するバッチ・アプリケーションがコミット・ポイントを含まない場合、バッチ・ジョブ全体が１つのトランザクションと見なされることになり、バッチ・アプリケーションによってアクセスされるレコードのレコード・ロックは、ＥＯＴでのみ解除されることになる。これによって、システム内でこれらのレコード・ロック・リソースを待っている、恐らくより重要なトランザクションを、タイムアウトさせる可能性がある。
【発明の概要】
【０００４】
一実施形態において、方法は、データ・システムのジョブ制御マネージャにおいて、バッチ・アプリケーションの実行を指定するコマンドを受信することを含む。方法は、ジョブ制御マネージャにおいて、バッチ・アプリケーションに関連付けられたコミット・カウントを受信することも含む。加えて、方法は、バッチ・アプリケーションがレコードのグループを処理するとともに、バッチ・アプリケーションを開始することを含む。方法は、バッチ・アプリケーションがレコードのグループ内の最終レコードの処理を完了しない限り、バッチ・アプリケーションはレコードのグループ内の第１のレコードをロック解除しないという条件で、第１のレコードがバッチ・アプリケーションによって処理されることに応答して、第１のレコードをロックすることも含む。さらに方法は、バッチ・アプリケーションがレコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、バッチ・アプリケーションの実行の結果としてロックされたレコードのグループのすべてのレコードをコミットすることを含む。本実施形態において、ｎはコミット・カウントに等しい。
【０００５】
別の実施形態において、コンピュータ・プログラム製品は、具体化されたプログラム命令を有するコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体は、一過性信号それ自体ではなく、具体化されたプログラム命令は、データ・システムのジョブ制御マネージャにおける処理回路によって、バッチ・アプリケーションの実行を指定するコマンドを処理回路に受信させるために、処理回路によって実行可能である。さらに、プログラム命令は、ジョブ制御マネージャにおける処理回路によって、バッチ・アプリケーションに関連付けられたコミット・カウントを処理回路に受信させるように、実行可能である。また、プログラム命令は、バッチ・アプリケーションがレコードのグループを処理するとともに、処理回路によってバッチ・アプリケーションを処理回路に開始させるように、実行可能である。加えて、バッチ・アプリケーションがレコードのグループ内の最終レコードの処理を完了しない限り、バッチ・アプリケーションはレコードのグループ内の第１のレコードをロック解除しないという条件で、第１のレコードがバッチ・アプリケーションによって処理されることに応答して、プログラム命令は、処理回路によって第１のレコードを処理回路にロックさせるように実行可能である。さらに、プログラム命令は、処理回路によって、および、バッチ・アプリケーションがレコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、バッチ・アプリケーションの実行の結果としてロックされたレコードのグループのすべてのレコードを処理回路にコミットさせるように実行可能である。本実施形態において、ｎはコミット・カウントに等しい。
【０００６】
さらに別の実施形態において、システムは、処理回路と、メモリと、処理回路によって実行されたとき、データ・システムのジョブ制御マネージャにおいて、バッチ・アプリケーションの実行を指定するコマンドを処理回路に受信させる、メモリに記憶されたロジックとを含む。ロジックはさらに、ジョブ制御マネージャにおいて、バッチ・アプリケーションに関連付けられたコミット・カウントを処理回路に受信させ、また、バッチ・アプリケーションがレコードのグループを処理するとともに、バッチ・アプリケーションを開始させる。加えて、ロジックは、バッチ・アプリケーションがレコードのグループ内の最終レコードの処理を完了しない限り、バッチ・アプリケーションはレコードのグループ内の第１のレコードをロック解除しないという条件で、第１のレコードがバッチ・アプリケーションによって処理されることに応答して、第１のレコードを処理回路にロックさせる。さらにロジックは、バッチ・アプリケーションがレコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、バッチ・アプリケーションの実行の結果としてロックされたレコードのグループのすべてのレコードを処理回路にコミットさせる。本実施形態において、ｎはコミット・カウントに等しい。
【０００７】
本発明の他の態様および実施形態は、図面に関連して説明されたとき、例として本発明の原理を示す、下記の詳細な説明から明らかになろう。
【図面の簡単な説明】
【０００８】
【図１】本発明の実施形態に従ったコンピューティング・ノードを示す図である。
【図２】一実施形態に従った、ネットワーク・アーキテクチャを示す図である。
【図３】一実施形態に従った、階層データ記憶システム（tiered data storage system）を示す図である。
【図４】一実施形態に従った、並列コンピューティング・システムを示す図である。
【図５】一実施形態に従った、方法を示すフローチャートである。
【発明を実施するための形態】
【０００９】
下記の説明は、本発明の一般原理を示す目的でなされたものであり、本明細書で請求される発明の概念を限定することは意図されていない。さらに、本明細書で説明される特定の特徴は、様々な可能な組合せおよび置き換えの各々において、他の説明される特徴との組合せで使用することが可能である。
【００１０】
本明細書で特に具体的に定義されていない限り、すべての用語には、本明細書から示唆される意味、ならびに、当業者によって理解される意味または辞書、論文などに定義される意味、あるいはその両方の意味を含む、それらの可能な最も広義な解釈が与えられるべきである。
【００１１】
本明細書および添付の特許請求の範囲で使用される場合、単数形「ある（a）」、「１つの（an）」、および「その（the）」は、特に指定のない限り、複数の指示対象を含むことも留意しなければならない。本明細書で使用されるとき、「含む」または「含んでいる」あるいはその両方の用語は、示される特徴、整数、ステップ、動作、要素、または構成要素、あるいはそれらの組合せの存在を指定するが、１つまたは複数の他の特徴、整数、ステップ、動作、要素、構成要素、またはそれらのグループ、あるいはそれらの組合せの存在または追加を除外するものではないことをさらに理解されよう。本明細書で使用される場合、「約」という用語は、当業者であれば理解されるように、「約」という用語が先行する値、ならびに、「約」という用語が先行する値にかなり近い任意の値を示す。特に示されていないとき、「約」という用語は、「約」という用語が先行する値±値の１０％を示す。たとえば、「約１０」は、９．０から１１．０までおよびそれらを含む、すべての値を示す。
【００１２】
下記の説明は、トランザクションの長期実行がレコード・ロックを保持することを防止するための、システム、方法、およびコンピュータ・プログラム製品のいくつかの好ましい実施形態を開示する。
【００１３】
１つの一般実施形態において、方法は、データ・システムのジョブ制御マネージャにおいて、バッチ・アプリケーションの実行を指定するコマンドを受信することを含む。方法は、ジョブ制御マネージャにおいて、バッチ・アプリケーションに関連付けられたコミット・カウントを受信することも含む。加えて、方法は、バッチ・アプリケーションがレコードのグループを処理するとともに、バッチ・アプリケーションを開始することを含む。方法は、バッチ・アプリケーションがレコードのグループ内の最終レコードの処理を完了しない限り、バッチ・アプリケーションはレコードのグループ内の第１のレコードをロック解除しないという条件で、第１のレコードがバッチ・アプリケーションによって処理されることに応答して、第１のレコードをロックすることも含む。さらに方法は、バッチ・アプリケーションがレコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、バッチ・アプリケーションの実行の結果としてロックされたレコードのグループのすべてのレコードをコミットすることを含む。本実施形態において、ｎはコミット・カウントに等しい。
【００１４】
別の一般実施形態において、コンピュータ・プログラム製品は、具体化されたプログラム命令を有するコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体は、一過性信号それ自体ではなく、具体化されたプログラム命令は、データ・システムのジョブ制御マネージャにおける処理回路によって、バッチ・アプリケーションの実行を指定するコマンドを処理回路に受信させるために、処理回路によって実行可能である。さらに、プログラム命令は、ジョブ制御マネージャにおける処理回路によって、バッチ・アプリケーションに関連付けられたコミット・カウントを処理回路に受信させるように、実行可能である。また、プログラム命令は、バッチ・アプリケーションがレコードのグループを処理するとともに、処理回路によってバッチ・アプリケーションを処理回路に開始させるように、実行可能である。加えて、バッチ・アプリケーションがレコードのグループ内の最終レコードの処理を完了しない限り、バッチ・アプリケーションはレコードのグループ内の第１のレコードをロック解除しないという条件で、第１のレコードがバッチ・アプリケーションによって処理されることに応答して、プログラム命令は、処理回路によって第１のレコードを処理回路にロックさせるように実行可能である。さらに、プログラム命令は、処理回路によって、および、バッチ・アプリケーションがレコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、バッチ・アプリケーションの実行の結果としてロックされたレコードのグループのすべてのレコードを処理回路にコミットさせるように実行可能である。本実施形態において、ｎはコミット・カウントに等しい。
【００１５】
さらに別の一般実施形態において、システムは、処理回路と、メモリと、処理回路によって実行されたとき、データ・システムのジョブ制御マネージャにおいて、バッチ・アプリケーションの実行を指定するコマンドを処理回路に受信させる、メモリに記憶されたロジックとを含む。ロジックは、さらに、ジョブ制御マネージャにおいて、バッチ・アプリケーションに関連付けられたコミット・カウントを処理回路に受信させ、また、バッチ・アプリケーションがレコードのグループを処理するとともに、バッチ・アプリケーションを開始させる。加えて、ロジックは、バッチ・アプリケーションがレコードのグループ内の最終レコードの処理を完了しない限り、バッチ・アプリケーションはレコードのグループ内の第１のレコードをロック解除しないという条件で、第１のレコードがバッチ・アプリケーションによって処理されることに応答して、第１のレコードを処理回路にロックさせる。さらにロジックは、バッチ・アプリケーションがレコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、バッチ・アプリケーションの実行の結果としてロックされたレコードのグループのすべてのレコードを処理回路にコミットさせる。本実施形態において、ｎはコミット・カウントに等しい。
【００１６】
図１を参照すると、一実施形態に従った、コンピューティング・ノード１０の概略的な例が示されている。コンピューティング・ノード１０は、好適なコンピューティング・ノードの単なる一例であり、本明細書で説明する本発明の実施形態の使用範囲または機能性に関して、いかなる限定をも提案することは意図されていない。それにもかかわらず、コンピューティング・ノード１０は、本明細書に示される機能性のうちのいずれかの、実装または実行あるいはその両方が可能である。さらに、コンピューティング・ノード１０は、本明細書で説明する、または当業者に知られた、あるいはその両方の、任意のシステム、ネットワーク、クラウド、クラスタ、またはデータ記憶環境、あるいはそれらの組合せに含めることができる。
【００１７】
コンピューティング・ノード１０において、多数の他の汎用または特定用途向けのコンピューティング・システム環境または構成と共に動作可能な、コンピュータ・システム／サーバ１２が存在する。コンピュータ・システム／サーバ１２と共に使用するのに好適な可能性のある周知のコンピューティング・システム、環境、または構成、あるいはそれらの組合せの例には、限定はしないが、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルド・デバイス、ラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベース・システム、セット・トップ・ボックス、プログラム可能家庭用電化製品、ネットワーク・パーソナル・コンピュータ（ＰＣ）、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および、上記のシステムまたはデバイスのいずれかを含む分散型クラウド・コンピューティング環境、その他が含まれる。
【００１８】
コンピュータ・システム／サーバ１２は、コンピュータ・システムによって実行される、プログラム・モジュールなどのコンピュータ・システム実行可能命令との一般的な関連において説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行するかまたは特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、構成要素、ロジック、およびデータ構造などを含むことができる。コンピュータ・システム／サーバ１２は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される、分散型クラウド・コンピューティング環境において実施可能である。分散型クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ記憶デバイスを含む、ローカルおよびリモートの両方のコンピュータ・システム記憶媒体内に配置することができる。
【００１９】
図１に示されるように、コンピューティング・ノード１０内のコンピュータ・システム／サーバ１２は、汎用コンピューティング・デバイスの形で示される。コンピュータ・システム／サーバ１２の構成要素は、限定はしないが、１つまたは複数のプロセッサ、処理回路、または処理ユニット、あるいはそれらの組合せ（まとめて、プロセッサ１６）、およびシステム・メモリ２８、ならびに、システム・メモリ２８を含む様々なシステム構成要素をプロセッサ１６に結合するバス１８を、含むことができる。
【００２０】
バス１８は、いずれかの多様なバス・アーキテクチャを使用する、メモリ・バス、メモリ・コントローラ、周辺バス、アクセラレイティッド・グラフィクス・ポート、プロセッサ、およびローカル・バスを含む、いくつかのタイプのバス構造のいずれかのうちの１つまたは複数を表す。例を挙げると、限定ではないが、こうしたアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ・エレクトロニクス規格協会（ＶＥＳＡ）ローカル・バス、および周辺構成要素相互接続（ＰＣＩ）バスを含む。
【００２１】
コンピュータ・システム／サーバ１２は、典型的には多様なコンピュータ可読記憶媒体を含む。こうした媒体は、コンピュータ・システム／サーバ１２によるアクセスが可能な任意の使用可能媒体とすることができ、揮発性および不揮発性、取り外し可能および取り外し不能などの、両方の媒体を含む。
【００２２】
システム・メモリ２８は、ランダム・アクセス・メモリ（ＲＡＭ）３０またはキャッシュ・メモリ３２あるいはその両方などの、揮発性メモリの形のコンピュータ可読記憶媒体を含むことができる。コンピュータ・システム／サーバ１２は、他の取り外し可能／取り外し不能、揮発性／不揮発性の、コンピュータ可読記憶媒体をさらに含むことができる。単なる例として、取り外し不能、不揮発性の磁気記憶媒体（図示されておらず、典型的には「ハード・ドライブ」または「ソリッド・ステート・ドライブ」と呼ばれる）からの読み取りおよびそれらへの書き込みのために、記憶システム３４を提供することができる。図示されていないが、取り外し可能、不揮発性の磁気ディスク（たとえば、「フロッピィ・ディスク」）からの読み取り、およびそれらへの書き込みのための、磁気ディスク・ドライブ、ならびに、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光媒体、あるいはそれらの組合せなどの、取り外し可能、不揮発性の光ディスクからの読み取り、またはそれらへの書き込み、あるいはその両方のための、光ディスク・ドライブが、提供可能である。こうした場合には、１つまたは複数のデータ媒体インターフェースによって、各々をバス１８に接続することができる。下記でさらに図示および説明するように、メモリ２８は、本発明の実施形態において説明される機能を実施するように構成されたプログラム・モジュールのセット（たとえば、少なくとも１つ）を有する、少なくとも１つのコンピュータ・プログラム製品を含むことができる。
【００２３】
プログラム・モジュール４２のセット（少なくとも１つ）を有するプログラム／ユーティリティ４０は、限定ではなく例として、メモリ２８、ならびにオペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データ内に記憶することができる。オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データ、またはそれらの任意の組合せの各々は、ネットワーキング環境の実装を含むことができる。プログラム・モジュール４２は、一般に、本明細書で説明する本発明の実施形態の機能または方法あるいはその両方を実施する。
【００２４】
コンピュータ・システム／サーバ１２は、キーボード、ポインティング・デバイス、ディスプレイ２４などの１つまたは複数の外部デバイス１４、ユーザがコンピュータ・システム／サーバ１２と対話できるようにする１つまたは複数のデバイス、または、コンピュータ・システム／サーバ１２が１つまたは複数の他のコンピューティング・デバイスと通信できるようにする任意のデバイス（たとえば、ネットワーク・カード、モデムなど）、あるいはそれらの組合せと、通信することもできる。こうした通信は、入力／出力（Ｉ／Ｏ）インターフェース２２を介して発生可能である。さらに、コンピュータ・システム／サーバ１２は、ローカル・エリア・ネットワーク（ＬＡＮ）、一般のワイド・エリア・ネットワーク（ＷＡＮ）、または公衆ネットワーク（たとえば、インターネット）、あるいはそれらの組合せなどの１つまたは複数のネットワークと、ネットワーク・アダプタ２０を介して通信することができる。図に示されるように、ネットワーク・アダプタ２０は、バス１８を介して、コンピュータ・システム／サーバ１２の他の構成要素と通信する。図には示されていないが、他のハードウェアまたはソフトウェア構成要素あるいはその両方が、コンピュータ・システム／サーバ１２と共に使用可能であることを理解されたい。例には、限定はしないが、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部ディスク・ドライブ・アレイ、独立ディスクの冗長アレイ（ＲＡＩＤ）システム、テープ・ドライブ、データ・アーカイブ記憶システムなどが含まれる。
【００２５】
コンピュータ・システム／サーバ１２は、その上に、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ（ＯＳ）、Ａｐｐｌｅ（登録商標）ＯＳ、ＵＮＩＸ（登録商標）  ＯＳなどのオペレーティング・システムを常駐させることができる。好ましい実施形態は、言及された以外のプラットフォームおよびオペレーティング・システム上でも実装可能であることを理解されよう。好ましい実施形態は、ＸＭＬ、Ｃ、またはＣ＋＋、あるいはそれらの組合せの言語、または他のプログラミング言語、ならびにオブジェクト指向プログラミング方法を使用して、作成可能である。複雑なアプリケーションを開発するためにますます使用されるようになってきている、オブジェクト指向プログラミング（ＯＯＰ）が使用可能である。
【００２６】
図２は、一実施形態に従ったアーキテクチャ１００を示す。図１に示されたコンピューティング・ノード１０は、図２に示されるようなアーキテクチャ１００において利用可能である。さらにアーキテクチャ１００は、第１のリモート・ネットワーク１０４および第２のリモート・ネットワーク１０６を含んだ複数のリモート・ネットワーク１０２を含むことができる。ゲートウェイ１０１は、リモート・ネットワーク１０２と近隣ネットワーク１０８との間に結合することができる。本アーキテクチャ１００との関連において、ネットワーク１０４、１０６は各々、ＬＡＮ、インターネットなどのＷＡＮ、公衆交換電話網（ＰＳＴＮ）、構内電話網などを含むが、限定されない、任意の形を取ることができる。
【００２７】
使用中、ゲートウェイ１０１は、リモート・ネットワーク１０２から近隣ネットワーク１０８への入口として働く。したがって、ゲートウェイ１０１は、ゲートウェイ１０１に到達するデータの所与のパケットを誘導することが可能なルータ、および、所与のパケットにゲートウェイ１０１の内外への実際の経路を与えるスイッチとして、機能することができる。
【００２８】
さらに、近隣ネットワーク１０８に結合された、および、ゲートウェイ１０１を介してリモート・ネットワーク１０２からアクセス可能な、少なくとも１つのデータ・サーバ１１４が含まれる。データ・サーバ１１４は、任意のタイプのコンピューティング・デバイス／グループウェアを含むことができることに留意されたい。各データ・サーバ１１４に、複数のユーザ・デバイス１１６が結合される。ユーザ・デバイス１１６は、ネットワーク１０４、１０６、１０８のうちの１つを介して直接接続することもできる。こうしたユーザ・デバイス１１６は、デスクトップ・コンピュータ、ラップトップ・コンピュータ、ハンドヘルド・コンピュータ、プリンタ、または任意の他のタイプのロジック、あるいはそれらの組合せを含むことができる。ユーザ・デバイス１１１は、一実施形態において、ネットワークのうちのいずれかに直接結合することも可能であることに留意されたい。
【００２９】
周辺装置１２０または一連の周辺装置１２０、たとえばファクシミリ機、プリンタ、ネットワーク化またはローカルあるいはその両方の記憶ユニットまたはシステムなどは、ネットワーク１０４、１０６、１０８のうちの１つまたは複数に結合することができる。データベースまたは追加の構成要素あるいはその両方は、ネットワーク１０４、１０６、１０８に結合された任意のタイプのネットワーク要素と共に利用するか、または統合することができることに留意されたい。本説明との関連において、ネットワーク要素は、ネットワークの任意の構成要素と呼ぶことができる。
【００３０】
いくつかの手法によれば、本明細書で説明する方法およびシステムは、ＩＢＭ  ｚ／ＯＳ環境をエミュレートするＵＮＩＸ（登録商標）システム、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）環境を仮想的にホストするＵＮＩＸ（登録商標）システム、ＩＢＭ  ｚ／ＯＳ環境をエミュレートするＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）システムなどの、仮想システム、または、１つまたは複数の他のシステムをエミュレートするシステム、あるいはその両方と共に、またはそれらの上で、あるいはその両方で、実装可能である。この仮想化またはエミュレーションあるいはその両方は、いくつかの実施形態において、ＶＭＷＡＲＥソフトウェアまたはいくつかの他の知られた仮想化層の使用を介して、機能強化することができる。
【００３１】
より多くの手法において、１つまたは複数のネットワーク１０４、１０６、１０８は、一般に「クラウド」と呼ばれる、システムのクラスタを表すことができる。クラウド・コンピューティングにおいて、処理能力、周辺装置、ソフトウェア、データ、サーバなどの共有リソースが、オンデマンドの関係性でクラウド内の任意のシステムに提供され、それによって、多くのコンピューティング・システム全体にわたるサービスへのアクセスおよびサービスの配布が可能になる。クラウド・コンピューティングは、典型的には、クラウド内で動作するシステム間のインターネット接続を含むが、システムを接続する他の技法も使用可能である。
【００３２】
次に図３を参照すると、一実施形態に従った階層記憶システム２００が示されている。様々な実施形態によれば、図３に示される要素のうちのいくつかは、ハードウェアまたはソフトウェアあるいはその両方として実装可能であることに留意されたい。記憶システム２００は、少なくとも１つの上位の記憶層２０２および少なくとも１つの下位の記憶層２０６上の複数の媒体と通信するための、記憶システム・マネージャ２１２を含むことができる。記憶システム・マネージャは、様々な実施形態に従って本明細書でより詳細に説明するように、ジョブ要求を管理するためのジョブ制御マネージャを含むこともできる。上位の記憶層２０２は、好ましくは、不揮発性メモリ（ＮＶＭ）、ソリッド・ステート・ドライブ（ＳＳＤ）内のソリッド・ステート・メモリ、フラッシュ・メモリ、ＳＳＤアレイ、フラッシュ・メモリ・アレイ、ハード・ディスク・ドライブ（ＨＤＤ）内のハード・ディスクなどの、１つまたは複数のランダム・アクセスまたはダイレクト・アクセスあるいはその両方の媒体２０４、または、本明細書に示されるかまたは当分野で知られたその他、あるいはそれらの組合せを、含むことができる。下位の記憶層２０６は、好ましくは、低速アクセスＨＤＤ、テープ・ドライブ内の磁気テープまたは光媒体あるいはその両方などの順次アクセス媒体、または、本明細書に示されるかまたは当分野で知られたその他、あるいはそれらの組合せを含む、１つまたは複数の下位実行記憶媒体２０８を含むことができる。１つまたは複数の追加の記憶層２１６は、システム２００の設計者が所望する記憶メモリ媒体の任意の組合せを含むことができる。また、上位の記憶層２０２または下位の記憶層２０６あるいはその両方のうちのいずれかは、記憶デバイスまたは記憶媒体あるいはその両方のいくつかの組合せを含むことができる。
【００３３】
記憶システム・マネージャ２１２は、図３に示されるようなストレージ・エリア・ネットワーク（ＳＡＮ）などのネットワーク２１０、またはいくつかの他の好適なネットワーク・タイプを介して、上位の記憶層２０２および下位の記憶層２０６上の記憶媒体２０４、２０８と通信することができる。記憶システム・マネージャ２１２は、記憶システム・マネージャ２１２の一部であるかまたは一部でない可能性のある、ホスト・インターフェース２１４を介して、１つまたは複数のホスト・システム（図示せず）と通信することもできる。記憶システム・マネージャ２１２または記憶システム２００の任意の他の構成要素あるいはその両方は、ハードウェアまたはソフトウェアあるいはその両方において実装可能であり、コマンドを実行するために、中央処理ユニット（ＣＰＵ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）などの、当分野で知られたタイプのプロセッサ（図示せず）を使用することができる。もちろん、当業者であれば本説明を読めばわかるように、記憶システムの任意の配置構成を使用することができる。
【００３４】
より多くの実施形態において、記憶システム２００は任意数のデータ記憶層を含むことができ、各記憶層内には同じかまたは異なる記憶メモリ媒体を含むことができる。たとえば、各データ記憶層は、ＨＤＤ、ＳＳＤ、順次アクセス媒体（テープ・ドライブ内のテープ、光ディスク・ドライブ内の光ディスクなど）、ダイレクト・アクセス媒体（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなど）、または、媒体記憶タイプの任意の組合せなどの、同じタイプの記憶メモリ媒体を含むことができる。こうした一構成において、上位の記憶層２０２は、高位実行記憶環境内にデータを記憶するために、（全ＳＳＤ記憶媒体を含めそれ以下の）大多数のＳＳＤ記憶媒体を含むことができ、下位の記憶層２０６および追加の記憶層２１６を含む残りの記憶層は、下位実行記憶環境内にデータを記憶するために、ＳＳＤ、ＨＤＤ、テープ・ドライブなどの任意の組合せを含むことができる。このようにして、より頻繁にアクセスされるデータ、より高い優先度を有するデータ、より迅速にアクセスする必要のあるデータなどは、上位の記憶層２０２に記憶することが可能であり、これらの属性のうちの１つを有さないデータは、下位の記憶層２０６を含む追加の記憶層２１６に記憶することが可能である。もちろん、当業者が本説明書を読めば、本明細書に提示された実施形態に従って、異なる記憶方式で実装するために記憶媒体タイプの多くの他の組合せを考案することが可能である。
【００３５】
特定の一実施形態において、記憶システム２００は、上位の記憶層２０２がＳＳＤ（および、恐らくは何らかのバッファ・メモリ）を含み、下位の記憶層２０６がＨＤＤ（および、恐らくは何らかのバッファ・メモリ）を含む、ＳＳＤおよびＨＤＤの組合せを含むことができる。別の実施形態によれば、記憶システム２００は、上位の記憶層２０２がＳＳＤ（および、恐らくは何らかのバッファ・メモリ）を含み、下位の記憶層２０６が磁気テープ（および、恐らくは何らかのバッファ・メモリ）および磁気テープからのデータにアクセスするための磁気テープ・ドライブを含む、ＳＳＤおよび磁気テープ・ドライブを備える磁気テープの組合せを含むことができる。さらに別の実施形態において、記憶システム２００は、上位の記憶層２０２がＨＤＤ（および、恐らくは何らかのバッファ・メモリ）を含み、下位の記憶層２０６が磁気テープ（および、恐らくは何らかのバッファ・メモリ）を含む、ＨＤＤおよび磁気テープの組合せを含むことができる。
【００３６】
図４を参照すると、複数のシステム３０２、たとえばシステム１  ３０２ａ、システム２  ３０２ｂ、・・・、システムＮ  ３０２ｎを含む、並列コンピューティング・システム（シスプレックス，ｓｙｓｐｌｅｘ）３００が示されている。各システムは、いくつかの構成要素を含む。図４に示されるように、システム１  ３０２ａは、端末とアプリケーション・プログラムとの間の通信の制御を維持し、ジョブ制御マネージャと呼ぶことができる、プログラムのセットである仮想通信アクセス方式（ＶＴＡＭ）エンジン３０４を含む。システム１  ３０２ａは、端末ネットワークの管理専用の顧客情報制御システム（ＣＩＣＳ）領域である端末所有領域（ＴＯＲ）３０６、および、複数のアプリケーション所有領域（ＡＯＲ）３０８、たとえばＡＯＲ１  ３０８ａ、ＡＯＲ２  ３０８ｂ、・・・、ＡＯＲｎ  ３０８ｎも含む。各ＡＯＲ  ３０８は、システムのリソースを動作および利用するためのアプリケーションへの空間の提供専用である。ＡＯＲ  ３０８は、記憶管理サブシステム（ＳＭＳＶＳＡＭ）３１０およびシステム・ロガー３１２のデータ共有サブシステムに結合される。これらの構成要素は、複数の仮想記憶アクセス方式（ＶＳＡＭ）データ・セット３１８、１つまたは複数のネットワーク３１４、および複数のシステム・ロガー・データ・セット３１６に結合される。
【００３７】
本並列シスプレックス３００を使用して、クロスシステム・ロッキングおよびバッファ無効化を保証しながら、ＶＳＡＭデータ・セットへのマルチシステム・アクセスを可能にする、レコード・レベル共有（ＲＬＳ）データ・アクセスを提供することができる。ＲＬＳは、クロスシステム拡張サービス（ＸＥＳ）を使用して、データ・セット・レベル・ロッキング、レコード・ロッキング、およびデータ・キャッシングを実行する。ＲＬＳは、コントロール・インターバル・レベルでデータ・コヒーレンシを維持する。これは、結合機構（ＣＦ）キャッシュをストア・スルー・キャッシュ（store-through cache）として使用する。書き込まれるデータのコントロール・インターバルに応答して、ＣＦキャッシュおよびダイレクト・アクセス記憶デバイス（ＤＡＳＤ）の両方に書き込まれる。これにより、ＣＦキャッシュ内の障害がＶＳＡＭデータの損失を発生させないことを保証する。もちろん、いくつかの実施形態において、システム１  ３０２ａなどの単一のシステムを利用して、ＶＳＡＭデータ・セット３１８へのアクセスを提供することができる。
【００３８】
次に図５を参照すると、一実施形態に従った方法４００が示されている。方法４００は、様々な実施形態において、とりわけ図１、図２、図３、および図４に示された環境のいずれかにおいて、本発明に従って実行することができる。もちろん、当業者が本説明を読めば理解されるように、図５に具体的に記載された動作よりも多くのまたは少ない動作を方法４００に含めることも可能である。
【００３９】
方法４００のステップの各々は、動作環境の任意の適当な構成要素によって実行することができる。たとえば様々な実施形態において、方法４００は、マイクロプロセッサ、サーバ、メインフレーム・コンピュータ、１つまたは複数のプロセッサを有する処理回路、あるいは、１つまたは複数のプロセッサを備える何らかの他のデバイスによって、部分的または全体的に実行することができる。処理回路、たとえば、プロセッサ、チップまたはハードウェアまたはソフトウェアあるいはその両方において実装され、好ましくは少なくとも１つのハードウェア構成要素を有するモジュール、あるいはそれらの組合せを、方法４００の１つまたは複数のステップを実行するために、任意のデバイス内で利用することができる。例示的なプロセッサは、限定はしないが、ＭＰＵ、ＣＰＵ、ＡＳＩＣ、ＦＰＧＡなど、それらの組合せ、または、当業者に知られた任意の他の好適なコンピューティング・デバイスを含む。
【００４０】
一実施形態において、動作環境は、環境内の追加のシステム（たとえば、シスプレックスなど）のクラスタのうちの１つとすることができる、データ・システムを含むことができる。別の実施形態において、データ・システムは、サーバ、パーソナル・コンピュータ、モバイル・デバイス、または、第１のプロセスを実行することが可能な任意のデバイスを含むことができる。さらに別の実施形態において、データ・システムを仮想記憶環境内に含めることができる。たとえばデータ・システムは、ＶＳＡＭ環境の一部とすることができる。
【００４１】
図５に示されるように、方法４００は動作４０２から開始することが可能であり、バッチ・アプリケーションの実行を指定するコマンドがデータ・システムのジョブ制御マネージャにおいて受信される。コマンドは、任意のフォーマットを有すること、および当分野で知られた任意のタイプとすることができる。さらにコマンドは、バッチ・アプリケーションの実行を開始したデバイス以外の、物理または仮想の、１つまたは複数の中間デバイスから、ジョブ制御マネージャに転送することができる。
【００４２】
ジョブ制御マネージャは、データ・システムの様々なリソースを使用してジョブ制御マネージャによって受信されたジョブ要求を制御することが可能であり、制御するように構成される。ジョブ制御マネージャは、当分野で知られた任意のタイプとすることができる。様々な手法において、ジョブ制御マネージャは、受信したジョブ要求を処理するためにデータ・システムのリソースを割り当て、データ・システムの有限リソース内でのジョブの実行を優先順位付けし、また次に実行するジョブを決定するために受信したジョブ要求を介してソートし、リソースの使用を最適化し、または、１人または複数のシステム管理者によって設定されるか、または、要求されたジョブに特有の、あるいはその両方の、ジョブ制御仕様を順守するか、あるいはその両方を行うことが可能である。ジョブ制御マネージャは、受信したジョブ要求を何らかの手法で記憶するために１つまたは複数のキューを利用することができる。
【００４３】
バッチ・アプリケーションは、当業者に知られており、内部で動作するデータ・システムおよびデバイスに適合するような、任意のタイプ、サイズ、構造、およびフォーマットとすることができる。たとえばバッチ・アプリケーションは、ＲＡＭ、ＲＯＭ、ＨＤＤ、ＳＳＤなどの、データ・システム内の１つまたは複数のコンピュータ可読記憶媒体上に記憶された１つまたは複数のレコードに、アクセスするよう要求することまたは処理すること、あるいはその両方が可能である。特定のレコードにアクセスすることは、当分野で知られるような、特定のレコードの読み取り、書き込み、修正、削除、移動、またはそれ以外の操作、あるいはそれらの組合せを含む。
【００４４】
動作４０４において、バッチ・アプリケーションに関連付けられたコミット・カウントが、ジョブ制御マネージャにおいて受信される。コミット・カウントは、単一の値または複数の値とすることができる。いずれの場合にも、コミット・カウントは、レコードをコミットする（たとえば、処理されたレコードに関連付けられたすべてのレコード・ロックを解除する）前にバッチ・アプリケーションによって処理するレコードの数を示す。
【００４５】
一実施形態において、コミット・カウントは、関連付けられたレコード・ロックをコミットする前に処理するレコードの最小数を表す、単一の値とすることができる。たとえば、最小値としてのコミット・カウントは、１、１０、１００、２００、５００、１０００などの値を有することが可能であり、この多くのレコードを処理するために生じる時間量に基づくことができる。最小値としてのコミット・カウントは、レコードの処理が完了した後も依然として未処理である可能性がある、これに関連付けられたレコード・ロックをコミットする前に、少なくとも（および、おそらくはさらに多くの）この数の（コミット・カウントに等しい）レコードが処理されることを示す。
【００４６】
別の実施形態において、コミット・カウントは、関連付けられたレコード・ロックをコミットする前に処理するレコードの最大数を表す、単一の値とすることができる。たとえば、最大値としてのコミット・カウントは、５、１０、１００、２００、５００、１０００などの値を有することが可能であり、この多くのレコードを処理するために生じる時間量に基づくことができる。最大値としてのコミット・カウントは、レコードの処理が完了した後も依然として未処理である可能性がある、これに関連付けられたレコード・ロックをコミットする前に、多くとも（しかし、恐らくはさらに少ない）この数の（コミット・カウントに等しい）レコードが処理されることを示す。
【００４７】
別の実施形態によれば、コミット・カウントは、関連付けられたレコード・ロックをコミットする前に処理するレコードの最小数および最大数の両方を表す、複数の値、たとえば最小値および最大値を含むことができる。たとえば、最小値または最大値としてのコミット・カウントは、最小値が最大値より少ないかまたは等しいとして、１、５、１０、１００、２００、５００、１０００などの値を有することができる。本実施形態において、コミット・カウントは、レコード・ロックが、最小値と最大値とを含むそれらの値の間の範囲内の任意のポイントでコミットし得るような範囲として作用する。さらに、最小値および最大値として選択される実際の値は、レコードを処理するために生じる時間量に基づくものとすることができる。加えて、最小値が最大値と同じであるとき、この厳密なレコード数が処理されると、レコード・ロックがコミットされる。
【００４８】
前述のように、方法４００において、コミット・カウントは、コミットの前に処理されるべきレコードの最小数、およびコミットの前に処理されるべきレコードの最大数という、２つの値を含むことができる。この手法において、コミットの前に処理されるべきレコードの最小数が、コミットの前に処理されるべきレコードの最大数に等しい旨の決定に応答して、バッチ・アプリケーションがレコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量は、追跡されず、処理されるべきレコードの最小数および最大数についての単一の値を示し、この厳密なレコード数が処理された後、すべての関連付けられたレコード・ロックを解除するためにコミットが実行される。
【００４９】
動作４０６において、バッチ・アプリケーションは、ジョブ制御マネージャによって直接または間接的のいずれかで開始される。バッチ・アプリケーションはレコードのグループを処理し、処理はレコードへのアクセスを含む。バッチ・アプリケーションによるレコードへのアクセスに従って、当分野で知られるように、処理されるレコードに対してレコード・ロックが発行される。レコードのグループは、複数のレコードの処理を扱うためのシステムの能力、ならびに、バッチ・アプリケーションの機能および設計に依存して、１から数百万までの任意数のレコードを含むことができる。
【００５０】
加えて、一実施形態において、レコードの追加の処理は、データ・システム内の１つまたは複数の追加のアプリケーションに関連付けることができる。たとえば、データ・システムの第１のアプリケーションは、データ・システム内の第１のレコード上で第１のプロセスを実行可能であり、データ・システムの第２のアプリケーションは、データ・システム内の第２のレコード上で第２のプロセスを実行可能である。別の実施形態において、第１のプロセスは、第１のレコードに関連して実行される１つまたは複数のアクションを含むことができる。たとえば第１のプロセスは、第１のレコードを編集すること、第１のレコードを除去すること、第１のレコードを作成すること、第１のレコードにアクセスすることなどが可能である。さらに別の実施形態において、第１のプロセスは、プロセスの大きなグループの一部とすることができる。たとえば第１のプロセスは、データ・システム内でバッチ・アプリケーションによって実行されるべきプロセスのバッチの一部とすることができる。また一実施形態において、第１のプロセスは、トランザクション・プロセス（たとえば、ＣＩＣＳトランザクションなど）、サブシステム・プロセス、バッチ・プロセスなどを含むことができる。
【００５１】
さらに、一実施形態において、レコードのグループのうちの各レコードは、データ・システムによるアクセスが可能な任意のデータを含むことができる。別の実施形態において、各レコードは、データ・システムのすべてのサブシステムまたは並列システムあるいはその両方によってアクセス可能であり得る。たとえば、レコードはシスプレックス内の共有データを含むことができる。さらに別の実施形態において、レコードは記憶データ（たとえば、ＶＳＡＭ内の仮想記憶データなど）を含むことができる。さらに別の実施形態において、レコードは、シスプレックスのシステムのうちの１つまたは複数のうちの、シスプレックス内の他のシステムから分離された記憶域内に記憶することができる。
【００５２】
財務記録、銀行記録、個人記録、医療記録、個人データ記録、社会保障および行政記録などを処理する、バッチ・アプリケーションなどの、当分野で知られた任意のバッチ・アプリケーションを開始することができる。開始することは、バッチ・アプリケーションのコード内に含まれる機能性の一部またはすべてを実行することができるように、バッチ・アプリケーションを開始すること（たとえば、バッチ・アプリケーションを実行すること）を意味する。
【００５３】
動作４０８において、レコードのグループのうちの第１のレコードは、バッチ・アプリケーションによって第１のレコードが処理されることに応答してロックされる。さらに動作４０８において、バッチ・アプリケーションがレコードのグループ内の最終レコードの処理を完了しない限り、および処理が完了するまで、バッチ・アプリケーションは、第１のレコードをロック解除させない。最終レコードとは、最終レコードと呼ばれるレコードを除き、レコードのグループ内のすべての他のレコードが処理されたことを意味する。この処理は、時間の流れに沿って、先入れ先出し（ＦＩＦＯ）や先入れ後出し（ＦＩＬＯ）などのキューイング方式に従って、サイズ（最小から最大、最大から最小）によって、レコード名またはレコードの何らかの他の属性に応じたアルファベット順に、またはランダムな順序に行うことができる。
【００５４】
さらに、追加のレコードは、これらの追加のレコードがバッチ・アプリケーションによって処理されることに応答して、ロックされ得る。このレコード・ロック・プロセスは、バッチ・アプリケーションがレコードのグループの追加のレコードにアクセスする限り、継続され得る。しかしながら、一度レコードのグループのすべてがバッチ・アプリケーションによって処理されると、バッチ・アプリケーションによるレコードの処理に基づいてそれ以上のレコード・ロックは発生しないことが見込まれる。
【００５５】
本実施形態において、第１のレコードについてのロックは、アクセス・ロックを含むことができる。たとえば、第１のレコードについてのロックは、データ・システムおよび任意の並列システムまたはそれらのサブシステム内の第１のレコードへの排他的アクセスを、バッチ・アプリケーションに提供することができる。別の例において、第１のレコードについてのロックは、バッチ・アプリケーションのプロセス以外の任意のプロセスが第１のレコードにアクセスすることを防止することができる。別の実施形態において、第１のレコードについてのロックは、所定の時間の間、バッチ・アプリケーションによって保持することができる。さらに別の実施形態において、第１のレコードについてのロックは、１つまたは複数の所定の基準に合致するまで、バッチ・アプリケーションによって保持することができる。たとえば、第１のレコードについてのロックは、処理が完了した後にロックを解除するためのコマンドがバッチ・アプリケーションによって発行されるまで、バッチ・アプリケーションによって保持することができる。
【００５６】
動作４１０において、バッチ・アプリケーションがレコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、バッチ・アプリケーションの実行の結果としてロックされたレコードのグループのすべてのレコードがコミットされる。コミットされるとは、バッチ・アプリケーションの処理の結果として、１つまたは複数の影響を受けるレコードに対して更新および変更が行われ、バッチ・アプリケーションの処理に基づいて発行されたすべてのレコード・ロックが解除され、別のプロセスがレコードにアクセスできるようになることを意味する。一実施形態において、ｎはコミット・カウントに等しく、レコードのグループに関連付けられたレコード・ロックをコミットする前にバッチ・アプリケーションによって処理するレコード数を示す、正の整数である。
【００５７】
たとえば、動作４１０では、ｎが１００に等しいものと想定すると、バッチ・アプリケーションは１００のレコードを処理し、１００番目のレコードの処理を完了したことに応答して、バッチ・アプリケーションの実行の結果としてロックされたレコードのグループのすべてのレコードがコミットされ、それにより、これらのレコード・ロックが解除される。
【００５８】
一実施形態によれば、方法４００は、バッチ・アプリケーションがレコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の存在を発見すること、および、レコード・ロック要求の量を追跡することを、含むことができる。この説明において、「レコード・ロック要求」という用語は「ウエータ（waiter）」とも呼ばれ、レコード・アクセス要求、および、結果として、１つまたは複数の特定のレコードについてレコード・ロックが発行されることになる、リソースにアクセスするための任意の他の要求を含み、これらのレコード・ロックは、バッチ・アプリケーションによって保持されるレコード・ロックとの競合に起因して保留され、遂行することができない。すなわち、レコード・ロック要求の保留の存在および数が追跡され、この値は、一手法において、ジョブ制御マネージャがアクセス可能なコンピュータ可読記憶媒体に記憶される。
【００５９】
これら保留中のレコード・ロック要求は、少なくとも１つのレコードをロックするため、または、バッチ・アプリケーションの実行に起因してすでにロックされ、したがって保留されており遂行されていない、少なくとも１つのレコードにアクセスするため、あるいは、その両方のために、１つまたは複数のデバイス（方法４００を実行するジョブ制御マネージャとは異なる物理または仮想デバイス）によって発行される。ジョブ制御マネージャは、バッチ・アプリケーションの実行に起因して遂行されていないため、保留（ウエータ）となる、レコード・ロック要求も発行することができるが、これら保留中のレコード・ロック要求は、方法４００のバッチ・アプリケーション以外の別のアプリケーションの利益のために発行され得る。
【００６０】
さらに、各ウエータは、タイムアウト値の前にレコード・ロックが処理されない場合、保留中のレコード・ロック要求がいつ満了するかを指示する、関連付けられたタイムアウト値を有することができる。一実施形態において、各レコード・ロック要求がいつ満了することになるかをジョブ制御マネージャが決定できるように、各ウエータに関連付けられたタイムアウト値もジョブ制御マネージャによって決定される。
【００６１】
このウエータの追跡によって、ジョブ制御マネージャは、バッチ・アプリケーションの実行中、いつまでも保持され得るレコードのグループのレコードにアクセスするために、他の要求に関するバッチ・アプリケーションの実行の影響を判断することができる。これによって、バッチ・アプリケーションよりも高い優先度を有する可能性があり、したがって、方法４００のバッチ・アプリケーションよりも便宜的に処理されるべきである、別のアプリケーションまたはプロセスあるいはその両方の実行において、重大な遅延を生じさせる可能性がある。
【００６２】
さらにまた、一実施形態において、複数のレコード・ロック要求をキュー内にエンキューイングすることができる。たとえば、第１のレコードのロックについての第１の要求を、現在他のプロセスによって保持されているレコードのロックについての複数の異なる要求を含むデータ・システムのグローバル待機キュー内で識別することができる。別の実施形態において、第１のレコードのロックについての第１の要求は、キュー内の第１のレコードのロックについての複数の要求のうちの１つとすることができる。たとえば、第２のプロセスは、バッチ・アプリケーションによって保持される第１のレコードのロックを待機しているキュー内の複数のプロセスのうちの１つとすることができる。
【００６３】
さらなる手法において、方法４００は、バッチ・アプリケーションがレコードのグループのうちの少なくとも最小数のレコードの処理を完了したこと、および、レコード・ロック要求（ウエータ）の量がしきい値を超えた旨の決定に応答して、バッチ・アプリケーションの実行の結果としてロックされたレコードのグループのすべてのレコードをコミットすることも含むことができる。一手法において、レコードの最小数は、コミット・カウントよりも少なく、結果として、保留されているレコード・ロック要求を処理するための早期（コミット・カウントに等しいレコードの量を処理する以前の）のコミットを可能にする技法をもたらす。
【００６４】
一実施形態において、保留中のレコード・ロック要求のしきい値は、１つのレコード・ロック要求とすることができる。代替実施形態において、保留中のレコード・ロック要求のしきい値は、２、４、５、１０、２０、５０、１００、またはそれ以上の保留中のレコード・ロック要求とすることができる。このしきい値は、データ・システムの管理者によって明示的に設定することができる。さらにこのしきい値は、バッチ・アプリケーションについて個別に設定することができ、システム内で実行される任意の他のアプリケーションについて、異なるしきい値を設定することができる。
【００６５】
別の実施形態によれば、方法４００は、バッチ・アプリケーションの開始から、バッチ・アプリケーションの実行の結果としてロックされたレコードのグループのうちのすべてのレコードをコミットするまでに経過する時間の量を決定することを含むことができる。この動作は、レコードのグループのうちのｎ番目のレコードが処理されること単独に応答して、または、バッチ・アプリケーションの開始後に、レコードのグループ内のいずれのレコードについても保留中のレコード・ロックが発見されない（たとえば、バッチ・アプリケーションの開始後、ウエータが発見されないかまたは他の方法で追跡されない）旨の決定との組み合わせに応答して、実施することができる。
【００６６】
別の実施形態において、方法４００は、ジョブ制御マネージャにおいて、第２のバッチ・アプリケーションの実行を指定する第２のコマンドを受信することを含むことができる。この第２のバッチ・アプリケーションは、動作４０６においてバッチ・アプリケーションが開始したものと同じ規則およびポリシーのセットを順守するか、または、いくつかの手法において、動作４０６において開始されたバッチ・アプリケーションの実行を規定する規則およびポリシーと重複してもよい第２のバッチ・アプリケーション特有の規則およびポリシーの異なるセットを順守することができる。一実施形態において、第２のバッチ・アプリケーションは、動作４０６において開始されたバッチ・アプリケーションと同じとすることができる。
【００６７】
方法４００は、第１のレコードのセットと部分的または完全に重複する可能性があるか、または、第１のレコードのセットとは別個である可能性がある、第２のレコードのグループを処理する第２のバッチ・アプリケーションを、直接または間接的に開始することを含むこともできる。さらに、方法４００は、１つまたは複数のレコードが第２のバッチ・アプリケーションによって処理されることに応答して、第２のレコードのグループのうちの１つまたは複数のレコードをロックすること、および、バッチ・アプリケーションが第２のレコードのグループ（第２のレコードのグループのウエータ）を処理することに起因して実行を保留しているレコード・ロック要求の量を追跡することを、含むことができる。このレコードのロックは、第２のバッチ・アプリケーションが第２のレコードのグループ内の最終レコードの処理を完了しない限り、および完了するまで、第２のバッチ・アプリケーションが１つまたは複数のレコードをロック解除させないように実行される。
【００６８】
加えて、方法４００は、バッチ・アプリケーションが第２のレコードのグループのうちのｍ番目のレコードの処理を完了したこと、および、第２のレコードのグループのうちのｍ番目のレコードの処理を完了した後、最短のタイムアウトの前にレコード・ロック要求の量が処理されることになる旨の決定に応答して、第２のバッチ・アプリケーションの実行の結果としてロックされた第２のレコードのグループのすべてのレコードをコミットすることを含むことができる。したがって、各レコード・ロック要求についてのタイムアウト値の決定または受信あるいはその両方も可能である。このコミットは、第２のレコードのグループのうちのｍ番目のレコードの処理を完了した後に実行される。さらに、一手法において、ｍはコミット・カウントに等しいものとすることができる。
【００６９】
しかしながら、代替の手法において、方法４００は、第２のレコードのグループのうちのｍ番目のレコードの処理を完了する前に、第２のバッチ・アプリケーションの実行の結果としてロックされた第２のレコードのグループのすべてのレコードをコミットすることを含むことができる。このコミットは、第２のレコードのグループのうちのｍ番目のレコードの処理を完了した後、最短のタイムアウトの前に、レコード・ロック要求の量が処理されない旨の決定に応答して、実行することができる。
【００７０】
これらの決定は、各保留中のレコード・ロック要求に関連付けられたタイムアウト値に基づくものである。したがって、すべての保留中のレコード・ロック要求についてのタイムアウトが比較され、最も早く、または最小時間内に発生することになるタイムアウトが、最短タイムアウトとして選択される。このタイムアウトが最短タイムアウトとして選択されると、（第２のレコードのグループのうちのｍ番目のレコードの処理後）最短タイムアウトのレコード・ロック要求がタイムアウトなしに処理できることになる場合、すべての保留中のレコード・ロック要求は、タイムアウトなしに処理できることになることを保証することができる。そうでなければ、保留中のレコード・ロック要求のいずれもタイムアウトしないことを保証するために、第２のレコードのグループの処理は、最小数のレコードを処理した後に中断される。
【００７１】
方法４００は、システムまたはコンピュータ・プログラム製品あるいはその両方において実装可能である。たとえばシステムは、処理回路、および、処理回路に統合された、処理回路によって実行可能な、または、処理回路によって統合され実行可能な、ロジックを含むことができる。統合されるということは、処理回路が、ＡＳＩＣ、ＦＰＧＡなどのハードコード化されたロジックを含むハードウェア・プロセッサであることを意味する。実行可能であるということは、プロセッサが、ソフトウェアロジックによって指示された機能性を達成するために、ソフトウェアロジックを実行するように構成されることを意味し、プロセッサは、恐らくはＭＰＵ、ＣＰＵ，マイクロプロセッサなどである。ロジックは、処理回路に方法４００を実行させるように構成される。
【００７２】
別の例において、コンピュータ・プログラム製品は、プログラム命令が具体化されたコンピュータ可読記憶媒体を含むことができる。コンピュータ可読記憶媒体は、情報を記憶し、記憶した情報へのコンピュータ・アクセスを可能にするように構成された、当分野で知られた任意の好適な記憶デバイスとすることができる。具体化されたプログラム命令は、処理回路に方法４００を実行させるために、処理回路によって実行可能である。
【００７３】
方法４００が、ＩＢＭ  ｚ／ＯＳ環境内などのトランザクションＶＳＡＭを順守するデータ・システム、または当分野で知られたトランザクションＶＳＡＭを利用する任意の他のシステムと共に実行されるとき、トランザクションＶＳＡＭエンジンが自動コミットをいつ実行するかを決定できるようにするために、ジョブ制御言語（ＪＣＬ）内のジョブ・ステップ、または、ＩＧＷＳＭＳｘｘパラメータ・ライブラリ（ｐａｒｍｌｉｂ）メンバ内などの、何らかの他の好適な場所において、新しいパラメータを追加することができる。本明細書で使用されるトランザクションＶＳＡＭエンジンは、ＶＳＡＭトランザクション・タスクを実行する機能のカプセル化されたブロックを含む、ソフトウェア・モジュール、ライブラリ、ソフトウェア開発キット（ＳＤＫ）、またはオブジェクト、あるいはそれらの組合せを表す。任意の好適なエンジンを、当業者に知られたものとして使用することができる。いくつかの実施形態において、トランザクションＶＳＡＭエンジンはジョブ制御マネージャと参照され得る。
【００７４】
新しいパラメータは、２つの値または３つの値などの、１つまたは複数の値を含むことができる。一手法において、新しいパラメータ（コミット・カウント）は、レコード・ロックおよびレコード・アクセス要求についての値の範囲を指定する、最小値および最大値を含むことができる。このコミット・カウントは、リソース・リカバリ・サービス（ＲＲＳ）を呼び出すことなどによって、バッチ・アプリケーションによって利用されるレコードの代わりにコミット・ポイントをいつ発行するか、および発行するかどうかを決定するために、トランザクションＶＳＡＭエンジンによって使用されることになる。トランザクションＶＳＡＭエンジンは、現行のトランザクションまたはリカバリの単位（ＵＲ）における保留中のレコード・ロック（ウエータ）の数の分析に基づいて、コミット頻度（アクセスされるレコードまたは要求されるレコード・ロックあるいはその両方の数）を、最小値と最大値との間の値で調整することができる。加えて、管理者または何らかの他のユーザは、ｓｙｓ１．ｐａｒｍｌｉｂの記憶管理サブシステム（ＩＧＤＳＭＳｘｘ）についての初期化ルーチン・メンバにおいて、同様のシステム・レベル・コミット・パラメータを指定することができる。さらにＪＣＬ値は、ＩＧＤＳＭＳｘｘで指定された値を上書きすることができる。
【００７５】
本例において、トランザクションＶＳＡＭエンジンは、トランザクションＶＳＡＭを使用するバッチ・アプリケーションまたはジョブの代わりに、１つまたは複数のコミット同期ポイント（同期ポイント）を発行する。前述のように、パラメータは、トランザクションＶＳＡＭエンジンがコミット同期ポイントをいつ発行すべきであるかを決定できるようにするために、ＪＣＬ実行ステートメントまたはｓｙｓ１．ｐａｒｍｌｉｂのＩＧＤＳＭＳｘｘメンバ内に指定される。自動コミットのために実行可能化される各ＵＲまたはトランザクションについて、トランザクションＶＳＡＭエンジンは、レコード・アクセス要求がバッチ・アプリケーションによって発行されるときに、それらの数（追加、消去、更新）をカウントすることができる。レコード・アクセス要求のカウントおよびパラメータによって指定された値を用いて、トランザクションＶＳＡＭサービス（ＴＶＳ）は、ＵＲについて自動コミットを実行する時間点を決定する。カウントは、コミットの間、その直後、またはバックアウト同期ポイントのイベントにおいて、リセットされる。
【００７６】
一実施形態において、自動コミット頻度を指定するために使用されるパラメータは、下記のとおりとすることができる。
【００７７】
【数１】
2021501936.tif 000003
【００７８】
この例示のパラメータにおいて、ＴＶＳＡＭＣＯＭは、レコードのコミットの前に処理するレコードの数を指示する１つまたは複数の値を含む。ｍｉｎｖａｌパラメータは、トランザクションＶＳＡＭエンジンがバッチ・アプリケーションに代わって自動コミットを発行する前に実行されるレコード・アクセス要求の最小数を表す整数（１〜９９９９９）である。また、ｍａｘｖａｌパラメータは、トランザクションＶＳＡＭエンジンがバッチ・アプリケーションに代わって自動コミットを発行する前に実行されるレコード・アクセス要求の最大数を表す整数（０〜９９９９９）である。この値は、トランザクションＶＳＡＭエンジンが、コミット頻度を（ロック競合分析に起因するなどで）ｍａｘｖａｌパラメータによって指定された最大値よりも少ない数へと動的に調整しない場合のみ、有効になる。
【００７９】
詳細な一実装例によれば、記憶管理サブシステム（ＳＭＳＶＳＡＭ）の（ＶＳＡＭを利用する）データ共有サブシステムの初期化中、トランザクションＶＳＡＭエンジンは記憶管理サブシステム（ＳＭＳ）から値を取り出し、それらの値を内部制御ブロックに保存する。ＵＲについてのデータ・セットの第１の「オープン」要求も、ＪＣＬ実行ステートメントからｍｉｎｖａｌ値およびｍａｘｖａｌ値を取り出し、それらをオープン要求に関連付けられた制御ブロック内に保存する。ＵＲについて発行された第１のレコード管理要求は、ＪＣＬ実行ステートメントおよびｓｙｓ１．ｐａｒｍｌｉｂ内に指定された値に基づいて、ＵＲについての最終ｍｉｎｖａｌおよびｍａｘｖａｌ値を設定する。ＪＣＬステートメント内に指定された値は、ＩＧＤＳＭＳｘｘ内に指定された値よりも優先される。
【００８０】
ｍｉｎｖａｌおよびｍａｘｖａｌに対して同じ値が指定された場合（ｍｉｎｖａｌ＝ｍａｘｖａｌ＆＆ｍａｘｖａｌ＞０）、トランザクションＶＳＡＭエンジンは、バッチ・アプリケーションによって発行された指定数のレコード・アクセス要求が実行された後に、自動コミットを実行する。この場合、トランザクションＶＳＡＭエンジンは、リソースを保存するためにＵＲによって発見または取得されたレコード・ロックについてのウエータの数に基づいて、コミット頻度を調整しない。
【００８１】
第１の例によれば、アプリケーションによって実行されたレコード・アクセス（レコードの処理）の数が１００に達したときに、ＴＶＳＡＭＣＯＭ＝（１００，１００）ＤＦＳＭＳＴＶＳが、アプリケーションに代わってコミットを発行することになるものと想定する。ｍｉｎｖａｌについて指定された値がｍａｘｖａｌよりも少ない場合（ｍｉｎｖａｌ＜ｍａｘｖａｌ＆＆ｍａｘｖａｌ＞０）、トランザクションＶＳＡＭエンジンは、コミット頻度をｍｉｎｖａｌとｍａｘｖａｌとの間の数に調整することになる。この場合、トランザクションＶＳＡＭエンジンは、ＵＲのために保持されたレコード・ロックについてのウエータ情報を要求することによって、ＵＲについてレコード・ロック競合分析を実行することになる。リモート・システムは、最速にタイムアウトすることになるＣＩＣＳ要求を用いて、および、タイムアウトを発生させることになる時刻（ＴＯＤ）を用いて、生起システムに応答することになる。生起システムは、すべてのシステムが特定のレコード・ロックについての競合要求に応答した旨の信号を受信すると、それ自体からの応答を含むすべての応答を分析する。レコード・ロックを待機しているＣＩＣＳジョブがない場合、競合が存在しないことを意味し、トランザクションＶＳＡＭエンジンは、ＵＲ内で処理されたレコードの数がｍａｘｖａｌ値に達した場合にのみ、コミットを発行することになる。
【００８２】
第２の例によれば、ＵＲによって保持されるレコード・ロックのうちのいずれについてもＣＩＣＳウエータが存在しないという条件で、１００のレコードが処理されたときに、ＴＶＳＡＭＣＯＭ＝（１０，１００）とすると、ＤＦＳＭＳＴＶＳが、アプリケーションに代わってコミットを発行することになる。戻された情報が、レコード・ロックのうちの少なくとも１つを待機しているＣＩＣＳジョブが存在することを示す場合、トランザクションＶＳＡＭエンジンは、１００のレコードが処理される前であるが、最小数の１０のレコードが処理された後にのみ、コミットする可能性がある。
【００８３】
ｍｉｎｖａｌおよびｍａｘｖａｌによって指定された範囲内でのこのコミット頻度の調整は、いくつかの要素を単独でまたは組み合わせて考慮することができる。トランザクションＶＳＡＭエンジンは、システム内で最速でタイムアウトすることになるＣＩＣＳ待機要求を決定することが可能であり、その後、このタイムアウト値に基づいて、トランザクションＶＳＡＭエンジンは、待機要求がタイムアウトすることになる特定の時間を計算することになる。その後、トランザクションＶＳＡＭエンジンは、下記のアルゴリズムに従って、タイムアウトに到達する前に、レコード・ロックを保持するＵＲが自然にコミットされるか（ｍａｘｖａｌに達するか）どうかを検証することになる。
【００８４】
動的自動コミットの実行が可能な各ＵＲについて、トランザクションＶＳＡＭエンジンは、各マイクロトランザクションに要する時間の平均を維持し、ＵＲを完了するために必要な時間の平均量を確立するようにすることができる。たとえば、ユーザが１０のｍｉｎｖａｌ値および１００のｍａｘｖａｌ値を指定する場合、ならびに、競合に起因して１００のレコードの処理を達成する前にバッチ・アプリケーションの処理中に実行される動的な自動コミットが存在しない場合、トランザクションＶＳＡＭエンジンは、１００のレコードが処理されることに応答してコミットすることになる。１００のレコードの処理を実行するための経過時間が記憶され、この記憶された時間およびすべての以前に達成された間隔を使用して、スケジューリングされたコミットまでのレコードを処理するための平均時間が計算される。トランザクションＶＳＡＭエンジンは、スケジューリングされたコミットまでレコードを処理するためのこの計算された平均時間を使用して、受信したＣＩＣＳ要求がタイムアウトになる時間に基づいて現行のＵＲを早期にコミットすべきであるかどうか、または、ＵＲを続行させ、処理したレコードの数がｍａｘｖａｌ値に到達したときにコミットさせるかどうかを識別することになる。トランザクションＶＳＡＭエンジンが、ＵＲがコミットされる前にレコード・アクセス要求の最大数に達することによって、タイムアウトが発生することになる旨を識別した場合、トランザクションＶＳＡＭエンジンは、同じＵＲについて発行された次の要求が実行される前に、ＴＶＳがバッチ・アプリケーションに代わって自動コミットを実行するように、ＵＲにフラグを立てることになる。前述のように、早期（ｍａｘｖａｌに達する前に）コミットが実行されることに応答して、トランザクションＶＳＡＭエンジンは、ｍｉｎｖａｌが指定された場合に、ｍｉｎｖａｌに達していることにのみ応答して、コミットを発行することになり、その他の場合、トランザクションＶＳＡＭエンジンは、動作条件から判断して、即時または可能な限り速やかにコミットを発行することになる。
【００８５】
一例において、ＴＶＳＡＭＣＯＭ＝（，１００）と想定すると、競合が検出されるとすぐに、および、１００のレコードが処理されたことにも応答して、コミットが発行される。別の例において、ＴＶＳＡＭＣＯＭ＝（１，）と想定し、また、ｍａｘｖａｌが指定されていないものと想定すると、ＣＩＣＳ要求がレコード・ロックを待機している旨を、トランザクションＶＳＡＭエンジンが見つけるかまたは発見することに応答して、ＵＲがコミットされることになる。一実施形態において、ＴＶＳＡＭＣＯＭ値がどちらも０に設定されること、すなわちＴＶＳＡＭＣＯＭ＝（０，０）に応答して、この機能を使用不可とすることができる。
【００８６】
一実施形態によれば、データ・セットがクローズされることに応答して、コミットをトリガすることが可能であり、この場合、トランザクションＶＳＡＭエンジンは、クローズを発行するタスク制御ブロック（ＴＣＢ）に関連付けられたＵＲをコミットすることになる。これを実行することによって、ＴＶＳは、データ・セットがクローズされた後にレコード・ロックは保持されないことを保証する。
【００８７】
別の実施形態において、バッチ・アプリケーションがレコード・ロックを取得したこと、および、トランザクションＶＳＡＭエンジンによって自動コミットが発行されていないことに応答して、コミットをトリガすることが可能である。このコミットは、ＵＲによって保持される様々なレコード・ロックの下位にレコードについてのウエータが存在しないため、または、ＴＶＳＡＭＣＯＭパラメータ内に指定された値に達していないため、発行することが可能であり、したがって、コミットをトリガするために、処理されたレコードの数がｍａｘｖａｌに達する前に、レコード・ロック情報を記憶するロック構造がフルになる可能性がある。この場合、ＴＶＳは、自動コミットを強制して、バッチ・アプリケーションによって保持されるレコード・ロックを解除し、時間ベース、量ベース、または何らかの他の測定可能パラメータに基づくもので有り得る、しきい値に一致したときにロック構造を空にすることになる。このしきい値は、管理者によって設定可能であるか、または、７５％フル、８０％フル、９０％フルなどのデフォルト値を使用することができる。
【００８８】
一実施形態によれば、コミット同期ポイントを実行するために、トランザクションＶＳＡＭエンジンは、ＡＴＲＣＭＩＴまたはＡＴＲ４ＣＭＩＴ  ＲＲＳマクロを呼び出し、ＵＲについての変更が永続とされるべきであることを示す。その後、バッチ・アプリケーションがＳＳＲＣＭＩＴ（ＣＯＭＭＩＴ＿ＵＲ）ＲＲＳ関数を発行するものであったかのように、すべては正確に動作する。ＲＲＳは、ＵＲについての変更を永続とするように、すべてのリソース・マネージャに要求することになる。
【００８９】
ユーザＴＣＢの下で、ＳＭＳＶＳＡＭアドレス空間からクロス・メモリ・モードでＲＲＳ  ＡＴＲＣＭＩＴが呼び出されることになる。このようにして、ＲＲＳは、コミットを実行しているＴＣＢおよびそれに関連付けられたＵＲを認識することができる。コミットが開始される前に、トランザクションＶＳＡＭエンジンは、実行中の非同期要求があれば、これが完了するのを待機することになる。これにより、ＵＲに関連付けられたすべての要求がコミットされることが保証される。コミットが実行されるとき、ＴＣＢはコミットが完了するまで待機するため、新しい要求は実行できない。何らかのコミット障害の場合、ＵＲはフラグが立てられ、エラーがユーザに戻され、バッチ・アプリケーションはトランザクションを取り消して、コミットを発生させるために再試行することになる。
【００９０】
本明細書で説明するいくつかの実施形態によれば、明示的コミットを実行しないバッチ・アプリケーションに代わって、データ記憶環境において自動コミットを実行し、レコード・ロックを解くことができる。これらのレコード・ロックは、後続のトランザクションが実施されるのを防止することができる。レコード・ロックをいつコミットするか、およびコミットするか（および、それによって関連付けられたレコードを処理のために解除するか）どうかに関する決定は、１人または複数のユーザによって指定されたパラメータ、またはデータ記憶環境およびそのリソースの特定の作業負荷、あるいはその両方に基づくものとすることができる。
【００９１】
さらに、本明細書で説明する実施形態において、アプリケーションは、それによって作成されたレコード・ロックをコミットするために明示的同期ポイントを追加するように、修正または更新される必要はない。この利点は、非常に煩わしい、非常に費用がかかる、非常に大量である、非常に時間がかかる、またはそれ以外に、アプリケーションまたはデータ記憶システムの管理者が変更を行うためのソース・コードを持っていないことなどが原因で、実行しているアプリケーションを変更することが実際的ではない、データ記憶システム上で実行されるアプリケーションにとって、有益である。
【００９２】
本発明は、システム、方法、またはコンピュータ・プログラム製品、あるいはそれらの組合せとすることができる。コンピュータ・プログラム製品は、本発明の態様をプロセッサに実施させるためのコンピュータ可読プログラム命令を有するコンピュータ可読記憶媒体を含むことができる。
【００９３】
コンピュータ可読記憶媒体は、命令実行デバイスによる使用のための命令を保持および記憶することが可能な、有形デバイスとすることができる。コンピュータ可読記憶媒体は、たとえば、限定はしないが、電子記憶デバイス、磁気記憶デバイス、光記憶デバイス、電磁記憶デバイス、半導体記憶デバイス、またはそれらの任意の好適な組合せとすることができる。コンピュータ可読記憶媒体のより具体的な例の非網羅的リストには、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、静的ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、デジタルバーサタイル・ディスク（ＤＶＤ）、メモリ・スティック、フロッピィ・ディスク、パンチカードまたは溝内に命令が記録された盛り上がり構造などの機械的符号化デバイス、および、それらの任意の好適な組合せが含まれる。本明細書で使用されるコンピュータ可読記憶媒体は、電波または他の自由に伝搬する電磁波、導波路または他の伝送媒体を介して伝搬する電磁波（たとえば、光ファイバ・ケーブルを通過する光パルス）、または、ワイヤを介して伝送される電気信号などの、一過性信号自体であるものと解釈されるべきではない。
【００９４】
本明細書で説明するコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング／処理デバイスへ、または、ネットワーク、たとえばインターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、またはワイヤレス・ネットワーク、あるいはそれらの組合せを介して、外部コンピュータまたは外部記憶デバイスへ、ダウンロードすることができる。ネットワークは、銅伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイヤウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはそれらの組合せを含むことができる。各コンピューティング／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、コンピュータ可読プログラム命令を、それぞれのコンピューティング／処理デバイス内のコンピュータ可読記憶媒体内に記憶するために転送する。
【００９５】
本発明の動作を実施するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、あるいは、Ｓｍａｌｌｔａｌｋ（登録商標）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組合せで作成されたソース・コードまたはオブジェクト・コードのいずれかとすることができる。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、スタンドアロン型ソフトウェア・パッケージとして、部分的にユーザのコンピュータ上および部分的にリモート・コンピュータ上で、あるいは、完全にリモート・コンピュータまたはサーバ上で、実行することができる。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）を含む、任意のタイプのネットワークを介してユーザのコンピュータに接続することが可能であるか、または、外部コンピュータに（たとえば、インターネット・サービス・プロバイダを使用してインターネットを介して）接続することが可能である。いくつかの実施形態において、たとえば、プログラマブル・ロジック回路要素、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル・ロジック・アレイ（ＰＬＡ）を含む、電子回路要素は、本発明の態様を実行するために、コンピュータ可読プログラム命令の状態情報を利用することによってコンピュータ可読プログラム命令を実行し、電子回路要素をパーソナライズすることができる。
【００９６】
本発明の態様は、本明細書において、本発明の実施形態に従った方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照しながら説明する。フローチャート図またはブロック図あるいはその両方の各ブロック、および、フローチャート図またはブロック図あるいはその両方におけるブロックの組合せは、コンピュータ可読プログラム命令によって実装可能であることを理解されよう。
【００９７】
これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行される命令が、フローチャートまたはブロック図あるいはその両方のブロック内に指定された機能／動作を実装するための手段を作成するように、汎用コンピュータ、特定用途向けコンピュータ、または他のプログラム可能データ処理装置のプロセッサに提供されて、マシンを作り出すものであってよい。これらのコンピュータ可読プログラム命令は、命令が記憶されたコンピュータ可読記憶媒体が、フローチャートまたはブロック図あるいはその両方のブロック内に指定された機能／動作の態様を実装する命令を含む製品を含むように、コンピュータ可読記憶媒体内に記憶され、コンピュータ、プログラム可能データ処理装置、または他のデバイス、あるいはそれらの組合せに特定の様式で機能するように指示することができるものであってもよい。
【００９８】
コンピュータ可読プログラム命令は、コンピュータ、他のプログラム可能装置、または他のデバイス上で実行される命令が、フローチャートまたはブロック図あるいはその両方のブロック内に指定された機能／動作を実装するように、コンピュータ実装プロセスを生成すべく、コンピュータ、他のプログラム可能データ処理装置、または他のデバイス上にロードされ、コンピュータ、他のプログラム可能装置、または他のデバイス上で、一連の動作ステップを実行させるものであってもよい。
【００９９】
図面内のフローチャートおよびブロック図は、本発明の様々な実施形態に従ったシステム、方法、およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能、および動作を示す。この点で、フローチャートまたはブロック図内の各ブロックは、指定された論理機能を実装するための１つまたは複数の実行可能命令を含む、モジュール、セグメント、または命令の一部を表すことができる。いくつかの代替の実装において、ブロック内に示された機能は、図面内に示された順序以外で行われることが可能である。たとえば、連続して示される２つのブロックは、実際にはほぼ同時に実行することが可能であるか、またはブロックは、関与する機能に応じて、時折逆順に実行することが可能である。ブロック図またはフローチャート図あるいはその両方の各ブロック、およびブロック図またはフローチャート図あるいはその両方におけるブロックの組合せは、指定された機能または動作を実行するか、あるいは、特定用途向けハードウェアおよびコンピュータ命令の組合せを実施する、特定用途向けハードウェア・ベース・システムによって実装可能であることにも留意されたい。
【０１００】
さらに、様々な実施形態に従ったシステムは、プロセッサおよび、プロセッサに統合されたロジック、またはプロセッサによって実行可能なロジック、あるいはその両方を含むことが可能であり、ロジックは、本明細書に示されたプロセス・ステップのうちの１つまたは複数を実行するように構成されている。統合されるということは、プロセッサが、ＡＳＩＣ、ＦＰＧＡなどのハードウェアロジックと共に具体化されたロジックを有することを意味する。プロセッサによって実行可能であるということは、ロジックが、ハードウェアロジック、ファームウェア、オペレーティング・システムの一部、アプリケーション・プログラムの一部などのソフトウェアロジック、または、プロセッサによってアクセス可能であり、プロセッサによる実行時にプロセッサに何らかの機能を実行させるように構成された、ハードウェアロジックとソフトウェアロジックとの何らかの組合せであることを意味する。ソフトウェアロジックは、当分野で知られた任意のメモリタイプのうちの、ローカルまたはリモートあるいはその両方のメモリ上に記憶することができる。ソフトウェア・プロセッサ・モジュール、または、ＡＳＩＣ、ＦＰＧＡ、ＣＰＵ、集積回路（ＩＣ）、グラフィクス処理ユニット（ＧＰＵ）などのハードウェア・プロセッサ、あるいはその両方などの、当分野で知られた任意のプロセッサが使用可能である。
【０１０１】
前述のシステムまたは方法あるいはその両方の様々な特徴を任意の様式で組み合わせ、上記の説明から複数の組合せを作成可能であることが明白であろう。
【０１０２】
以上、様々な実施形態を説明してきたが、それらは限定ではなく単なる例として提示したものであることを理解されたい。したがって、好ましい実施形態の幅および範囲は、上記の例示的実施形態のうちのいずれによっても限定されるものではなく、添付の特許請求の範囲およびそれらの均等物に従ってのみ定義されるものである。
【図１】
2021501936.tif 000004
【図２】
2021501936.tif 000005
【図３】
2021501936.tif 000006
【図４】
2021501936.tif 000007
【図５】
2021501936.tif 000008
【手続補正書】
【提出日】令和2年5月14日(2020.5.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンピュータの情報処理による方法であって、
データ・システムのジョブ制御マネージャにおいて、バッチ・アプリケーションの実行を指定するコマンドを受信すること、
前記ジョブ制御マネージャにおいて、前記バッチ・アプリケーションに関連付けられたコミット・カウントを受信すること、
前記バッチ・アプリケーションを開始することであって、前記バッチ・アプリケーションはレコードのグループを処理する、前記開始すること、
前記バッチ・アプリケーションが前記レコードのグループ内の最終レコードの処理を完了しない限り、前記バッチ・アプリケーションは前記レコードのグループ内の第１のレコードをロック解除しないという条件で、前記第１のレコードが前記バッチ・アプリケーションによって処理されることに応答して、前記第１のレコードをロックすること、および、
前記バッチ・アプリケーションが前記レコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのすべてのレコードをコミットすることであって、ｎは前記コミット・カウントに等しい、前記コミットすること、
を含む、方法。
【請求項２】
前記バッチ・アプリケーションが前記レコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量を追跡すること、
をさらに含む、請求項１に記載の方法。
【請求項３】
前記バッチ・アプリケーションが前記レコードのグループのうちの少なくとも最小数のレコードの処理を完了したこと、および、前記レコード・ロック要求の量がしきい値を超えた旨の決定に応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットすること、
をさらに含み、前記最小数のレコードは前記コミット・カウントよりも少ない、
請求項２に記載の方法。
【請求項４】
前記しきい値は１つのレコード・ロック要求である、請求項３に記載の方法。
【請求項５】
前記レコードのグループのうちの前記ｎ番目のレコードが処理されることに応答して、前記バッチ・アプリケーションの開始から、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットするまでに経過する時間の量を決定することをさらに含む、請求項１に記載の方法。
【請求項６】
前記バッチ・アプリケーションの開始から、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットするまでに経過する前記時間の量は、
前記レコードのグループのうちの前記ｎ番目のレコードが処理されたこと、および、
前記バッチ・アプリケーションの開始後に、前記レコードのグループ内のどのレコードについても保留中のレコード・ロックが発見されなかったこと、
の両方の決定に応答して決定される、
請求項５に記載の方法。
【請求項７】
前記ジョブ制御マネージャにおいて、第２のバッチ・アプリケーションの実行を指定する第２のコマンドを受信すること、
前記第２のバッチ・アプリケーションを開始することであって、前記第２のバッチ・アプリケーションは、第２のレコードのグループを処理する、前記開始すること、
前記第２のバッチ・アプリケーションが前記第２のレコードのグループ内の最終レコードの処理を完了しない限り、前記第２のバッチ・アプリケーションは前記１つまたは複数のレコードをロック解除しないという条件で、前記１つまたは複数のレコードが前記第２のバッチ・アプリケーションによって処理されることに応答して、前記第２のレコードのグループのうちの１つまたは複数のレコードをロックすること、
前記バッチ・アプリケーションが前記第２のレコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量を追跡すること、
前記バッチ・アプリケーションが前記第２のレコードのグループのうちのｍ番目のレコードの処理を完了したこと、および、前記第２のレコードのグループのうちの前記ｍ番目のレコードの処理を完了した後、最短のタイムアウトの前に前記レコード・ロック要求の量が処理されることになる旨の決定に応答して、前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理が完了した後に、前記第２のバッチ・アプリケーションの実行の結果としてロックされた前記第２のレコードのグループのうちのすべてのレコードをコミットすることであって、ｍは前記コミット・カウントに等しい、前記コミットすること、ならびに、
前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理を完了した後、前記最短のタイムアウトの前に前記レコード・ロック要求の量が処理されない旨の決定に応答して、前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理を完了する前に、前記第２のバッチ・アプリケーションの実行の結果としてロックされた前記第２のレコードのグループのすべてのレコードをコミットすること、
をさらに含む、請求項５に記載の方法。
【請求項８】
前記コミット・カウントは、
コミットの前に処理されるべきレコードの最小数、および、
前記コミットの前に処理されるべきレコードの最大数、
という、２つの値を含み、
前記コミットの前に処理されるべき前記レコードの最小数が、前記コミットの前に処理されるべき前記レコードの最大数に等しい旨の決定に応答して、前記バッチ・アプリケーションが前記レコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量は追跡されない、
請求項１に記載の方法。
【請求項９】
コンピュータ・プログラムであって、コンピュータに、
データ・システムのジョブ制御マネージャにおいて、バッチ・アプリケーションの実行を指定するコマンドを受信すること、
前記ジョブ制御マネージャにおいて、前記バッチ・アプリケーションに関連付けられたコミット・カウントを受信すること、
前記バッチ・アプリケーションを開始することであって、前記バッチ・アプリケーションはレコードのグループを処理する、前記開始すること、
前記バッチ・アプリケーションが前記レコードのグループ内の最終レコードの処理を完了しない限り、前記バッチ・アプリケーションは前記レコードのグループ内の第１のレコードをロック解除しないという条件で、前記第１のレコードが前記バッチ・アプリケーションによって処理されることに応答して、前記第１のレコードをロックすること、および、
前記バッチ・アプリケーションが前記レコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのすべてのレコードをコミットすることであって、ｎは前記コミット・カウントに等しい、前記コミットすること、
を実行させるためのコンピュータ・プログラム。
【請求項１０】
前記コンピュータ・プロブラムは、コンピュータに、
前記バッチ・アプリケーションが前記レコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量を追跡すること、
をさらに実行させる、請求項９に記載のコンピュータ・プログラム。
【請求項１１】
前記コンピュータ・プロブラムは、コンピュータに、
前記バッチ・アプリケーションが前記レコードのグループのうちの少なくとも最小数のレコードの処理を完了したこと、および、前記レコード・ロック要求の量がしきい値を超えた旨の決定に応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットすること、
をさらに実行させ、前記最小数のレコードは前記コミット・カウントよりも少ない、
請求項１０に記載のコンピュータ・プログラム。
【請求項１２】
前記コンピュータ・プロブラムは、コンピュータに、
前記レコードのグループのうちの前記ｎ番目のレコードが処理されることに応答して、前記バッチ・アプリケーションの開始から、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットするまでに経過する時間の量を決定すること、
前記ジョブ制御マネージャにおいて、第２のバッチ・アプリケーションの実行を指定する第２のコマンドを受信すること、
前記第２のバッチ・アプリケーションを開始することであって、前記第２のバッチ・アプリケーションは第２のレコードのグループを処理する、前記開始すること、
前記第２のバッチ・アプリケーションが前記第２のレコードのグループ内の最終レコードの処理を完了しない限り、前記第２のバッチ・アプリケーションは前記１つまたは複数のレコードをロック解除しないという条件で、前記１つまたは複数のレコードが前記第２のバッチ・アプリケーションによって処理されることに応答して、前記第２のレコードのグループのうちの１つまたは複数のレコードをロックすること、
前記バッチ・アプリケーションが前記第２のレコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量を追跡すること、
前記バッチ・アプリケーションが前記第２のレコードのグループのうちのｍ番目のレコードの処理を完了したこと、および、前記第２のレコードのグループのうちの前記ｍ番目のレコードの処理を完了した後、最短のタイムアウトの前に前記レコード・ロック要求の量が処理されることになる旨の決定に応答して、前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理が完了した後に、前記第２のバッチ・アプリケーションの実行の結果としてロックされた前記第２のレコードのグループのうちのすべてのレコードをコミットすることであって、ｍは前記コミット・カウントに等しい、前記コミットすること、ならびに、
前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理を完了した後、前記最短のタイムアウトの前に前記レコード・ロック要求の量が処理されない旨の決定に応答して、前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理を完了する前に、前記第２のバッチ・アプリケーションの実行の結果としてロックされた前記第２のレコードのグループのすべてのレコードをコミットすること、
を、さらに実行させる、請求項９に記載のコンピュータ・プログラム。
【請求項１３】
前記バッチ・アプリケーションの開始から、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットするまでに経過する前記時間の量は、前記レコードのグループのうちの前記ｎ番目のレコードが処理されたこと、および、前記バッチ・アプリケーションの開始後に、前記レコードのグループ内のどのレコードについても保留中のレコード・ロックが発見されないこと、の両方の決定に応答してのみ決定される、請求項１２に記載のコンピュータ・プログラム。
【請求項１４】
前記コミット・カウントは、
コミットの前に処理されるべきレコードの最小数、および、
前記コミットの前に処理されるべきレコードの最大数、
という、２つの値を含み、
前記コミットの前に処理されるべき前記レコードの最小数が、前記コミットの前に処理されるべき前記レコードの最大数に等しい旨の決定に応答して、前記バッチ・アプリケーションが前記レコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量は追跡されない、
請求項９に記載のコンピュータ・プログラム。
【請求項１５】
システムであって、
処理回路、
メモリ、および、
前記メモリに記憶されるロジック、
を備え、前記ロジックは前記処理回路によって実行されると、
データ・システムのジョブ制御マネージャにおいて、バッチ・アプリケーションの実行を指定するコマンドを受信すること、
前記ジョブ制御マネージャにおいて、前記バッチ・アプリケーションに関連付けられたコミット・カウントを受信すること、
前記バッチ・アプリケーションを開始することであって、前記バッチ・アプリケーションはレコードのグループを処理する、前記開始すること、
前記バッチ・アプリケーションが前記レコードのグループ内の最終レコードの処理を完了しない限り、前記バッチ・アプリケーションは前記レコードのグループ内の第１のレコードをロック解除しないという条件で、前記第１のレコードが前記バッチ・アプリケーションによって処理されることに応答して、前記第１のレコードをロックすること、および、
前記バッチ・アプリケーションが前記レコードのグループのうちのｎ番目のレコードの処理を完了したことに応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのすべてのレコードをコミットすることであって、ｎは前記コミット・カウントに等しい、前記コミットすること、
を、前記処理回路に実行させる、
システム。
【請求項１６】
前記ロジックは、
前記バッチ・アプリケーションが前記レコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量を追跡すること、
を、前記処理回路にさらに実行させる、請求項１５に記載のシステム。
【請求項１７】
前記ロジックは、
前記バッチ・アプリケーションが前記レコードのグループのうちの少なくとも最小数のレコードの処理を完了したこと、および、前記レコード・ロック要求の量がしきい値を超えた旨の決定に応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットすること、
を、前記処理回路にさらに実行させ、
前記最小数のレコードは前記コミット・カウントよりも少なく、
前記しきい値は１つのレコード・ロック要求である、
請求項１６に記載のシステム。
【請求項１８】
前記ロジックは、
前記レコードのグループのうちの前記ｎ番目のレコードが処理されること、および、
前記バッチ・アプリケーションの開始後に、前記レコードのグループ内のどのレコードについても保留中のレコード・ロックが発見されなかったこと、
の両方の決定に応答して、
前記バッチ・アプリケーションの開始から、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットするまでに経過する時間の量を決定すること、
前記ジョブ制御マネージャにおいて、第２のバッチ・アプリケーションの実行を指定する第２のコマンドを受信すること、
前記第２のバッチ・アプリケーションを開始することであって、前記第２のバッチ・アプリケーションは第２のレコードのグループを処理する、前記開始すること、
前記第２のバッチ・アプリケーションが前記第２のレコードのグループ内の最終レコードの処理を完了しない限り、前記第２のバッチ・アプリケーションは前記１つまたは複数のレコードをロック解除しないという条件で、前記１つまたは複数のレコードが前記第２のバッチ・アプリケーションによって処理されることに応答して、前記第２のレコードのグループのうちの１つまたは複数のレコードをロックすること、
前記バッチ・アプリケーションが前記第２のレコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量を追跡すること、
前記バッチ・アプリケーションが前記第２のレコードのグループのうちのｍ番目のレコードの処理を完了したこと、および、前記第２のレコードのグループのうちの前記ｍ番目のレコードの処理を完了した後、最短のタイムアウトの前に前記レコード・ロック要求の量が処理されることになる旨の決定に応答して、前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理が完了した後に、前記第２のバッチ・アプリケーションの実行の結果としてロックされた前記第２のレコードのグループのうちのすべてのレコードをコミットすることであって、ｍは前記コミット・カウントに等しい、前記コミットすること、ならびに、
前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理を完了した後、前記最短のタイムアウトの前に前記レコード・ロック要求の量が処理されない旨の決定に応答して、前記第２のレコードのグループのうちの前記ｍ番目のレコードの前記処理を完了する前に、前記第２のバッチ・アプリケーションの実行の結果としてロックされた前記第２のレコードのグループのすべてのレコードをコミットすること、
を、前記処理回路にさらに実行させる、請求項１５に記載のシステム。
【請求項１９】
前記ロジックは、
前記バッチ・アプリケーションが前記レコードのグループのうちの少なくとも最小数のレコードの処理を完了したこと、および、前記レコード・ロック要求の量が第１のしきい値を超えた旨の決定に応答して、前記バッチ・アプリケーションの実行の結果としてロックされた前記レコードのグループのうちのすべてのレコードをコミットすること、
を、前記処理回路にさらに実行させ、前記最小数のレコードは前記コミット・カウントよりも少ない、請求項１８に記載のシステム。
【請求項２０】
前記コミット・カウントは、
コミットの前に処理されるべきレコードの最小数、および、
前記コミットの前に処理されるべきレコードの最大数、
という、２つの値を含み、
前記コミットの前に処理されるべき前記レコードの最小数が、前記コミットの前に処理されるべき前記レコードの最大数に等しい旨の決定に応答して、前記バッチ・アプリケーションが前記レコードのグループを処理することに起因して実行を保留しているレコード・ロック要求の量は追跡されない、
請求項１５に記載のシステム。
【国際調査報告】
2021501936.tif 000009
2021501936.tif 000010