障害モード

壊滅的な GLM 障害では、すべてのエンタープライズ サーバー クラスターのメンバーによるすべてのアクティブなジョブの正常な完了は、グローバル ロック マネージャー (GLM) に依存します。接続が永続的に切断した状況では、システム管理者は GLM とクライアント上で対策を講じる必要があります。

エンタープライズ サーバー クラスター クライアントに示される GLM 障害

エンタープライズ サーバー クラスター クライアントでは、GLM 障害を次のコンソール メッセージによって特定できます。 
CASCS1117I Connection to GLM_APPLID (sysid GLM_SYSID) lost (protocol P2P)
ここで、
  • GLM_APPLID は GLM APPLID です。
  • GLM_SYSID は GLM SYSID です。
このメッセージは、GLM への接続が切断されたことを示します。接続が断たれた原因として接続の問題が考えられますが、GLM の壊滅的な障害でも同じメッセージが表示されます。壊滅的な GLM 障害では、GLM を再起動しない限り接続は再び確立されません。また壊滅的な GLM 障害では、クラスター クライアントが最初の接続を試みた直後にこのメッセージが返されます。それ以外の場合、システムは ES_GLM_TIMEOUT 環境変数に指定された期間まで接続を再試行し続けます。この期間に達すると、次のコンソール ログ出力が表示されます。 
CASCS3032S Connection to ES Cluster manager ESCLMGR (sysid MST1) is disabled, verify and
release global locks on ES cluster manager.

対処策

GLM の再起動の前に、障害の原因を特定して修正することが欠かせません。必要に応じて、CAS データを収集し障害を詳しく分析します。

エンタープライズ サーバー クラスター クライアントでは、グローバル ロックを DEQUEUE しようとするまで、アクティブなジョブは実行を継続できます。DEQUEUE が要求される前に GLM を再起動すると、DEQUEUE は正常に実行します。それ以外の場合、DEQUEUE は失敗しますがその失敗は無視されローカル DEQUEUE が正常に実行されます。これにより JCL が正常に実行され、クライアント側のアクションは必要ありません。

クラスターからのエンタープライズ サーバー クラスター クライアントの削除

壊滅的な GLM 障害が発生した後、またはエンタープライズ サーバー クラスター クライアントの障害イベントで、またはその他の状況でエンタープライズ サーバー リージョンをクラスターから除外する必要がある場合、何らかの対処が必要です。

GLM の再起動の前に GLM で行う対処
障害が発生した後に GLM が再起動するとき、前に接続されていたクラスター クライアントは CASGLM.LCK ファイルですべて ACTIVE としてマークされます。この結果、GLM は各クラスターにそれぞれのアクティブなグローバル ロック送信を要求して待機し、GLM 自体は応答を待つ間 NOWORK ステータスになります。このステータスは、GLM がすべてのクライアントから応答を受信した直後に再び ACTIVE に切り替わります。各クライアントからの応答が 1 つでもない状態では、GLM は作業を進めることができません。

NOWORK ステータスは GLM に表示されます。

ESMAC の [Server Information] ページ (CASRDO5) に、次のステータス情報が表示されます。

CASGLM.LCK で ACTIVE としてマークされるすべてのエンタープライズ サーバー クラスター クライアントが再接続されると、次が表示されます。

GLM のコンソール ログで、次のメッセージが表示されます。 
CASKC6008S No reply received for lock request from ESCLSLV2. GLM work halted until reply on ESMAC
 control page is provided.
GLM が NOWORK ステータスにあるときエンタープライズ サーバー クラスター クライアントで JCL ジョブを実行しようすると、次の一連のメッセージが表示されます。 
ESCL1  CASCS3036E GLM ESCLMGR (sysid MST1) is in "NOWORK" state, waiting for all ES Cluster
clients to send their locks. Check message KC6008S on the GLM. 10:36:43
ESCL1   JCLCM0188I JOB02312 LCKSLEEP JOB  STARTED 10:36:43
ESCL1   JCLCM2000E JOB02312 LCKSLEEP Unable to acquire global lock for job LCKSLEEP. 10:36:43
ESCL1   CLCM0181S JOB02312 LCKSLEEP JOB  ABENDED - COND CODE S922 10:36:43

GLM がロック処理を再開できるように、GLM の ESMAC 画面の [CONTROL] ページ (CASRDO11) で応答が実行されます。

エンタープライズ サーバー クラスター クライアント ESCLSLV2 をクラスターから削除するには、チェックボックスをオフにします。

GLM への接続が永続的に切断した後のロック削除

GLM への接続が永続的に切断した状況では、クライアントと GLM の両方の対処が必要になります。

次のシナリオでは、グローバル ロックの削除が必要な状況を示します。

エンタープライズ サーバー クラスターのメンバー
  • GLM
  • エンタープライズ サーバー クラスター クライアント 1：ESCLCLT1
  • エンタープライズ サーバー クラスター クライアント 2：ESCLCLT2
シナリオ
すべてのメンバーが正常に起動してハンドシェイクを完了しています。JCL が両方のリージョンで実行しています。
クライアント 1 のステータス
ESCLCLT1 で、JCL1 は PID1 で実行しておりリソース 1 とリソース 2 で排他的ロックを保持しています。ESCLCLT1 PID1 JCL1 はアクティブなキューで ACTIVE ステータスにあります。
クライアント 2 のステータス
ESCLCLT2 では、JCL2 は PID2 で実行しておりリソース 1 のロックを要求します。ESCLCLT2 PID2 JCL2 はアクティブなキューで WAIT ステータスにあります。
GLM と ESCLCLT1 の間で永続的な接続障害が発生します。GLM はアクティブなままで、ESCLCLT2 と GLM との接続はアクティブです。

ESCLCLT1 の接続障害の間に JCL1 がロックの DEQUEUE を試みると、エンタープライズ サーバー クラスター クライアント層は ES_GLM_TIMEOUT で設定された期間に渡り再試行します。この設定値に達すると、エンタープライズ サーバー クラスター層は GLM への接続に disabled のマークを付け、すべてのグローバルな ENQUEUE/DEQUEUE 要求は拒否されます。JCL は正常に終了し、ロック (エンタープライズ サーバー クラスター クライアント上のグローバル ロックを含む) が解放されます。ただし GLM 上のグローバル ロックはアクティブなままになります。

エンタープライズ サーバー クラスター クライアント上
システム管理者は、JCL1 を完了まで実行するかまたはキャンセルする必要があるかを判断する必要があります。
エンタープライズ サーバー クラスター GLM 上
どのような判断でも、ESCLCLT2 で JCL2 ジョブが完了まで実行するように、GLM 上の JCL1 で保持されるロックを削除する必要があります。

次の節では、caslock コマンドと該当する [ESMAC] ページ (CASRDO33) の使用方法について説明します。両方のツールには、ロックを参照および削除する機能、およびクラスターをオフラインにする機能があります。

上位ヘルプ： エンタープライズ サーバーのクラスター化