要約

  • RFC 2155 の DisplayableDlcAddress は管理端末での表示用であり、DLC ヘッダーの実バイトは DLC 固有 MIB で確認する構造だった。
  • 隣接 CP 名は XID 由来とは限らずローカル設定の場合があり、履歴行は現在状態ではなく、アクティブなリンクもセッション成功を意味しない。
  • 検証可能な記録には、表示文字列だけでなく、APPN インスタンス、DLC 種別とポインター、実バイトとスコープ、時刻付き状態、相手情報の由来、セッション結果が必要になる。

画面の整然さが生む誤解

運用画面で同じ文字列が繰り返し現れると、それを不変のキーとして扱いたくなる。RFC 2155 は 1997 年 6 月、APPN の管理オブジェクトを定める Proposed Standard として、その誘惑に明確な制限を置いた。

DisplayableDlcAddress は 0〜64 文字の ASCII 文字列で、管理端末は表示にのみ用いる。データリンク・ヘッダーを流れる「実際の」DLC アドレスは、多くの場合、DLC 固有の MIB で得られる。常に得られるという保証ではなく、表示値が必ず誤りだという意味でもない。表示値には回線表現を確定する権限がない、という境界である。空文字列はエージェントが不明とする値だが、非空であっても一意性、鮮度、隣接、セッション成立は生まれない。

ポインターの先で証拠の所管が変わる

APPN のポート行とリンク局行は、ローカル／リモートの表示アドレスに加えて appnPortSpecific または appnLsSpecific を持つ。RowPointer が該当 DLC のオブジェクトを示し、識別できないときは 0.0 となる。正しい照合には APPN インスタンス、DLC 種別、ポインター、インターフェース、下位アドレス、採取時刻を一組で残さなければならない。

RFC 1747 の SDLC MIB では、リンク局アドレスは 1〜255 のポーリング値で、定義された範囲内でのみ一意である。接触状態は別オブジェクトだ。RFC 2024 の DLSw MIB には、6 バイト MAC やネットワークバイト順の 4 バイト IP という異なる形もある。一つの可読文字列だけでは、こうした符号化とスコープを保持できない。

見覚えのある名前は設定値かもしれない

appnLsAdjCpName は XID で受信した隣接コントロールポイント名を返し得る。しかし XID がまだ届いていなければ、ローカルに定義された値を返せる。どちらもなければ空文字列となる。同じ表示でも「相手から観測した」と「運用者が期待した」では証拠能力が違う。

パートナーノード ID は XID の 4 バイトに由来し、利用不能なら ASCII の 00000000 となる。末尾 5 桁をゼロにしてノード内で非一意だと示す規約もあった。TG 番号 256 は未交渉または不明である。馴染み深い見た目を、観測済みの一意な身元へ昇格させてはならない。

現在状態と履歴と結果を混ぜない

リンク局の稼働状態は、非アクティブ、アクティブ化待ち、アクティブ、非アクティブ化待ちに分かれた。成功／失敗 XID カウンター、アクティブ化時刻、現在状態へ入った時刻も別々である。アドレス文字列からそれらを推定することはできない。

ステータステーブルが保持したのは、アクティブ化、XID、終了時の例外または潜在的例外だった。正常動作では行が作られず、保持件数と期間は製品側の選択である。残存行は過去の出来事を示すが、現在の隣接を示さない。さらに RFC 2155 はエンドポイント・セッションの監視と制御を対象外とした。リンクがアクティブでも、APPN セッションやアプリケーション成功には別の観測が要る。

RFC Editor の記録と Datatracker の履歴が文書の位置を示す。1998 年 11 月、APPN の追加仕様と実装経験を反映した RFC 2455 が RFC 2155 を置き換えたが、表示専用という境界は残った。Heng Lu の実行コード優先、最小初期仕様、現実の層は、本稿で明示した編集上の視点であり、RFC の要件ではない。

出典