How To
Summary
【Hints & Tips】z/OS 3.1よりOSAを介したSNA接続ができなくなり、Enterprise Extender（以下、EE）を利用したIP接続に移行するケースが増えています。これにより、サブエリアとAPPNが混在した環境が生まれます。本記事では、サブエリアとAPPNの混在環境におけるセッション確立の注意点についてまとめます。設定次第ではセッション確立に失敗しますのでご注意ください。
Objective
以下の条件を全て満たす環境が今回の注意対象になり、設定次第ではセッション確立に失敗します。
・サブエリアとAPPNが混在した環境になる場合
・APPNに配置されたVTAMにてDYNLU=YESを定義しない場合（デフォルトはNO）
*サブエリアとは？
SNAの接続形態。日本では主にホスト間のチャネル接続（CTC）に使われる。ホストのVTAMが接続経路を管理する。OSAを介したホストとサーバー、あるいはホストと端末の接続にも使われていたが、z/OS 3.1よりOSAを介したSNA接続は廃止されている。
SNAの接続形態。日本では主にホスト間のチャネル接続（CTC）に使われる。ホストのVTAMが接続経路を管理する。OSAを介したホストとサーバー、あるいはホストと端末の接続にも使われていたが、z/OS 3.1よりOSAを介したSNA接続は廃止されている。
*APPNとは？
サブエリアよりも後に出てきたSNAの接続形態。サブエリアとは異なり、接続機器同士が経路情報を交換し合うことで基本的には動的な接続を行う。サブエリアとの互換性はない。日本では利用実績は少ない。
サブエリアよりも後に出てきたSNAの接続形態。サブエリアとは異なり、接続機器同士が経路情報を交換し合うことで基本的には動的な接続を行う。サブエリアとの互換性はない。日本では利用実績は少ない。
概説
EEはAPPNを前提として機能します。日本ではAPPNの利用実績が少ないため、日本においてはEE化はAPPN化とセットで実施することが多いです。この時、APPN化はEEを適用する接続のみに行い、既存のホスト間の接続は従来型のサブエリア接続のままとすることがほとんどです。したがって、EE化することでサブエリアとAPPNが混在した環境になります。
EE化するVTAMはサブエリアとAPPNの境界に位置することになりますが、サブエリアとAPPNの境界に位置するVTAMのことをInterChange Node(ICN)と呼びます。ICNはAPPNが出てきた際、サブエリアからAPPNに移行する過渡期において作られており、経路選択としてAPPNを優先的に選択する傾向があります（図1）。APPNを優先的に選択する傾向については「詳細」にて後述します。
*ICNとは？
InterChange Nodeの略称。サブエリアとAPPNの両方の機能を併せ持ち、サブエリアからAPPN、あるいはAPPNからサブエリアへのセッション要求を媒介する。APPNを優先的に経路選択する傾向がある。ICNとして機能するVTAMは、VTAMスタート時にSYSLOGに「IST1348I VTAM STARTED AS INTERCHANGE NODE」と出力される。「D NET,VTAMOPTS」コマンドでも同メッセージを確認することができる。
InterChange Nodeの略称。サブエリアとAPPNの両方の機能を併せ持ち、サブエリアからAPPN、あるいはAPPNからサブエリアへのセッション要求を媒介する。APPNを優先的に経路選択する傾向がある。ICNとして機能するVTAMは、VTAMスタート時にSYSLOGに「IST1348I VTAM STARTED AS INTERCHANGE NODE」と出力される。「D NET,VTAMOPTS」コマンドでも同メッセージを確認することができる。
図1) 他VTAMからのセッション確立をICNが媒介する際のセッション確立経路の違い
図2) TN3270サーバーとのサブエリア接続をEE化した場合
図3) サーバーとのサブエリア接続をEE化した場合
注意点
【ICN以外のVTAMからのセッション確立要求をICNが媒介する場合(図1)】
ICNがセッション確立の途中経路になる場合、ICNはAPPN側で経路探索を行います。このときAPPN経路を辿って目的の資源まで探索できると、続いてAPPN経路を使用したセッション確立の処理に移ります。ICNを含めたAPPN側のVTAMにて、DYNLU=YES（デフォルトはDYNLU=NO）の設定がない場合、セッション確立は基本的には失敗します。
*CDRSCとは？
VTAMが他のVTAMに定義された資源を扱うための定義。クロスドメイン・リソースと言う。資源数が多い場合、全ての資源を定義するのは大変なため、動的にCDRSCを生成することも可能。
VTAMが他のVTAMに定義された資源を扱うための定義。クロスドメイン・リソースと言う。資源数が多い場合、全ての資源を定義するのは大変なため、動的にCDRSCを生成することも可能。
*DYNLUとは？
APPN接続にて動的CDRSCを利用するために必要な定義。動的CDRSCを利用するにはDYNLU=YESを設定する。DYNLU=NOを設定する場合、APPN経路上の全てのVTAMに静的なCDRSC定義が必要。
【TN3270サーバー配下の端末からのセッション確立要求をICNが媒介する場合(図2)】
ICNがセッション確立の途中経路になる場合、ICNはAPPN側で経路探索を行います。このときAPPN経路を辿って目的の資源まで探索できると、続いてAPPN経路を使用したセッション確立の処理に移ります。ICNを含めたAPPN側のVTAMにて、DYNLU=YES（デフォルトはDYNLU=NO）の設定がない場合、セッション確立は基本的には失敗します。
【サーバーとのセッション確立をICNが行う場合(図3)】
ICNは自身の資源に対してサーバーと1対1の関係でセッション確立を行うため、サブエリアとAPPNが混在する環境であってもサーバーと直接セッション確立を行います。サブエリアの時と経路が変わることはありません。ただし、サーバーが二つのVTAMに同時にAPPN接続している場合、「ICN以外のVTAMからのセッション確立要求をICNが媒介する場合」と同様の注意点は当てはまります。
ICNは自身の資源に対してサーバーと1対1の関係でセッション確立を行うため、サブエリアとAPPNが混在する環境であってもサーバーと直接セッション確立を行います。サブエリアの時と経路が変わることはありません。ただし、サーバーが二つのVTAMに同時にAPPN接続している場合、「ICN以外のVTAMからのセッション確立要求をICNが媒介する場合」と同様の注意点は当てはまります。
*補足
1つのVTAMが複数のサーバーとAPPN接続する場合(図4)、今回の注意点は当てはまりません。APPN経路で他のVTAMの資源が探索できるわけではないからです。
図4) VTAMが複数のサーバーとAPPN接続する場合
対応策
次のいずれかの対応を行います。
・ICNにてDYNLU=YESを定義する
DYNLU=YESを定義していれば、セッションは確立します。APPN経路に配置されたVTAMに対し、DYNLU=YESを定義します。DYNLU=YESはVTAMスタート・オプションに定義できますが、PU等にも個別に定義可能です。詳しい定義方法はマニュアル「SNA Resource Definition Reference」をご確認ください。
DYNLU=YESを定義していれば、セッションは確立します。APPN経路に配置されたVTAMに対し、DYNLU=YESを定義します。DYNLU=YESはVTAMスタート・オプションに定義できますが、PU等にも個別に定義可能です。詳しい定義方法はマニュアル「SNA Resource Definition Reference」をご確認ください。
・ICN以外のVTAMにてCDRSC定義を行う
ICNを経由しないようCDRSC定義にて接続先のCDRMを明確にすることも有効です。図1の例では、VTAM AにCDRSC大ノードを下記のように定義します。
ICNを経由しないようCDRSC定義にて接続先のCDRMを明確にすることも有効です。図1の例では、VTAM AにCDRSC大ノードを下記のように定義します。
CDRSCA VBUILD TYPE=CDRSC
APPB CDRSC CDRM=VTAMB
これにより、ICNを経由しないサブエリア接続が可能となるため、ICNにDYNLU=NOを定義していたとしてもサブエリア接続側でセッション確立が可能となります。
・ICN以外のVTAMにて静的ADJSSCPテーブルを使用する
サブエリアの経路探索はADJSSCPテーブルを使用し、テーブル上の上から順番に経路探索します。このADJSSCPテーブルを事前に作成しておき、ICNとなるVTAMをテーブルの最下部に定義することで、ICNへの経路探索の優先順位を下げることができます。事前にADJSSCPテーブルを作成しない場合、ADJSSCPテーブルは動的に作成されます（接続したVTAMの順番に上から定義されていく）。
サブエリアの経路探索はADJSSCPテーブルを使用し、テーブル上の上から順番に経路探索します。このADJSSCPテーブルを事前に作成しておき、ICNとなるVTAMをテーブルの最下部に定義することで、ICNへの経路探索の優先順位を下げることができます。事前にADJSSCPテーブルを作成しない場合、ADJSSCPテーブルは動的に作成されます（接続したVTAMの順番に上から定義されていく）。
ADJSSCPテーブルとは？
サブエリア接続において、探索対象となるVTAMを順に定義したもの。
サブエリア接続において、探索対象となるVTAMを順に定義したもの。
・APPNの代替経路を作らない
APPN経路を辿って目的の資源まで探索できない場合、つまり図1でいえばVTAM YとVTAM ZのAPPN接続がない場合、VTAM XはAPPNでの資源探索に失敗した後、サブエリアでの資源探索を行います。その後、サブエリアでのセッション確立が行われます。
APPN経路を辿って目的の資源まで探索できない場合、つまり図1でいえばVTAM YとVTAM ZのAPPN接続がない場合、VTAM XはAPPNでの資源探索に失敗した後、サブエリアでの資源探索を行います。その後、サブエリアでのセッション確立が行われます。
・ICNに静的CDRSC定義を行わない
DYNLU=NOであっても、ICNに静的CDRSC定義があるとAPPN経路を探索に行きます。この時、APPN経路上の全てのVTAMにおいて正しく静的CDRSC定義がない場合、セッション確立に失敗します。逆に言えば、ICNに静的CDRSC定義を行わなければAPPN経路を使用してセッション確立しようとはせず、サブエリア経路を使用してセッションを確立します。
・APPN経路上の全てのVTAMに静的CDRSC定義を行う
DYNLU=NOを利用する場合、APPN経路上の全てのVTAMに静的CDRSC定義が必要となります。接続元、接続先の全ての資源を静的CDRSCとして定義します。図1〜図3を例にすれば、VTAM X、VTAM Y、VTAM Zそれぞれに、接続元、接続先の全ての資源を静的CDRSCとして定義します。ただ、DYNLU=NOを利用するのはAPPNを経由して不必要にセッションを確立させないという意図があると思われますが、この対応を行うとAPPNを経由して不必要にセッションを確立することになるため、現実的には対応策になり得ないと考えます。
詳細
ICNの経路選択の特性は以下の通りです。
・ICNが他VTAMからのセッション要求を媒介する場合、ICNはまずAPPN経路を選択する
・ICNが自身からセッション要求をする場合、SORDERとSSCPORDの設定に応じて経路を選択する
・ICNが他VTAMからのセッション要求を媒介する場合、ICNはまずAPPN経路を選択する
・ICNが自身からセッション要求をする場合、SORDERとSSCPORDの設定に応じて経路を選択する
【ICNが他VTAMからのセッション要求を媒介する場合、ICNはまずAPPN経路を選択する】
ICNは他VTAMからセッション要求を受けた場合、ICN自身に該当リソースがなければ他VTAMにリソースを探索しにいきます。このとき、まずはAPPN経路を探索しにいきます。
ICNは他VTAMからセッション要求を受けた場合、ICN自身に該当リソースがなければ他VTAMにリソースを探索しにいきます。このとき、まずはAPPN経路を探索しにいきます。
・サブエリア → APPNで該当資源が見つかる場合(図4)
DYNLU=YES：
DYNLU=YES：
APPN経路でセッションが確立します。
DYNLU=NO：
ICNに静的CDRSC定義があるとAPPN経路を探索に行きます。図4の場合、VTAM XにAPP YのCDRSC定義があると、APPN経路を探索に行きます。この時、APPN経路上の全てのVTAMにおいて正しく静的CDRSC定義を行うことでセッションが確立します。図4を例にすれば、VTAM X、VTAM Y、VTAM Zそれぞれに、接続元、接続先の全ての資源を静的CDRSCとして定義します。一箇所でも静的CDRSC定義が誤っている場合、セッション確立は失敗します。逆に言えば、ICNに静的CDRSC定義を行わなければAPPN経路を使用してセッション確立しようとはせず、サブエリア経路を使用してセッションを確立します。
なお、静的CDRSC定義の不備によりセッション確立に失敗する場合、以下のセンスコードにてセッション確立に失敗します。
SENSE=08970015
SYSLOG例
IST663I CDINIT REQUEST TO EXP06 FAILED, SENSE=08970015
IST664I REAL OLU=EXPNET.GW01LU01 ALIAS DLU=EXPNET.TSO02
IST889I SID = D10386847ABC3679
IST1669I IPADDR..PORT 9.66.86.46..55714
IST891I EXPNET.EXP11 GENERATED FAILURE NOTIFICATION
IST314I END
図5) サブエリア → APPNで該当資源が見つかる場合
・サブエリア → APPN → サブエリアで該当資源が見つかる場合(図6)
DYNLU=YES：
サブエリアから一度APPNを経由し、再びサブエリアにセッション確立を行う場合、DISJOINT=YESの設定が必要になります（デフォルトはNO）。DISJOINT=NOの設定によりセッション確立に失敗する場合、サブエリア経路でのセッションが確立し、VTAM AはAPP Bを使用することができます（図7）。
DYNLU=YES：
サブエリアから一度APPNを経由し、再びサブエリアにセッション確立を行う場合、DISJOINT=YESの設定が必要になります（デフォルトはNO）。DISJOINT=NOの設定によりセッション確立に失敗する場合、サブエリア経路でのセッションが確立し、VTAM AはAPP Bを使用することができます（図7）。
既存のサブエリア環境においてDISJOINTを設定することはないため、APPNとの混在環境になった場合でもDYNLU=YESを設定しておくことで、APPN経路を一度探索するものの、セッション自体は引き続きサブエリア接続で繋がることになります。
*DISJOINTとは？
APPNをまたがってサブエリア間の接続をつなぐために必要な定義。サブエリア → APPN → サブエリアという経路でセッションを確立する場合、ICNにDISJOINT=YESを設定する。
APPNをまたがってサブエリア間の接続をつなぐために必要な定義。サブエリア → APPN → サブエリアという経路でセッションを確立する場合、ICNにDISJOINT=YESを設定する。
DYNLU=NO：
ICNに静的CDRSC定義があるとAPPN経路を探索に行きます。図5の場合、VTAM XにAPP BのCDRSC定義があると、APPN経路を探索に行きます。この時、APPN経路上の全てのVTAMにおいて正しく静的CDRSC定義を行うことでセッションが確立します。図5を例にすれば、VTAM X、VTAM Y、VTAM Zそれぞれに、接続元、接続先の全ての資源を静的CDRSCとして定義します。一箇所でも静的CDRSC定義が誤っている場合、セッション確立は失敗します。逆に言えば、ICNに静的CDRSC定義を行わなければAPPN経路を使用してセッション確立しようとはせず、サブエリア経路を使用してセッションを確立します。
なお、静的CDRSC定義の不備によりセッション確立に失敗する場合、以下のセンスコードにてセッション確立に失敗します。
SENSE=08970015
SYSLOG例
IST663I CDINIT REQUEST TO EXP06 FAILED, SENSE=08970015
IST664I REAL OLU=EXPNET.GW01LU01 ALIAS DLU=EXPNET.TSO02
IST889I SID = D10386847ABC3679
IST1669I IPADDR..PORT 9.66.86.46..55714
IST891I EXPNET.EXP11 GENERATED FAILURE NOTIFICATION
IST314I END
図6) サブエリア → APPN → サブエリアで該当資源が見つかる場合
図7) サブエリア → APPN → サブエリアで該当資源が見つかる場合の実際のセッション確立経路（DYNLU=YES、DISJOINT=NOの場合）
【ICNが自身からセッション要求をする場合、SORDERとSSCPORDの設定に応じて経路を選択する】
ICNが自身からセッション要求をする場合、SORDERとSSCPORDの設定に応じて経路を選択します。それぞれの設定値における経路選択の順序は表1のとおりです。
ICNが自身からセッション要求をする場合、SORDERとSSCPORDの設定に応じて経路を選択します。それぞれの設定値における経路選択の順序は表1のとおりです。
表1) SORDERとSSCPORDの設定による経路探索順序
出典：White Papers "Searching In Mixed APPN and Subarea Networks"
-以上-
Document Location
Worldwide
[{"Type":"MASTER","Line of Business":{"code":"LOB35","label":"Mainframe SW"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSSN3L","label":"Communications Server for z\/OS"},"ARM Category":[{"code":"a8m0z0000001jShAAI","label":"Comm Server DSD AIX V7"},{"code":"a8m0z0000001jSmAAI","label":"Comm Server DSD Linux V7"}],"ARM Case Number":"","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"All Versions"}]
Was this topic helpful?
Document Information
Modified date:
20 April 2025
UID
ibm17230243