Le Decsystem-20 À L'UniversitÉ Columbia (1977-1988)

Source: http://www.columbia.edu/cu/computinghistory/dec20.html

Frank da Cruz et Christine Gianone

Frank da Cruz et Christine M. Gianone,

Regardez une vidéo récemment découverte du déclassement de l'un des DEC-20 de l'Université de Columbia en 1986 :

Une réminiscence non technique écrite en 1988 (à l'occasion du débranchement du dernier DECSYSTEM-20 de l'Université de Columbia) pour un livre de Digital Press qui devait commémorer les machines 36 bits de DEC avec une série d'articles, mais qui n'a jamais été publié. Modifications mineures, notes, glossaire, liens et formatage HTML ajoutés en janvier 2001 (plus des mises à jour mineures de temps à autre par la suite). Pour en savoir plus sur l'histoire de l'informatique à l'Université de Columbia, CLIQUEZ ICI .

REMARQUE : Cet article a été « slashdotted » le 18 janvier 2001 et a été lu par de nombreuses personnes sans aucune idée de ce dont il s'agit. Veuillez garder à l'esprit que ceci ne prétend pas être une introduction ou une explication des ordinateurs influents de la Digital Equipment Corporation (DEC) 36 bits de 1964 à 1988 ; il s’agissait plutôt d’un essai dans un livre dans lequel d’autres essais expliqueraient l’architecture et l’histoire de la technologie. Vous pouvez trouver quelques sites Web thématiques dans la section LIENS à la fin.

Pour ceux pour qui le concept d'ordinateur 36 bits semble étrange : le tout premier ordinateur commercial binaire (par opposition au décimal) était l' IBM 701 , mis en ligne pour la première fois en 1952. Il contenait un mot de 36 bits. Il a été suivi par le 704 (où le premier langage de haut niveau, Fortran, a été développé en 1953-57, et dont le jeu de caractères BCD de 6 bits et le mot de 36 bits expliquent la limite de 6 caractères sur les noms de variables Fortran), le 709 , le 7090 et le 7094 , tous 36 bits. Les machines IBM 36 bits ont été le berceau du LISP (*) et ( sans doute ) du temps partagé (Compatible Time Sharing System du MIT, CTSS, vers 1962) et ont également inspiréLe PDP-6 36 bits de DEC (1964), qui était le précurseur du PDP-10 et du DECSYSTEM-20 , a duré jusqu'en 1988, année où DEC a arrêté de fabriquer des machines 36 bits. Ainsi, les architectures 36 bits étaient des caractéristiques importantes (et à bien des égards dominantes) du paysage informatique de 1952 à 1988 : 36 ans.

List Processing Language, John McCarthy, Université de Stanford, 1960, toujours le langage principal pour la recherche sur l'intelligence artificielle. Les CAR et CDR de LISP sont des concepts IBM 704 : le contenu de la partie adresse du registre et le contenu de la partie décrémentation du registre — c'est-à-dire les moitiés gauche et droite du mot de 36 bits. Les machines 36 bits avec leurs demi-mots gauche et droit de 18 bits sont de parfaites machines LISP.

INTRODUCTION

Jusqu'au milieu des années 1970, l'Université de Columbia était fermement ancrée dans le calcul en mode batch OS/360 sur mainframe IBM. La zone « Entrée/Sortie libre-service » a été fièrement nommée parce qu'elle représentait un grand pas en avant par rapport à l'époque où les étudiants et les chercheurs présentaient docilement leurs jeux de cartes aux opérateurs et revenaient le jour ouvrable suivant pour leur sortie - généralement pour découvrir que leur SYSMSG était rempli de plaintes incompréhensibles, dont le déchiffrement pénible conduisait généralement l'utilisateur frustré à une virgule manquante ou à un espace supplémentaire dans le Job Control Language. Ou si le JCL réussissait l'inspection, alors il y avait une décharge de 3 pieds d'épaisseur avec laquelle se pelotonner. La zone SSIO était une pièce remplie de la cacophonie abrutissante des frappes sur les touches , des hurlements des redoutables 1403 imprimantes d'IBM., le battement saccadé des lecteurs de cartes , des trieurs de cartes et des interprètes ; des foules anxieuses se sont rassemblées autour des imprimantes, jusqu'à la taille sous les déchets...

L'IBM 360 modèle 91 de Columbia , avec son frontal 360/75, était l'un des ordinateurs les plus gros, les plus rapides, les plus lourds et les plus bruyants au monde lorsqu'il a été installé à la fin des années 1960. Il couvrait des hectares de surface au sol et vous pouviez regarder les noyaux magnétiques à travers les fenêtres des boîtes à mémoire de noyau de 6 pieds de haut , disposées en rangées qui disparaissaient dans le point de fuite. L'électricité était fournie par un moteur-générateur en fonte grondant aussi gros qu'un petit camion, et le refroidissement par de l'eau distillée réfrigérée (livrée de Deer Park dans de grandes bouteilles en verre dans des caisses en bois) pompée à travers des kilomètres de plomberie interne. Le panneau de contrôle du processeurIl y avait plus de lumières que Times Square. Selon la légende, parmi les milliers de boutons et de bascules, il y en avait un dont la mission mortelle était « Bulb Eject » – une mort certaine pour quiconque appuyait dessus. Le panneau de contrôle repose désormais [1988] au repos au Computer Museum de Boston, ses ampoules hypnotiques éteintes pour toujours ( 1 ).

Ce Stonehenge massif gris et bleu, ses épais tentacules s'étendant jusqu'à la zone SSIO, exécutait de lourds « codes » Fortran pour nos ingénieurs : ponts tournants ; bombarder des substances malheureuses avec des neutrons ; calculer Pi en millions de chiffres ; transformer le champ magnétique terrestre en musique... Pour nos spécialistes des sciences sociales, il prédisait année après année le résultat de l'élection présidentielle de 1956 avec une précision mortelle. Pour les administrateurs, cela a craché des chèques de paie, des relevés de notes et des états comptables. Et finalement, une petite partie a été attribuée à nos étudiants en ingénierie, appliquant leurs boucles DO et GOTO laborieusement conçues à la série de Taylor, à la règle de Simpson, à la quadrature de Gauss et à la transformée de Laplace. Ces étudiants avaient une tâche relativement simple : rédiger le programme, placez-le dans un sandwich de cartes JCL magiques, introduisez le sandwich dans le lecteur de carte et récupérez le résultat obtenu. De nombreux enseignants revenaient sur ces jours simples avec une tendresse mélancolique, même si les souvenirs des étudiants étaient davantage hantés par des images de doigts glissants ramassant des piles de cartes perforées tombées.

Les terminaux ont commencé à apparaître au début des années 1970, au début seulement parmi les programmeurs système obscurs d'Olympus, capables de converser dans des langages obscurs avec des « moniteurs de terminaux » portant des noms comme Milten, Cleo, Orvyl et Wylbur, et finalement APL. et TSO (le premier étant l'"Irtnog" des langages informatiques, le second une forme de JCL tapé sur son terminal). Interagir avec l’ordinateur était attrayant, mais insatisfaisant. Les commandes étaient obscures et le calcul était toujours – à l’exception de l’APL – dans le lot.

Entrez, en 1975, dans notre premier véritable système de partage de temps, un DEC PDP-11/50 exécutant le système d'exploitation RSTS/E. Il s’agissait d’une expérience à petit budget de véritable informatique interactive. Construit autour du langage BASIC, RSTS permettait à jusqu'à 32 utilisateurs simultanés assis sur DECwriters de programmer, déboguer, communiquer entre eux et généralement se comporter mal, le tout en temps réel. Le RSTS s'est avéré extrêmement populaire et le PDP-11 a rapidement été submergé par des étudiants enthousiastes.

DEC a été choisi parce qu'IBM n'offrait pas vraiment de partage de temps interactif à usage général à l'époque. Par rapport aux autres concurrents, l'offre DEC était mieux développée, plus mature et... plus amusante. Et RSTS a été choisi comme système d'exploitation, plutôt que, disons, UNIX, parce que la version 6 d'UNIX était un système de confiance puissant qui permettait à n'importe qui de faire n'importe quoi. Nous avions en germe l’idée selon laquelle le système devrait jouer un certain rôle dans la protection des utilisateurs les uns contre les autres et contre eux-mêmes. Alors qu'UNIX offrait peu ou pas de fonctionnalités dans ce domaine, RSTS n'était pas sans faiblesses. Les utilisateurs ont vite compris qu'ils pouvaient attribuer tous les ATS, afin que personne d'autre ne puisse les utiliser. Mieux encore, après avoir attribué un ATS, ils pourraient exécuter un programme dessus pour se faire passer pour le processus de connexion,

BIENVENUE T@\R\~~~~xxx }}}}}~~

D'autres utilisateurs ingénieux ont découvert que s'ils ouvraient un nouveau fichier pour un accès orienté enregistrement, ils pouvaient lire les enregistrements avant de les écrire, en récupérant les anciennes données des fichiers supprimés d'autres utilisateurs ou le fichier de mot de passe du système.

Et à un moment donné, notre système a été infesté par une cabale d'adolescents d'une école préparatoire voisine, qui s'étaient introduits par effraction en exploitant un bug dans le processus de connexion. Ils ont utilisé le système pendant plusieurs semaines avant d'être détectés, et il a fallu plusieurs jours de travail 24 heures sur 24 pour éradiquer les nombreuses trappes et bombes à retardement qu'ils avaient laissées derrière eux.

Malgré ses problèmes, RSTS s'est avéré très populaire et est rapidement devenu surchargé. L'expérience a été déclarée réussie et nous avons commencé à chercher quelque chose de plus grand et de plus sophistiqué, le BASIC n'étant pas exactement le langage de prédilection des informaticiens. C'est à peu près à ce moment-là que DEC a annoncé pour la première fois le DECSYSTEM-20 (son logo, tout en majuscules contrairement à celui de son cousin aîné le DECsystem-10)., il s'agirait d'un glissement de la touche Caps Lock sur la demande de marque). Avant même d'examiner le système, nous avons forcé les responsables marketing à apporter une aide technique et leur avons demandé sans pitié si les utilisateurs pouvaient attribuer tous les appareils, remplir le disque, contrôler-C hors du processus de connexion, se bombarder de messages. des messages stupides, même si un fichier a été « nettoyé » lors de sa suppression. Lorsque tout nous a paru satisfaisant, nous avons jeté un coup d’œil au système.

Émerveillement et étonnement, cet ordinateur sait ce que vous allez taper et le tape pour vous ! Eh bien, presque. Mais ses attraits étaient évidents au premier coup d’œil. Si vous ne savez pas quoi taper, tapez un point d'interrogation et il répertorie les possibilités pour vous. Soudain, le « remplir le blanc » est devenu davantage un « choix multiple ». Et bien sûr, cela peut vous le dire ! Il sait quels sont les choix, alors pourquoi ne devrait-il pas vous le dire ??? Une question qui aurait pu être posée avec avantage dix ou quinze ans plus tôt (visions de programmeurs système chevronnés parcourant manuel après manuel à la recherche de quoi taper dans le champ suivant d'une commande obscure... un spectacle courant sur certaines machines même pour ce jour). Et ça "?" n'était pas une fonction hautement privilégiée (comme l'était la possession du manuel) - même les UTILISATEURS ORDINAIRES pouvaient l'utiliser. Étonnés, nous avons découvert que les messages d'erreur apparaissaient sous forme de texte clair et compréhensible, plutôt que de nombres hexadécimaux à 17 chiffres, de sorte qu'ils pouvaient être compris sans livre de « messages et codes ».

