Terminaux d’ordinateur: mode bloc et mode caractère

Dans mon précédent article, j’ai parlé de l’histoire et de l’émergence des terminaux informatiques.

Pour approfondir un peu plus, examinons la manière dont ils communiquaient avec les mainframes. Fondamentalement, il y avait deux philosophies (ou peut-être que les «religions» pourraient être une meilleure description en fonction de la personne à qui vous parlez) qui déterminent la manière dont un terminal communique avec un hôte système. Il s’agissait d’appareils en mode verrouillé ou d’appareils «  intelligents  » et en mode caractère, ou d’appareils «  stupides  » et, pour confondre les choses, il y avait aussi une sorte de terminal qui pouvait fonctionner dans n’importe quel mode et basculer facilement entre eux. Quelles étaient les différences entre ces deux idées? Fondamentalement, lors de l’utilisation d’un terminal en mode bloc une fois que le système hôte avait configuré l’affichage de l’écran du terminal, l’opérateur pouvait saisir des données dans des «champs» sur l’écran sans interagir avec l’hôte. Lorsque l’opérateur a terminé, le terminal a collecté toutes les entrées et les a renvoyées à l’hôte sous forme de « bloc » de données. D’un autre côté, un terminal en mode caractère devait constamment envoyer et recevoir chaque frappe et chaque donnée vers et depuis le système hôte pendant le fonctionnement normal. Le terminal en mode caractère utilisait le système hôte pour effectuer toutes les validations des données entrées par l’opérateur. Chaque fois qu’une touche était enfoncée, le code de caractère de cette touche était envoyé au système hôte. Tout ce que faisait le processeur hôte a été interrompu pour qu’il puisse traiter le personnage et l’application, puis décider de l’action à entreprendre et enfin effectuer cette action. Il peut s’agir simplement de renvoyer le caractère au terminal ou d’agir sur l’un des caractères de contrôle qui peuvent avoir été envoyés. Les applications utilisant des terminaux en mode caractère nécessitaient une configuration laborieuse des affichages d’une manière qui permettrait à l’opérateur de les comprendre. . Cela impliquait de déplacer le curseur sur l’écran, d’activer et de désactiver les attributs de caractères et d’imprimer du texte à l’écran. Dans ces terminaux, tout se passe à l’emplacement actuel du curseur sur l’écran. À titre d’exemple simple, considérons le cas où nous voulons que l’opérateur saisisse un numéro de client, le valide et affiche le nom et l’adresse d’un client. En supposant que nous utilisons un terminal VT100, le système hôte enverrait initialement les données suivantes (notez que les données préfixées par Esc sont une séquence d’échappement, une commande spéciale utilisée par les terminaux): Esc [2J: – efface tout l’écranEsc [H: – Positionnez le curseur dans la partie supérieure gauche de l’écran. Echap [1m: – Activez Gras pour faire ressortir le message Non. depuis le client: écrivez le message pour que l’opérateur saisisse le dataEsc [0m: – Désactivez boldEsc [0; 9: – Déplacez le curseur à l’endroit où l’on veut voir le numéro de client Une fois tout cela fait, l’opérateur peut écrire le numéro de client, au fur et à mesure que chaque caractère est écrit, l’hôte reçoit le caractère avant qu’il ne soit affiché et le retournera au terminal pour apparaître à l’écran. Des caractères spéciaux sont utilisés comme retour arrière pour permettre une édition facile. Enfin, la touche Entrée indique que le numéro de client est complet. À ce stade, l’hôte a ce dont il a besoin pour voir si le client existe et afficher les détails de ce client en déplaçant le curseur comme ci-dessus et en imprimant les informations formatées. De toute évidence, dans un scénario du monde réel, la quantité de configuration d’écran impliquée était considérablement plus grande. Il devrait être clair que beaucoup de travail doit être fait au niveau de l’hôte pour toute application utile, et qu’il a fallu beaucoup de temps aux développeurs pour créer des applications hôtes qui fonctionneraient avec des écrans utiles. Les terminaux en mode bloc avaient une intelligence locale limitée et adressaient l’écran comme une fenêtre vers un formulaire. Le formulaire n’avait pas besoin de tenir sur l’écran en une seule pièce, car l’opérateur pouvait déplacer les pièces hors de l’écran afin qu’elles puissent être consultées au besoin. Les terminaux en mode bloc peuvent avoir plusieurs pages dans lesquelles des données peuvent être saisies ou des données peuvent être affichées. L’opérateur a pu passer à différentes parties du formulaire et à différentes pages en émettant des commandes au terminal qui ont été traitées localement. Il y avait peu ou pas de participation de l’hôte pendant la phase de saisie des données. Prenons le cas d’un terminal en mode bloc, tel qu’un IBM 3279, utilisé sur des mainframes IBM plus anciens, tels que le System 360. Lors de l’interaction avec ce terminal, l’hôte enverrait d’abord un bloc de données au terminal représentant le formulaire à remplir, y compris une liste de caractères qui sont légaux dans chacun des champs. Une fois le formulaire affiché à l’écran, l’opér.