Résumé

  • NETRJS permettait à un hôte distant de se comporter comme un terminal par lots virtuel auprès de l’IBM 360/91 de UCLA-CCN.
  • La soumission, la console opérateur et le retour des impressions passaient par des canaux distincts; les RFC révèlent aussi les limites de livraison.

Le résultat pouvait arriver après la déconnexion

Pour la personne qui attendait un calcul, NETRJS changeait surtout la manière d’attendre : le terminal distant n’avait pas à rester connecté jusqu’à l’impression. L’utilisateur envoyait son travail au Campus Computing Network de UCLA, se déconnectait, puis revenait chercher le résultat. La machine gardait le lot en file et renvoyait la sortie plus tard. Ce n’était pas une promesse de calcul instantané; c’était la possibilité de laisser l’ordinateur travailler sans réserver une session réseau jusqu’à la fin. L’unité utile n’était donc pas l’ouverture d’une connexion, mais le cycle complet, de l’envoi au retour du résultat.

Un terminal virtuel rendait le lot accessible par le réseau

Le RFC 740 de 1977 qualifie NETRJS de protocole privé, défini par UCLA-CCN pour soumettre des lots à un IBM 360 Model 91. Le même service RJS desservait aussi des terminaux à cartes reliés par des lignes directes. Il s’agissait donc d’un service de calcul particulier, accessible par plusieurs voies, et non de la preuve que tous les travaux d’ARPANET passaient par UCLA.

Le travail n’était fini qu’après livraison

L’extrémité distante était modélisée comme un Virtual Remote Batch Terminal. Ce terminal virtuel comprenait un lecteur de cartes pour les travaux entrants, une imprimante et une perforatrice pour les résultats, et une console opérateur pour les commandes, l’état, les erreurs et la connexion. Le travail arrivait sous forme d’images de cartes d’au plus 80 caractères, avec son langage de contrôle. Le serveur l’ajoutait à la file du système batch selon sa priorité puis renvoyait les sorties à l’imprimante ou à la perforatrice virtuelles. L’utilisateur pouvait attendre ou revenir ultérieurement.

Contrôle et données étaient séparés. La console utilisait une connexion Telnet bidirectionnelle; les flux du lecteur, de l’imprimante et de la perforatrice empruntaient chacun un canal simplex distinct. Le protocole prévoyait jusqu’à cinq connexions. Les canaux de données n’avaient besoin d’être ouverts que pendant leur usage et pouvaient fonctionner simultanément. Un processus distant pilotait ainsi un modèle de périphériques de traitement par lots, pas une session interactive de terminal.

Le service précède le RFC 740. RFC 88 le décrivait déjà en 1971; RFC 599 le mettait à jour en 1973; le document de 1977 remplaçait RFC 189 et RFC 599. L’actualisation de 1973 conserve un relevé rare : en octobre, UCLA-CCN avait soumis 1 373 travaux via NETRJS; 1 105 avaient été imprimés et aucun perforé. Le RFC compte 49 400 cartes lues, 822 900 lignes et 18 907 pages imprimées, pour 393,6 heures de connexion. Ces nombres portent sur un service et un mois, pas sur tout l’ARPANET. Le document jugeait assez courant un travail moyen de 360 lignes d’entrée (« cartes ») et 745 lignes de sortie réparties sur 17,1 pages.

Ces totaux ne garantissaient pas que le résultat soit bien arrivé. RFC 599 décrit le problème surnommé « squish » : avec les tampons NCP, la machine batch pouvait supprimer un court fichier de sortie avant que son premier message n’atteigne l’hôte distant. Une panne ou une annulation côté distant pouvait alors laisser l’utilisateur sans copie récupérable. UCLA a corrigé le problème en attendant l’accusé RFNM de fin de données avant de demander à RJS de supprimer la sortie. L’achèvement traversait donc deux frontières : le calcul et la livraison.

Les jeux de caractères formaient une autre frontière. L’IBM 360 de UCLA traitait l’EBCDIC; certains hôtes distants utilisaient ASCII. En 1972, des utilisateurs de RAND, Utah et Illinois ont signalé les défauts de la table de correspondance initiale. UCLA l’a modifiée et en a ajouté une autre. Le RFC 740 permettait au terminal virtuel de choisir EBCDIC, ASCII-68 ou ASCII-63, avec conversion des cartes entrantes et des impressions lorsque nécessaire.

NETRJS changeait la place de l’utilisateur dans le temps du calcul : envoyer les cartes, se déconnecter, puis reprendre le résultat quand il était prêt. Le travail pouvait attendre dans une file pendant que la liaison n’était plus occupée; cette liberté ne supprimait ni l’attente de calcul ni le risque de perte en transit. Les RFC rendent ce service concret : entrée des cartes, ordonnancement, récupération des sorties et confirmation avant suppression. L’ARPANET rendait le centre informatique accessible à distance; le protocole faisait de cette distance un cycle de travail praticable.

Sources primaires