Nous avons été immédiatement convaincus par la convivialité, l'attitude décontractée, l'humour. Nous n'avons su que plus tard que COOKIE (qui survit aujourd'hui sous UNIX sous le nom de « fortune ») n'était pas un élément standard du système, et puis il y a eu TECO ( 2 ) :

@faire l'amour

pas la guerre?

Le DEC-20 était un véritable système de temps partagé à usage général. Il n'a pas été construit autour d'un langage particulier, comme RSTS l'était autour du BASIC. Il offrait une large gamme de compilateurs, d'interprètes, d'éditeurs de texte et d'utilitaires, reflétant de nombreuses années de développement des logiciels TOPS-10 et TENEX. Il pourrait absorber non seulement nos utilisateurs RSTS, mais également un grand nombre de nos utilisateurs mainframe IBM Fortran et APL, et sa facilité d'utilisation attirerait également de nombreux nouveaux utilisateurs.

Notre nouveau DEC-20 est arrivé le 29 juin 1977, avec TOPS-20 version 1B. L'installation était terminée le 26 juillet. À côté de l'IBM 360/91, et même du DEC PDP-11, il était malheureusement sans caractéristiques : pas de lumière à proprement parler, pas de commutateurs pour saisir les données, pas de cadrans, pas de moteurs, pas de pompes... Pourtant, le DEC-20 était infiniment plus puissant que le faible PDP-11. Il était équipé de quatre lecteurs de disque RP06 ( 3 ) de pointe qui ne pourraient jamais se remplir, et d'une incroyable mémoire principale de 256 Ko – des mots, pas des octets ! Une telle machine répondrait à nos besoins informatiques pédagogiques pour les années à venir.

Chaque fois qu'une installation informatique se dote d'un nouveau type d'ordinateur, les programmeurs se lancent immédiatement dans une furieuse vague d'activités pour transformer le nouveau système en leur ancien système bien-aimé. Tel qu'il a été livré, le seul éditeur du DEC-20 (outre une copie non officielle de TECO) était l'EDIT énigmatique, orienté ligne, descendant du TOPS-10 SOS. Nos utilisateurs étaient habitués à Wylbur, l'éditeur de ligne beaucoup moins énigmatique de notre IBM 360/91, nous nous sommes donc immédiatement lancés dans l'écriture d'une version de Wylbur pour le DEC-20, afin que nos utilisateurs IBM se sentent plus à l'aise.

Nous avons commencé à apprendre le langage assembleur DEC-20 et à lire le manuel de référence des appels Monitor. Nous avons vite découvert qu’il s’agissait en effet d’une machine merveilleuse. Le jeu d'instructions et le répertoire d'appels de moniteur (JSYS) étaient incroyablement riches. Parmi les appels du moniteur figurait un ensemble spécial, différent de tout ce que nous avions jamais vu : intégré au système d'exploitation lui-même, des fonctions standard de conversion entre les représentations internes et externes de tous les différents types de données significatives pour le système : des nombres dans différentes bases, caractères, chaînes, noms de fichiers, noms de répertoires, dates et heures. Les programmeurs d'une époque antérieure savaient que la partie la plus difficile et la plus fastidieuse de l'écriture d'un programme interactif était de demander, d'accepter et de valider les données saisies par l'utilisateur.

Mieux encore, ces fonctions de conversion ont été regroupées dans un seul package appelé COMND JSYS, développé par Dan Murphy , qui a permis aux programmeurs d'utiliser la même « interface utilisateur » dans leurs programmes que celle du TOPS-20 Exec : complète. incitation, édition, aide dans tous les domaines ; abréviation et reconnaissance de mots-clés et de commutateurs ; complétion des noms de fichiers ; pardon lorsque l'utilisateur fait une faute de frappe, etc.

Les programmes codés avec COMND JSYS avaient de nombreuses vertus. Ils étaient sympathiques, serviables et cohérents. Tous les programmes écrits avec COMND fonctionnaient de la même manière : tapez "?" pour savoir quelles sont les commandes ou les options, tapez ESC pour compléter le champ actuel (si possible) et recevez une invite pour le champ suivant. Les gens pourraient utiliser le "?" et ESC dispose généreusement de fonctionnalités pour apprendre à se frayer un chemin à travers un nouveau programme, et plus tard, pourrait taper des commandes laconiques et abrégées pour la vitesse. Cette approche, appelée « menu à la demande », ne favorise pas le novice par rapport à l'expert (comme le font les systèmes orientés menu), ni l'expert par rapport au novice (comme le font les jeux de commandes énigmatiques et laconiques d'APL ou d'UNIX).

Notre nouvel éditeur de type Wylbur, appelé "Otto", a été écrit pour tirer pleinement parti du COMND JSYS. Malgré toutes ses limitations tenaces, Otto a connu un succès immédiat car il a permis aux utilisateurs de mainframe IBM de migrer sans douleur vers le nouvel environnement, tout en les endoctrinant simultanément à la manière du DEC-20. Son but caché était de les rendre accros, puis de les frustrer suffisamment pour qu'ils prennent le temps d'apprendre un « vrai » éditeur.

[ Haut ] [ Suivant ]

LANGAGES DE PROGRAMMATION

Au fil des mois, nous avons pris contact avec d'autres sites DEC 36 bits, dont beaucoup - Stanford, CMU, MIT, Rutgers, BBN, SRI - avec de nombreuses années d'expérience TOPS-10, TENEX, WAITS ou ITS, et reçu d'eux des programmes qui allaient nous occuper pendant des années. Certains étaient des faux départs, mais d’autres prospéreront sous une forme ou une autre jusqu’au siècle prochain, héritage des 10e et 20 décembre. De cette expérience, nous avons appris les avantages du partage et savions que si jamais nous devions produire quelque chose d'utilité générale, nous le partagerions avec d'autres dans le même esprit que ces institutions partageaient leur travail avec nous.

Notre objectif principal en parcourant ces sites était de découvrir ce qu'ils faisaient en matière de programmation. Lors de leur conception, les interfaces utilisateur et système du DEC-20 étaient aussi proches de la perfection que quiconque à l'époque (en dehors de Xerox PARC) pouvait l'imaginer, mais dans la pratique, la conception n'a pas été complètement réalisée. La plupart des langages de programmation provenaient directement de TOPS-10 et ne donnaient pas accès aux appels du moniteur TOPS-20 ou à son système de fichiers. Et pourtant, nous étions déterminés à ne pas écrire de code au niveau système en langage assembleur à l’ère de la programmation structurée. Après de brefs flirts avec Bliss-10, BCPL, Simula et même un premier Portable C (qui n'était pas adapté à l'architecture 36 bits), nous avons choisi Sail de l'Université de Stanford comme "langue officielle", Mais plusieurs années de dévouement à Sail se sont finalement soldées par une désillusion. Il y avait trop de bugs, trop de dépendance au système d'exécution et de savoir où il se trouvait, trop de conversions nécessaires lors des nouvelles versions de Sail ou de TOPS-20, trop de solutions de contournement grotesques pour accomplir ce qui aurait été naturel en assembleur - le seul langage qui comprenait vraiment la machine et le système d'exploitation. Et à partir de ce jour, toute la programmation de nos systèmes a été réalisée en assembleur. Mais plusieurs années de dévouement à Sail se sont finalement soldées par une désillusion. Il y avait trop de bugs, trop de dépendance au système d'exécution et de savoir où il se trouvait, trop de conversions nécessaires lors des nouvelles versions de Sail ou de TOPS-20, trop de solutions de contournement grotesques pour accomplir ce qui aurait été naturel en assembleur - le seul langage qui comprenait vraiment la machine et le système d'exploitation. Et à partir de ce jour, toute la programmation de nos systèmes a été réalisée en assembleur.

Comme beaucoup de choses, la dépendance à l’assembleur est bonne et mauvaise. C'était bien parce que cela touchait un nerf créatif : les programmeurs étaient libres, libres des exigences bureaucratiques et des restrictions autoritaires des langages de haut niveau, et ils avaient un accès complet au jeu d'instructions de la machine et au répertoire d'appels de moniteur, qui, sur le DEC- 20, étaient une joie à voir. La programmation en assembleur était tout simplement amusante, et nos programmeurs produisaient joyeusement des millions de lignes de code, mais avec le sentiment tenace qu'il y avait quelque chose de pécheur là-dedans. Cela était dû au mauvais côté : les programmes en langage assembleur sont spécifiques à la machine et au système d’exploitation sous-jacents. Qu'arrive-t-il à ces programmes lorsque la machine disparaît ?

