Open(PLU) OK Response には、接続情報制御ブロック (CICB) が含まれています。これにより、アプリケーションは接続の特定の特性をカスタマイズでき、BIND 検証で使用される情報が含まれます。 ローカル ノードは、Open(PLU) OK 応答で実行される BIND パラメーターを検証することに注意してください。 ホストからの元の BIND 要求/応答ユニット (RU) のコピーは保持されません。 BIND が交渉可能な場合、アプリケーションは BIND RU 内のパラメーターの変更を許可されますが、ネゴシエートできない場合は、変更されていない BIND RU を返す必要があります。 Open(PLU) 要求では、交渉可能な BIND フラグが提供されます。
PLU セッションの多くの特性は BIND パラメーターによって決まりますが、アプリケーションは CICB のフィールドを指定することによって特定の特性を選択できます。 詳細については、次の表を参照してください。 CICB の使用方法と、さまざまな CICB オプションを選択することによる PLU セッションへの影響についての詳細な情報は、チェーニングやペーシングといった PLU セッションの特性を扱うこのセクションのトピックにおいて、コンテキストの中で提供されています。
BIND は、BIND 検査テーブル項目 (CICB で索引が指定されている) を使用して検証されます。 このエントリは 、BIND のさまざまなフィールドに対応します。 BIND チェック テーブルのエントリは、構成ファイルに格納されます。 たとえば、 BIND チェック テーブル エントリは、セカンダリ チェーン応答プロトコルが "確定応答" または "確定応答または例外応答" (バイト 5 ビット 2 および 3 = B10 または B11) の場合に BIND を受け入れるように指定できます。 これは、アプリケーションが要求例外 (RQE) チェーンを送信したくない場合に適しています。
接続情報制御ブロックの使用状況を次の表に示します。
| フィールド | 説明 |
|---|---|
| セグメント配信オプション | 0x00の値は、ローカル ノードが送信セグメント アセンブリを実行し、完全な RU のみを配信する必要があることを示します。 0x01の値は、アプリケーションがローカル ノードに RU セグメントを配信することを望んでいることを示します。 詳細については、「 セグメント配信」を参照してください。 |
| アプリケーション のペーシング オプション | 0x00 の値は、アプリケーションがペーシングを処理するためにローカルノードを必要としていることを示します。 0x01の値は、アプリケーションが Status-Resource メッセージを介した送信ペーシングに関与する必要があることを示します。 詳細については、「ペーシングとチャンク」を参照してください。 |
| アプリケーションの取り消しオプション | 0x00の値は、ローカル ノードが自動的に CANCEL を生成することを示します。 0x01の値は、アプリケーションが CANCEL を生成することを示します。 詳細については、「 受信チェーン」を参照してください。 |
| アプリケーション トランザクション番号オプション | 0x00の値は、アプリケーションがトランザクション番号をサポートしていないことを示します。 0x01の値は、アプリケーションがトランザクション番号をサポートしていることを示します。 詳細については、「 回復」を参照してください。 |
| BIND インデックス チェック | BIND パラメーターを検証する必要がある BIND チェック テーブル エントリのインデックスを指定します。 次のいずれかの値を使用する必要があります。 - 0x01 —3270 プリンター セッション - 0x02 —3270 ディスプレイ セッション - 0x10 —LUA (LU タイプ 0) アプリケーション |
Open(PLU) Confirm は、ローカル ノードからアプリケーションに対して、BIND 検証が成功したかどうかを示し、成功した場合は、バインド情報制御ブロック (BICB) を提供します。 BICB は、セッション BIND パラメーターを高レベル言語に適した形式で要約し、PLU セッションの特性を効果的に定義します。 BIND をネゴシエートしないアプリケーションは、通常、Open(PLU) 要求で BIND を調べる必要はありません。また、Open(PLU) OK Confirm で BICB を使用する必要があります。
次の表は、BICB のフィールドと 、BIND RU のパラメーターとの対応をまとめたものです。 詳細については、IBM マニュアル ・システム・ネットワーク・アーキテクチャ: フォーマット (GA27-3136) を参照してください。
| Open(PLU) OK Confirm 上の位置 | Bind RU の位置 [バイト、ビット] | 説明 |
|---|---|---|
| dataru[0] | [ 2, ] | 関数管理 (FM) プロファイル |
| dataru[1] | [ 3, ] | 伝送サービスプロファイル |
| dataru[2] | [ 4, 0] | プライマリ チェーンの使用 |
| dataru[3] | [ 4, 1] | プライマリ要求制御モード |
| dataru[4] | [ 4,2-3] | プライマリ チェーン応答プロトコル |
| dataru[5] | [ 4, 4] | プライマリ 2 フェーズ コミット |
| dataru[6] | [ 4, 6] | プライマリ圧縮インジケーター |
| dataru[7] | [ 4, 7] | プライマリ送信終了ブラケット (EB) インジケーター |
| dataru[8] | [ 5, 0] | セカンダリ チェーンの使用 |
| dataru[9] | [ 5, 1] | 補助要求制御モード |
| dataru[10] | [ 5,2-3] | 二次チェーン応答プロトコル |
| ataru[11]** | [ 5, 4] | セカンダリ 2 フェーズ コミット |
| dataru[12] | [ 5, 6] | セカンダリ圧縮インジケーター |
| dataru[13] | [ 5, 7] | セカンダリ送信 EB インジケーター |
| dataru[14] | [ 6, 1] | FM ヘッダーの使用法 |
| dataru[15] | [ 6, 2] | 角かっこの使用法1 |
| dataru[16] | [ 6, 2] | ブラケット リセット状態 2 |
| dataru[17] | [ 6, 3] | 角かっこの終了規則 |
| dataru[18] | [ 6, 4] | 代替コード セット インジケーター |
| dataru[19] | [ 6, 5] | シーケンス番号の可用性 |
| dataru[20] | [ 7,0-1] | 標準フロー送受信モード |
| dataru[21] | [ 7, 7] | 半二重フリップフロップのリセット |
| dataru[22] | [ 8,2-7] | セカンダリ ペーシング送信ウィンドウ |
| ataru[23]** | [ 9,2-7] | セカンダリー ペーシング受信ウィンドウ |
| dataru[24-25]\* | [10, ] | 副次送信最大要求ユニットサイズ |
| dataru[26-27]\* | [11, ] | プライマリ送信の最大リクエストユニットサイズ |
| dataru[28] | [14,1-7] | LU-LU セッションの種類 |
| dataru[29] | [27, ] | PLU 名のサイズ |
| dataru[30-37] | [28, ] | 拡張バイナリコード化10進インターチェンジコード (EBCDIC) の PLU 名 |
| dataru[38] | [15,0-3] | セッション・タイプ 1: PS 関数管理ヘッダー (FMH) タイプ |
| dataru[39] | [15,4-7] | PS データストリームのプロファイル |
| dataru[40] | [16, 0] | 未処理の宛先の数 |
| dataru[41] | [16, 1] | 圧縮されたデータ インジケーター |
| ataru[42]** | [16, 2] | 周辺機器情報レコード (PDIR) 許可インジケーター |
| dataru[43] | [15, 0] | セッションの種類 2 または 3: クエリのサポート |
| dataru[44] | [24,1-7] | 動的画面サイズ |
| dataru[45] | [20, ] | 基本的な行サイズ |
| dataru[46] | [21, ] | 基本的な列サイズ |
| dataru[47] | [22, ] | 代替行サイズ |
| dataru[48] | [23, ] | 代替列サイズ |
注
10x00 = ブランケットは使用されていません。 0x01 = 角かっこが使用されている。
注
20x01 = ブラケットリセットの状態はBETB（ビトウィーンブラケット）です。 0x02 = ブラケットリセット状態は INB (角かっこ内) です。
注
これらの値は INTEGER 型です (それ以外はすべて CHAR 型です)。
Open(PLU) エラー応答と適切なセンス コードを送信することで、アプリケーションが Open(PLU) 要求 を拒否した場合 (たとえば、 バインド パラメーターが ネゴシエーション不可能な BIND で許容できない場合 ) は、開始 PLU シーケンスが 失敗する可能性があります。 ローカル ノードは、指定されたセンス コードを含む BIND 要求に対して否定応答をホストに送信します。 PLU 接続は Open(PLU) エラー応答の後に閉じられていると見なされ、ローカル ノードは Open(PLU) Confirm を生成しません。 次の図は、アプリケーションがOpen(PLU)要求を拒否したために、(交渉不可能なBIND)によりPLU接続が開かない状態を示しています。
開くことができませんでしたPLU接続
開く PLU シーケンスは、アプリケーションによって指定された BIND チェック テーブル エントリに対する BIND 検証が失敗した場合にも失敗する可能性があります。 この場合、ローカル ノードは次の処理を行います。適切なセンス コードを使用して 、BIND 要求に対する否定応答をホストに送信します。
Open(PLU) エラー確認をアプリケーションに送信します。最初のエラーコードとしてセンスコードの最初の単語を用い、二番目のエラーコードとしてエラーが発生したBIND パラメーターのインデックスを指定します。
PLU 接続は、 Open(PLU) エラー確認後に閉じられたと見なされます。 次の図は、 BIND 検証エラーによる PLU 接続の開き失敗を示しています。 エラー コード 2 では、 BIND パラメーターの RU のインデックスがエラーで示されることに注意してください。
BIND 検証エラーが原因で PLU 接続を開けないため