障害モード
Enterprise Server クラスター クライアントに示される GLM 障害
CASCS1117I Connection to GLM_APPLID (sysid GLM_SYSID) lost (protocol P2P)詳細は次のとおりです。
- GLM_APPLID は GLM APPLID です。
- GLM_SYSID は GLM SYSID です。
CASCS3032S Connection to ES Cluster manager ESCLMGR (sysid MST1) is disabled, verify and release global locks on ES cluster manager.
対処策
GLM の再起動の前に、障害の原因を特定して修正することが欠かせません。必要に応じて、CAS データを収集し障害を詳しく分析します。
Enterprise Server クラスター クライアントでは、グローバル ロックを DEQUEUE しようとするまで、アクティブなジョブは実行を継続できます。DEQUEUE が要求される前に GLM を再起動すると、DEQUEUE は正常に実行します。それ以外の場合、DEQUEUE は失敗しますがその失敗は無視されローカル DEQUEUE が正常に実行されます。これにより JCL が正常に実行され、クライアント側のアクションは必要ありません。
クラスターからの Enterprise Server クラスター クライアントの削除
壊滅的な GLM 障害が発生した後、または Enterprise Server クライアントの障害イベントで、またはその他の状況で Enterprise Server リージョンをクラスターから除外する必要がある場合、何らかの対処が必要です。
- GLM の再起動の前に GLM で行う対処
- 障害が発生した後に GLM が再起動する際、前に接続されていたクラスター クライアントは CASGLM.LCK ファイルですべて ACTIVE としてマークされます。この結果、GLM は各クラスターにそれぞれのアクティブなグローバル ロック送信を要求して待機し、GLM 自体は応答を待つ間 NOWORK ステータスになります。このステータスは、GLM がすべてのクライアントから応答を受信した直後に再び
ACTIVE に切り替わります。応答しないクライアントが 1 つでもある場合、GLM は作業を進めることができません。
NOWORK ステータスは GLM に表示されます。
ESMAC の [Server Information] ページ (CASRDO5) に、次のステータス情報が表示されます。
CASGLM.LCK で ACTIVE としてマークされるすべての Enterprise Server クラスター クライアントが再接続されると、次が表示されます。
GLM のコンソール ログで、次のメッセージが表示されます。CASKC6008S No reply received for lock request from ESCLSLV2. GLM work halted until reply on ESMAC control page is provided.
GLM が NOWORK ステータスにある場合に Enterprise Server クラスター クライアントで 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) で応答が実行されます。
Enterprise Server クラスター クライアント ESCLSLV2 をクラスターから削除するには、チェックボックスをオフにします。
GLM への接続が永続的に切断した後のロック削除
GLM への接続が永続的に切断した状況では、クライアントおよび GLM の両方の対処が必要になります。
次のシナリオでは、グローバル ロックの削除が必要な状況を示します。
- GLM
- Enterprise Server クラスター クライアント 1：ESCLCLT1
- Enterprise Server クラスター クライアント 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 を試みると、Enterprise Server クラスター クライアント層は ES_GLM_TIMEOUT で設定された期間に渡り再試行します。この設定値に達すると、Enterprise Server クラスター層は GLM への接続に disabled のマークを付け、すべてのグローバルな ENQUEUE/DEQUEUE 要求は拒否されます。JCL は正常に終了し、ロック (Enterprise Server クラスター クライアント上のグローバル ロックを含む) が解放されます。ただし GLM 上のグローバル ロックはアクティブなままになります。
- Enterprise Server クラスター クライアント上
- システム管理者は、JCL1 を完了まで実行するかまたはキャンセルする必要があるかを判断する必要があります。
- Enterprise Server クラスター GLM 上
- どのような判断でも、ESCLCLT2 で JCL2 ジョブが完了まで実行するように、GLM 上の JCL1 で保持されるロックを削除する必要があります。
次のセクションでは、caslock コマンドおよび該当する [ESMAC] ページ (CASRDO33) の使用方法について説明します。両方のツールには、ロックを参照および削除する機能と、クラスターをオフラインにする機能があります。