Résumé

  • Le RFC 1205 documente l’acheminement du flux d’un poste IBM 5250 par Telnet. Client et serveur doivent négocier Binary, End-of-Record et Terminal-Type, puis traiter des enregistrements issus d’une technique IBM antérieure de passage des écrans.
  • Quand le serveur envoie Cancel Invite, le client accuse réception et cesse de transmettre les données ordinaires de l’utilisateur jusqu’à une nouvelle commande de lecture. L’exemple de System Request montre une parenthèse plus longue : sauvegarde d’écran, menu, réponse, restauration et reprise.

Un réseau ouvert, un tour de parole distribué par l’hôte

Une touche enfoncée n’envoyait pas toujours aussitôt son caractère. Le RFC 1205 explique que le serveur pouvait transmettre l’opération Cancel Invite. Le client renvoyait cette opération, puis ne transmettait plus de données utilisateur tant que l’hôte ne l’avait pas de nouveau invité par une commande de lecture. La personne restait devant son clavier. Dans cette session, l’hôte fixait le moment où une saisie ordinaire pouvait franchir la connexion.

Le cas de System Request déroule ce principe comme une petite pièce de théâtre technique. Le client signale l’appui sur la touche correspondante. L’hôte annule l’invitation courante, fait enregistrer l’image de l’écran, présente un menu et reçoit la réponse par une étape Put/Get qu’il a lui-même déclenchée. Après le traitement, il restaure l’ancien écran et émet une lecture Invite qui ramène le poste à son état précédent. L’utilisateur voit un menu puis retrouve son travail. Derrière cette continuité visuelle, plusieurs changements de sens de circulation ont eu lieu.

L’interface était destinée aux hôtes Internet voulant prendre en charge le flux des postes 5250 dans Telnet. Le transport fournit un chemin vers l’ordinateur. Il ne dit pas où se trouve le champ modifiable sur l’écran, si une touche demande une opération système, ni où finit une commande. Ce sont des règles du terminal et de son application. La différence entre « connecté » et « utilisable » tenait donc à des accords précis entre les deux extrémités.

Trois options déjà connues, puis le vrai travail

IBM n’a défini aucune nouvelle option Telnet pour ce mode. Le RFC exigeait l’accord des deux côtés sur Binary, End-of-Record et Terminal-Type. Dans son dialogue d’exemple, le serveur demande le type de terminal et le client répond IBM-5251-11. Ils conviennent ensuite, dans les deux sens, de transmettre les marqueurs de fin d’enregistrement et les données binaires. Ces réponses ouvrent les conditions du mode 5250 ; elles ne remplacent pas la grammaire des écrans et des touches.

La liste des terminaux montre pourquoi le type importait. Certains affichages étaient de 24 lignes sur 80 colonnes, d’autres de 27 sur 132. Il y avait de la couleur, du monochrome et des modèles capables de traiter des caractères sur deux octets. Le RFC décrit aussi une requête Query Device et la réponse contenant les attributs du poste. Un serveur qui doit préparer un écran a besoin de cette information, pas seulement d’une adresse réseau.

Le contenu 5250 voyageait ensuite dans une enveloppe particulière. Une partie fixe de l’en-tête occupait six octets, suivie d’une partie variable de quatre octets à cette date. La longueur logique comptait l’en-tête, se calculait avant que Telnet ne double les octets IAC, et excluait le marqueur final IAC EOR. Une erreur dans ce calcul décale la lecture du prochain ordre d’écran. La frontière d’un segment TCP n’a aucune raison de tomber au même endroit que celle de cet enregistrement logique.

Une grammaire plus ancienne dans un transport nouveau

Le format d’en-tête venait du 5250 Display Station Pass-Through, utilisé sur SNA avec les systèmes AS/400, System/36 et System/38. La valeur de type General Data Stream y restait reconnaissable. Le choix permettait à l’hôte de conserver sa manière de traiter les écrans tout en passant par Telnet. Il donnait également au développeur du client une tâche supplémentaire : reproduire correctement une convention venue d’un autre environnement réseau.

Le texte ne prétend pas contenir toutes les commandes du 5250. Il renvoie au manuel IBM 5250 Functions Reference Manual pour le langage complet des écrans. Son cinquième chapitre corrige et complète même l’édition alors disponible. Il rétablit, par exemple, la valeur hexadécimale de l’ordre Insert Cursor et précise les limites de lignes et de colonnes. Un client qui lit la mauvaise valeur peut placer le curseur au mauvais endroit malgré une négociation Telnet impeccable. La documentation du passage réseau et celle de l’application devaient marcher ensemble.

Cette dépendance est le cœur historique de l’affaire. L’interface publiée rendait possible l’écriture d’un client 5250 dans le monde Internet. Le comportement du terminal demeurait réglé par le langage IBM et par les ordres de l’hôte. Une connexion universelle pouvait transporter un dialogue très particulier.

Le refus temporaire avait un mode d’emploi

L’exemple simple de Cancel Invite demande deux messages : ordre du serveur, confirmation du client. Les données ordinaires attendent alors la prochaine commande de lecture. Dans l’exemple plus long, le serveur ouvre une lecture propre au menu par Put/Get, puis restaure l’écran et invite de nouveau le poste pour reprendre la session normale. Dire seulement que « le clavier est bloqué » ferait perdre ce détail : le menu est une autre étape contrôlée par l’hôte, avec sa propre réponse attendue.

Le RFC fournit un protocole et des exemples, sans journal daté d’un poste effectivement utilisé ni inventaire d’installations. Une capture des échanges accompagnée de l’état de l’écran donnerait ce résultat pour un site précis. Le document suffit à établir le choix de conception de 1991 : Telnet livrait les enregistrements, mais l’ordinateur qui faisait tourner l’application restait maître de l’invitation à saisir.

Source