Néanmoins, MACRO était irrésistible (MACRO est utilisé ici comme un terme générique, englobant les MACRO-10 et -20 de DEC, ainsi que Midas du MIT et FAIL de Ralph Gorin). Contrairement à FORTRAN ou BASIC ou à tout autre langage sur le DEC-20 (sauf Sail, pour lequel nous avions écrit un package d'interface COMND JSYS), MACRO vous a permis d'écrire de vrais programmes DEC-20 — des programmes utiles, doux et indulgents pour l'utilisateur. Pour les programmeurs en langage assembleur ayant une expérience IBM 360, l’architecture de la machine et le jeu d’instructions étaient délicieux. Un espace d'adressage linéaire de 256 Ko mots (plus de BALR et USING !), des centaines d'instructions exotiques... Et l'assembleur lui-même permettait de réaliser des programmes relativement propres, voire "structurés". Par exemple, les littéraux en ligne de MACRO sont presque équivalents aux blocs « début… fin » d’Algol ou de Pascal, évitant ainsi l’horrible logique spaghetti qui sévit dans la plupart des programmes en langage assembleur. Par exemple, voici une construction IF-THEN-ELSE avec plusieurs instructions dans chaque partie, et sans GOTO ni étiquette (excusez les erreurs, c'est de mémoire) :

CAIL B, FOO ; SI (b >= foo) ALORS

PUSHJ P, [ ; COMMENCER

HRROI A, [ASCIZ/.LT./] ; message = ".LT.";

SÉTOM MOINS ; moins = -1 ;

AOS (P) ; FIN (sauter la partie ELSE)

POPJP, ] ; AUTRE

PUSHJ P, [ ; COMMENCER

HRROI A, [ASCIZ/.GE./] ; message = ".GE.";

SETZM MOINS ; moins = 0 ;

POPJP, ] ; FIN;

PSOUT ; IMPRIMER le message ;

Tout ce qui est entre crochets est un littéral ; l'assembleur trouve un endroit pour le mettre et remplace le littéral par l'adresse de cet endroit. Ainsi, (presque) n'importe quelle quantité de données ou de code peut être placée "en ligne", plutôt que dans une zone de données séparée. Et comme vous pouvez le voir dans l'exemple, les littéraux peuvent être imbriqués. D'autres structures de contrôle courantes peuvent également être simulées à l'aide de littéraux, telles que l'instruction CASE :

DÉPLACER B, @[EXP FOO, BAR, BAZ](A)

Cet exemple stocke B dans FOO, BAR ou BAZ, en fonction de la valeur de A. Une telle opération nécessiterait de nombreuses lignes de code dans la plupart des autres langages assembleur et dans la plupart des langages de haut niveau.

Pour couronner le tout, les programmes en langage assembleur pourraient être débogués de manière interactive à un niveau symbolique en utilisant le "DDT" - non pas le dichloro-diphényl-trichloroéthane, mais un "outil de débogage dynamique" conçu pour éliminer les bogues aussi efficacement que les vrais, avec moins d'effets secondaires indésirables (d'autres aides au débogage portaient des noms d'insecticides similaires, comme RAID). Avec DDT ( 4), il n'est plus nécessaire de fouiller dans les épais imprimés hexadécimaux, plus besoin d'insérer des instructions d'impression et de réassembler, etc. Sa syntaxe de commande est un peu abstruse, composée principalement de lettres simples énigmatiques, de signes de ponctuation, de tabulations et d'une utilisation libérale de l'ESC. Caractère ("Altmode"), souvent doublé. Mais le DDT peut tout faire. En fait, comme il peut exécuter toutes les instructions informatiques et tous les services système, les créateurs du « système de partage de temps incompatible » (ITS) du MIT pour le PDP-10 l'ont utilisé comme interpréteur de commandes de niveau supérieur. Parlez de convivialité...

Le jeu d'instructions DEC-10/20, les appels de surveillance, l'assembleur et le débogueur ont attiré de nombreux programmeurs autrement sensés dans des sessions de codage prolongées, ou des « attaques de piratage ». Une sous-culture de programmeurs DEC-10/20 est née, parlant des mots et des phrases étranges dont les étymologies étaient principalement attribuables au manuel de référence du matériel PDP-10. L'ingrédient ajouté par les hackers (à l'époque, ce n'était pas un terme péjoratif) était la prononciation de mnémoniques jamais destinés aux organes de la parole humaine (AOS, BLT, JRST, ILDB, HRROI), et l'extension de leur signification à d'autres domaines de la vie ( manger principalement). Finalement, ce lexique a été collecté et codifié par Guy Steele de la CMU et d'autres sous le nom de « Hacker's Jargon », publié à l'origine sous forme de fichier, puis développé dans un livre (voir bibliographie).

Les hackers DEC-10/20 constituaient au début un petit groupe, principalement en raison du manque de documentation utilisable. Pour écrire un programme fonctionnel, on peut consulter le manuel de référence du matériel, le manuel de référence des appels de moniteur et le manuel de référence de MACRO Assembler. Mais ces manuels n'étaient que des listes d'instructions, d'appels de moniteur et de pseudo-opérations, et ne donnaient pas la moindre idée sur la façon de mettre en place un programme. En 1981, la situation a radicalement changé avec la publication du livre de programmation en langage assembleur DEC-20 de Ralph Gorin, et le monde fut bientôt surpeuplé de programmeurs DEC-20 de premier cycle.

Chris Ryland et Frank avaient travaillé sur un guide de programmation en langage assembleur DEC-20 en 1979-80, qui aurait pu devenir un livre si Ralph ne nous avait pas devancé :-) CLIQUEZ ICI pour en voir une version en texte brut, récemment découvert (septembre 2002), environ 220 pages.

Néanmoins, l’absence d’un ensemble cohérent de langages de programmation de haut niveau, entièrement intégrés au système d’exploitation et au système de fichiers, était l’un des défauts fatals du DEC-20. Cette faiblesse a été corrigée par DEC dans VAX/VMS, où les programmes écrits dans une variété de langages peuvent faire appel à un support d'exécution commun ou compatible, et les programmes système peuvent être écrits dans pratiquement n'importe quel langage, même BASIC ou FORTRAN.

De nombreux TOPS-10 ont fonctionné – et fonctionneront encore jusqu'au dernier souffle du dernier DEC-20 – en « mode de compatibilité ». Cela signifiait que les programmes écrits dans ces langages ne pouvaient accéder aux fichiers que selon les règles TOPS-10 : pas de noms de fichiers longs, pas de caractères amusants dans les noms de fichiers, pas de références explicites à des répertoires ou à des numéros de génération. En particulier, les programmes sources de la plupart des langages de programmation avaient cette restriction : la plupart des compilateurs n'avaient pas été TOPS-20-isés, et même s'ils l'avaient fait, LINK ne l'avait pas été. En fin de compte, cela signifiait que l'utilisateur devait connaître TOPS-10 pour pouvoir utiliser TOPS-20, et que les programmeurs de langage de haut niveau se voyaient refuser l'accès à de nombreuses fonctionnalités de TOPS-20.

Outils de développement

(Cette section a été ajoutée en janvier 2019.) Des décennies plus tard, les vrais DECSYSTEM-20 sont difficiles à trouver, mais des émulateurs existent ; recherchez sur Google pour les trouver. Utiliser un émulateur DEC-20, c'est comme utiliser un vrai DEC-20. Par exemple, vous pouvez écrire et exécuter des programmes en langage assembleur. Pour ce faire, vous aurez besoin des manuels. Voici quelques copies archivées localement :

Titre	Sujet	Date	Format	Taille
Manuel de référence du processeur DECsystem-10 DECSYSTEM-20	Ensemble d'architecture et d'instructions	juin 1982	PDF	29 Mo
Manuel de référence de l'assembleur de macros DECSYSTEM-20	Manuel du langage assembleur	avril 1978	PDF	5 Mo
Manuel de référence des appels du moniteur TOPS-20	alias manuel JSYS (services système)	Décembre 1982	PDF	26 Mo
Manuel TOPS-20 DDT	Outil de débogage dynamique	mai 1985	PDF	5 Mo
NAVIGUER	Langage d'intelligence artificielle de Stanford	Août 1976	PDF	5 Mo

Voir le programme DEC-20 Kermit comme exemple de codage en langage assembleur.

SAIL (un langage de programmation de haut niveau de Stanford) n'est normalement pas installé sur les DEC-20, donc si le manuel vous intrigue, vous devrez rechercher un téléchargement.

[ Haut ] [ Suivant ] [ Précédent ]

FAIRE FACE À LA CROISSANCE

En un an, notre DEC-20 était désespérément surchargé, avec des charges moyennes fulgurantes et des disques se remplissant régulièrement. Elle est restée dans cet état pendant encore un an jusqu'à ce que nous trouvions un moyen d'acheter une deuxième machine. Bientôt, celui-ci fut également plein et, dans les années qui suivirent, il y eut un troisième et un quatrième, plus un DEC-20 au département d'informatique de Columbia et un autre au Columbia Teachers College. Les systèmes du centre informatique ont été mis à niveau en ajoutant de la mémoire et des disques, puis en les interconnectant tous avec CFS et en installant des lecteurs de disque RA-81 et un HSC-50. Finalement, tous les processeurs ont été mis à niveau vers des 2065 avec une mémoire maximale, et nous ne pouvions rien faire de plus pour en tirer plus de performances. Comme d’autres fidèles au DEC-20, nous avions rempli notre salle des machines à pleine capacité avec des DEC-20 et n’avions plus de place pour plus. Notre seule option d’expansion serait un nouveau modèle, avec plus de puissance sur moins d’espace au sol. Pendant plusieurs années, nous nous sommes rendus périodiquement à Marlboro pour discuter d’une prochaine machine. Il y avait en fait 2 projets.

DOLPHIN a commencé comme un système haut de gamme offrant une architecture 36 bits véritablement distribuée. Les grands DAUPHINS seraient assis au milieu de petits MINNOWS mono-utilisateur sur un réseau à large bande passante. DOLPHIN et MINNOW ont tous deux succombé à des problèmes technologiques. DOLPHIN utilisait des puces Motorola conçues sur mesure qui présentaient des problèmes de fiabilité. L'emballage dense de MINNOW, conçu pour tenir dans un boîtier de terminal VT52 , associé à la nécessité d'un lecteur de disque RP06 connecté localement (!), ont été sa chute. Ethernet était encore loin d'être utilisé commercialement, et le problème du réseau persistait également. [2]

Le projet JUPITER est arrivé plusieurs mois après l'annulation de DOLPHIN. Sa conception n'incorporait pas de MINNOW distribués, mais approuvait l'exigence d'un processeur centralisé rapide. Ce devait être 10+MIPS et bon marché. Un processus de conception long et difficile n'a abouti à aucun de ces objectifs et en 1983, le projet a été annulé, bien que certaines parties aient finalement atteint le marché - le CI, le HSC-50, etc. [2]

La direction et les ingénieurs de LCG nous ont toujours assuré à chaque visite à Marlboro (MA) (comprenant parfois des promenades en hélicoptère et en limousine, ainsi que l'hébergement dans des hôtels « à thème ») que le nouveau système n'était qu'à « 18 mois » de l'annonce, quel que soit son nom de code. . Le coût de possession de l’un ou l’autre système aurait été nettement inférieur à celui du nombre équivalent de KL.

En attendant l’apparition de Jupiter, nous avions encore besoin de moyens pour répartir de la manière la plus équitable possible nos ressources DEC-20 existantes entre les utilisateurs. C'était une préoccupation depuis le début. Le DEC-20, tel qu'il était initialement livré, permettait aux utilisateurs ordinaires de prendre possession de la machine de diverses manières, la rendant inutilisable par tout le monde. Les utilisateurs ont écrit des programmes pour créer sans fin des forks auto-réplicatifs, ils ont attribué tous les PTY et les ont utilisés pour écrire des voleurs de mots de passe, ils ont exécuté des programmes dans des boucles infinies qui consommaient tous les cycles CPU disponibles, ils ont monopolisé les rares lignes de terminaux pendant de longues heures, ils ont rempli le des files d'attente par lots, ils ont bombardé les opérateurs avec des milliers de demandes fallacieuses de montage de bandes, ils ont imprimé des millions de pages d'absurdités, etc.

En tant que site source de surveillance et d'exécution, Columbia a pu apporter des modifications pour restreindre l'accès à certaines ressources à certaines classes d'utilisateurs, en fonction de l'ID utilisateur ou de la chaîne de compte, ou en reprenant les bits « inutilisés » dans le mot de capacité. Mais à l'époque d'OS/360, nous avons appris la douloureuse leçon selon laquelle les modifications locales des systèmes d'exploitation reviennent nous hanter lorsque de nouvelles versions apparaissent : il a fallu des années pour mettre à niveau notre IBM OS/360 21.0 fortement modifié vers 21.8. C'est pourquoi nous nous sommes sentis obligés de convaincre DEC que nos exigences s'appliquaient universellement. Pour ce faire, nous avons parcouru différents canaux, en soumettant d'abord des formulaires de rapport sur les performances logicielles, puis en écrivant des lettres, et enfin nous avons eu une série de réunions avec le groupe de surveillance à Marlboro.

L'un des produits de ces réunions a été le travail de contrôle d'accès. Il s'agissait d'une tâche fournie par le client qui était consultée par le moniteur chaque fois que les utilisateurs demandaient l'accès à certaines ressources. L'ACJ pourrait décider d'accorder ou de refuser l'accès en fonction des propres critères du site client. Certaines de ces ressources comprenaient la connexion, l'activation de fonctionnalités, la création de tâches, la création de fork, l'affectation de périphériques, la soumission de tâches par lots, les montages de bandes, les montages de structures, la création de répertoires, les modifications de classe de planificateur, l'accès et la connexion, etc. Ce fut une grande aubaine pour la sécurité. et la gestion des ressources.

Mais l’ACJ ne nous a pas permis de réguler la consommation continue des ressources. Pour cela, nous devions produire un programme de surveillance pour collecter des statistiques par utilisateur sur le processeur et le temps de connexion. Les étudiants bénéficiaient d'un budget hebdomadaire de temps de connexion et de temps CPU, et recevaient des avertissements périodiques à mesure qu'ils approchaient de la limite. Même après la coupure, ils étaient autorisés à revenir pendant les heures creuses pour terminer leur travail. L'ACJ et Omega ont permis à nos DEC-20 d'accueillir une population de plus de 6 000 étudiants actifs sur quatre machines au plus fort de l'ère DEC-20.

Un domaine nous a particulièrement intéressé. Les terminaux n'étaient pas connectés directement à nos DEC-20, mais étaient commutés via un PBX de données. Par conséquent, le DEC-20 ne savait pas que le TTY37 (par exemple) était le numéro de terminal X dans la salle Y du bâtiment Z. Pour des raisons à la fois de sécurité et de commodité, il était nécessaire d'avoir cette connaissance. Si un utilisateur était soupçonné de mauvaise conduite, le personnel devait connaître son emplacement physique. Et lors de la création du poste, l'exécutif devait connaître le type et la vitesse du terminal, afin que l'utilisateur ne soit pas dérouté par des écrans fracturés et confus. Heureusement, le PBX de données disposait d'un terminal console qui tenait un journal des connexions. Celui-ci était connecté, via un câble Octopus RS-232, aux ports de chacun des DEC-20, qui conservait une base de données des ports PBX, des emplacements, des types de terminaux et des vitesses.

Les journaux tenus par l'ACJ et Omega incluaient l'emplacement physique du travail. Ces journaux nous ont permis de retrouver de nombreux contrevenants potentiels et réels à la sécurité du système et à la vie privée des autres utilisateurs.

[ Haut ] [ Suivant ] [ Précédent ]

LA MISE EN RÉSEAU

Notre premier DEC-20 était connecté à l'IBM 360/91 à l'aide du produit HASP/RJE de DEC, qui nécessitait son propre frontal DN20 dédié. Cette méthode de communication était assez pénible, obligeant le DEC-20 à se faire passer pour un lecteur de carte et une imprimante ligne auprès du système IBM. Nous avons écrit une série de programmes Sail qui construiraient le « sandwich JCL magique » pour nos utilisateurs qui souhaitaient envoyer des fichiers ou soumettre des travaux au système IBM.

Dès que nous avons reçu notre deuxième DEC-20, nous l'avons connecté au premier avec DECnet [1980], puis avons connecté ce petit réseau avec d'autres systèmes DEC sur le campus. DECnet était également utilisé sur les machines du centre informatique de l'Université Carnegie-Mellon, et nous avons donc fusionné nos deux DECnets en un seul avec une ligne téléphonique louée entre New York et Pittsburgh, appelant le réseau étendu CCnet [1982] (CC signifie Computer Center, ou peut-être Carnegie-Columbia). Peu de temps après, d’autres institutions ont rejoint le réseau : le Stevens Institute of Technology, la Case Western Reserve University, l’Université de New York, l’Université de Toledo et d’autres. Le principal avantage était le partage des logiciels et du travail de programmation par le personnel de gestion informatique de ces sites, qui comprenait des DEC-20, DEC-10, VAX, PDP-11 et d'autres systèmes DEC. Pendant de nombreuses années, Columbia et CMU exploitaient un système commun DEC-20 Galaxy, développé conjointement, qui permettait une impression transparente sur DECnet et des bandes d'impression en attente pour l'imprimante Xerox 9700. L'un des DEC-20 de Columbia servait de passerelle de messagerie entre CCnet et BITNET, un vaste réseau universitaire basé sur les protocoles RSCS du mainframe IBM.

La contribution la plus importante du DEC-20 aux réseaux a été sa prise en charge des protocoles ARPANET, d'abord NCP puis TCP/IP. Pendant de nombreuses années, DEC a été le seul grand fournisseur d'ordinateurs à prendre en charge ces protocoles, qui étaient principalement développés sur des machines DEC 36 bits sous TENEX, TOPS-10 et TOPS-20 (et plus tard sur VAX pour Berkeley UNIX). À la fin des années 70 et au début des années 80, époque à laquelle l’ARPAnet s’est développé et a prospéré au-delà de son minuscule mandat de recherche initial, il était dominé par les machines DEC 36 bits, et de nombreux protocoles et procédures Internet de base ont été développés dans ce cadre. DEC lui-même disposait d'un DEC-20 sur ARPANET, qui permettait aux principaux sites universitaires et de recherche DEC-20 de communiquer directement avec les ingénieurs TOPS-20, d'envoyer des rapports de bugs ou des correctifs par e-mail, de transférer des fichiers, etc. Une liste de diffusion ARPANET des managers TOPS-20 a été créée par Mark Crispin à Stanford. La liste de diffusion comprenait des développeurs TOPS-20 du DEC, et il y avait beaucoup de concessions mutuelles utiles qui contournaient la lourde procédure SPR.

Localement, nos propres DEC-20 ont reçu des interfaces Ethernet NIA20 pour remplacer les frontaux DN20 encombrants et surdimensionnés. Ethernet nous a permis d'exécuter TCP/IP aux côtés de DECnet, et peu de temps après [vers 1982], il y avait un grand Ethernet à l'échelle du campus connectant le centre informatique DEC-20 aux systèmes du département sur tout le campus et au-delà, grâce à l'Internet du département d'informatique. adhésion [1982 ?], et plus tard [1984 ?], notre propre adhésion à d'autres réseaux étendus basés sur TCP/IP comme NYSERNET et JVNCNET. Ethernet et TCP/IP nous ont même permis d'abandonner notre liaison HASP RJE vers les mainframes IBM, qui étaient désormais sur Ethernet, exécutant le code TCP/IP de l'Université du Wisconsin (incorporé plus tard par IBM dans leur propre gamme de produits).

[ Haut ] [ Suivant ] [ Précédent ]

KERMIT

Au plus fort de la popularité du DEC-20, la demande d'identifiants d'utilisateur parmi les étudiants et les professeurs était si grande que nous ne pouvions plus nous permettre de délivrer des identifiants perpétuels. Au lieu de cela, les identifiants pédagogiques étaient attribués pour chaque cours, puis supprimés à la fin de chaque semestre. Même si les fichiers étaient scrupuleusement sauvegardés sur bande, les étudiants n'étaient pas autorisés à demander la restauration des fichiers d'un trimestre précédent en raison de la capacité limitée du lecteur de bande et de la couverture des opérateurs. Et même pendant le trimestre, le quota de disque d'un étudiant (35 Ko — K, pas M ou G !) n'était souvent pas suffisant pour garder tous ses fichiers en ligne en même temps.

Si les utilisateurs de DEC-20 disposaient d’une sorte de support amovible, ils pourraient assumer la responsabilité de la gestion et de l’archivage de leurs propres fichiers. Notre premier effort dans ce domaine impliquait un produit peu connu appelé DN200, une station DECnet distante conçue à l'origine pour connecter 32 terminaux et une imprimante ligne au DEC-20 (ce produit n'a jamais vraiment mûri). Le DN200 était un PDP-11/34 exécutant un dérivé du RSX. Le nôtre – unique en son genre – comprenait un lecteur de disquettes de 8 pouces. Notre plan était d'écrire un logiciel DN200 pour copier des fichiers entre les disquettes et le système de fichiers DEC-20. Les utilisateurs inséraient simplement leurs propres disquettes et émettaient des commandes COPY pour sauvegarder ou restaurer leurs fichiers. Heureusement, ce projet n’a jamais vu le jour.

Mais l’idée des supports amovibles semblait bonne. Les utilisateurs d'ordinateurs l'avaient depuis des années sous la forme de cartes, de bandes de papier ou même des irrésistibles petites bandes DEC tournant en va-et-vient de DEC, comme celles des PDP-8, -9, -10, -11, - 12, etc, et manque cruellement au -20. Un certain nombre de projets fous ont été envisagés et rejetés : permettre aux utilisateurs d'envoyer des fichiers vers la perforatrice de la carte du mainframe IBM, installer un lecteur de bande "libre service" à 9 pistes dans un espace public, écrire un programme qui convertirait les données de l'utilisateur en codes à barres pour impression sur nos imprimantes Printronix...

À cette époque (1980), les micro-ordinateurs CP/M 8 bits faisaient leur apparition. Même s’ils n’étaient pas bons à autre chose, ils pouvaient communiquer et lire et écrire sur des disquettes. Placez-en quelques-uns dans les espaces publics, connectez-les aux DEC-20, et les étudiants disposeront de leurs supports amovibles, de petits disques qu'ils pourront emporter avec eux, stocker et réutiliser sans dépendre du personnel du centre informatique. La grande question était de savoir comment déplacer un fichier d’un gros ordinateur central en temps partagé vers un petit ordinateur personnel.

Nous avons examiné le marché et constaté qu'il existait quelques packages de communication RS-232 commerciaux pour les micros, mais aucun pour le DEC-20. Et nous devions nous soucier non seulement des DEC-20 et des micros, mais aussi de nos mainframes IBM. Si nous achetions un logiciel pour transférer des fichiers entre le DEC-20 et l' Intertec Superbrain(c'est le micro que nous avons sélectionné, principalement pour sa construction à l'épreuve des utilisateurs, et malgré son nom idiot), en supposant qu'il soit disponible, nous devrons acheter encore un autre logiciel pour que nos utilisateurs de mainframe IBM fassent de même. Nous avons également dû considérer que le Superbrain n'est peut-être pas le micro de choix de tout le monde. Columbia, étant une organisation hautement décentralisée et diversifiée, était susceptible de disposer d'autant de types d'ordinateurs différents qu'il y avait d'endroits où les installer. Si un progiciel distinct était nécessaire pour connecter chaque paire unique de systèmes, nous aurions alors besoin de progiciels distincts de près de n carrés, où n est le nombre de types différents de systèmes informatiques, avec suffisamment de copies pour couvrir chaque instance de chaque système. système.

Il est bien préférable d'avoir un logiciel sur chaque ordinateur, un package capable d'échanger des données avec tous les autres ordinateurs. Cela réduit le nombre de programmes requis à n , ce qui allège le budget et facilite un peu la vie de l'utilisateur.

Toutes ces questions ont abouti à la décision d’investir dans nos propres programmeurs plutôt que dans les éditeurs de logiciels. De cette façon, nous pourrions disposer d’un logiciel spécialement conçu pour nos propres besoins. Le résultat final fut le protocole de transfert de fichiers Kermit. Nos premiers programmes Kermit ont été écrits pour le DEC-20 et le Superbrain. Des supercerveaux ont été placés dans des espaces publics pour permettre aux étudiants de copier leurs propres fichiers sur des disquettes et de les restaurer ultérieurement sur le DEC-20.

Le protocole Kermit a été largement influencé par les limitations du DEC-20. Le DEC-20, avec son frontal PDP-11/40, a été conçu sur l'hypothèse que les entrées du terminal proviennent directement de personnes assises devant un clavier et tapant avec leurs doigts à une vitesse relativement lente - peut-être 10 caractères par seconde, maximum - alors que de grandes des quantités de sortie soutenues peuvent être envoyées de l’ordinateur à l’écran. RSX20F, le système d'exploitation du frontal, alloue donc de petits tampons pour l'entrée et de grands pour la sortie. Nous l'avons appris à nos dépens, lors de l'achat de nos premiers terminaux dotés d'une fonction « écran de transmission » (HDS Concept-100s). Dès que quelqu’un l’a essayé, l’avant s’est écrasé. Des phénomènes similaires ont été observés avec les touches à répétition automatique (comme lorsqu'un de nos programmeurs s'endormit sur le clavier)( 5), et encore lorsque DEC a sorti pour la première fois son terminal VT100 : lors d'un défilement fluide à 9 600 bps, le terminal a submergé le pauvre frontal avec des XOFF et des XON. Les versions ultérieures du RSX20F ont résolu ces problèmes de manière draconienne : si les tampons d'entrée ne pouvaient pas être alloués assez rapidement, le frontal mettait la vitesse de la ligne à zéro pendant une seconde ou deux ! La leçon? N'envoyez pas de rafales soutenues de données de terminal dans le DEC-20 - c'est comme essayer de faire manger à un moineau un héros aux boulettes de viande. Les paquets normaux de Kermit sont donc assez courts, 96 caractères maximum : des graines, des insectes et des vers qu'un moineau peut digérer.

Une autre particularité du DEC-20 est sa sensibilité aux caractères de contrôle. Au cours du dialogue normal du terminal, 17 des 33 caractères de contrôle ASCII sont utilisés à des fins spéciales — édition, interruption du programme, contrôle de flux, rapport d'état, signalisation de fin de fichier, etc. — plutôt que d'être acceptés comme données. Même si un programme DEC-20 peut ouvrir le terminal en "mode binaire" pour contourner le traitement spécial de ces caractères, cela n'est pas forcément souhaitable, car certaines de ces fonctions pourraient être utiles lors du transfert de données. La leçon ici est de ne pas envoyer de caractères de contrôle « nus » lors du transfert de données. En fait, le protocole Kermit (dans sa configuration la plus basique) envoie des paquets qui sont strictement de courtes lignes de texte.

Le mainframe IBM (à cette époque, le 360/91 avait été remplacé par un 4341 exécutant le système d'exploitation VM/CMS) avait son propre ensemble de particularités. Contrairement au DEC-20, il utilisait une communication semi-duplex et utilisait 7 bits de données avec parité lors de la communication avec le monde ASCII extérieur. Cela signifiait que notre protocole de transfert de fichiers devrait également être semi-duplex et nécessiterait un mécanisme spécial pour transmettre des données binaires 8 bits via une liaison de communication 7 bits. De plus, comme toutes les communications se faisaient via un frontal 3705 (mode ligne) ou un convertisseur de protocole IBM Series/1 (ou équivalent, par exemple 7171 ou 4994) 3270, qui traitaient tous deux de nombreux caractères de contrôle comme des commandes à exécuter immédiatement, l'interdiction des caractères de contrôle nus dans les données a été renforcée. Réduire le protocole au plus petit dénominateur commun a permis de le faire fonctionner dans tous les cas, mais au détriment de l’efficacité et de l’élégance. Certaines des lacunes qui en ont résulté ont été corrigées au cours des années suivantes par l'ajout de paquets longs et du transport de paquets à fenêtre coulissante en duplex intégral au protocole, ainsi que d'une option de « dépréfixation » des caractères de contrôle.

Par une heureuse coïncidence, les bizarreries combinées du DEC-20, de l'ordinateur central IBM et du micro-ordinateur CP/M ont abouti à une conception qui s'avérerait adaptable à pratiquement n'importe quel ordinateur capable de communication asynchrone. Un fichier a été transféré pour la première fois avec le protocole Kermit le 29 avril 1981, par deux instances de Kermit-20 fonctionnant sur un seul DEC-20, en utilisant deux ports série interconnectés par un câble null modem.

L'idée de partager nos programmes Kermit et de donner le code source est une conséquence naturelle de nos expériences avec la communauté des sites DEC-10/20. Nous avons reçu une grande partie de nos propres logiciels provenant d'autres sites, ce n'était que justice. Nous avons inclus Kermit sur nos bandes d'exportation et l'avons soumis à DECUS. DEC a été la première entreprise à reconnaître Kermit comme un outil de grande valeur et l'a publié dans ses dépliants et bulletins d'information sur les grands systèmes (par exemple Copy-N-Mail , Large Systems News et EDU) .). Et DEC a été la première organisation à porter Kermit sur une nouvelle plate-forme : son micro VT-180 CP/M. Parce que nous voulions que les logiciels Kermit soient partagés ouvertement, nous n'avons pas placé nos programmes Kermit dans le domaine public. Bien que cela puisse paraître contradictoire, nous avons estimé qu'en protégeant les programmes, nous pourrions empêcher qu'ils soient repris par des entrepreneurs et vendus comme produits commerciaux, ce qui semblait nécessaire puisque nous avions entendu des histoires d'autres universités à qui il avait été interdit d'utiliser des programmes qu'elles avaient elles-mêmes. avaient été écrits par des entreprises qui avaient pris leur travail dans le domaine public et l'avaient protégé par droit d'auteur pour elles-mêmes.

En raison de la large diffusion des premiers programmes Kermit, ainsi que du code source et des spécifications du protocole, des sites dotés d'autres types d'ordinateurs ont commencé à écrire leurs propres programmes Kermit et à nous les renvoyer. Certaines des premières contributions dans cette veine étaient les programmes DECsystem-10 et VAX/VMS Kermit du Stevens Institute of Technology (écrits en Common Bliss afin que le code puisse être partagé entre TOPS-10, VMS et P/OS), PDP-11. Kermit de l' Université de Tolède et le premier UNIX Kermit simple en C de notre propre département d'informatique. Le processus s'est poursuivi pendant de nombreuses années, aboutissant à la vaste collection de programmes Kermit que vous pouvez trouver aujourd'hui sur le site Web du projet Kermit .

Le projet Kermit de Columbia a utilisé le DEC-20, notre système CU20B, comme banc d'essai, bibliothécaire et réseau depuis le début jusqu'à ce que le CU20B (notre dernier DEC-20 restant) soit éteint en septembre 1988. Le bulletin d'information électronique Info-Kermit a été produit et envoyé aux personnes des réseaux universitaires et d'entreprise du monde entier à partir du DEC-20 en utilisant MM, le programme de messagerie électronique DEC-20. Ces mêmes utilisateurs peuvent utiliser MM et d'autres clients de messagerie pour des requêtes et des informations, et ils peuvent également accéder aux programmes, au code source et à la documentation via les serveurs de fichiers DECnet et TCP/IP du DEC-20. Même nos bandes de distribution ont été initialement expédiées à partir de nos DEC-20 aux formats DUMPER, BACKUP et ANSI.

Jusqu'en 1985 environ, le DEC-20 Kermit était la « référence » par rapport à laquelle tous les autres Kermits devaient être vérifiés pour leur interopérabilité. De nombreuses nouvelles fonctionnalités Kermit ont d'abord été ajoutées à DEC-20 Kermit (mode serveur, macros, etc.). L'interface utilisateur du DEC-20 est devenue le modèle pour la plupart des programmes Kermit, de sorte que des millions de personnes utilisent aujourd'hui (une simulation remarquable) du COMND JSYS du DEC-20 sans le savoir. Bien après que le DEC-20 ait disparu de la scène, les programmes Kermit sur Windows, UNIX, VMS, MS-DOS et de nombreuses autres plates-formes continuent de « garder la foi ».

Peu de temps après l'apparition de Kermit, la micro-informatique est devenue une force importante avec l'introduction du PC IBM . Les PC sont soudainement devenus des ordinateurs polyvalents utiles à part entière. En réponse aux demandes urgentes des professeurs de Columbia qui avaient reçu les premiers PC IBM, nous avons produit à la hâte la version 1.0 d'IBM PC Kermit et avons constaté que Kermit était utilisé d'une manière que nous n'avions pas prévue. Plutôt que d'utiliser les disquettes du PC pour stocker les fichiers du mainframe, les utilisateurs effectuaient la plupart de leurs créations et manipulations de fichiers sur le PC et envoyaient les résultats au mainframe pour archivage et partage. Kermit était devenu l'un des premiers modèles de traitement distribué.

[ Accueil du projet Kermit ] [ Problèmes Kermit News ] [ Archives de la liste de diffusion Kermit ] [ Archives du groupe de discussion Kermit ]

[ Haut ] [ Suivant ] [ Précédent ]

PACKS LOGICIELS

Les grands systèmes DEC 36 bits ont été la source de certains des progiciels les plus influents et les plus durables jamais écrits. Ici, nous mentionnons arbitrairement quelques-uns de nos favoris, avec nos excuses aux centaines que nous avons négligées.

Éditeurs

Au premier rang des programmes créés sur ces systèmes se trouve l'éditeur de texte EMACS, créé par Richard M. Stallman sur ITS, le « système de partage de temps incompatible » du MIT pour le PDP-10. EMACS incarnait le concept révolutionnaire selon lequel l'écran du terminal devait agir comme une fenêtre sur le texte en cours d'édition et que toute modification apportée au texte devait être immédiatement reflétée sur l'écran. Après de nombreuses années d'édition orientée ligne (et avant cela, de frappe), il nous a été difficile au début de comprendre la puissance et la commodité d'un éditeur d'écran. Il y a même eu une discussion pour savoir si nous devrions l'autoriser sur notre système, comme s'il s'agissait d'une influence subversive... "Pourquoi en avons-nous besoin ? Chaque frappe entraîne 37 changements de contexte !" etc etc. Mais bientôt même les sceptiques ont commencé à apprécier l'EMACS pour son énorme coup de pouce à la productivité humaine, et il est rapidement devenu l'éditeur de choix du personnel, des étudiants et des professeurs. Une industrie artisanale a vu le jour à Columbia pour ajouter de nouveaux types de terminaux et opérations à la base de données de TECO (DEC-10/20 EMACS a été écrit en TECO), ainsi que de nouvelles bibliothèques pour EMACS lui-même.

Bien que certains puissent considérer EMACS et ses descendants et parents comme « obsolètes » aujourd'hui, par rapport aux éditeurs GUI et aux traitements de texte, ils ont un grand avantage sur les éditeurs plus récents : ils sont entièrement pilotés par des caractères ASCII ordinaires ( 6) (par opposition aux touches de fonction ou aux touches fléchées, à la souris, etc.) afin que les dactylos n'aient jamais à quitter les touches d'accueil, et que les utilisateurs qualifiés d'EMACS puissent saisir et manipuler du texte plus rapidement que les experts d'autres éditeurs, en particulier les éditeurs d'interface graphique modernes mais exigeants en main-d'œuvre. . Et en limitant le jeu de commandes aux caractères ASCII ordinaires, EMACS peut être utilisé sur n'importe quelle plate-forme, quelle que soit la manière dont vous y accédez (le clavier et l'écran du poste de travail, une fenêtre xterm, telnet, numérotation, rlogin, ssh, etc.). Un autre avantage d'EMACS, bien sûr, est sa personnalisation et sa programmabilité, mais seules les générations plus anciennes d'utilisateurs d'ordinateurs connaissent ou s'intéressent à ces choses.

Formateurs de texte

EMACS est un éditeur de texte brut, ce qui signifie qu'il ne peut normalement pas produire d'effets d'impression spéciaux comme le gras, l'italique, le soulignement, la notation mathématique, différentes tailles de points, les graphiques, etc. Pour cela, nous avons besoin - du moins dans le monde des caractères terminaux - un formateur de texte. EMACS était l'un des nombreux éditeurs d'écran pour le DEC-20 (TV et TVEDIT étaient d'autres premiers concurrents), et il y avait également plusieurs formateurs de texte. Le DEC-20 est bien entendu livré avec RUNOFF, le formateur standard de DEC. RUNOFF est simple, pas trop puissant, mais présente l'avantage que les fichiers RUNOFF sont pour la plupart portables entre les PDP-11, VAX, DEC-10 et DEC-20. Cependant, RUNOFF est propriétaire et n'est donc pas disponible sur les systèmes non-DEC. RUNOFF présente également trois défauts fondamentaux. Premièrement, c'est strictement procédural, ce qui signifie que l'écrivain doit se comporter comme un programmeur, instruisant RUNOFF dans les moindres détails. Deuxièmement, il ne peut pas faire de mathématiques. Et troisièmement, il ne prend pas en charge une grande variété de périphériques de sortie.

Ces lacunes sont comblées par plusieurs formateurs de texte développés par les utilisateurs de grands systèmes DEC, et d'ailleurs par certains de ses plus petits systèmes (UNIX, par exemple, a été écrit à l'origine pour le PDP-7, puis déplacé vers le PDP-11). ; UNIX nroff et troff sont probablement des ramifications de RUNOFF). Les premiers efforts sur les systèmes 36 bits incluaient R et Pub.

Brian Reid, travaillant sur un DECsystem-10 pour sa thèse de doctorat à la CMU, a conçu un langage de production de documents appelé Scribe, qui aborde l'élément procédural. Là où dans RUNOFF il faut dire "centrer et souligner ce mot, laisser 7 lignes blanches, mettre en retrait 4 espaces, etc", dans Scribe on dit "Ceci est un article, voici le titre, voici une section, voici une note de bas de page , voici une citation bibliographique, mettez-la dans l'index, insérez une photographie ici et mettez-la à l'échelle comme ainsi, etc. » et laisse les décisions stylistiques et les détails à Scribe, qui comprend une vaste base de données de types de documents et de styles de publication. Par exemple, si vous avez écrit un article pour le CACM, vous pouvez demander à Scribe de le formater dans le style requis par le CACM. Lorsque le CACM le rejette, vous dites simplement à Scribe de le refaire au format IEEE Computer,7 ).

Au cours de son développement, Scribe a été partagé librement avec d'autres universités, et il y a eu beaucoup de concessions mutuelles entre Brian et les utilisateurs du monde entier. Cependant, lorsque Brian a quitté la CMU, les droits de Scribe ont été vendus à une société privée, Unilogic Ltd, qui l'a vendu comme produit commercial ( 8 ). Scribe était présent sur de nombreux sites DEC-10 et -20 et a été converti du Bliss original vers d'autres langages pour une utilisation sur des systèmes comme UNIX, VMS et même les mainframes IBM.

Pendant ce temps, à Stanford, Donald Knuth prévoyait de nouvelles éditions de son ouvrage en plusieurs volumes, The Art of Computer Programming . Mais il découvrit bientôt que depuis la parution de ses premières éditions, l'art de la composition mathématique, comme celui de la taille de pierre architecturale, était mort : il ne trouvait pas de compositeur à la hauteur de la tâche. Il s'est donc mis au travail sur un programme informatique de composition mathématique et sur un ensemble de polices harmonieuses adaptées au téléchargement informatique sur une imprimante laser. Le travail a été effectué sur un PDP-10 à Stanford, exécutant leur système d'exploitation local WAITS ("Il vous attend mains et pieds"), dans le langage Sail. Le résultat, un système appelé T EX (tau epsilon chi) et METAFONT, son compagnon de création de polices, ont attiré de nombreux passionnés, et le programme Sail original a été rapidement traduit dans d'autres langues pour des raisons de portabilité. Il fonctionne désormais sur de nombreuses plates-formes différentes et est responsable de la production de nombreux livres et articles d'une beauté typographique inégalée.

TeX et Scribe prennent en charge une grande variété de périphériques de sortie et sont parmi les premiers formateurs de texte à le faire. Lorsque Xerox a laissé quelques-unes de ses imprimantes XGP (une imprimante xérographique expérimentale avec des polices téléchargées depuis l'hôte) s'échapper dans les laboratoires de Stanford, du MIT et de la CMU au début des années 70, celles-ci ont été rapidement connectées aux PDP-10, pour être pilotées par des formateurs comme R et Pub. Leur flexibilité a incité des personnes comme Don et Brian à inclure des concepts de composition complets dans leurs conceptions, et grâce à cela, il a été possible plus tard d'ajouter la prise en charge de TeX et Scribe pour des imprimantes comme la GSI CAT-4 (alors largement utilisée chez Bell). Labs avec Troff), la Xerox Dover, l'Imagen et les imprimantes PostScript d'aujourd'hui (et si nous ne nous trompons pas, Brian était également la force directrice derrière PostScript).

Dans le nouveau millénaire, Scribe a quasiment disparu, ce qui est dommage. Mais d'une certaine manière, il perdure dans LaTEX , qui est un langage de type Scribe construit sur TEX. Comme de nombreux outils des années 1970 et 1980, Scribe, TEX et LaTEX ( et, par exemple), peu importe, EMACS) nécessitent pas mal d'études pour commencer, mais cela en vaut la peine car une fois que vous êtes à l'aise avec eux, vous pouvez surpasser tout le monde !

Courrier électronique

Les avantages du courrier électronique n'ont guère besoin d'être vantés, mais il fut un temps où les gens ne l'utilisaient pas ou ne lui faisaient pas confiance. Aujourd’hui, bon nombre de ces mêmes personnes peuvent difficilement s’en passer. Son principal avantage est qu'il permet aux personnes qui y participent de communiquer facilement et avec une certaine assurance que le message sera reçu. Contrairement au courrier postal, le courrier électronique peut être envoyé sur un coup de tête et un seul message peut être envoyé à plusieurs personnes à la fois. Contrairement aux appels téléphoniques, le courrier électronique ne dépend pas de la présence de l'appelé au moment de l'envoi du message. Il y a ceux qui disent que c'est une influence déshumanisante, que les gens dans les bureaux adjacents qui autrefois se rendaient visite et discutaient sont maintenant collés à leur écran et s'envoient des messages électroniques, des messages dont la véritable intention ne peut être glanée à partir de l'expression du visage, le langage du corps, ou le ton de la voix. C'est peut-être vrai, mais le courrier électronique est là pour rester et la plupart des gens trouveront un moyen de l'intégrer de manière judicieuse dans leur vie.

Même si le courrier électronique était disponible pour une utilisation sur un ordinateur depuis le début des années 1960 (par exemple sur le système de partage de temps CTSS du MIT), le courrier électronique entre ordinateurs a fait ses débuts sur les DEC-20 (ou, à proprement parler, les KL-10 exécutant TENEX, le "proto-TOPS-20"), chez BBN à Cambridge, Massachusetts, en 1972, lorsque Ray Tomlinson de BBN a adapté son programme de messagerie TENEX pour envoyer des messages à d'autres nœuds ARPANET. Cela impliquait non seulement de nouveaux logiciels et protocoles, mais également une nouvelle notation : le format d'adresse utilisateur @ hôte désormais omniprésent .

Si vous faisiez un SYSTAT sur n'importe quel DEC-20 à Columbia entre 1978 et 1988, vous verriez qu'environ la moitié des utilisateurs utilisaient EMACS et l'autre moitié MM, avec seulement des délais d'attente occasionnels pour le formatage de texte, la compilation de programmes, le transfert de fichiers et d'autres types. du « vrai travail ». MM est le Mail Manager, initialement écrit par Mike McMahon et repris plus tard par Mark Crispin. Il s'agit du côté « agent utilisateur » du système de messagerie. MM est un programme utilisateur ordinaire sans privilèges qui vous permet de lire votre courrier, de rédiger et d'envoyer du courrier à d'autres utilisateurs, de transférer du courrier et de gérer votre fichier courrier. MM vous permet de déplacer des messages vers différents fichiers, d'imprimer des messages, de les supprimer, de les marquer pour une attention ultérieure, etc.

Toute opération que MM peut effectuer sur un seul message peut également s'appliquer à une séquence de messages. C'est l'une des fonctionnalités les plus puissantes de MM. Les fonctions de sélection de messages de MM vous permettent de traiter votre fichier courrier presque comme une base de données et d'émettre des requêtes complexes telles que « montrez-moi (ou répondez, ou supprimez, ou transférez, ou marquez, ou imprimez) tous les messages envoyés par tel ou tel. entre telle et telle date qui sont plus longues que tant de caractères et incluent le mot 'foo' dans leur sujet."

MM est extrêmement puissant, mais il est également facile à utiliser car il utilise pleinement le COMND JSYS. Les utilisateurs peuvent savoir ce qui est attendu à tout moment en tapant un point d'interrogation (sauf lors de la rédaction du texte du message, auquel cas le point d'interrogation devient une partie du texte). Il existe une commande SET qui permet de personnaliser de nombreuses opérations de MM et de modifier ses actions par défaut. Les utilisateurs peuvent enregistrer ces personnalisations dans un fichier d'initialisation, afin qu'elles soient effectuées automatiquement à chaque exécution de MM.

MM a été rapidement adopté au profit de DEC-20 MAIL et RDMAIL, et a été initialement utilisé par l'équipe de programmation. Son utilisation s'est rapidement répandue parmi les étudiants et les professeurs, au point que plusieurs cours en sont devenus totalement dépendants. Des devoirs et des lectures ont été attribués, des conférences ont été organisées, des devoirs rendus, des questions posées et répondues, le tout avec MM. MM est également utilisé pour publier des messages sur des « tableaux d'affichage » publics, qui étaient utilisés pour tout, de la vente de motos d'occasion aux quiz en passant par les controverses faisant rage sur des sujets politiques.

À Columbia, de nombreux départements sont répartis dans différents bâtiments, sur le campus et hors du campus. Ces départements étaient des candidats idéaux pour le courrier électronique, et nombre d'entre eux géraient leurs activités quotidiennes avec MM. Et MM est également à l'aise dans l'environnement en réseau. Compte tenu des connexions réseau et de l'agent de livraison appropriés, le MM peut être - et est - utilisé pour transmettre du courrier électronique partout dans le monde, plus rapidement que n'importe quel bureau de poste ou service de livraison ne pourrait livrer du papier. Depuis la Colombie, nous envoyons des e-mails vers des endroits aussi éloignés que l'Utah, l'Angleterre, la Norvège, l'Australie, le Brésil, le Japon, la Chine et l'URSS, et recevons des réponses en quelques minutes (en supposant que nos correspondants gardent les mêmes horaires impairs que nous). faire!).

Post-scriptum de mai 2003 : Il n'a fallu qu'une décennie supplémentaire pour que le courrier électronique devienne plus une malédiction qu'une bénédiction, et que chaque utilisateur d'ordinateur soit submergé de courriers indésirables et/ou malveillants, appelés « spam ». Le DEC-20 a également été pionnier dans ce domaine : le tout premier spam a été envoyé le 1er mai 1978 1233-EDT depuis DEC-MARLBORO.ARPA (un DEC-20) à tous les contacts ARPANET (de la base de données WHOIS), annonçant de nouveaux Modèles DEC-20.

En 2015, Columbia a externalisé sa messagerie électronique auprès de Google.

[ Haut ] [ Suivant ] [ Précédent ]

AUTRES CONTRIBUTIONS DIGNES

L'architecture DEC-20 remonte en fait au milieu des années 1960, au PDP-6 de DEC, qui a été conçu avec LISP à l'esprit — les demi-mots et les instructions associées sont parfaits pour les CAR et les CDR (c'est le langage LISP, issu du jeu d'instructions de l'IBM). 704, où LISP a été développé pour la première fois). La plupart des grandes implémentations de LISP ont été réalisées pour les machines 36 bits de DEC – MACLISP, INTERLISP – et parmi les applications basées sur ces machines, MACSYMA du MIT se démarque comme une référence. MACSYMA est utilisé par les scientifiques et les ingénieurs pour manipuler des expressions mathématiques de complexité arbitraire au niveau symbolique plutôt que numérique. Il existe une histoire célèbre (peut-être apocryphe) sur un astronome-mathématicien du XIXe siècle qui a consacré sa vie à formuler l’équation exacte du mouvement de la lune. Le résultat a rempli un livre de 300 pages.

En 1971, Ralph Gorin de l'Université de Stanford a écrit le premier correcteur orthographique informatique connu pour le texte, SPELL pour TOPS-10. Il a ensuite été adapté au DEC-20 et « interfacé » avec des packages comme EMACS et MM. Les descendants de SPELL sont légion : aucun programme de traitement de texte sur PC qui se respecte n'apparaîtrait en public sans un correcteur orthographique.

[ Haut ] [ Suivant ] [ Précédent ]

CONVERSION VERS UNIX

[Rappelez-vous : ce document a été rédigé en 1988.]

" Une navigation en douceur dans les années 80... " À la fin des années 80, la demande pour le service DEC-20 s'est stabilisée, puis a commencé à chuter. Le DEC-20 était comme un clipper, la plus haute expression d'une technologie que beaucoup croyaient obsolète : le grand ordinateur central à temps partagé. " Les étudiants étaient désormais prêts à renoncer aux commodités du DEC-20 pour le contrôle et la prévisibilité de leur propre PC. Grâce à l'adhésion de Columbia au Apple University Consortium, des milliers de Macintosh furent bientôt entre les mains des étudiants. Arrangements spéciaux avec IBM Ils ont également installé des PC IBM dans des centaines de bureaux et de dortoirs. Ces systèmes répondaient aux besoins des étudiants pour de petits travaux de programmation en Pascal et Basic, ainsi que pour un traitement de texte modeste, et soulageaient les systèmes centraux d'une lourde charge. Cependant, les PC ne répondaient pas les besoins des départements Informatique et autres départements d'ingénierie,où des projets plus importants étaient confiés dans des langages comme Fortran, C, Prolog et Lisp, qui n'étaient pas facilement et abordablement disponibles pour les PC.

Pendant ce temps, UNIX conquérait le monde informatique – sur les mainframes, les minis, les postes de travail et même les PC. Notre principal groupe d'utilisateurs pédagogiques - les étudiants CS - effectuaient l'essentiel de leur travail sur les ATT 3B2 du département, mais avaient cruellement besoin d'un environnement centralisé et fiable avec des performances, des sauvegardes, un service et tout le reste tolérables. Nous utilisions déjà UNIX sur un VAX 750 depuis quelques années (pour des travaux de développement interne), ainsi qu'Amdahl UTS sur un mainframe IBM, nous avions donc développé une certaine expertise UNIX.

Pour ces raisons, nous avons décidé qu'il était temps de commencer la conversion de TOPS-20 vers UNIX. Pour des raisons financières, nous avons choisi à cet effet un VAX 8650. L'échange DEC-20 était intéressant et nous avons pu conserver nos anciens lecteurs de disques et de bandes. En fait, nous avons estimé que sur 3 ans, acheter le VAX revenait moins cher que conserver le DEC-20. Et il était plus puissant, avec un espace d'adressage plus grand, dans un encombrement plus réduit, que le DEC-20 qu'il remplaçait.

VMS n'a pas été choisi pour plusieurs raisons. Premièrement, nous nous sentions quelque peu trahis par l'abandon du TOPS-20 par DEC et ne voulions pas nous exposer au même traitement à l'avenir. UNIX, contrairement à VMS, ne vous lie pas à un fournisseur particulier. De plus, UNIX dispose de réseaux et de communications pour tous nos principaux besoins : Ethernet, TCP/IP, DECnet (notre UNIX initial était Ultrix-32), BITNET (UREP), terminaux RS-232 et LAT, Kermit. Et UNIX lui-même présente de nombreux avantages : un environnement de développement d'applications très puissant pour les programmeurs expérimentés, un shell programmable, un pipeline de programmes, des utilitaires simples mais puissants.

UNIX, cependant, est notoirement concis, énigmatique et peu convivial, en particulier pour les utilisateurs d'ordinateurs novices. VMS, bien qu'il lui manque le COMND JSYS du DEC-20, est certainement plus convivial qu'UNIX et est verbeux à l'excès. Ce n’est donc pas sans quelques appréhensions que nous nous sommes lancés dans la conversion.

Beaucoup d’entre nous, utilisateurs du DEC-20, étaient résistants au changement. La familiarité, pour le meilleur ou pour le pire, est souvent plus attrayante que l’incertitude. Mais la conversion vers UNIX nous a obligé à abandonner certaines des fonctionnalités qui nous avaient initialement attirés vers le DEC-20.

Le shell "convivial" fourni par le TOPS-20 Exec, qui aide ceux qui en ont besoin mais ne pénalise pas les utilisateurs experts, est probablement la fonctionnalité qui a le plus manqué. Sous UNIX, la plupart des commandes sont des programmes, supposés avoir des arguments composés uniquement d'options ou de noms de fichiers. Cela signifie que vous ne pouvez pas avoir "?" pour les commandes et les arguments dans le shell, car les programmes qui agiraient sur la demande d'aide n'ont même pas encore commencé à s'exécuter. C'est le contraire de TOPS-20, où la plupart des fonctions principales sont intégrées à l'exécutable, mais qui ne permet pas de regrouper des programmes de base concis comme le fait UNIX.

Pour citer un exemple de la différence radicale entre les philosophies TOPS-20 et UNIX, supposons que vous souhaitiez créer une procédure qui produirait une liste de répertoires, la trierait dans l'ordre inverse par taille de fichier et formaterait la liste en pages numérotées avec trois colonnes chacune. page, adaptée à l’impression. Dans TOPS-20, vous passeriez une semaine à écrire un programme en langage assembleur pour faire tout cela. Sous UNIX, les outils sont déjà là et il suffit de les combiner de la manière souhaitée :

ls-s | trier -r | pr-3

Cela rend UNIX assez attrayant. Mais le programme DEC-20, une fois écrit, contiendra une aide intégrée, la complétion des commandes et des noms de fichiers, etc., alors que la procédure UNIX ne peut être utilisée que par ceux qui savent exactement ce qu'ils font. Si vous avez tapé "ls -s | sort" mais que vous ne savez pas quelle est l'option de tri appropriée, taper un point d'interrogation à ce stade ne servira à rien car le programme de tri n'est pas encore en cours d'exécution.

Le DEC-20 (comme la plupart des systèmes d'exploitation courants) utilise des commandes et des noms de fichiers indépendants de la casse. La dépendance à la casse est cependant une caractéristique d'UNIX qui est vigoureusement défendue par ses défenseurs. Cela peut être assez déroutant pour les utilisateurs d'autres systèmes d'exploitation. En général, les commandes UNIX sont très différentes des commandes utilisées dans d'autres systèmes. Même si le DEC-20 n'avait pas proposé de menu d'aide à la demande, l'utilisateur moyen aurait probablement pu deviner les commandes à saisir : DELETE pour supprimer un fichier, COPY pour copier un fichier, RENAME pour renommer un fichier, etc. Sous UNIX, comment supprimer un fichier ? SUPPRIMER? Non... EFFACER ? Non, c'est "rm" (en minuscules uniquement !).

Sans manuel à vos côtés, comment pourriez-vous le découvrir ? Même si vous connaissiez "man -k" (recherche par mot-clé dans le manuel en ligne), UNIX ne vous aide pas beaucoup : "man -k delete" ne donne rien de pertinent, pas plus que "man -k delete" . Mais au moins « rm » évoque quelque peu le mot « supprimer », et en effet « man -k remove » aurait découvert la commande insaisissable (les premières versions d'UNIX avaient un nom encore plus insaisissable pour cette commande : dsw, une abréviation de "do swedanya", russe pour au revoir, translittéré en polonais ou peut-être en allemand ; ce n'est pas le seul endroit où la censure a été à l'œuvre... Les versions "standard" actuelles d'UNIX n'ont pas de commande "help", mais en versions antérieures,

Je (fdc) ne me souviens pas où j'ai trouvé la référence "do swedanya", mais c'est évidemment une légende urbaine. Dennis Ritchie a déclaré dans un article sur Usenet de 1981 que l'étymologie réelle est « supprimer des commutateurs » ; le programme dsw PDP-7 original était un précurseur de "rm -i" (supprimer de manière interactive), dans lequel les commutateurs du processeur assuraient l'interaction.

Un avantage particulier de TOPS-20 est la conservation de plusieurs générations (versions) de chaque fichier, ce qui donne la possibilité de revenir à une version antérieure si la dernière souffre d'une erreur humaine, d'une folie ou d'une tragédie. Ceci, associé à la possibilité de ressusciter un fichier après sa suppression, confère un sentiment de confort et de sécurité qui ne peut être apprécié qu'une fois passé à un système de fichiers plus conventionnel et précaire. Si vous supprimez un fichier sous UNIX ou créez un nouveau fichier portant le même nom qu'un fichier existant, l'ancien fichier disparaît tout simplement. La commande "rm *" sous UNIX est tout simplement trop puissante et trop silencieuse. Oui, il a fait ce que vous avez dit, mais comment sait-il que vous pensiez ce que vous avez dit ? UNIX ne sauve pas les utilisateurs d'eux-mêmes.

Une autre caractéristique importante du TOPS-20 est le nom logique de l'appareil, qui peut être défini de manière infinie pour le système dans son ensemble et pour chaque utilisateur individuel. Chaque nom logique peut pointer vers un périphérique et/ou un répertoire particulier, ou vers toute une série d'entre eux, à rechercher dans l'ordre. Ceux-ci sont intégrés au système d'exploitation lui-même, alors que les notions de PATH et CDPATH sont réfléchies après coup, greffées dans le shell UNIX, non disponibles à partir des programmes et non applicables en dehors de leurs sphères d'opération limitées.

Ensuite, nous avons les langages de programmation qui ne seraient plus disponibles : ALGOL (60 & 68), APL, BASIC, BCPL, BLISS (10, 11 et 36), CPL (et "vrai" PL/I), ECL, FOCAL. , PPL, SAIL, SIMULA, SNOBOL, ... Et TECO ! Et MACRO et Midas et Fail... En fait, peu de gens en manqueront, à l'exception possible d'APL (utilisé dans certaines classes) et de SNOBOL (que l'on peut encore trouver pour UNIX sur certaines plates-formes).

Bien entendu, toutes nos applications maison écrites en langage assembleur ont dû être refaites pour UNIX : saisie et gestion des identifiants utilisateur (par opposition à l'édition du fichier passwd), comptabilité, restrictions utilisateur (ACJ, Omega). Et une fonctionnalité dont nous ne pourrions plus jamais nous passer est MM, un puissant système de gestion de courrier utilisable aussi bien par les novices que par les experts.

Du côté positif, nous n'abandonnerions pas EMACS, Scribe, TeX, Kermit ou les utilitaires TCP/IP Telnet et FTP. Tous ces programmes sont disponibles sous une forme ou une autre pour UNIX. Certaines implémentations UNIX sont des améliorations définitives, comme GNU EMACS de la Free Software Foundation, sans les limitations de mémoire de TOPS-20 EMACS. Il existe également un Fortran de haute qualité de DEC pour nos ingénieurs, et bien sûr l'ensemble des environnements de programmation C et LISP pour les étudiants CS et autres développeurs de logiciels, ainsi qu'un ensemble d'utilitaires puissants de manipulation de texte comme sed, grep, awk, lex et yacc. , dont les fonctions doivent ressortir clairement de leurs noms.

L'installation de VAX a été beaucoup plus rapide que l'installation typique de DEC-20. Les performances du 8650 étaient assez rapides et sa fiabilité excellente. Après un an, le 8650 a été vendu et un deuxième DEC-2065 a été échangé à DEC contre un VAX 8700. Le 8700 a à peu près la même puissance que le 8650, mais, contrairement au 8650, il est compatible avec les nouveaux appareils BI, et évolutif vers un modèle VAX plus grand s'il s'essouffle.

Il s'est toutefois avéré qu'au moment de l'expansion, il était plus rentable d'acheter des systèmes Sun UNIX plutôt que de mettre à niveau le 8700 vers un VAX plus grand. C'est un choix que vous n'avez pas avec un système d'exploitation propriétaire comme TOPS-20, VMS, etc. La conversion d'un VAX en SUN nécessite un certain « abandon » (par exemple DECnet), mais pas autant que le voyage depuis DEC. -20 au VAX, et en retour vous obtenez une machine très puissante dans une fraction de l'espace au sol du VAX - ce que le Jupiter aurait dû être, mais avec UNIX au lieu de TOPS-20.

[ Haut ] [ Suivant ] [ Précédent ]

PRINCIPAUX PROBLEMES DE CONVERSION

[Rappelez-vous : cela a été écrit en 1988.]

Une grande question lors de la conversion vers UNIX était la formation des utilisateurs. UNIX n'aide pas les utilisateurs comme le fait TOPS-20. Il n'y a pas de style COMND ? help, il n'y a même pas de commande "help". Les commandes elles-mêmes n'ont pas de noms intuitifs : un utilisateur aurait du mal à deviner que "mv" est la commande pour renommer un fichier, "cat" pour saisir un fichier, etc. Comment les utilisateurs sauront-ils comment répondre à la sourdine ? "$" (ou "%") les regardant en face ? Devrions-nous leur écrire un shell convivial ? Ou des tonnes de tutoriels et de manuels de référence ?

Malgré sa concision énigmatique, UNIX est devenu très populaire. Les systèmes UNIX fonctionnent sur des ordinateurs de toutes sortes, des PC aux superordinateurs. Par conséquent, les librairies informatiques regorgent de livres du type "Teach Yourself UNIX". Notre sentiment a été que, aussi énigmatique et hostile qu'UNIX lui-même puisse être, il ne devrait pas être modifié. Sinon, nous perdons la compatibilité avec les autres systèmes UNIX, les livres et les articles, nous nous laissons exposés à un cauchemar de maintenance et nous laissons nos utilisateurs se retrouver dans une rude surprise s'ils rencontraient un jour un véritable système UNIX.

Un autre problème est le système de messagerie. En tant qu'agent de messagerie au niveau utilisateur, vous avez le choix entre la messagerie UNIX ou GNU EMACS RMAIL. Le courrier UNIX est primitif et peu intuitif, et RMAIL n'est accessible qu'à ceux qui connaissent EMACS. RMAIL présente l'avantage d'une interface cohérente - pas de saut dans et hors de l'éditeur - mais il dispose d'un répertoire de commandes relativement limité.

Nos utilisateurs se sont très bien habitués au courrier électronique, en grande partie grâce à la puissance, à la commodité et à la convivialité de MM. La plupart des plus grands utilisateurs de MM sont des professeurs ou des administrateurs qui n'ont pas besoin d'apprendre un nouveau système de messagerie. Mais un programme aussi puissant que MM nécessite beaucoup de commandes, et lorsque vous disposez de nombreuses commandes, vous avez besoin du type d'aide intégrée fournie gratuitement sur le DEC-20. Des commentaires similaires s'appliquent à d'autres programmes complexes, par exemple (sur notre système) les programmes de saisie et de gestion des identifiants utilisateur, l'interface opérateur (comme OPR sur le DEC-20), etc.

Pour cette raison, nous avons décidé de « transformer notre nouveau système en notre ancien bien-aimé » en écrivant un package COMND pour UNIX. Ce package, CCMD, a débuté dans le cadre du projet "Hermit", un effort de recherche de Colombie financé par DEC, 1983-87. Nous essayions de concevoir une architecture réseau qui permettrait à différents types de PC — IBM, Rainbow, Pro-380, VAXstation, SUN, Macintosh, etc. — d'accéder aux fichiers et services de nos mainframes DEC-20 et IBM de manière cohérente et manière transparente. Le projet a finalement échoué, car la technologie nous a dépassés (connexions et passerelles Ethernet et Token Ring bon marché, Sun NFS, serveurs de fichiers Macintosh basés sur VAX, etc.).

CCMD, entièrement écrit en C, exécute toutes les fonctions COMND et plus encore, analyse à partir du terminal, d'un fichier, d'une entrée standard redirigée ou d'une chaîne en mémoire. Il n’est orienté vers aucun clavier ou écran spécifique. Cela ne favorise ni le novice ni l’expert. Il fonctionne sous 4.xBSD, Ultrix, AT&T System V, SunOS et MS-DOS, et il devrait être facilement portable vers VAX/VMS et tout autre système doté d'un compilateur C.

CCMD est une implémentation COMND complète, permettant des FDB chaînés (par exemple analyser un nom de fichier, un numéro ou une date), la redirection de l'entrée de commande, etc. Les ajouts au DEC-20 COMND JSYS incluent des listes d'aide "?" pour la correspondance des noms de fichiers, la complétion partielle des noms de fichiers (jusqu'au premier caractère qui n'est pas unique), un analyseur d'heure et de date très flexible et des types de données supplémentaires.

Grâce à CCMD, les programmeurs de Columbia ont pu écrire un clone de DEC-20 MM entièrement en C. Il possède toutes les fonctionnalités de DEC-20 MM, plus quelques autres. Il gère une variété de formats de fichiers courrier, notamment DEC-20, Babyl (RMAIL) et mbox (courrier UNIX). Il utilise sendmail UNIX comme système de livraison et doit être adaptable aux services de livraison des systèmes non UNIX.

Les auteurs – et un nombre surprenant d’autres personnes dans le monde – utilisent encore aujourd’hui Columbia MM comme client de messagerie (mais, hélas, plus chez Columbia depuis 2015). Il peut être construit et installé sur (au moins) Linux, FreeBSD, OpenBSD, NetBSD, Solaris et SunOS. Vous pouvez le trouver ICI .

[ Haut ] [ Suivant ] [ Précédent ]

DERNIER MOTS...

[Rappelez-vous : cela a été écrit en 1988.]

La Colombie est très décentralisée et est confrontée à la compression budgétaire commune à tous les établissements d'enseignement supérieur. Il n’existe pas de mandat central pour installer des postes de travail coûteux sur chaque bureau, connectés par des réseaux de fibre optique Gigabit. Les étudiants, les professeurs et le personnel utilisent pour la plupart leurs propres fonds ou ceux du département pour obtenir le meilleur PC qu'ils peuvent utiliser, généralement un PC IBM ou un Macintosh avec une interface RS-232. La plupart des utilisateurs ne communiquent que sporadiquement via une ligne commutée ou en transportant une disquette vers un laboratoire informatique public, où les ordinateurs sont connectés au réseau ou à une imprimante laser.

Alors que les PC deviennent moins chers et plus puissants, que reste-t-il à faire de manière centralisée ? Certains prétendent que tout ce qu'un VAX ou un DEC-20 peut faire peut également être fait sur un PC. Les seules exceptions pourraient être les applications très volumineuses, les bases de données partagées et/ou volumineuses et/ou en constante évolution, et la communication en général — réseaux étendus, courrier, bibliothèques de programmes partagées, tableaux d'affichage, conférences, ...

Mais la décentralisation massive de l’informatique entraîne une énorme duplication des efforts et des dépenses en matière de matériel, de licences de logiciels et de maintenance. Tout le monde devient gestionnaire de système, effectuant des sauvegardes, du dépannage, de l'installation et du débogage de logiciels, du conseil, de la formation, de la recherche de pièces. Les chercheurs qui étaient autrefois sur la piste d'un remède contre le cancer ou le SIDA manipulent désormais les commutateurs DIP, exécutent les utilitaires Norton sur leurs disques durs fracturés, parcourant les dernières pages de BYTE à la recherche de bonnes affaires. Chaque personne ou groupe peut disposer d'une collection unique de logiciels et de matériel, ce qui rend l'enseignement, la collaboration et la plupart des autres fonctions beaucoup plus difficiles qu'à l'époque du temps partagé. Et il faut trouver de l'espace pour le matériel informatique dans pratiquement tous les bureaux et dortoirs, plutôt que dans une zone centrale. Un jour, les responsables du budget pourraient remarquer l’effet cumulatif de toute cette informatique distribuée et le pendule commencerait à revenir dans l’autre sens. Quelle est l'expression "économies d'échelle" ?...

Il y a quelques années, pendant la crise du carburant, il y avait un article dans le journal sur le retour des clippers... Les grands systèmes DEC, les clippers de l'ère du temps partagé, ne reviendront jamais, mais ils vivront dans les logiciels qu'ils ont engendrés. — EMACS, TeX, Scribe, Spell, MM, Kermit, dialectes LISP avancés, etc. Pendant ce temps, alors que l'industrie informatique s'efforce de transformer les PC en systèmes multi-utilisateurs et de réinventer le multitraitement, la sécurité et d'autres concepts oubliés, il pourrait être utile de s'arrêter sur les dernières décennies, lorsque le coût et les limites des équipements informatiques ont obligé les concepteurs et les codeurs à soyez... eh bien, plus intelligent.

[ Haut ] [ Suivant ] [ Précédent ]

ÉPILOGUE

(janvier 2001)

Aujourd'hui, alors que vous pouvez entrer dans un magasin de détail ordinaire et acheter un ordinateur avec 10 fois la puissance (et 100 fois la mémoire principale et 1 000 fois la capacité du disque) du plus grand et du plus rapide KL10 jamais conçu pour moins de 1 000 $, branchez-le sur une prise murale ordinaire et une prise téléphonique (ou un décodeur câble, etc.), et être sur Internet en quelques minutes avec des graphiques en couleur, de la vidéo, du son, et qui sait quoi d'autre, nous pourrions facilement oublier comment les ordinateurs ont évolué depuis leur statut de grand calculatrices autonomes à programme stocké en « communicateurs ». Au moins pour nous, à l'Université de Columbia, le changement a commencé avec les grands systèmes DEC qui nous ont exposés simultanément au partage de fichiers, au courrier électronique et aux réseaux locaux et étendus, ouvrant ainsi des possibilités de collaboration et de communication au travail et dans la vie : sur l'ordinateur, sur le campus et dans le monde entier.

L’autopsie du PDP-10 a été longue et douloureuse (qui l’a tué et pourquoi, comment aurait-il pu survivre et à quoi ressemblerait le monde aujourd’hui s’il l’avait fait), mais ceux qui aimeraient encore avoir un aperçu de la période passionnante des années 1970 et les années 80, lorsque les ordinateurs sont devenus un phénomène culturel et qu'un moyen de communication peut désormais le faire avec plusieurs projets d'émulation logicielle PDP-10 en cours. Le plus grand héritage de cette époque se trouve peut-être dans le mouvement actuel du logiciel ouvert, dans lequel les développeurs du monde entier coopèrent sur des projets allant des systèmes d'exploitation (Linux, FreeBSD, etc.) aux applications de toutes sortes, tout comme le PDP-10 ARPANET original. les "hackers" l'ont fait ( la question de savoir s'il s'agit-il d'un modèle commercial viable est une autre question :-)

Pendant ce temps, beaucoup d'entre nous qui ont vécu cette époque conservent nos vieilles habitudes, utilisant toujours des applications basées sur du texte telles que EMACS et MM plutôt que leurs remplacements d'interface graphique à la mode mais exigeants en main-d'œuvre, mais sur des plates-formes UNIX telles que Linux au lieu de PDP-10. Chaque fois qu'un nouveau virus PC plonge la planète entière dans le chaos et la panique, nous le remarquons à peine . Il y a quelque chose à dire sur les anciennes méthodes.