Resumo

  • DisplayableDlcAddress era destinado somente à exibição; os bytes reais do cabeçalho deveriam ser procurados na MIB específica do DLC.
  • Nome de CP, ID do parceiro, estado operacional, eventos históricos e sessão tinham origens e valores sentinela próprios, impossíveis de deduzir de uma string preenchida.
  • A prova útil encadeia rótulo, instância, tipo e ponteiro do DLC, bytes e escopo, estado com tempo, procedência XID e resultado de sessão.

Uma string conveniente não era uma chave

Uma tela organizada faz um valor parecer mais definitivo do que ele é. Na RFC 2155, publicada em junho de 1997 como Proposed Standard para APPN, DisplayableDlcAddress aceitava de zero a 64 caracteres ASCII. A estação de gerenciamento deveria usá-lo apenas para exibição.

O endereço DLC “real” — os bytes que circulam no cabeçalho — estava frequentemente disponível na MIB própria do DLC. Isso não prometia disponibilidade em todo agente, nem declarava a string humana necessariamente errada. Dizia que ela não tinha autoridade para definir a forma no fio. Vazio significava endereço desconhecido pelo agente; preenchido não significava único, atual, adjacente ou com sessão bem-sucedida.

O RowPointer preservava a fronteira

As linhas de porta e de estação de enlace traziam endereços visíveis ao lado de appnPortSpecific ou appnLsSpecific. Os RowPointer levavam a objetos específicos do DLC; 0.0 indicava que o agente não conseguia identificá-los. A correlação correta exige instância APPN, tipo do DLC, ponteiro, interface, endereço inferior e horário.

A RFC 1747 mostra o SDLC: o endereço da estação é um valor de polling entre 1 e 255, único dentro do escopo definido, enquanto o contato possui estado separado. A RFC 2024 mostra formas DLSw diferentes, inclusive MAC de seis bytes e IP de quatro bytes em ordem de rede. Uma string agradável não preserva sozinha todos esses formatos e escopos.

O nome conhecido podia ter sido configurado aqui

appnLsAdjCpName podia refletir o nome do ponto de controle recebido no XID. Antes de receber XID, o agente podia devolver um valor definido localmente; sem ambos, devolvia vazio. Assim, a mesma aparência visual podia representar observação do par ou expectativa do operador.

O ID do nó parceiro vinha de quatro bytes do XID e usava 00000000 quando indisponível. Uma convenção com cinco zeros finais podia assinalar que o identificador não era único no nó. O TG 256 significava não negociado ou desconhecido. Familiaridade não era procedência.

Estado atual, memória e resultado não se confundem

A estação de enlace tinha estados inativo, aguardando ativação, ativo e aguardando desativação. Contadores de XID bons e ruins, instante da ativação e entrada no estado atual apareciam separadamente. O endereço não resumia nada disso.

A tabela de status guardava eventos excepcionais ou potencialmente excepcionais de ativação, XID e encerramento. Operação normal não criava linha, e retenção era escolha do produto. Uma linha persistente é memória, não adjacência corrente. Além disso, a RFC 2155 excluía monitoramento e controle de sessões de ponta; enlace ativo não prova sessão APPN nem êxito da aplicação.

O registro do RFC Editor e o histórico no Datatracker situam o documento. A RFC 2455 o tornou obsoleto em novembro de 1998 após ampliações arquiteturais e experiência de implementação, mas preservou a distinção entre exibição e bytes do cabeçalho. Os textos de Heng Lu sobre primazia do código em execução, especificação inicial mínima e camadas da realidade são lentes editoriais declaradas, não obrigações da RFC.

Fontes