このドキュメントでは CICS ノードエラープログラムに関する考慮事項について説明します。
次のトピックについて説明します。
以下の項目も参照してください。
CICS ノードエラープログラムのインストール。CICS ノードエラープログラムのインストールの詳細については、対応する CICS バージョンの『CICS Customization Guide』で、ユーザーが交換可能なプログラムに関するセクションを参照してください。
Natural セッションがアクティブな場合は常に、スレッドストレージ、ロール機能エントリ（つまり VSAM RRDS ファイルまたは CICS 一時ストレージキュー内のレコード）、スワッププールスロットなどの CICS リソースが使用されます。
これらのリソースが Natural CICS インターフェイスに制御されている場合は、セッションが正常終了しても異常終了しても、リソースは正常に解放されます。
次の場合は、Natural CICS インターフェイスによって制御することはできません。
Natural によって呼び出された Natural 以外のプログラムが、EXEC CICS ABEND CANCEL コマンドまたは同等の CICS マクロ要求を発行します。すべてのセッションリソースを適切に解放するため、CICS タスクは、Natural CICS インターフェイスが制御を受け取ることなくキャンセルされます。
一部の CICS モニタ製品には CICS タスクを削除するツールがあり、アプリケーションによって設定された異常終了出口をバイパスします。 Natural タスクがこのようにキャンセルされた場合、Natural CICS インターフェイスは、まだセッションに所有されているリソースを解放することができません。
Natural セッションが CICS においてアクティブでないときに（擬似会話型画面 I/O）、ユーザーが、電源をオフにするか、セッションマネージャの該当する機能を使用して CICS リージョンから端末を切断します。
Natural CICS インターフェイスには、このような状況から回復するためのリカバリメカニズムがあります。以下に例を示します。
新しい Natural セッションを開始する場合は常にテーブルをスキャンして、同じ端末 ID を持つ別の Natural セッションがすでにアクティブになっていないかを確認します。 このようなセッションが存在する場合は論理的に終了し、そのすべてのリソースを、新しいセッションを開始する前に解放します。
しかし、セッションを論理的に終了してからリソースを解放するまでに長い時間がかかる場合があります。また、セキュリティの問題がある場合もあります。
NCIPARM 生成パラメータ COMARET を NO に設定すると、Natural セッションを再開する情報は CICS 一時ストレージレコードに保存され、このレコードの端末 ID は一時ストレージキュー名の一部になります。 別の CICS ユーザーがこの端末 ID で Natural を開始しようとすると、新しいセッションは開始されずに古い
Natural セッションが再開されます。
上記のリストで 3 つ目のケースが最も重大です。 CICS のノードエラープログラム（NEP）出口インターフェイスを使用すると、このような場合に、失われたセッションを Natural CICS インターフェイスで終了することができます。 NCIZNEP という適切なプログラムが、Natural CICS ソースライブラリで提供されています（「Natural CICS のサンプルプログラム」を参照）。このプログラムは DFHZNEP ノードエラープログラムによって呼び出す必要があります。
この他にもいくつかの考慮事項があります。
Natural CICS ソースライブラリには、CICS/VSE バージョン 2.3 用の XNCINEP1 および CICS/TS 用の XNCINEP2 という 2 つのサンプルのノードエラープログラムが含まれています。 どちらのサンプルプログラムも Natural CICS 環境に対して特別な処理を実行することはなく、単に（LINK を介して）NCIZNEP プログラムを呼び出し、そのプログラムが CICS 環境の Natural を処理します。
DFHZNEP は、特定のインストールに対してすでにカスタマイズされている場合があります。ノードエラープログラムは 1 つに制限されているため、関連する XNCINEPx プログラムのロジックを既存の DFHZNEP ロジックに適合させる必要があります。
MRO 環境では、DFHZNEP は TOR にインストールする必要があります。
CICS 3.3 以上では、NCIZNEP プログラムを EXECKEY(CICS) で定義する必要があります。
上記の項目 3 で説明した場合において、 DFHZNEP はさまざまな内部エラーコードによって、複数回制御を受け取る場合があります。これは、各内部エラーコードは特定の CICS エラーメッセージと関連していますが、ある特定のアクションから複数のエラーメッセージが生じる場合があるためです。
完了時に、NCIZNEP はパラメータ入力をクリアすることによって、作業、つまり Natural セッションクリーンアップタスクの起動が正常に完了したかどうかを呼び出し元（通常は DFHZNEP）に示します。
ノードエラープログラムが起動されるたびに、CICS コントロールブロック群は変更されている可能性があります。例えば、TCTTE の COMMAREA および NEXTRANSID 情報は、特定のノードエラーイベントの後に失われている場合があります。
この場合、NCIPARM パラメータ COMARET を適切に設定する必要があります。これは、CICS によってすでにクリーンアップされた CICS COMMAREA の Natural 擬似会話型セッション再スタートデータを渡すときに起動されるノードエラープログラムのノードエラーイベントを選択できないことを意味します。
特定のアクションで起動される DFHZNEP の回数とエラーコード、および TCTTE の状態を調べるには、ダミーのノードエラープログラムを記述します。このプログラムは、要求された情報を示す CICS トレース要求のみを発行します。
次のサンプルでは、DFHZNEP エラープロセッサは、DFHZNEP に渡される可能なすべてのエラーコードに対して、制御を受け取ることができます。
.
DFHSNEP TYPE=INITIAL
ORG NEPTT
DC 256X'03' invoke error processor '3' for ALL error codes
ORG ,
DFHSNEP TYPE=ERRPROC,GROUP=3,CODE=49
.
set up requested information and issue trace request(s)