Resumo

  • O RFC 1205 documentou uma interface para levar o fluxo de uma estação IBM 5250 pelo Telnet. Cliente e servidor precisavam concordar com Binary, End-of-Record e Terminal-Type e interpretar um registro herdado do sistema de passagem de telas da IBM.
  • No exemplo de Cancel Invite, o host manda parar os dados comuns do usuário; o cliente confirma e espera nova leitura. O caso de System Request mostra o host salvando a tela, oferecendo um menu, recebendo uma resposta, restaurando a tela e retomando a entrada normal.

Quem tinha a palavra era o host

Há um momento no RFC 1205 em que a infraestrutura desaparece atrás de um verbo simples: convidar. Uma estação é considerada “convidada” quando o servidor enviou um comando de leitura. Se o servidor transmite Cancel Invite, o cliente devolve a operação e deixa de mandar dados do usuário até receber outro comando de leitura. O teclado não some da mesa; o fluxo do aplicativo é que fecha a porta para a digitação ordinária.

O exemplo de System Request põe a regra em movimento. O usuário pressiona a tecla correspondente e o cliente informa isso por um bit. O host cancela o convite em vigor, pede que a tela seja salva, mostra um menu e recebe a escolha por meio de Put/Get. Quando termina, devolve a tela guardada e emite um novo Invite para restaurar a condição anterior. A resposta ao menu passa por uma leitura específica do host. Durante a sequência, o caminho de rede continua transportando registros; o que muda é o estado de participação do terminal.

P. Chmielewski escreveu a especificação para quem quisesse implementar um cliente capaz de emular uma estação 5250 conectada a um host pela Internet. A finalidade era prática: programas de Telnet precisavam falar com aplicações que esperavam comandos de tela, campos editáveis e teclas especiais. Um canal de bytes não informa sozinho se um sinal representa texto digitado ou pedido de sistema. O acordo útil tinha de chegar ao nível da estação de trabalho.

Três opções conhecidas antes de qualquer tela

A IBM não criou uma opção nova de Telnet para o modo 5250. O documento exigia ao menos a concordância dos dois lados sobre Binary, End-of-Record e Terminal-Type. No diálogo ilustrativo, o servidor pergunta o tipo de terminal e o cliente responde IBM-5251-11. Depois, em cada sentido, as máquinas acertam transmissão binária e marcadores de fim de registro. São as condições para começar a interpretar o fluxo 5250; a identidade do usuário e o desenho dos campos na tela pertencem a outras partes do sistema.

O catálogo de tipos já mostra por que a negociação importava. Havia telas de 24 linhas por 80 colunas e de 27 por 132, modelos coloridos e monocromáticos, além de opções com caracteres de dois bytes. O host precisava saber que equipamento o cliente dizia reproduzir. O RFC traz também uma consulta Query Device: o servidor pergunta atributos e o cliente responde. O endereço da máquina na rede não informa o tamanho da tela que uma aplicação deve montar.

O registro 5250 entrava como carga dentro de Telnet. Um cabeçalho fixo de seis octetos vinha antes de uma parte variável, então com quatro octetos; depois chegava o fluxo da estação. O campo de comprimento incluía o cabeçalho, era calculado antes da duplicação de qualquer byte IAC por Telnet e excluía o IAC EOR final. Contar do jeito errado desloca o início do próximo comando. Pacotes TCP podem atravessar esse limite em qualquer lugar. O delimitador do registro era uma escolha do aplicativo, não do transporte.

O vocabulário antigo atravessou a nova ligação

O cabeçalho não nasceu para a Internet. Segundo o RFC, foi criado para 5250 Display Station Pass-Through, usado com AS/400, System/36 e System/38 sobre SNA. O tipo General Data Stream permaneceu no envelope. Essa continuidade poupava mudanças ao lado do host, mas transferia trabalho a quem escrevesse outro cliente. Era preciso compreender uma gramática anterior ao uso de Telnet.

O RFC remete ao IBM 5250 Functions Reference Manual para os comandos completos do fluxo da estação. A seção 5 corrige erros da edição então disponível e acrescenta funções ainda ausentes dela. Um exemplo concreto é o código hexadecimal de Insert Cursor, impresso incorretamente no manual; outro envolve limites de linha e coluna. Um cliente que erre esses detalhes pode negociar corretamente as três opções e ainda posicionar mal o cursor ou aceitar a entrada no lugar errado. A documentação de rede e a documentação da tela eram peças da mesma compatibilidade.

O resultado é mais interessante do que a fórmula “terminal antigo na Internet”. O transporte era conhecido, a interface de passagem foi publicada e o comportamento de tela continuou ancorado no vocabulário da IBM. Para o host, essa era uma forma de oferecer acesso sem trocar a lógica do aplicativo. Para o desenvolvedor independente, a abertura real dependia da precisão do manual e das correções do RFC.

Cancelar o convite não desligava a sessão

O exemplo curto é inequívoco: servidor envia Cancel Invite, cliente confirma e dados comuns aguardam outro comando de leitura. No exemplo longo, o host assume o comando, abre uma resposta ao menu com Put/Get, restaura a tela e convida novamente a estação. Isso explica como a pessoa podia responder ao menu durante uma interrupção do trabalho anterior. O sistema não havia concedido liberdade geral para digitar qualquer coisa; tinha criado um novo turno de entrada com finalidade específica.

O RFC apresenta a interface e exemplos de fluxo, sem uma captura datada de operação ou uma contagem de instalações. Uma transcrição de registros associada ao estado da tela estabeleceria o comportamento em um local determinado. A escolha de projeto está escrita: a Internet levava a sessão, enquanto o host decidia quando o terminal podia falar com o aplicativo.

Fonte