Resumo

  • RFC 1041 criou uma opção única, 3270-REGIME. RFC 1576 registrou sua adoção muito pequena e descreveu o arranjo que rodava: Terminal-Type, Binary e EOR negociados separadamente.
  • O trio definia emulação, octetos e fronteiras de bloco. Não permitia pedir um device/LU específico, ver o BIND SNA, receber respostas correlacionadas nem atribuir um significado universal a ATTN e SYSREQ.
  • TN3270E acrescentou nome de dispositivo, BIND-IMAGE e RESPONSES como funções distintas. Negociar a opção não garantia todas elas, autenticação ou resultado final.

A ponte prática não usou a entrada planejada

O 3270 não era apenas outro terminal de caracteres. Usava EBCDIC e organizava a comunicação em blocos. Modelo, tamanho da tela e recursos estendidos influenciavam o que a aplicação podia enviar. Colocá-lo sobre Telnet exigia combinar modo binário, limite de mensagem e emulação.

RFC 1041 propôs em 1988 concentrar essa transição na opção 29, 3270-REGIME. O cliente enviaria uma lista preferencial; o servidor escolheria um regime compatível. A escolha implicava Binary e IAC EOR; uma lista vazia retornava ao NVT ASCII.

A especificação também cuidava do instante da mudança. Durante a negociação, o cliente deveria suspender a entrada do usuário e o servidor evitar dados novos. Antes de confirmar, o servidor precisava escoar o que estava pendente. Cada lado trocava de parser em um evento definido, e buffers poderiam precisar de flush. O objetivo era impedir que bytes antigos fossem consumidos pela gramática nova.

O mecanismo elegante não ganhou a base instalada. RFC 1576 afirma que pouquíssimos desenvolvedores e fornecedores implementaram RFC 1041. O registro do RFC Editor o identifica como Informational, de janeiro de 1994. Isso não prova ausência absoluta nem mede o mercado; explica por que o documento descreveu outra convenção.

Três peças antigas viraram o regime de fato

Traditional TN3270 usava o Telnet básico, Terminal-Type, Binary Transmission e End of Record. O servidor solicitava um tipo e o cliente declarava uma emulação. Binary mantinha oito bits. EOR encerrava cada comando completo com IAC EOR.

Nenhuma opção isolada dizia que TN3270 estava pronto. A composição de seus estados criava o regime. RFC 1576 não exigia ordem fixa. Quando tipo apropriado, Binary e EOR estavam acertados, os blocos podiam circular. Se o servidor retirasse Binary ou EOR, o cliente voltava a interpretar os próximos dados como NVT ASCII.

O contrato comum era útil justamente por ser limitado. Binary protegia octetos; EOR definia framing; Terminal-Type escolhia apresentação. O gateway ainda decidia como chegar à aplicação por SNA ou por uma ligação não-SNA.

Tipo de tela não era nome de recurso

Terminal-Type era assimétrico. O servidor perguntava, e o cliente percorria alternativas. Ao responder, o cliente podia trocar sua emulação. O servidor que recebia o nome não era obrigado a mudar imediatamente o processamento.

Um tipo 3278 descrevia uma tela, não um dispositivo físico, uma pessoa ou a Logical Unit por trás do gateway. O sufixo -E sugeria structured fields e, para alguns servidores, atributos estendidos; a própria RFC registrava interpretações diferentes.

Em SNA, o terminal normalmente mantinha uma sessão com a aplicação e outra com o System Services Control Point. A interface TN3270 mostrava apenas uma conexão Telnet. Não havia mecanismo para o cliente pedir um 3270 device-name específico ou descobrir o LU name atribuído pelo servidor SNA. RFC 1576 chama o endereço IP do cliente de equivalente mais próximo disponível. Próximo não é igual: IP localiza uma ponta de rede; LU nomeia um recurso lógico do host.

