Кратко

  • DisplayableDlcAddress в RFC 2155 предназначался только для показа; фактические байты в заголовке следовало искать в MIB конкретного DLC.
  • Рабочее состояние, полученное через XID имя соседа, локальная подстановка, история исключений и успех сеанса имели отдельное происхождение и не выводились из заполненной строки.
  • Проверяемая запись связывает метку с экземпляром, типом DLC и RowPointer, байтами и областью, временем и состоянием, источником имени и результатом сеанса.

Хорошо оформленное поле не становилось ключом

Читаемую строку удобно перенести из консоли в инвентарную систему, и именно поэтому ее легко принять за устойчивый идентификатор. RFC 2155, опубликованный в июне 1997 года как Proposed Standard для APPN, заранее обозначил предел.

DisplayableDlcAddress содержал от нуля до 64 символов ASCII и должен был использоваться станцией управления только для отображения. «Настоящий» адрес DLC — байты, проходящие в заголовке канала, — часто находился в MIB конкретного DLC. «Часто» не означает всегда; отображение не обязательно ошибочно, но оно не определяет форму в канале. Пустая строка означала, что агент не знает адрес. Непустая не доказывала уникальность, свежесть, соседство или сеанс.

RowPointer передавал вопрос на компетентный уровень

Строки порта и link station содержали видимые адреса вместе с appnPortSpecific либо appnLsSpecific. RowPointer мог вести к объекту MIB нужного DLC; 0.0 означал, что агент не способен его определить. Для надежной корреляции нужны экземпляр APPN, тип DLC, указатель, интерфейс, нижележащий адрес и время сбора.

RFC 1747 показывает SDLC: адрес станции — poll-значение от 1 до 255, уникальное лишь в определенной области, а состояние контакта хранится отдельно. В RFC 2024 у DLSw встречаются иные формы: шестибайтовый MAC и четырехбайтовый IP в сетевом порядке. Одна экранная строка не сохраняет все такие кодировки и области.

Знакомое имя могло быть локальным ожиданием

appnLsAdjCpName мог содержать имя соседнего control point, принятое в XID. Если XID еще не получен, агент мог вернуть локально заданное значение; при отсутствии обоих — пустую строку. Одинаковое отображение означало либо наблюдение от соседа, либо ожидание оператора.

ID узла-партнера извлекался из четырех байтов XID и принимал ASCII 00000000, если был недоступен. Форма с пятью нулями в конце могла отмечать неуникальность на узле. Номер TG 256 означал «не согласован» или «неизвестен». Узнаваемый вид не создавал происхождения.

Текущее состояние, память и результат — разные записи

Link station могла быть неактивной, ожидающей активации, активной или ожидающей деактивации. Счетчики хороших и плохих XID, время активации и входа в текущее состояние были отдельными объектами. Адрес их не заменял.

Таблица статуса сохраняла исключительные или потенциально исключительные события активации, XID и завершения. Нормальная работа не создавала строку, а срок хранения определял продукт. Сохранившаяся строка подтверждает прошлое событие, не текущее соседство. RFC 2155 также не охватывал мониторинг и управление конечными сеансами: активный канал не доказывал успех APPN-сеанса или приложения.

Карточка RFC Editor и история Datatracker фиксируют статус документа. RFC 2455 заменил его в ноябре 1998 года после расширений APPN и опыта реализации, сохранив границу между показом и байтами заголовка. Тексты Heng Lu о приоритете работающего кода, минимальной начальной спецификации и слоях реальности используются как явно раскрытые редакционные рамки, а не требования RFC.

Источники