Resumen

  • NETRJS permitía que un host remoto funcionara como terminal por lotes virtual para el IBM 360/91 de UCLA-CCN.
  • La consola, las tarjetas de entrada y la salida impresa usaban canales distintos; los RFC también documentan problemas reales de entrega.

El resultado podía llegar después de desconectarse

Un trabajo por lotes podía terminar cuando su autor ya no estaba conectado. Con NETRJS, una persona en un host remoto enviaba el trabajo al Campus Computing Network de UCLA, cerraba sesión y podía volver más tarde para recoger el resultado. ARPANET llevaba la entrada al ordenador y devolvía su salida. La unidad práctica era ese viaje completo, no el instante en que se abría una conexión.

Una terminal virtual llevó el lote a la red

El RFC 740 de 1977 llama a NETRJS un protocolo privado creado por UCLA-CCN para enviar trabajos por lotes a un IBM 360 Model 91. El mismo servicio RJS atendía terminales de tarjetas conectadas también por líneas directas. Era un servicio concreto accesible por más de una vía; no demuestra que todos los trabajos de ARPANET pasaran por UCLA.

El trabajo no terminaba hasta recibir la salida

El extremo remoto se representaba como una Virtual Remote Batch Terminal. Incluía un lector de tarjetas para los trabajos entrantes, una impresora y una perforadora para los resultados, y una consola de operador para iniciar sesión, enviar órdenes y recibir estados y errores. El trabajo llegaba como imágenes de tarjetas de hasta 80 caracteres con instrucciones de control. El servidor lo incorporaba al sistema por lotes según su prioridad y devolvía las impresiones o tarjetas perforadas a la terminal virtual de origen. El usuario podía esperar o volver después.

Control y datos viajaban separados. La consola usaba una conexión Telnet dúplex; el lector, la impresora y la perforadora tenían cada uno un canal simplex. El protocolo admitía hasta cinco conexiones entre los procesos cliente y servidor. Los canales de datos solo tenían que abrirse mientras se usaban, y los tres tipos de dispositivo podían operar a la vez. El host remoto manejaba así un modelo de periféricos por lotes, no una sesión interactiva de terminal.

NETRJS existía antes del RFC de 1977. RFC 88 lo describía en 1971; RFC 599 lo actualizó en 1973; RFC 740 reemplazó RFC 189 y RFC 599. La actualización de 1973 ofrece una rara fotografía operativa: en octubre, UCLA-CCN procesó 1.373 trabajos por NETRJS; 1.105 se imprimieron y ninguno se perforó. El documento registra 49.400 tarjetas leídas, 822.900 líneas, 18.907 páginas impresas y 393,6 horas de conexión. Son cifras de ese servicio en ese mes, no de toda ARPANET. RFC 599 considera bastante típico un trabajo medio de 360 líneas de entrada («tarjetas») y 745 líneas de salida en 17,1 páginas.

Esas cifras no garantizaban que el resultado llegara. RFC 599 describe un fallo llamado «squish»: con el almacenamiento intermedio de NCP, el ordenador por lotes podía eliminar un archivo corto antes de que el primer mensaje alcanzara la máquina remota. Si el host remoto fallaba o el usuario cancelaba la transmisión, podía perderse la única copia. UCLA corrigió el problema haciendo que NETRJS esperara la confirmación RFNM del fin de datos antes de pedir a RJS que descartara la salida. El trabajo debía cruzar dos fronteras: terminar el cálculo y entregar el resultado.

Los juegos de caracteres eran otra frontera. El IBM 360 procesaba EBCDIC, mientras que algunos clientes remotos usaban ASCII. En 1972, usuarios de RAND, Utah e Illinois señalaron defectos en la conversión inicial. UCLA modificó la tabla y añadió otra. El RFC 740 permitía elegir EBCDIC, ASCII-68 o ASCII-63 para la terminal virtual, y convertía las tarjetas entrantes y las impresiones salientes cuando correspondía.

NETRJS revela una Internet capaz de transportar trabajo programado, además de conversaciones en tiempo real. El usuario enviaba un trabajo estructurado; el servicio decidía cuándo ejecutarlo; los canales separados devolvían el producto. Los RFC muestran el contrato práctico: identificación, entrada de tarjetas, recogida de resultados, compatibilidad de caracteres y confirmación antes de borrar. La red hacía accesible el ordenador por lotes; el servicio hacía utilizable el ciclo entero.

Fuentes primarias