Essa lacuna afetava comportamento real, porque aplicações centrais podiam tratar terminais de maneira diferente conforme seu nome de rede. Emulação correta não provava alocação correta.

EOR entregava a borda, não o resultado

Como o bloco 3270 não tinha um comprimento externo, EOR era indispensável. O receptor sabia onde um comando acabava e podia processá-lo. Não sabia se o processamento terminaria bem.

RFC 1576 inclui entre as funções ausentes as respostas positivas e negativas de SNA. A positiva indicava conclusão do processamento anterior. A negativa podia revelar comando inválido ou falha mecânica no cliente. Traditional TN3270 não devolvia esse recibo; o dado era presumido tratado ou ignorado.

Por isso, recebimento TCP, reconstrução binária, EOR, aceitação do comando, atualização de tela, impressão, ação da aplicação e atenção humana são fatos diferentes.

NOP ou Timing Mark tampouco fechavam a cadeia. Eles ajudavam a testar se a sessão ainda estava presente; NOP não exigia resposta da aplicação, e um cliente morto podia aparecer apenas como erro de envio TCP. Processo alcançável não é aplicação saudável nem pessoa presente.

ATTN e SYSREQ mostravam quem controlava a tradução

ATTN costumava pedir interrupção do processamento. Muitos clientes o mapeavam para Telnet BREAK; o servidor traduzia isso para o host. Um servidor não-SNA podia ignorar BREAK.

SYSREQ variava mais: alguns servidores usavam Telnet Interrupt Process, outros uma 3270 Test Request. Em SNA, a tecla alternava entre sessão da aplicação e sessão SSCP. Como o formato SSCP não atravessava diretamente TN3270, o gateway precisava processá-lo, convertê-lo ou deixar a função sem efeito.

Tecla pressionada, comando Telnet, tradução do servidor, evento SNA e interrupção da aplicação exigiam registros próprios. A primeira etapa não podia certificar as demais.

TN3270E separou as dívidas

RFC 1646 e RFC 1647 descreveram as primeiras extensões. RFC 2355, cuja ficha oficial mostra o Standards Track de 1998, consolidou TN3270E.

O novo option começava por device-type e, opcionalmente, resource/device-name. O servidor devolvia o nome alocado ou rejeitava com causa como nome desconhecido, dispositivo ocupado ou incompatibilidade. Em seguida vinha a negociação de FUNCTIONS.

BIND-IMAGE informava início e fim da sessão SNA com a aplicação. RESPONSES acrescentava header, política de resposta e sequência para correlacionar resultado positivo ou negativo ao bloco certo. SYSREQ e controles de impressão ficavam separados. A lista podia ser vazia, formando basic TN3270E.

Silêncio continuava ambíguo até conhecer a política: no response, resposta só em erro ou sempre. Sem RESPONSES, sequence number não servia como recibo. Sem BIND-IMAGE, o BIND não surgia apenas porque TN3270E foi aceito. Se a opção fosse recusada, o modo tradicional continuava disponível.

RFC 2355 também dizia que TN3270E não oferecia segurança além de Telnet comum. Alocação de device-name e autorização do usuário eram decisões distintas.

Código em execução não herda autoridade ilimitada

RFC 1041 mostra clareza formal sem adoção ampla; traditional TN3270 mostra compatibilidade instalada com evidência incompleta; TN3270E mostra como acrescentar recibos sem apagar fallback.

O ensaio de Heng Lu sobre primazia do código em execução exige olhar para o sistema que realmente atua. O texto sobre especificação mínima e decisão local explica o valor de uma composição pequena e voluntária. A análise das camadas de realidade impede que apresentação, sessão, identidade e resultado virem um único símbolo. É uma lente editorial posterior, não intenção atribuída aos autores.

Três opções fizeram a tela funcionar. O tipo nomeava a emulação, Binary preservava bytes e EOR fechava o bloco. LU, BIND, processamento, interrupção e consequência permaneciam aguardando sua própria evidência.

Fontes