リカバリー・アクションが発生するのは、GLOBALCONFIG ステートメントの SYSPLEXMONITOR パラメーターに RECOVERY が指定されている場合です。デフォルト設定 (SYSPLEXMONITOR NORECOVERY) がアクティブ状態の場合、このメッセージが出されるのみで、問題が訂正されなければそれ以上のアクションは発生しません。
VARY TCPIP,,SYSPLEX,LEAVEGROUP コマンドを使用して、シスプレックス・メンバーを手動で強制的に TCP/IP シスプレックス・グループから 離すことができます。スタックが TCP/IP シスプレックス・グループを離れると、 メッセージ EZZ9670E がメッセージ EZD1170E と同様にクリアされます。 他の未解決結果アクション・メッセージはすべて、問題の条件がクリアされると (例えば VTAM® が始動されると) クリアされます。 VARY TCPIP,,SYSPLEX コマンドについて詳しくは、「z/OS Communications Server: IP システム管理者のコマンド」を参照してください。
TCP/IP プロファイルの GLOBALCONFIG ステートメントの SYSPLEXMONITOR パラメーター で RECOVERY が指定された場合で、この TCP/IP スタックが TCP/IP シスプレックス・グループの 唯一のメンバーではない場合、このスタックは、 いずれかのメッセージが出された場合に、TCP/IP シスプレックス・グループを離れます。 これに対する唯一の例外は EZZ9672E で、これは OMPROUTE 警告メッセージとしてのみ発行されます。対応する EZZ9678E OMPROUTE メッセージが引き続き出されない限り、アクションは発生しません。
スタックが TCP/IP シスプレックス・グループに現在結合されているかどうかを 判別するには、DISPLAY TCPIP,,SYSPLEX,GROUP コマンドを発行します。 スタックが現在 TCP/IP シスプレックス・グループに結合されていない場合、 このコマンドにより次のメッセージが表示されます。
EZZ8269I tcpstackname mvsname NOT A MEMBER OF A SYSPLEX GROUPスタックが現在結合されている場合、TCP/IP XCF グループの名前が表示されます。
シスプレックスの任意のメンバーから、D XCF,GROUP,groupname コマンドを使用して、現在シスプレックス・グループ内にあるシステムを表示します。ここで、groupname は EZBTCPCS です。サブプレックス化が使用される場合は、EZBTvvtt です。ここで、vv は VTAM XCF グループ ID サフィックスであり、tt は TCP グループ ID サフィックスです。
RECOVERY オプションが指定され、TCP/IP スタックが、TCP/IP シスプレックス・グループを離れることによって自動リカバリー・アクションを開始すると、すべてのローカル DVIPA が非活動化され、すべての VIPADYNAMIC ブロック定義が保管されます。動的に作成された DVIPA (VIPARANGE または MODDVIPA) にバインドされたアプリケーションはすべて、非同期エラー (EUNATCH (3448) : アドレス・ファミリーのサポートに必要なプロトコルが使用不可能) を受け取ります。
内部問題によってこれらのリソースが除去されない場合、 結果アクション・メッセージ EZZ9675E が出され、TCP/IP シスプレックス・グループに 加わるには、スタックの再始動が必要です。 すべての DVIPA が正常に除去されると、結果アクション・メッセージ EZZ9676E が出され、シスプレックス問題検出のクリーンアップに成功したことが示されます。正常なクリーンアップが行われた後で、 スタックがシスプレックス・グループを再結合し、このメッセージをクリアするには 2 つの方法があります。
リカバリーは、TCP/IP シスプレックスのほかのメンバーがオペレーターのアクションを必要とせずに、自動的にメンバーの機能を引き継ぐことができるので、お勧めする操作方法です。IBM® Health Checker for z/OS® を使用すると、IPCONFIG DYNAMICXCF または IPCONFIG6 DYNAMICXCF ステートメントが指定されているときに、RECOVERY パラメーターが指定されているかどうかを確認することができます。 IBM Health Checker for z/OS について詳しくは、「z/OS Communications Server: IP Diagnosis Guide」を参照してください。
しかし、環境およびシナリオによっては、この自動化リカバリー・アクションが望ましくなく、使用可能にすべきではないと考えられる場合もあります。
自動化リカバリー・アクションの基本的な前提は、 システム内の他の 1 つ以上の TCP/IP スタックが、障害のある TCP/IP スタックが所有する すべての DVIPA の所有権の責任を引き取ることができることです。 これができない場合は、 バックアップ TCP/IP スタックを指定する利点を慎重に評価して、 バックアップ機能を含む構成を実装することをお勧めします。 これが不可能な場合または望ましくない場合は、RECOVERY を指定してはなりません。RECOVERY を指定しない場合、 自動化リカバリー・アクションはデフォルトで使用不可になります。
例えば、この種の構成の 1 つとしては、 常に特定の TCP/IP スタックにバインドされる DVIPA (すなわち、静的 VIPA の代わり) の 使用に限る場合があります。 このシナリオでは、自動転送されるこれらの DVIPA の所有権を持つ可能性がないため、自動化リカバリー・アクションを起動する意味がなく、自動化リカバリー機能を使用可能化しないこと、あるいは静的 VIPA を使用することを考慮すべきです (静的 VIPA は自動化リカバリー・アクションの影響を受けないため)。
これには、z/VM® の下で、または共用プロセッサーおよび非常に限定されたリソースを使用する LPAR 内で、z/OS を第 2 レベルのゲストとして実行する場合の環境も含まれます。これらの環境で自動化リカバリー・アクションを使用不可にしておくことにより、不要な検出の条件 (例えば、意図的に作られた厳しいリソース不足が検出されるシナリオなど) によって不要なリカバリー・アクションを起動しないようにするのに役立ちます。
ユーザーの現行の操作手順に、VTAM または OMPROUTE を長期間停止する機能が含まれる場合、ユーザーがこれらのコンポーネントを停止し再始動する期間の前後には、自動化リカバリー処理を使用不可にし、再度使用可能にすることを 考慮する必要があります。これは VARY TCPIP,,OBEYFILE コマンドを使用して行うことができます。
代わりの解決策としては、通常の操作手順の間に VTAM または OMPROUTE が非アクティブになると予想される最長期間に対応できるように、TIMERSECS 値を増やすという方法があります。この方法の潜在的な欠点は、ほかの状態をモニターしたり自動リカバリー機能を起動する場合の即応性に欠けることです。