Resumen

  • RFC 1205 expuso la interfaz necesaria para llevar el flujo de un puesto IBM 5250 dentro de Telnet. Cliente y servidor tenían que acordar Binary, End-of-Record y Terminal-Type, además de leer un formato de registros heredado de IBM.
  • En el ejemplo Cancel Invite, el servidor ordena detener los datos ordinarios del usuario; el cliente confirma y aguarda una nueva lectura. El recorrido de System Request añade guardado de pantalla, menú, respuesta, restauración y reanudación de la entrada.

El teclado no tenía siempre la palabra

El detalle más revelador del RFC 1205 cabe en dos mensajes. El servidor envía Cancel Invite. El cliente devuelve la misma operación y deja de enviar datos del usuario hasta que llegue otra orden de lectura. El teclado sigue ahí, ante la persona. Dentro de la sesión, la aplicación del servidor decide cuándo puede incorporarse lo escrito. El documento lo llama una inversión del sentido normal del flujo.

La secuencia de System Request enseña por qué importaba ese control. Una tecla de petición del sistema provoca un indicador enviado por el cliente. El servidor retira la invitación vigente, pide guardar la pantalla, presenta un menú y recibe la elección mediante una operación Put/Get. Después restaura la pantalla anterior y emite una lectura Invite para recuperar el estado de trabajo. El usuario percibe una interrupción y un regreso. El protocolo registra quién dio permiso para cada parte.

La publicación respondía a una necesidad concreta: que un host en Internet pudiera atender un cliente Telnet que imitase una estación IBM 5250. El trayecto de red solo mueve octetos. No sabe si el octeto forma parte de un campo editable, de una orden para guardar la pantalla o de una tecla especial. La utilidad de la conexión dependía de que ambas máquinas compartieran las reglas del terminal, no solo una dirección de destino.

Tres acuerdos antes del primer registro

IBM no creó una opción nueva de Telnet para el modo 5250. Pidió que ambos extremos acordaran al menos Binary, End-of-Record y Terminal-Type. En el ejemplo, el servidor solicita la clase de terminal y el cliente responde IBM-5251-11. Los dos negocian después el envío de los finales de registro y de datos binarios en ambos sentidos. Estos acuerdos preparan la sesión. No autorizan por sí mismos a una persona ni describen el contenido de cada pantalla.

La variedad de terminales explica la pregunta por el tipo. La lista contiene pantallas de 24 por 80 y de 27 por 132, modelos en color y monocromos, y capacidad para caracteres de doble byte en algunos casos. El documento incluye también un intercambio Query Device: el servidor pregunta por atributos y el cliente responde. Una dirección IP no le dice al programa qué dimensiones tiene el área de trabajo ni qué caracteres puede mostrar.

Dentro de Telnet viaja un registro 5250 con su propia estructura. La cabecera tiene seis octetos fijos y una parte variable que en aquel momento ocupaba cuatro. La longitud lógica incluye la cabecera, se calcula antes de duplicar los octetos IAC para Telnet y deja fuera el IAC EOR que marca el final. Si un programa suma los octetos escapados como si fueran datos originales, leerá mal el inicio del siguiente registro. Los paquetes TCP pueden llegar cortados en otros puntos; el delimitador de la aplicación es el que manda aquí.

El pasado de SNA viajó en el sobre

La cabecera procedía de 5250 Display Station Pass-Through, una aplicación que IBM había usado con AS/400, System/36 y System/38 sobre SNA. Conservó incluso el valor de tipo General Data Stream. Llevarla por Telnet permitía mantener el modo de trabajo del host mientras cambiaba el transporte. Para quien construía un cliente nuevo, significaba aprender el formato heredado y no solo la negociación de Telnet.

El RFC remite al manual IBM 5250 Functions Reference Manual para el conjunto completo de órdenes y datos de pantalla. Su sección final corrige información errónea y añade funciones que la edición vigente aún no describía. Corrige, por ejemplo, el valor hexadecimal de Insert Cursor y aclara límites de filas y columnas. Un error en esas instrucciones puede arruinar la pantalla aun cuando la sesión haya negociado perfectamente Binary, EOR y Terminal-Type. La interoperabilidad no se compra al precio de tres respuestas WILL.

La interfaz pública y el lenguaje completo del terminal ocupaban documentos distintos. Eso delimitaba la oferta real: un tercero podía saber cómo iniciar y enmarcar el intercambio por Internet; para reproducir el comportamiento debía conocer también la gramática IBM. El host mantenía la última palabra sobre la entrada ordinaria mediante Invite y Cancel Invite.

Una invitación cancelada no rompía la línea

En el ejemplo breve, el servidor envía el código 0A, el cliente lo confirma y la entrada ordinaria espera hasta un nuevo comando de lectura. En el ejemplo extenso, el host abre una lectura para el menú con Put/Get y, al restaurar la pantalla, da un Invite final. Esa distinción evita confundir la pausa de la actividad normal con la imposibilidad absoluta de responder al menú. El servidor organiza los turnos y el cliente los obedece mientras transporta la sesión por Telnet.

RFC 1205 presenta la interfaz y los intercambios ilustrativos. No proporciona un registro de operación con fecha ni cifras de instalación; una captura de una sesión real mostraría qué hizo un host concreto. El diseño publicado ya deja una conclusión precisa. Una ruta común de Internet podía llevar los bytes de un terminal especializado, mientras la aplicación de origen seguía decidiendo cuándo correspondía escribir.

Fuente