Das Decsystem-20 An Der Columbia University (1977-1988)

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

Frank da Cruz und Christine Gianone

Das Kermit-Projekt

Columbia University, New York City, 29. Dezember 1988; Copyright © 1988, 2021,

Frank da Cruz und Christine M. Gianone,

Alle Rechte vorbehalten.

Sehen Sie sich ein kürzlich ausgegrabenes Video der Stilllegung eines DEC-20 der Columbia University im Jahr 1986 an:

Videogalerie mit Screenshots

Eine nicht-technische Reminiszenz, die 1988 (anlässlich der Abschaltung des letzten DECSYSTEM-20 der Columbia University) für ein Digital Press-Buch geschrieben wurde, das mit einer Reihe von Artikeln an die 36-Bit-Maschinen von DEC erinnern sollte, aber nie veröffentlicht wurde. Kleinere Änderungen, Anmerkungen, Glossar, Links und HTML-Formatierung wurden im Januar 2001 hinzugefügt (und danach von Zeit zu Zeit kleinere Aktualisierungen). Weitere Informationen zur Geschichte der Informatik an der Columbia University finden Sie HIER .

HINWEIS: Dieser Artikel wurde am 18. Januar 2001 mit „ Schrägstrichen“ versehen und von vielen Leuten gelesen, die keine Ahnung hatten, worum es geht. Bitte beachten Sie, dass es sich hier nicht um eine Einführung oder Erklärung der einflussreichen 36-Bit-Computer der Digital Equipment Corporation (DEC) von 1964-1988 handelt; Vielmehr sollte es ein Aufsatz in einem Buch sein, in dem andere Aufsätze die Architektur und Geschichte der Technologie erklären würden. Einige aktuelle Websites finden Sie im Abschnitt LINKS am Ende.

Für diejenigen, denen das Konzept eines 36-Bit-Computers seltsam vorkommt: Der allererste kommerzielle Binärcomputer (im Gegensatz zum Dezimalcomputer) war der IBM 701 , der erstmals 1952 online ging. Er hatte ein 36-Bit-Wort. Es folgte 704 (wo 1953–57 die erste Hochsprache, Fortran, entwickelt wurde und deren 6-Bit-BCD-Zeichensatz und 36-Bit-Wort die 6-Zeichen-Beschränkung für Fortran-Variablennamen erklären), die 709 , 7090 und 7094 , alle 36 Bit. Die 36-Bit-IBM-Maschinen waren die Geburtsstätte von LISP (*) und ( wohl ) des Timesharings (MITs Compatible Time Sharing System, CTSS, etwa 1962) und waren auch die Inspiration fürDECs 36-Bit-PDP-6 (1964), der Vorläufer von PDP-10 und DECSYSTEM-20 , das bis 1988 bestand, dem Jahr, in dem DEC die Produktion von 36-Bit-Maschinen einstellte. Somit waren 36-Bit-Architekturen von 1952 bis 1988, also 36 Jahre lang, herausragende (und in vielerlei Hinsicht dominierende) Merkmale der Computerlandschaft .

List Processing Language, John McCarthy, Stanford University, 1960, immer noch die Hauptsprache für die Forschung im Bereich der künstlichen Intelligenz. CAR und CDR von LISP sind IBM 704-Konzepte: Inhalt des Adressteils des Registers und Inhalt des Dekrementteils des Registers – dh die linke und rechte Hälfte des 36-Bit-Wortes. 36-Bit-Maschinen mit ihren linken und rechten 18-Bit-Halbwörtern sind perfekte LISP-Maschinen.

EINFÜHRUNG

Bis Mitte der 1970er Jahre war die Columbia University fest im Batch-Modus-Computing von IBM Mainframe OS/360 verankert. Der Bereich „ Self-Service-Input/Output “ wurde voller Stolz benannt, weil er einen großen Sprung nach vorn im Vergleich zu den Tagen darstellte, als Studenten und Forscher den Betreibern bescheiden ihre Kartendecks präsentierten und am nächsten Arbeitstag für ihre Ausgabe zurückkamen – normalerweise nur, um sie vorzufinden Ihr SYSMSG war voller unverständlicher Beschwerden, deren schmerzhafte Entschlüsselung den frustrierten Benutzer im Allgemeinen zu einem fehlenden Komma oder einem zusätzlichen Leerzeichen in der Job Control Language führte. Oder wenn das JCL die Inspektion bestanden hatte, gab es eine 3 Fuß dicke Kernschüttung, mit der man sich zusammenrollen konnte. Der SSIO-Bereich war ein Raum, erfüllt von der atemberaubenden Kakophonie der Tastatureingaben und dem Kreischen der furchteinflößenden 1403-Drucker von IBM, das Stakkato-Flattern von Kartenlesern , Kartensortierern und Dolmetschern ; Besorgte Menschenmengen versammelten sich um die Drucker, hüfthoch in weggeworfenen Drucksachen...

Columbias IBM 360 Model 91 mit seinem 360/75-Frontend war einer der größten, schnellsten, schwersten und lautesten Computer der Welt, als er Ende der 1960er Jahre installiert wurde. Es umfasste mehrere Hektar Grundfläche, und man konnte die magnetischen Kerne durch Fenster in den 6 Fuß hohen Kernspeicherboxen betrachten , die in Reihen standen und im Fluchtpunkt verschwanden. Die Stromversorgung erfolgte durch einen rumpelnden gusseisernen Motorgenerator, der so groß war wie ein kleiner Lastwagen, und die Kühlung erfolgte durch gekühltes destilliertes Wasser (das in großen Glasflaschen in Holzkisten aus Deer Park geliefert wurde), das durch kilometerlange interne Rohrleitungen gepumpt wurde. Das CPU-Bedienfeldhatte mehr Lichter als der Times Square. Der Legende nach befand sich unter den Tausenden von Schaltern und Knöpfen einer, dessen tödliche Mission „Bulb Eject“ war – der sichere Tod für jeden, der ihn drückte. Das Bedienfeld liegt jetzt [1988] im Computermuseum in Boston in Ruhe, seine hypnotischen Glühbirnen sind für immer gedimmt ( 1 ).

Dieses massive graue und blaue Stonehenge, dessen dicke Tentakel bis in den SSIO-Bereich reichten, führte für unsere Ingenieure schwerfällige Fortran-„Codes“ aus: verdrehte Brücken; unglückselige Substanzen mit Neutronen bombardieren; Berechnen von Pi in Millionen von Ziffern; das Erdmagnetfeld in Musik umwandeln... Für unsere Sozialwissenschaftler sagte es Jahr für Jahr den Ausgang der Präsidentschaftswahlen von 1956 mit tödlicher Genauigkeit voraus. Für die Administratoren spuckte es Gehaltsschecks, Abschriften und Buchhaltungsberichte aus. Und schließlich wurde ein kleiner Teil davon unseren Ingenieurstudenten zugewiesen, die ihre mühsam erstellten DO-Schleifen und GOTOs auf Taylors Reihen, die Simpson-Regel, die Gauß-Quadratur und die Laplace-Transformation anwendeten. Diese Studenten hatten eine relativ einfache Aufgabe: das Programm schreiben, Legen Sie es in ein Sandwich aus magischen JCL-Karten, führen Sie das Sandwich dem Kartenleser zu und sammeln Sie die resultierende Ausgabe. Viele Lehrer blickten mit melancholischer Vorliebe auf diese einfachen Tage zurück, während die Erinnerungen der Schüler eher von Bildern glitschiger Finger heimgesucht wurden, die Stapel heruntergefallener Lochkarten aufsammelten.

In den frühen 1970er Jahren tauchten Terminals auf, zunächst nur verstreut unter den zwielichtigen Systemprogrammierern auf dem Olymp, die in geheimnisvollen Sprachen mit „Terminalmonitoren“ mit Namen wie Milten, Cleo, Orvyl und Wylbur und schließlich APL kommunizieren konnten und TSO (ersteres ist das „Irtnog“ der Computersprachen, letzteres eine Form von JCL, die am eigenen Terminal eingegeben wird). Die Interaktion mit dem Computer war reizvoll und dennoch unbefriedigend. Die Befehle waren unklar und die Berechnung befand sich – abgesehen von APL – immer noch im Stapel.

Im Jahr 1975 kam unser erstes echtes Timesharing-System auf den Markt, ein DEC PDP-11/50 mit dem Betriebssystem RSTS/E. Dies sollte ein Low-Budget-Experiment im echten interaktiven Computing werden. Basierend auf der BASIC-Sprache ermöglichte RSTS bis zu 32 gleichzeitigen Benutzern, die bei DECwriters saßen, zu programmieren, zu debuggen, miteinander zu kommunizieren und sich allgemein schlecht zu benehmen – und das alles in Echtzeit. RSTS erwies sich als äußerst beliebt und der PDP-11 wurde bald von eifrigen Studenten überwältigt.

Die Wahl fiel auf DEC, weil IBM damals kein interaktives Timesharing für allgemeine Zwecke anbot. Im Vergleich zu den anderen Konkurrenten war das DEC-Angebot besser entwickelt, ausgereifter und ... unterhaltsamer. Und RSTS wurde als Betriebssystem ausgewählt und nicht beispielsweise UNIX, weil Version 6 von UNIX ein mächtiges, vertrauenswürdiges System war, das jedem alles erlauben konnte. Wir hatten die Idee, dass das System eine gewisse Rolle dabei spielen sollte, Benutzer voreinander und vor sich selbst zu schützen. Während UNIX in diesem Bereich kaum oder gar keine Möglichkeiten bot, war RSTS nicht ohne eigene Schwächen. Benutzer lernten bald, dass sie alle TTYs zuweisen konnten, sodass sie niemand anderes verwenden konnte. Besser noch: Nach der Zuweisung eines TTY könnten sie darauf ein Programm ausführen, das sich als Anmeldevorgang ausgibt.

WILLKOMMEN T@\R\~~~~xxx }}}}}~~

Andere findige Benutzer stellten fest, dass sie, wenn sie eine neue Datei für den datensatzorientierten Zugriff öffneten, Datensätze lesen konnten, bevor sie sie schrieben, und so alte Daten aus den gelöschten Dateien anderer Benutzer oder der Systemkennwortdatei abrufen konnten.

Und irgendwann wurde unser System von einer Gruppe von Teenagern aus einer nahegelegenen Privatschule befallen, die durch Ausnutzen eines Fehlers im Anmeldevorgang eingebrochen waren. Sie hatten mehrere Wochen lang mit dem System zu kämpfen, bevor sie entdeckt wurden, und es dauerte mehrere Tage rund um die Uhr, um die zahlreichen Falltüren und Zeitbomben zu beseitigen, die sie zurückgelassen hatten.

Trotz seiner Probleme erwies sich RSTS als recht beliebt und wurde schnell überlastet. Das Experiment wurde für erfolgreich erklärt und wir begannen, uns nach etwas Größerem und etwas Anspruchsvollerem umzusehen – BASIC war nicht gerade die Sprache der Wahl unter Informatikern. Ungefähr zu diesem Zeitpunkt kündigte DEC erstmals das DECSYSTEM-20 an (sein Logo ist im Gegensatz zu dem seines älteren Cousins, dem DECsystem-10, nur in Großbuchstaben geschrieben)., soll ein Versehen der Feststelltaste auf der Markenanmeldung gewesen sein). Bevor wir uns das System überhaupt angesehen haben, zwangen wir die Marketingleute, technische Hilfe in Anspruch zu nehmen, und befragten sie gnadenlos, ob Benutzer alle Geräte zuweisen, die Festplatte füllen, Control-C aus dem Anmeldevorgang entfernen und sich gegenseitig damit bombardieren könnten dumme Nachrichten, auch wenn eine Datei beim Löschen „gereinigt“ wurde. Als alles zu unserer Zufriedenheit schien, haben wir uns das System angeschaut.

Wunder und Staunen, dieser Computer weiß, was Sie eingeben werden, und gibt es für Sie ein! Naja fast. Aber seine Reize waren auf den ersten Blick erkennbar. Wenn Sie nicht wissen, was Sie eingeben sollen, geben Sie ein Fragezeichen ein. Daraufhin werden die Möglichkeiten für Sie aufgelistet. Plötzlich wurde das „Lückenausfüllen“ eher zu einer Art „Multiple-Choice“. Nun, natürlich kann es es Ihnen sagen! Es kennt die Möglichkeiten, also warum sollte es es Ihnen nicht sagen??? Eine Frage, die vor zehn oder fünfzehn Jahren vielleicht zu gutem Zweck gestellt worden wäre (Visionen von erfahrenen Systemprogrammierern, die Handbücher nach Handbüchern durchwühlen, auf der Suche nach dem, was sie in das nächste Feld eines obskuren Befehls eingeben sollen ... selbst auf manchen Maschinen ein alltäglicher Anblick dieser Tag). Und das "?" war keine hochprivilegierte Funktion (wie der Besitz des manuellen Satzes) – selbst NORMALER BENUTZER konnte sie nutzen. Erstaunt stellten wir fest, dass Fehlermeldungen in einfachem, verständlichem Text und nicht in 17-stelligen Hexadezimalzahlen ausgegeben wurden, sodass sie auch ohne ein Buch über „Meldungen und Codes“ verstanden werden konnten.

Wir waren sofort von der Freundlichkeit, der lockeren Art und dem Humor begeistert. Wir wussten erst später, dass COOKIE (das heute unter UNIX als „Fortune“ überlebt) kein Standardbestandteil des Systems war, und dann war da noch TECO ( 2 ):

@Liebe machen

nicht Krieg?

Das DEC-20 war ein echtes Allzweck-Timesharing-System. Es basierte nicht auf einer bestimmten Sprache, da RSTS auf BASIC basierte. Es bot eine breite Palette an Compilern, Interpretern, Texteditoren und Dienstprogrammen, die viele Jahre der Softwareentwicklung von TOPS-10 und TENEX widerspiegeln. Es könnte nicht nur unsere RSTS-Benutzer, sondern auch viele unserer IBM-Mainframe-Fortran- und APL-Benutzer ansprechen, und seine Benutzerfreundlichkeit würde auch viele Erstbenutzer anziehen.

Unser neuer DEC-20 kam am 29. Juni 1977 mit der TOPS-20-Version 1B auf den Markt. Die Installation wurde am 26. Juli abgeschlossen. Im Vergleich zum IBM 360/91 und sogar dem DEC PDP-11 war es enttäuschend funktionslos – keine nennenswerten Lichter, keine Schalter zur Dateneingabe, keine Wählscheiben, keine Motoren, keine Pumpen ... Doch beim DEC-20 war es so unendlich leistungsfähiger als der schwache PDP-11. Es war mit vier hochmodernen RP06 ( 3 )-Festplattenlaufwerken ausgestattet, die nie voll werden konnten, und unglaublichen 256 KB Hauptspeicher – Worte, keine Bytes! Eine solche Maschine würde unsere Computeranforderungen für den Unterricht in den kommenden Jahren erfüllen.

Immer wenn eine Computereinrichtung einen neuen Computertyp erhält, beginnen die Programmierer sofort mit einer hektischen Flut von Aktivitäten, um das neue System in ihr geliebtes altes System umzuwandeln. Im Auslieferungszustand war der einzige Editor des DEC-20 (neben einer inoffiziellen Kopie von TECO) der kryptische, zeilenorientierte EDIT, der von TOPS-10 SOS abstammt. Unsere Benutzer waren an Wylbur gewöhnt, den viel weniger kryptischen Zeileneditor auf unserem IBM 360/91, also machten wir uns sofort daran, eine Version von Wylbur für den DEC-20 zu schreiben, um unseren IBM-Benutzern das Gefühl zu geben, zu Hause zu sein.

Wir begannen, die Assemblersprache DEC-20 zu lernen und das Monitor Calls Reference Manual zu lesen. Wir stellten bald fest, dass dies tatsächlich eine wunderbare Maschine war. Der Befehlssatz und das Repertoire an Monitoraufrufen (JSYS) waren erstaunlich umfangreich. Zu den Monitoraufrufen gehörte ein spezieller Satz, anders als alles, was wir je gesehen hatten: In das Betriebssystem selbst waren Standardfunktionen für die Konvertierung zwischen internen und externen Darstellungen aller verschiedenen Arten von Daten integriert, die für das System von Bedeutung waren: Zahlen in verschiedenen Radices, Zeichen, Zeichenfolgen, Dateinamen, Verzeichnisnamen, Datums- und Uhrzeitangaben. Programmierer aus früheren Zeiten wussten, dass der schwierigste und mühsamste Teil beim Schreiben eines interaktiven Programms darin bestand, vom Benutzer eingegebene Daten anzufordern, zu akzeptieren und zu validieren.

Das Beste daran ist, dass diese Konvertierungsfunktionen in einem einzigen Paket namens COMND JSYS zusammengefasst wurden, das von Dan Murphy entwickelt wurde und es Programmierern ermöglichte, in ihren Programmen dieselbe „Benutzeroberfläche“ zu verwenden wie im TOPS-20 Exec: full Aufforderung, Bearbeitung, Hilfe in jedem Bereich; Abkürzung und Erkennung von Schlüsselwörtern und Schaltern; Vervollständigung von Dateinamen; Vergebung, wenn der Benutzer einen Tippfehler macht usw.

Mit COMND JSYS codierte Programme hatten viele Vorteile. Sie waren freundlich, hilfsbereit und konsequent. Alle mit COMND geschriebenen Programme funktionierten auf die gleiche Weise: Geben Sie „?“ ein. Um herauszufinden, um welche Befehle oder Optionen es sich handelt, geben Sie ESC ein, um das aktuelle Feld auszufüllen (falls möglich) und eine Eingabeaufforderung für das nächste Feld zu erhalten. Die Leute könnten das „?“ verwenden. und ESC-Funktionen großzügig, um sich durch ein neues Programm zurechtzufinden, und könnten später aus Gründen der Geschwindigkeit knappe, abgekürzte Befehle eingeben. Dieser als „Menü auf Abruf“ bezeichnete Ansatz begünstigt nicht den Anfänger gegenüber dem Experten (wie es bei menüorientierten Systemen der Fall ist) und auch nicht den Experten gegenüber dem Anfänger (wie es bei den kryptischen, knappen Befehlssätzen von APL oder UNIX der Fall ist).

Unser neuer Wylbur-ähnlicher Editor namens „Otto“ wurde geschrieben, um die Vorteile von COMND JSYS voll auszunutzen. Trotz all seiner hartnäckigen Einschränkungen war Otto sofort ein Erfolg, da es IBM-Mainframe-Benutzern den problemlosen Wechsel in die neue Umgebung ermöglichte und sie gleichzeitig mit den Methoden des DEC-20 vertraut machte. Sein verborgener Zweck bestand darin, sie süchtig zu machen und sie dann so zu frustrieren, dass sie sich die Zeit nehmen würden, einen „richtigen“ Editor zu erlernen.

PROGRAMMIERSPRACHEN

Im Laufe der Monate nahmen wir Kontakt mit anderen DEC-36-Bit-Sites auf, viele von ihnen – Stanford, CMU, MIT, Rutgers, BBN, SRI – mit langjähriger TOPS-10-, TENEX-, WAITS- oder ITS-Erfahrung Von ihnen erhielten wir Programme, die uns noch viele Jahre lang beschäftigen sollten. Einige waren Fehlstarts, aber andere werden in irgendeiner Form bis weit ins nächste Jahrhundert hinein gedeihen, das Erbe des 10. und 20. Dezembers. Aus dieser Erfahrung lernten wir die Vorteile des Teilens kennen und wussten, dass wir, wenn wir jemals etwas von allgemeinem Nutzen hervorbringen sollten, es mit anderen teilen würden, im gleichen Sinne, wie diese Institutionen ihre Arbeit mit uns geteilt haben.

Unser Hauptziel bei der Erkundung dieser Websites bestand darin, herauszufinden, was sie im Bereich Programmierung tun. In der Konzeption kamen die Benutzer- und Systemschnittstellen des DEC-20 der Perfektion so nahe, wie man es sich damals (außerhalb von Xerox PARC) vorstellen konnte, in der Praxis wurde die Konzeption jedoch nur unvollständig umgesetzt. Die meisten Programmiersprachen stammten direkt von TOPS-10 und boten keinen Zugriff auf die TOPS-20-Monitoraufrufe oder das Dateisystem. Und dennoch waren wir fest davon überzeugt, dass wir im Zeitalter der strukturierten Programmierung keinen Code auf Systemebene in Assembler schreiben würden. Nach kurzen Flirts mit Bliss-10, BCPL, Simula und sogar einem frühen Portable C (das für die 36-Bit-Architektur schlecht geeignet war) entschieden wir uns für Sail der Stanford University als unsere „offizielle Sprache“. Doch mehrere Jahre der Hingabe an Sail führten schließlich zur Ernüchterung. Es gab zu viele Fehler, zu viel Abhängigkeit vom Laufzeitsystem und dem Wissen, wo es sich befand, zu viele Konvertierungen, die bei neuen Versionen von Sail oder TOPS-20 erforderlich waren, zu viele groteske Problemumgehungen, um das zu erreichen, was in Assembler selbstverständlich gewesen wäre – das Einzige Sprache, die die Maschine und das Betriebssystem wirklich versteht. Und von diesem Tag an erfolgte die gesamte Systemprogrammierung in Assembler. Doch mehrere Jahre der Hingabe an Sail führten schließlich zur Ernüchterung. Es gab zu viele Fehler, zu viel Abhängigkeit vom Laufzeitsystem und dem Wissen, wo es sich befand, zu viele Konvertierungen, die bei neuen Versionen von Sail oder TOPS-20 erforderlich waren, zu viele groteske Problemumgehungen, um das zu erreichen, was in Assembler selbstverständlich gewesen wäre – das Einzige Sprache, die die Maschine und das Betriebssystem wirklich versteht. Und von diesem Tag an erfolgte die gesamte Systemprogrammierung in Assembler.

Wie viele andere Dinge ist auch die Abhängigkeit vom Assembler gut und schlecht. Es war gut, weil es einen kreativen Nerv berührte – Programmierer wurden nicht durch die bürokratischen Anforderungen und autoritären Beschränkungen von Hochsprachen eingeschränkt, und sie hatten vollen Zugriff auf den Befehlssatz und das Repertoire an Monitoraufrufen der Maschine, die laut DEC- 20, waren eine Augenweide. Das Programmieren in Assembler hat einfach nur Spaß gemacht, und unsere Programmierer haben fröhlich Millionen von Codezeilen geschrieben, aber mit dem quälenden Gefühl, dass da etwas Sündhaftes drin war. Das lag an der schlechten Seite: Assemblersprachenprogramme sind spezifisch für die zugrunde liegende Maschine und das zugrunde liegende Betriebssystem. Was passiert mit diesen Programmen, wenn die Maschine verschwindet?

Dennoch war MACRO unwiderstehlich (MACRO wird hier als allgemeiner Begriff verwendet, der MACRO-10 und -20 von DEC sowie Midas von MIT und FAIL von Ralph Gorin umfasst). Im Gegensatz zu FORTRAN oder BASIC oder jeder anderen Sprache auf dem DEC-20 (mit Ausnahme von Sail, für das wir ein COMND-JSYS-Schnittstellenpaket geschrieben hattenMit MACRO können Sie echte DEC-20-Programme schreiben – Programme, die hilfreich, sanft und nachsichtig für den Benutzer sind. Für Assembler-Programmierer mit IBM 360-Hintergrund waren die Maschinenarchitektur und der Befehlssatz reizvoll. Ein linearer Adressraum mit 256 KB Wörtern (keine BALRs und USINGs mehr!), Hunderte exotischer Anweisungen ... Und der Assembler selbst ermöglichte relativ saubere, sogar „strukturierte“ Programme. Beispielsweise sind die Inline-Literale von MACRO nahezu äquivalent zu den „Begin ... End“-Blöcken von Algol oder Pascal, wodurch die schreckliche Spaghetti-Logik vermieden wird, die den meisten Assemblerprogrammen zu schaffen macht. Hier ist zum Beispiel eine IF-THEN-ELSE-Konstruktion mit mehreren Anweisungen in jedem Teil und ohne GOTOs oder Labels (entschuldigen Sie etwaige Fehler, das stammt aus dem Gedächtnis):

CAIL B, FOO ; WENN (b >= foo) DANN

PUSHJ P, [ ; BEGINNEN

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

SETOM WENIGER ; weniger = -1;

AOS (P) ; ENDE (ELSE-Teil überspringen)

POPJ P, ] ; ANDERS

PUSHJ P, [ ; BEGINNEN

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

SETZM WENIGER ; weniger = 0;

POPJ P, ] ; ENDE;

PSOUT ; Nachricht DRUCKEN;

Alles in eckigen Klammern ist ein Literal; Der Assembler findet einen Ort, an dem er es ablegen kann, und ersetzt das Literal durch die Adresse dieses Ortes. Somit kann (fast) jede Menge an Daten oder Code „inline“ platziert werden, anstatt in einem separaten Datenbereich. Und wie Sie dem Beispiel entnehmen können, können Literale verschachtelt werden. Auch andere gängige Kontrollstrukturen können mithilfe von Literalen simuliert werden, beispielsweise mit der CASE-Anweisung:

MOVEM B, @[EXP FOO, BAR, BAZ](A)

In diesem Beispiel wird B in FOO, BAR oder BAZ gespeichert, abhängig vom Wert von A. Eine solche Operation würde in den meisten anderen Assemblersprachen und in den meisten Hochsprachen viele Codezeilen erfordern.

Um das Ganze abzurunden, könnten Assemblersprachenprogramme interaktiv auf symbolischer Ebene mithilfe von „DDT“ debuggt werden – nicht Dichlor-Diphenyl-Trichlorethan, sondern einem „Dynamischen Debugging-Tool“, das entwickelt wurde, um die Fehler genauso effektiv zu beseitigen wie das Original weniger unerwünschte Nebenwirkungen (andere Debugging-Hilfsmittel trugen ähnlich insektizide Namen, wie RAID). Mit DDT ( 4) muss man sich nicht mehr durch dicke Hex-Dump-Ausdrucke wühlen, keine Druckanweisungen mehr einfügen und wieder zusammensetzen usw. usw. Die Befehlssyntax ist etwas abstrus und besteht hauptsächlich aus kryptischen Einzelbuchstaben, Satzzeichen, Tabulatoren und der großzügigen Verwendung von ESC („Altmode“)-Zeichen, oft verdoppelt. Aber DDT kann alles. Da es tatsächlich alle Computeranweisungen und Systemdienste ausführen kann, verwendeten die Entwickler des „Inkompatiblen Timesharing System“ (ITS) des MIT für den PDP-10 es als Befehlsinterpreter der obersten Ebene. Sprechen Sie über Benutzerfreundlichkeit...

Der DEC-10/20-Befehlssatz, Monitoraufrufe, Assembler und Debugger lockten viele ansonsten vernünftige Programmierer zu längeren Codierungssitzungen oder „Hack-Angriffen“. Es entstand eine Subkultur von DEC-10/20-Programmierern, die seltsame Wörter und Phrasen sprachen, deren Etymologie sich hauptsächlich auf das PDP-10-Hardware-Referenzhandbuch zurückführen ließ. Die von den Hackern hinzugefügte Zutat (damals kein abwertender Begriff) war die Aussprache von Mnemoniken, die nie für menschliche Sprachorgane gedacht waren (AOS, BLT, JRST, ILDB, HRROI) und die Ausweitung ihrer Bedeutung auf andere Lebensbereiche ( hauptsächlich Essen). Schließlich wurde dieses Lexikon von Guy Steele von der CMU und anderen als „Hacker's Jargon“ gesammelt und kodifiziert, ursprünglich als Datei veröffentlicht und später zu einem Buch erweitert (siehe Bibliographie).

DEC-10/20-Hacker waren zunächst eine kleine Gruppe, was hauptsächlich auf den Mangel an brauchbarer Dokumentation zurückzuführen war. Um ein funktionierendes Programm zu schreiben, kann man das Hardware-Referenzhandbuch, das Monitor Calls-Referenzhandbuch und das MACRO Assembler-Referenzhandbuch zu Rate ziehen. Bei diesen Handbüchern handelte es sich jedoch lediglich um Listen mit Anweisungen, Überwachungsaufrufen und Pseudooperationen, die nicht die geringste Vorstellung davon vermittelten, wie man ein Programm zusammenstellt. Im Jahr 1981 änderte sich die Situation dramatisch mit der Veröffentlichung von Ralph Gorins DEC-20-Buch zur Assemblerprogrammierung, und bald war die Welt mit DEC-20-Programmierern im Grundstudium übervölkert.

Chris Ryland und Frank arbeiteten 1979-80 an einem DEC-20-Leitfaden zur Assembler-Programmierung, aus dem vielleicht ein Buch geworden wäre, wenn Ralph uns nicht zuvorgekommen wäre :-) KLICKEN SIE HIER, um eine reine Textversion davon anzusehen . Kürzlich ausgegraben (September 2002), ca. 220 Seiten.

Dennoch war das Fehlen eines kohärenten Satzes höherer Programmiersprachen, die vollständig in das Betriebssystem und das Dateisystem integriert waren, einer der schwerwiegenden Mängel des DEC-20. Diese Schwäche wurde von DEC in VAX/VMS behoben, wo in verschiedenen Sprachen geschriebene Programme auf gemeinsame oder kompatible Laufzeitunterstützung zurückgreifen können und Systemprogramme in praktisch jeder Sprache geschrieben werden können – sogar BASIC oder FORTRAN.

Viele TOPS-10-Überbleibsel liefen – und werden bis zum letzten Atemzug des letzten DEC-20 noch laufen – im „Kompatibilitätsmodus“. Das bedeutete, dass in diesen Sprachen geschriebene Programme nur nach den TOPS-10-Regeln auf Dateien zugreifen konnten: keine langen Dateinamen, keine lustigen Zeichen in Dateinamen, keine expliziten Verweise auf Verzeichnisse oder Generationsnummern. Insbesondere Quellprogramme für die meisten Programmiersprachen wiesen diese Einschränkung auf: Die meisten Compiler waren nicht TOPS-20-isiert, und selbst wenn, wäre dies bei LINK nicht der Fall gewesen. Letztendlich bedeutete dies, dass der Benutzer TOPS-10 kennen musste, um TOPS-20 verwenden zu können, und dass Hochsprachenprogrammierern der Zugriff auf viele der Funktionen von TOPS-20 verwehrt blieb.

Entwicklerwerkzeuge

(Dieser Abschnitt wurde im Januar 2019 hinzugefügt.) Jahrzehnte später sind echte DECSYSTEM-20 schwer zu finden, aber Emulatoren existieren; Durchsuchen Sie Google, um sie zu finden. Die Verwendung eines DEC-20-Emulators ist genau wie die Verwendung eines echten DEC-20. Sie können beispielsweise Assemblerprogramme schreiben und ausführen. Dazu benötigen Sie die Handbücher. Hier sind einige lokal archivierte Kopien:

Titel	Thema	Datum	Format	Größe
DECsystem-10 DECSYSTEM-20 Prozessor-Referenzhandbuch	Architektur und Befehlssatz	Juni 1982	PDF	29 MB
DECSYSTEM-20 Macro Assembler Referenzhandbuch	Assembler-Handbuch	April 1978	PDF	5 MB
Referenzhandbuch für TOPS-20-Monitoranrufe	auch bekannt als JSYS-Handbuch (Systemdienste)	Dezember 1982	PDF	26 MB
TOPS-20 DDT-Handbuch	Dynamisches Debugging-Tool	Mai 1985	PDF	5 MB
SEGEL	Stanford-Sprache für künstliche Intelligenz	August 1976	PDF	5 MB

Sehen Sie sich das Kermit-Programm DEC-20 als Beispiel für die Assembler-Codierung an.

SAIL (eine Hochprogrammiersprache von Stanford) ist normalerweise nicht auf dem DEC-20 installiert. Wenn Sie also das Handbuch interessant finden, müssen Sie nach einem Download suchen.

Mit dem Wachstum zurechtkommen

Innerhalb eines Jahres war unser DEC-20 hoffnungslos überlastet, die durchschnittliche Belastung ging durch die Decke und die Scheiben füllten sich regelmäßig. In diesem Zustand blieb es noch ein weiteres Jahr, bis wir eine Möglichkeit fanden, eine zweite Maschine zu kaufen. Bald war auch dieser voll, und in den folgenden Jahren kamen ein dritter und ein vierter hinzu, dazu ein DEC-20 in der Informatikabteilung der Columbia University und ein weiterer am Columbia Teachers College. Die Systeme des Rechenzentrums wurden durch das Hinzufügen von Speicher und Festplatten und schließlich durch die Verbindung aller Systeme mit CFS sowie durch die Installation von RA-81-Festplattenlaufwerken und einem HSC-50 aufgerüstet. Schließlich wurden alle CPUs auf 2065er mit maximalem Speicher aufgerüstet, und wir konnten nichts weiter tun, um mehr Leistung aus ihnen herauszuholen. Wie andere DEC-20-Getreue hatten auch wir unseren Maschinenraum mit DEC-20 vollgestopft und hatten keinen Platz mehr. Unsere einzige Erweiterungsmöglichkeit wäre ein neues Modell mit mehr Leistung auf weniger Grundfläche. Mehrere Jahre lang unternahmen wir regelmäßig Reisen nach Marlboro, um eine bevorstehende Maschine zu besprechen. Eigentlich waren es 2 Projekte.

DOLPHIN begann als High-End-System, das eine wirklich verteilte 36-Bit-Architektur bieten sollte. Große DELFINE würden inmitten kleiner Einzelbenutzer-MINNOWS in einem Netzwerk mit hoher Bandbreite sitzen. Sowohl DOLPHIN als auch MINNOW erlagen technischen Problemen. DOLPHIN verwendete speziell entwickelte Motorola-Chips, die Probleme mit der Zuverlässigkeit hatten. Die dichte Verpackung von MINNOW, die so konzipiert war, dass sie in ein VT52-Terminalgehäuse passte , gepaart mit der Notwendigkeit eines lokal angeschlossenen RP06-Festplattenlaufwerks (!) waren der Untergang. Von der kommerziellen Nutzung war Ethernet noch Jahre entfernt, und auch das Netzwerkproblem blieb bestehen. [2]

Das JUPITER-Projekt entstand mehrere Monate nach der Absage von DOLPHIN. Sein Design beinhaltete keine verteilten MINNOWs, unterstützte aber die Forderung nach einem schnellen zentralen Prozessor. Es sollte 10+ MIPS haben und günstig sein. Ein langer und schwieriger Designprozess führte dazu, dass keines dieser Ziele erreicht wurde, und 1983 wurde das Projekt abgebrochen, obwohl Teile davon schließlich auf den Markt kamen – das CI, das HSC-50 usw. [2]

Das LCG-Management und die Ingenieure versicherten uns bei jedem Besuch in Marlboro (MA) (manchmal inklusive Helikopter- und Limousinenfahrten sowie Unterbringung in „Themen“-Hotels), dass das neue System unabhängig vom Codenamen nur noch „18 Monate“ von der Ankündigung entfernt sei . Die Betriebskosten wären bei beiden Systemen deutlich niedriger gewesen als bei der entsprechenden Anzahl von KLs.

Während wir auf das Erscheinen des Jupiter warteten, brauchten wir immer noch Möglichkeiten, unsere vorhandenen DEC-20-Ressourcen möglichst gerecht auf die Benutzer aufzuteilen. Dies war schon früh ein Problem. Der DEC-20, wie er ursprünglich geliefert wurde, ermöglichte es normalen Benutzern, die Maschine auf verschiedene Arten zu übernehmen, wodurch sie für alle anderen unbrauchbar wurde. Benutzer haben Programme geschrieben, um endlos selbstreplizierende Forks zu erstellen, sie haben alle PTYs zugewiesen und sie zum Schreiben von Passwortdiebstahlern verwendet, sie haben Programme in Endlosschleifen ausgeführt, die alle verfügbaren CPU-Zyklen verbraucht haben, sie haben stundenlang knappe Terminalleitungen monopolisiert, sie haben die... Batch-Warteschlangen, sie bombardierten die Bediener mit Tausenden von falschen Anfragen zur Bandmontage, sie druckten Millionen von Seiten Unsinn usw. usw.

Als Monitor- und Exec-Source-Site war Columbia in der Lage, Änderungen vorzunehmen, um den Zugriff auf bestimmte Ressourcen durch bestimmte Benutzerklassen einzuschränken, basierend auf der Benutzer-ID oder der Kontozeichenfolge oder durch die Übernahme „unbenutzter“ Bits im Fähigkeitswort. Aber schon zu unseren OS/360-Tagen haben wir die schmerzhafte Lektion gelernt, dass lokale Änderungen an Betriebssystemen uns immer wieder heimsuchen, wenn neue Versionen auf den Markt kommen: Es hat Jahre gedauert, unser stark modifiziertes IBM OS/360 21.0 auf 21.8 zu aktualisieren. Deshalb fühlten wir uns verpflichtet, DEC davon zu überzeugen, dass unsere Anforderungen universell gelten. Zu diesem Zweck gingen wir alle Kanäle durch, reichten zunächst Formulare für Software-Leistungsberichte ein, schrieben dann Briefe und führten schließlich eine Reihe von Treffen mit der Überwachungsgruppe in Marlboro durch.

Ein Produkt dieser Treffen war der Access Control Job. Hierbei handelte es sich um eine vom Kunden bereitgestellte Aufgabe, die vom Monitor immer dann konsultiert wurde, wenn Benutzer Zugriff auf bestimmte Ressourcen anforderten. Der ACJ könnte auf der Grundlage der eigenen Kriterien des Kundenstandorts entscheiden, ob der Zugriff gewährt oder verweigert wird. Zu diesen Ressourcen gehörten Anmeldung, Aktivierung von Funktionen, Auftragserstellung, Fork-Erstellung, Gerätezuweisung, Stapelauftragsübermittlung, Band-Mounts, Struktur-Mounts, Verzeichniserstellung, Änderungen der Scheduler-Klasse, Zugriff und Verbindung usw. Dies war ein großer Segen für die Sicherheit und Ressourcenmanagement.

Der ACJ erlaubte uns jedoch nicht, den laufenden Ressourcenverbrauch zu regulieren. Dazu mussten wir ein Überwachungsprogramm erstellen, um pro Benutzer Statistiken zur CPU und zur Verbindungszeit zu sammeln. Den Schülern wurde ein wöchentliches Budget für Verbindungs- und CPU-Zeit zugeteilt und sie erhielten regelmäßig Warnungen, wenn sie sich der Unterbrechung näherten. Auch nach der Sperrung durften sie außerhalb der Hauptverkehrszeiten zurückkehren, um ihre Arbeit zu erledigen. Der ACJ und Omega ermöglichten es unseren DEC-20, auf dem Höhepunkt der DEC-20-Ära eine Bevölkerung von mehr als 6000 aktiven Schülern auf vier Maschinen unterzubringen.

Ein Bereich war für uns besonders interessant. Die Terminals waren nicht direkt mit unseren DEC-20 verbunden, sondern wurden über eine Daten-PBX vermittelt. Daher wusste das DEC-20 nicht, dass TTY37 (zum Beispiel) Terminal Nummer Wenn bei einem Benutzer ein Fehlverhalten vermutet wurde, mussten die Mitarbeiter den physischen Standort des Benutzers kennen. Und bei der Auftragserstellung musste die Führungskraft den Terminaltyp und die Geschwindigkeit kennen, damit der Benutzer nicht durch zerbrochene, durcheinandergebrachte Bildschirme verwirrt wird. Glücklicherweise verfügte die Daten-PBX über ein Konsolenterminal, das die Verbindungen protokollierte. Dies war über ein Octopus-RS-232-Kabel mit den Ports jedes DEC-20 verbunden, das eine Datenbank mit PBX-Ports, Standorten, Terminaltypen und Geschwindigkeiten führte.

Die vom ACJ und Omega geführten Protokolle enthielten auch den physischen Standort des Auftrags. Mithilfe dieser Protokolle konnten wir mehr als nur ein paar potenzielle und tatsächliche Verstöße gegen die Systemsicherheit und die Privatsphäre anderer Benutzer aufspüren.

VERNETZUNG

Unser erster DEC-20 wurde über das HASP/RJE-Produkt von DEC mit dem IBM 360/91 verbunden, was ein eigenes dediziertes DN20-Frontend erforderte. Diese Kommunikationsmethode war ziemlich mühsam und erforderte, dass sich der DEC-20 für das IBM-System als Kartenleser und Zeilendrucker ausgab. Wir haben eine Reihe von Sail-Programmen geschrieben, die das „magische JCL-Sandwich“ für unsere Benutzer bilden würden, die Dateien oder Jobs an das IBM-System senden wollten.

Sobald wir unser zweites DEC-20 bekamen, verbanden wir es mit DECnet [1980] mit dem ersten und verbanden dann dieses kleine Netzwerk mit anderen DEC-Systemen auf dem Campus. DECnet war auch auf den Rechenzentrumsmaschinen der Carnegie-Mellon University im Einsatz, und so haben wir unsere beiden DECnets mit einer gemieteten Telefonleitung zwischen New York und Pittsburgh zu einem zusammengelegt und das erweiterte Netzwerk CCnet [1982] genannt (CC steht für Computer Center, oder vielleicht Carnegie-Columbia). Bald schlossen sich weitere Institutionen dem Netzwerk an – das Stevens Institute of Technology, die Case Western Reserve University, die New York University, die University of Toledo und andere. Der größte Vorteil war die gemeinsame Nutzung der Software- und Programmierarbeit durch die Computerverwaltungsmitarbeiter an diesen Standorten, zu denen DEC-20, DEC-10, VAX, PDP-11 und andere DEC-Systeme gehörten. Für viele Jahre, Columbia und CMU nutzten ein gemeinsam entwickeltes DEC-20 Galaxy-System, das transparentes Drucken über DECnet und gespulte Druckbänder für den Xerox 9700-Drucker ermöglichte. Eines der DEC-20 von Columbia diente als Mail-Gateway zwischen CCnet und BITNET, einem großen akademischen Netzwerk, das auf IBM-Mainframe-RSCS-Protokollen basiert.

Der wichtigste Beitrag des DEC-20 zur Vernetzung war seine Unterstützung der ARPANET-Protokolle, zuerst NCP und später TCP/IP. Viele Jahre lang war DEC der einzige große Computerhersteller, der diese Protokolle unterstützte, die größtenteils auf DEC-36-Bit-Maschinen unter TENEX, TOPS-10 und TOPS-20 (und später auf VAXes für Berkeley UNIX) entwickelt wurden. In den späten 70er und frühen 80er Jahren, als das ARPAnet über seinen ursprünglichen kleinen Forschungsauftrag hinaus wuchs und florierte, wurde es von DEC 36-Bit-Maschinen dominiert und viele der grundlegenden Internetprotokolle und -verfahren wurden in diesem Rahmen entwickelt. DEC selbst verfügte über ein DEC-20 im ARPANET, das es großen DEC-20-Akademie- und Forschungsstandorten ermöglichte, direkt mit TOPS-20-Ingenieuren zu kommunizieren, Fehlerberichte oder Korrekturen per E-Mail zu senden, Dateien zu übertragen usw. Eine ARPANET-Mailingliste mit TOPS-20-Managern wurde von Mark Crispin in Stanford eingerichtet. Auf der Mailingliste standen TOPS-20-Entwickler von DEC, und es gab viel nützliches Geben und Nehmen, das das umständliche SPR-Verfahren umging.

Vor Ort erhielten unsere eigenen DEC-20 NIA20-Ethernet-Schnittstellen, um die umständlichen und übergroßen DN20-Frontends zu ersetzen. Ethernet ermöglichte es uns, TCP/IP neben DECnet zu betreiben, und schon bald [ca. 1982] gab es ein großes campusweites Ethernet, das das Rechenzentrum DEC-20s dank des Internets der Informatikabteilung mit Abteilungssystemen auf dem gesamten Campus und darüber hinaus verband Mitgliedschaft [1982?] und später [1984?] unsere eigene Mitgliedschaft in anderen Weitverkehrs-TCP/IP-basierten Netzwerken wie NYSERNET und JVNCNET. Ethernet und TCP/IP ermöglichten es uns sogar, unsere HASP-RJE-Verbindung zu den IBM-Mainframes zu verwerfen, die inzwischen über Ethernet angeschlossen waren und TCP/IP-Code von der University of Wisconsin ausführten (der später von IBM in ihre eigene Produktlinie integriert wurde).

KERMIT

Auf dem Höhepunkt der Beliebtheit des DEC-20 war die Nachfrage unter Studenten und Lehrkräften nach Benutzerausweisen so groß, dass wir es uns nicht mehr leisten konnten, unbefristete Ausweise auszugeben. Stattdessen wurden Lehr-IDs pro Kurs vergeben und dann am Ende jedes Semesters gelöscht. Obwohl die Dateien gewissenhaft auf Band gesichert wurden, war es den Studierenden aufgrund der begrenzten Kapazität des Bandlaufwerks und der Abdeckung durch den Bediener nicht gestattet, die Wiederherstellung der Dateien eines früheren Semesters zu beantragen. Und selbst während des Semesters reichte das Festplattenkontingent einer Studentin (35.000 – K, nicht M oder G!) oft nicht aus, um alle ihre Dateien gleichzeitig online zu halten.

Wenn DEC-20-Benutzer über Wechselmedien verfügten, könnten sie die Verantwortung für die Verwaltung und Archivierung ihrer eigenen Dateien übernehmen. Unser erster Versuch in diesem Bereich umfasste ein wenig bekanntes Produkt namens DN200, eine dezentrale DECnet-Station, die ursprünglich für den Anschluss von 32 Terminals und einem Zeilendrucker an den DEC-20 konzipiert war (dieses Produkt wurde nie ganz ausgereift). Der DN200 war ein PDP-11/34, auf dem ein RSX-Derivat lief. Unseres – einzigartig – enthielt ein 8-Zoll-Diskettenlaufwerk. Unser Plan war, DN200-Software zum Kopieren von Dateien zwischen den Disketten und dem DEC-20-Dateisystem zu schreiben. Benutzer legten einfach ihre eigenen Disketten ein und gaben COPY-Befehle aus, um ihre Dateien zu speichern oder wiederherzustellen. Glücklicherweise kam dieses Projekt nie auf den Weg.

Aber die Idee von Wechselmedien fühlte sich richtig an. Computerbenutzer hatten es schon seit Jahren in Form von Karten, Klebeband oder sogar DECs eigenen unwiderstehlichen kleinen, sich hin und her drehenden DECtapes, wie sie auf den PDP-8, -9, -10, -11, - zu finden sind. 12 usw. und fehlt in der -20 schmerzlich. Eine Reihe verrückter Pläne wurden in Betracht gezogen und verworfen: Benutzern das Senden von Dateien an den Kartenstanzer des IBM-Mainframes zu ermöglichen, ein 9-Spur-Selbstbedienungsbandlaufwerk in einem öffentlichen Bereich aufzustellen und ein Programm zu schreiben, das die Daten des Benutzers in Barcodes umwandelt Drucken auf unseren Printronix-Druckern...

Ungefähr zu dieser Zeit (1980) tauchten 8-Bit-CP/M-Mikrocomputer auf. Auch wenn sie zu nichts anderem taugten, konnten sie kommunizieren und Disketten lesen und beschreiben. Stellen Sie ein paar davon in öffentlichen Bereichen auf, schließen Sie sie an die DEC-20 an, und schon hätten die Schüler ihre Wechselmedien – kleine Datenträger, die sie mitnehmen, speichern und wiederverwenden könnten, ohne auf das Personal des Rechenzentrums angewiesen zu sein. Die große Frage war, wie man eine Datei von einem großen Timesharing-Mainframe auf einen kleinen Personalcomputer verschieben kann.

Wir haben uns auf dem Markt umgesehen und festgestellt, dass es einige kommerzielle RS-232-Kommunikationspakete für Mikros gibt, aber keines für den DEC-20. Und wir mussten uns nicht nur um DEC-20 und Mikros kümmern, sondern auch um unsere IBM-Großrechner. Wenn wir Software zum Übertragen von Dateien zwischen dem DEC-20 und dem Intertec Superbrain gekauft hätten(Dies war das Mikro, das wir hauptsächlich wegen seiner panzerähnlichen, benutzerfreundlichen Konstruktion und trotz seines albernen Namens ausgewählt haben.) Vorausgesetzt, es wäre verfügbar, müssten wir für unsere IBM-Mainframe-Benutzer noch ein weiteres Softwarepaket kaufen, um dasselbe zu tun. Wir mussten auch berücksichtigen, dass das Superbrain möglicherweise nicht jedermanns Wahl ist. Columbia, eine stark dezentralisierte und vielfältige Organisation, verfügte wahrscheinlich über so viele verschiedene Arten von Computern, wie es Orte gab, an denen sie untergebracht werden konnten. Wenn ein separates Softwarepaket erforderlich wäre, um jedes einzelne Paar von Systemen zu verbinden, dann würden wir nahezu n -Quadrat-unterschiedliche Pakete benötigen, wobei n die Anzahl verschiedener Arten von Computersystemen ist, mit ausreichend Kopien, um jede Instanz von jedem abzudecken System.

Viel besser ist es, auf jedem Computer ein Softwarepaket zu haben, das in der Lage ist, Daten mit allen anderen Computern auszutauschen. Dadurch reduziert sich die Anzahl der benötigten Programme auf n , was wiederum das Budget entlastet und dem Anwender das Leben ein wenig erleichtert.

All diese Fragen führten zu der Entscheidung, in unsere eigenen Programmierer zu investieren und nicht in die Softwareunternehmen. Auf diese Weise könnten wir eine Software erhalten, die speziell auf unsere eigenen Bedürfnisse zugeschnitten ist. Das Endergebnis war das Kermit-Dateiübertragungsprotokoll. Unsere ersten Kermit-Programme wurden für den DEC-20 und den Superbrain geschrieben. Superbrains wurden in öffentlichen Bereichen platziert, um es den Schülern zu ermöglichen, ihre eigenen Dateien auf Disketten zu kopieren und sie später auf dem DEC-20 wiederherzustellen.

Das Kermit-Protokoll wurde weitgehend von den Einschränkungen des DEC-20 beeinflusst. Der DEC-20 mit seinem PDP-11/40-Frontend wurde unter der Annahme entwickelt, dass die Terminaleingabe direkt von Leuten kommt, die an Tastaturen sitzen und mit ihren Fingern relativ langsam tippen – höchstens 10 Zeichen pro Sekunde –, während sie groß sind Es können kontinuierliche Ausgabemengen vom Computer an den Bildschirm gesendet werden. RSX20F, das Betriebssystem des Frontends, weist daher kleine Puffer für die Eingabe und große für die Ausgabe zu. Das haben wir auf die harte Tour gelernt, als wir unsere ersten Terminals gekauft haben, die über eine „Bildschirmübertragungs“-Funktion verfügten (HDS Concept-100s). Sobald jemand es versuchte, stürzte das Frontend ab. Ähnliche Phänomene wurden bei Autorepeat-Tasten beobachtet (als einer unserer Programmierer auf der Tastatur einschlief)( 5), und noch einmal, als DEC zum ersten Mal sein VT100-Terminal herausbrachte : Beim sanften Scrollen mit 9600 bps überforderte das Terminal das schlechte Frontend mit XOFFs und XONs. Spätere Versionen von RSX20F bewältigten diese Probleme auf drakonische Weise – wenn Eingabepuffer nicht schnell genug zugewiesen werden konnten, setzte das Frontend die Geschwindigkeit der Leitung für ein oder zwei Sekunden auf Null! Der Unterricht? Senden Sie keine anhaltenden Schübe von Terminaldaten an den DEC-20 – das ist, als würde man versuchen, einen Sperling dazu zu bringen, einen Fleischbällchen-Helden zu fressen. Kermits normale Pakete sind daher mit maximal 96 Zeichen recht kurz – Samen, Insekten und Würmer, die ein Spatz verdauen kann.

Eine weitere Besonderheit des DEC-20 ist seine Empfindlichkeit gegenüber Steuerzeichen. Während des normalen Terminaldialogs werden 17 der 33 ASCII-Steuerzeichen für spezielle Zwecke verwendet – Bearbeitung, Programmunterbrechung, Flusskontrolle, Statusmeldung, Signalisierung des Dateiendes usw. – und nicht als Daten akzeptiert. Auch wenn ein DEC-20-Programm das Terminal im „Binärmodus“ öffnen kann, um die spezielle Verarbeitung dieser Zeichen zu umgehen, ist dies nicht unbedingt wünschenswert, da einige dieser Funktionen während der Datenübertragung nützlich sein könnten. Die Lektion hier ist, dass Sie beim Übertragen von Daten keine Steuerzeichen „nackt“ senden sollten. Tatsächlich sendet das Kermit-Protokoll (in seiner grundlegendsten Konfiguration) Pakete, die ausschließlich aus kurzen Textzeilen bestehen.

Der IBM-Großrechner (zu diesem Zeitpunkt war der 360/91 durch einen 4341 mit dem Betriebssystem VM/CMS ersetzt worden) hatte seine eigenen Besonderheiten. Im Gegensatz zum DEC-20 nutzte es Halbduplex-Kommunikation und verwendete 7 Datenbits mit Parität bei der Kommunikation mit der externen ASCII-Welt. Das bedeutete, dass unser Dateiübertragungsprotokoll ebenfalls Halbduplex sein musste und einen speziellen Mechanismus zur Übertragung von 8-Bit-Binärdaten über eine 7-Bit-Kommunikationsverbindung erfordern würde. Da außerdem die gesamte Kommunikation entweder über ein 3705-Frontend (Linemode) oder einen IBM Series/1-Protokollkonverter (oder gleichwertig, z. B. 7171 oder 4994) 3270 erfolgte, wobei beide viele der Steuerzeichen als sofort auszuführende Befehle behandelten, Das Verbot bloßer Steuerzeichen in Daten wurde verschärft. Durch die Reduzierung des Protokolls auf den kleinsten gemeinsamen Nenner funktionierte es in allen Fällen, allerdings auf Kosten der Effizienz und Eleganz. Einige der daraus resultierenden Mängel wurden in späteren Jahren durch die Hinzufügung langer Pakete und Vollduplex-Pakettransport mit Schiebefenster zum Protokoll sowie einer Option zum „Entfernen des Präfixes“ von Steuerzeichen behoben.

Durch einen glücklichen Zufall führten die kombinierten Besonderheiten des DEC-20, des IBM-Großrechners und des CP/M-Mikrocomputers zu einem Design, das sich praktisch an jeden Computer anpassen ließ, der zur asynchronen Kommunikation fähig war. Eine Datei wurde erstmals am 29. April 1981 mit dem Kermit-Protokoll von zwei Kermit-20- Instanzen übertragen , die auf einem einzelnen DEC-20 liefen, wobei zwei serielle Ports verwendet wurden, die über ein Nullmodemkabel miteinander verbunden waren.

Die Idee, unsere Kermit-Programme zu teilen und den Quellcode zu verschenken, war eine natürliche Folge unserer Erfahrungen mit der Community der DEC-10/20-Sites. Wir haben so viel eigene Software von anderen Websites erhalten, das war nur fair. Wir haben Kermit in unsere Exportbänder aufgenommen und an DECUS übermittelt. DEC war das erste Unternehmen, das Kermit als ein weit verbreitetes Werkzeug erkannte und es in seinen Large Systems-Flyern und Newslettern (z. B. Copy-N-Mail , Large Systems News und EDU ) bekannt machte). Und DEC war die erste Organisation, die Kermit auf eine neue Plattform portierte – ihren VT-180 CP/M Micro. Da wir wollten, dass Kermit-Software offen geteilt wird, haben wir unsere Kermit-Programme nicht öffentlich zugänglich gemacht. Auch wenn dies widersprüchlich erscheinen mag, waren wir der Meinung, dass wir durch das Urheberrecht an den Programmen verhindern könnten, dass sie von Unternehmern übernommen und als kommerzielle Produkte verkauft werden, was notwendig erschien, da wir Geschichten von anderen Universitäten gehört hatten, denen die Nutzung von Programmen, die sie selbst erstellt hatten, untersagt worden war wurden von Firmen geschrieben, die ihre gemeinfreie Arbeit übernommen und für sich selbst urheberrechtlich geschützt hatten.

Aufgrund der weiten Verbreitung der frühen Kermit-Programme zusammen mit dem Quellcode und der Protokollspezifikation begannen Websites mit anderen Computertypen, eigene Kermit-Programme zu schreiben und sie an uns zurückzusenden. Einige der frühen Beiträge in diesem Sinne waren DECsystem-10 und VAX/VMS Kermit-Programme vom Stevens Institute of Technology (geschrieben in Common Bliss, damit der Code zwischen TOPS-10, VMS und P/OS geteilt werden konnte) und PDP-11 Kermit von der Universität Toledo und der erste reine UNIX-Kermit in C aus unserer eigenen Informatikabteilung. Der Prozess dauerte viele Jahre und führte zu der großen Sammlung von Kermit-Programmen, die Sie heute auf der Website des Kermit-Projekts finden .

Das Kermit-Projekt in Kolumbien nutzte von Anfang an das DEC-20, unser CU20B-System, als Testumgebung, Bibliothek und Netzwerkheim, bis CU20B (unser letztes verbliebenes DEC-20) im September 1988 abgeschaltet wurde. Der elektronische Info-Kermit-Newsletter wurde erstellt und vom DEC-20 aus mit MM, dem DEC-20-E-Mail-Programm, an Menschen in akademischen und Unternehmensnetzwerken auf der ganzen Welt verschickt. Dieselben Benutzer könnten MM und andere E-Mail-Clients für Abfragen und Informationen verwenden und über die DECnet- und TCP/IP-Dateiserver des DEC-20 auf Programme, Quellcode und Dokumentation zugreifen. Sogar unsere Vertriebsbänder wurden ursprünglich von unseren DEC-20 in den Formaten DUMPER, BACKUP und ANSI geliefert.

Bis etwa 1985 war DEC-20 Kermit der „Benchmark“, anhand dessen alle anderen Kermits auf Interoperabilität überprüft werden sollten. Viele neue Kermit-Funktionen wurden zunächst zu DEC-20 Kermit hinzugefügt (Servermodus, Makros usw.). Die Benutzeroberfläche des DEC-20 wurde zum Vorbild für die meisten Kermit-Programme, sodass Millionen von Menschen heute (eine bemerkenswerte Simulation) des COMND JSYS des DEC-20 verwenden, ohne es zu wissen. Lange nachdem DEC-20 von der Bildfläche verschwunden ist, behalten Kermit-Programme auf Windows, UNIX, VMS, MS-DOS und vielen anderen Plattformen weiterhin „den Glauben“.

Kurz nach Kermits erstem Erscheinen wurde die Mikroinformatik mit der Einführung des IBM-PCs zu einer wichtigen Kraft . PCs wurden plötzlich zu eigenständigen, nützlichen Allzweckcomputern. Als Reaktion auf dringende Anfragen von Columbia-Fakultätsmitgliedern, die die ersten IBM-PCs erhalten hatten, produzierten wir hastig Version 1.0 von IBM PC Kermit und stellten fest, dass Kermit auf eine Weise verwendet wurde, die wir nicht erwartet hatten. Anstatt die Disketten des PCs zum Speichern von Mainframe-Dateien zu verwenden, führten Benutzer den Großteil ihrer Dateierstellung und -bearbeitung auf dem PC durch und sendeten die Ergebnisse zur Archivierung und Weitergabe an den Mainframe. Kermit war zu einem frühen Modell der verteilten Verarbeitung geworden.

SOFTWAREPAKETE

Die 36-Bit-Großsysteme von DEC waren die Quelle einiger der einflussreichsten und beständigsten Softwarepakete, die je geschrieben wurden. Hier erwähnen wir willkürlich einige unserer Favoriten und entschuldigen uns bei den Hunderten, die wir vernachlässigt haben.

Herausgeber

Unter den auf diesen Systemen erstellten Programmen ist vor allem der Texteditor EMACS hervorzuheben, der von Richard M. Stallman auf ITS, dem „Inkompatiblen Timesharing-System“ des MIT für den PDP-10, entwickelt wurde. EMACS verkörperte das revolutionäre Konzept, dass der Terminalbildschirm als Fenster für den zu bearbeitenden Text fungieren sollte und dass alle Änderungen am Text sofort auf dem Bildschirm angezeigt werden sollten. Nach vielen Jahren der zeilenorientierten Bearbeitung (und davor der Tastatureingabe) fiel es uns zunächst schwer, die Leistungsfähigkeit und den Komfort eines Bildschirmeditors zu begreifen. Es gab sogar Diskussionen darüber, ob wir es auf unserem System zulassen sollten, als wäre es ein subversiver Einfluss ... „Wozu brauchen wir es? Jeder Tastendruck führt zu 37 Kontextwechseln!“ usw. usw. Aber bald begannen selbst die Skeptiker, EMACS für seine enorme Steigerung der menschlichen Produktivität zu schätzen. und es wurde schnell zum bevorzugten Herausgeber für Mitarbeiter, Studenten und Lehrkräfte gleichermaßen. In Columbia entstand eine Heimindustrie, die der TECO-Datenbank neue Terminaltypen und -operationen hinzufügte (EMACS vom 10. Dezember 2020 wurde in TECO geschrieben) sowie neue Bibliotheken für EMACS selbst.

Während einige EMACS und seine Nachkommen und Verwandten heute im Vergleich zu GUI-Editoren und Textverarbeitungsprogrammen als „veraltet“ ansehen, haben sie einen großen Vorteil gegenüber den neueren Editoren: Sie werden vollständig von gewöhnlichen ASCII-Zeichen gesteuert ( 6) (im Gegensatz zu Funktions- oder Pfeiltasten, Maus usw.), sodass Touch-Schreibkräfte nie die Home-Tasten verlassen müssen und erfahrene EMACS-Benutzer Text schneller eingeben und bearbeiten können als Experten mit anderen Editoren, insbesondere mit modernen, aber arbeitsintensiven GUI-Editoren . Und durch die Beschränkung des Befehlssatzes auf gewöhnliche ASCII-Zeichen kann EMACS auf jeder Plattform verwendet werden, unabhängig davon, wie Sie darauf zugreifen (über die Tastatur und den Bildschirm der Workstation, ein xterm-Fenster, Telnet, Dialin, Rlogin, SSH usw.). Ein weiterer Vorteil von EMACS ist natürlich seine Anpassbarkeit und Programmierbarkeit, aber nur die älteren Generationen von Computerbenutzern wissen solche Dinge oder kümmern sich darum.

Textformatierer

EMACS ist ein Editor für Klartext, was bedeutet, dass er normalerweise keine speziellen Druckeffekte wie Fettschrift, Kursivschrift, Unterstreichung, mathematische Notation, unterschiedliche Schriftgrößen, Grafiken usw. erzeugen kann. Dafür brauchen wir – zumindest in der Welt der Zeichen Terminals – ein Textformatierer. EMACS war einer von mehreren Bildschirmeditoren für DEC-20 (TV und TVEDIT waren weitere frühe Konkurrenten), und es gab auch mehrere Textformatierer. Der DEC-20 verfügt natürlich über RUNOFF, den Standardformatierer von DEC. RUNOFF ist einfach, nicht zu leistungsstark, hat aber den Vorteil, dass RUNOFF-Dateien größtenteils zwischen PDP-11, VAX, DEC-10 und DEC-20 portierbar sind. Allerdings ist RUNOFF proprietär und daher auf Nicht-DEC-Systemen nicht verfügbar. RUNOFF hat außerdem drei grundlegende Mängel. Erstens ist es streng prozedural, was bedeutet, dass sich der Autor wie ein Programmierer verhalten muss. RUNOFF bis ins kleinste Detail anweisen. Zweitens kann es nicht rechnen. Und drittens unterstützt es nicht viele verschiedene Ausgabegeräte.

Diese Mängel werden durch mehrere Textformatierer behoben, die von Benutzern großer DEC-Systeme und auch einiger kleinerer Systeme entwickelt wurden (UNIX beispielsweise wurde ursprünglich für PDP-7 geschrieben und später auf PDP-11 umgestellt). ; UNIX nroff und troff sind wahrscheinlich Ableger von RUNOFF). Zu den ersten Bemühungen auf 36-Bit-Systemen gehörten R und Pub.

Brian Reid, der für seine Doktorarbeit an der CMU an einem DECsystem-10 arbeitete, entwickelte eine Dokumentproduktionssprache namens Scribe, die sich mit dem prozeduralen Element befasste. Während man in RUNOFF sagen muss: „Zentrieren und unterstreichen Sie dieses Wort, lassen Sie 7 Leerzeilen, rücken Sie 4 Leerzeichen ein usw.“ sagt man in Scribe: „Dies ist ein Artikel, hier ist der Titel, hier ist ein Abschnitt, hier ist eine Fußnote.“ , hier ist ein bibliografisches Zitat, fügen Sie dies in den Index ein, fügen Sie hier ein Foto ein und skalieren Sie es wie folgt usw.“ und überlässt die stilistischen Entscheidungen und Details Scribe, das eine umfangreiche Datenbank mit Dokumenttypen und Veröffentlichungsstilen enthält. Wenn Sie beispielsweise einen Artikel für das CACM geschrieben haben, können Sie Scribe bitten, ihn im erforderlichen Stil des CACM zu formatieren. Wenn das CACM es ablehnt, weisen Sie Scribe einfach an, es im IEEE-Computerformat zu wiederholen.7 ).

Während seiner Entwicklung wurde Scribe frei mit anderen Universitäten geteilt, und es gab viel Geben und Nehmen zwischen Brian und den Benutzern überall. Als Brian die CMU verließ, wurden die Rechte an Scribe jedoch an ein privates Unternehmen, Unilogic Ltd, verkauft, das es als kommerzielles Produkt verkaufte ( 8 ). Scribe war ein fester Bestandteil vieler DEC-10- und -20-Standorte und wurde vom ursprünglichen Bliss in andere Sprachen konvertiert, um auf Systemen wie UNIX, VMS und sogar IBM-Mainframes verwendet zu werden.

Währenddessen plante Donald Knuth in Stanford Neuauflagen seines mehrbändigen Werks The Art of Computer Programming . Doch schon bald stellte er fest, dass seit der Veröffentlichung seiner ersten Ausgaben die Kunst des mathematischen Schriftsatzes ebenso wie die des architektonischen Steinmetzhandwerks ausgestorben war: Er konnte keinen Schriftsetzer finden, der dieser Aufgabe gewachsen war. Also machte er sich an die Arbeit an einem Computerprogramm für den mathematischen Schriftsatz und einer Reihe harmonischer Schriftarten, die sich zum Herunterladen auf einen Laserdrucker eignen. Die Arbeit wurde auf einem PDP-10 in Stanford durchgeführt, auf dem das selbst entwickelte Betriebssystem WAITS („Es wartet auf Hand und Fuß“) in der Sail-Sprache lief. Das Ergebnis ist ein System namens T EX (tau epsilon chi) und METAFONT, sein begleitender Font-Builder, zogen viele Anhänger an, und das ursprüngliche Sail-Programm wurde bald zur Portabilität in andere Sprachen übersetzt. Mittlerweile läuft es auf vielen verschiedenen Plattformen und ist für die Produktion zahlreicher Bücher und Artikel von überragender typografischer Schönheit verantwortlich.

Sowohl TeX als auch Scribe unterstützen eine Vielzahl von Ausgabegeräten und gehören zu den ersten Textformatierern, die dies tun. Als Xerox Anfang der 70er Jahre einige seiner XGP-Drucker (ein experimenteller xerografischer Drucker mit vom Host heruntergeladenen Schriftarten) in die Labore von Stanford, MIT und CMU entkommen ließ, wurden diese schnell an PDP-10 angeschlossen, um damit betrieben zu werden Formatierer wie R und Pub. Ihre Flexibilität gab Leuten wie Don und Brian den Anstoß, umfassende Satzkonzepte in ihre Entwürfe einzubeziehen, und dadurch war es später möglich, TeX und Scribe für Drucker wie den GSI CAT-4 (der damals bei Bell weit verbreitet war) zu unterstützen Labs mit Troff), dem Xerox Dover, dem Imagen und den heutigen PostScript-Druckern (und wenn wir uns nicht irren, war Brian auch die treibende Kraft hinter PostScript).

Im neuen Jahrtausend ist Scribe so gut wie verschwunden, was eine Schande ist. Aber in gewisser Weise lebt es in LaT E X weiter , einer Scribe-ähnlichen Sprache , die auf T E (was auch immer wichtig ist, EMACS) erfordert zunächst einiges an Lernen, aber es lohnt sich, denn sobald man sich darin wohlfühlt, kann man alle anderen übertreffen!

E-Mail

Die Vorteile der elektronischen Post müssen wohl kaum angepriesen werden, aber es gab eine Zeit, in der die Leute sie weder nutzten noch ihr vertrauten. Heute können viele dieser Menschen ohne sie kaum noch leben. Der Hauptvorteil besteht darin, dass die daran teilnehmenden Personen bequem kommunizieren können und eine gewisse Sicherheit haben, dass die Nachricht auch ankommt. Im Gegensatz zur Post kann eine E-Mail spontan versendet werden und eine einzelne Nachricht kann gleichzeitig an mehr als eine Person gesendet werden. Im Gegensatz zu Telefonanrufen ist es beim E-Mail-Versand nicht erforderlich, dass der Angerufene beim Versenden der Nachricht anwesend ist. Es gibt Leute, die sagen, es handele sich um einen entmenschlichenden Einfluss, dass Menschen in benachbarten Büros, die einst zu Besuch kamen und sich unterhielten, jetzt an ihren Bildschirmen festsitzen und sich gegenseitig E-Mail-Nachrichten senden, Nachrichten, deren wahre Absicht nicht aus dem Gesichtsausdruck herausgelesen werden kann, Körpersprache, oder Tonfall. Das mag stimmen, aber E-Mails werden uns erhalten bleiben und die meisten Menschen werden einen Weg finden, sie auf sinnvolle Weise in ihr Leben zu integrieren.

Obwohl E-Mail seit den frühen 1960er Jahren für die Verwendung innerhalb eines Computers verfügbar war (z. B. auf dem CTSS-Timesharing-System des MIT), begann die E-Mail zwischen Computern auf DEC-20s (oder genau genommen KL-10s mit TENEX). „proto-TOPS-20“), bei BBN in Cambridge, Massachusetts, im Jahr 1972, als Ray Tomlinson von BBN sein E-Mail-Programm TENEX anpasste, um Nachrichten an andere ARPANET-Knoten zu senden. Dies beinhaltete nicht nur neue Software und Protokolle, sondern auch eine neue Notation: das mittlerweile allgegenwärtige Benutzer- @ Host- Adressformat.

Wenn Sie zwischen 1978 und 1988 an irgendeinem DEC-20 in Columbia ein SYSTAT durchführen würden, würden Sie sehen, dass etwa die Hälfte der Benutzer EMACS und die andere Hälfte MM ausführten, mit nur gelegentlichen Auszeiten für Textformatierung, Programmkompilierung, Dateiübertragung und andere Dinge von „echter Arbeit“. MM ist der Mail Manager, ursprünglich von Mike McMahon geschrieben und später von Mark Crispin übernommen. Es handelt sich um die „Benutzeragenten“-Seite des Mailsystems. MM ist ein gewöhnliches Programm für unprivilegierte Benutzer, mit dem Sie Ihre E-Mails lesen, E-Mails verfassen und an andere Benutzer senden, E-Mails weiterleiten und Ihre E-Mail-Dateien verwalten können. Mit MM können Sie Nachrichten in andere Dateien verschieben, Nachrichten drucken, löschen, zur späteren Bearbeitung markieren usw.

Jeder Vorgang, den MM für eine einzelne Nachricht ausführen kann, kann auch auf eine Nachrichtensequenz angewendet werden. Dies ist eine der leistungsstärksten Funktionen von MM. Mit den Nachrichtenauswahlfunktionen von MM können Sie Ihre E-Mail-Datei fast wie eine Datenbank behandeln und komplexe Abfragen wie „Zeigen Sie mir (oder beantworten Sie sie oder löschen Sie sie oder leiten Sie sie oder kennzeichnen Sie sie oder drucken) alle von jemandem gesendeten Nachrichten“ aus zwischen diesen und jenen Datumsangaben, die länger als so viele Zeichen sind und das Wort „foo“ in ihrem Betreff enthalten.“

MM ist enorm leistungsstark, aber auch einfach zu bedienen, da es COMND JSYS vollständig nutzt. Benutzer können jederzeit herausfinden, was erwartet wird, indem sie ein Fragezeichen eingeben (außer beim Verfassen eines Nachrichtentexts, in diesem Fall wird das Fragezeichen Teil des Textes). Es gibt einen SET-Befehl, mit dem viele MM-Vorgänge angepasst und die Standardaktionen geändert werden können. Benutzer können diese Anpassungen in einer Initialisierungsdatei speichern, sodass sie bei jeder Ausführung von MM automatisch vorgenommen werden.

MM wurde schnell zugunsten von DEC-20 MAIL und RDMAIL übernommen und zunächst von den Programmierern verwendet. Seine Nutzung verbreitete sich schnell bei Studenten und Lehrkräften, so dass mehrere Kurse vollständig darauf angewiesen waren. Hausaufgaben und Lesungen wurden verteilt, Konferenzen abgehalten, Aufgaben abgegeben, Fragen gestellt und beantwortet, alles mit MM. MM wird auch verwendet, um Nachrichten an öffentliche „Schwarze Bretter“ zu senden, die für alles Mögliche genutzt wurden, vom Verkauf gebrauchter Motorräder über Wissensquizze bis hin zu hitzigen Kontroversen zu politischen Themen.

An der Columbia sind viele Abteilungen auf verschiedene Gebäude auf dem Campus und außerhalb davon verteilt. Diese Abteilungen waren ideale Kandidaten für E-Mail und viele von ihnen wickelten ihr Tagesgeschäft mit MM ab. Und MM ist auch im vernetzten Umfeld zu Hause. Bei entsprechenden Netzwerkverbindungen und Zustelldiensten kann und wird MM zur Übermittlung elektronischer Post in die ganze Welt verwendet, und zwar schneller, als jedes Postamt oder jeder Zustelldienst Papier zustellen könnte. Von Kolumbien aus senden wir E-Mails an so weit entfernte Orte wie Utah, England, Norwegen, Australien, Brasilien, Japan, China und die UdSSR und erhalten Antworten innerhalb von Minuten (vorausgesetzt, unsere Korrespondenten haben die gleichen ungeraden Öffnungszeiten wie wir). Tun!).

Nachtrag vom Mai 2003: Es dauerte nur ein weiteres Jahrzehnt, bis E-Mails mehr zu einem Fluch als zu einem Segen wurden und jeder Computerbenutzer mit Junk- und/oder bösartigen E-Mails, bekannt als „Spam“, überhäuft wurde. Der DEC-20 war auch in diesem Bereich ein Pionier: Der allererste Spam wurde am 1. Mai 1978 um 1233 EDT von DEC-MARLBORO.ARPA (ein DEC-20) an alle ARPANET-Kontakte (aus der WHOIS-Datenbank) gesendet und warb für Neues DEC-20-Modelle.

Im Jahr 2015 hat Columbia seinen E-Mail-Bereich an Google ausgelagert.

WEITERE BEMERKENSWERTE BEITRÄGE

Die DEC-20-Architektur geht tatsächlich auf die Mitte der 1960er Jahre zurück, auf DECs PDP-6, der mit Blick auf LISP entwickelt wurde – die Halbwörter und zugehörigen Anweisungen eignen sich perfekt für CARs und CDRs (das ist LISP-Sprache, abgeleitet vom Befehlssatz von IBM). 704, wo LISP erstmals entwickelt wurde). Die meisten großen Implementierungen von LISP wurden für die 36-Bit-Maschinen von DEC durchgeführt – MACLISP, INTERLISP – und unter den darauf basierenden Anwendungen sticht MACSYMA vom MIT als Meilenstein hervor. MACSYMA wird von Wissenschaftlern und Ingenieuren verwendet, um mathematische Ausdrücke beliebiger Komplexität auf symbolischer und nicht auf numerischer Ebene zu manipulieren. Es gibt eine berühmte (vielleicht apokryphe) Geschichte über einen Astronomen und Mathematiker aus dem 19. Jahrhundert, der sein Leben der Formulierung der exakten Bewegungsgleichung des Mondes widmete. Das Ergebnis füllte ein 300-seitiges Buch.

Im Jahr 1971 schrieb Ralph Gorin von der Stanford University die erste bekannte computergestützte Rechtschreibprüfung für Text, SPELL for TOPS-10. Es wurde später an den DEC-20 angepasst und mit Paketen wie EMACS und MM „angebunden“. Die Nachkommen von SPELL sind Legion – kein PC-basiertes Textverarbeitungsprogramm mit Selbstachtung würde ohne eine Rechtschreibkorrektur in der Öffentlichkeit erscheinen.

UMSTELLUNG AUF UNIX

[Denken Sie daran: Dieses Dokument wurde 1988 verfasst.]

„ Sorgloses Segeln durch die 80er Jahre...“ Ende der 80er Jahre stagnierte die Nachfrage nach DEC-20-Diensten und begann dann zu sinken. Die DEC-20 war wie ein Klipper, der höchste Ausdruck einer Technologie, die viele für veraltet hielten – der große zentrale Time-Sharing-Computer . Die Studenten waren nun bereit, auf die Annehmlichkeiten des DEC-20 zu verzichten, um die Kontrolle und Vorhersehbarkeit eines eigenen PCs zu behalten. Dank der Mitgliedschaft Columbias im Apple University Consortium befanden sich bald Tausende von Macintosh-Computern in den Händen der Studenten. Besondere Vereinbarungen mit IBM installierte außerdem IBM-PCs in Hunderten von Büros und Wohnheimzimmern. Diese Systeme erfüllten die Bedürfnisse der Studenten nach kleinen Programmieraufgaben in Pascal und Basic sowie nach bescheidener Textverarbeitung und entlasteten die zentralen Systeme von einer großen Belastung. PCs erfüllten diese Anforderungen jedoch nicht die Bedürfnisse der Informatik und anderer Ingenieurabteilungen,wo größere Projekte in Sprachen wie Fortran, C, Prolog und Lisp durchgeführt wurden, die für PCs nicht ohne weiteres und kostengünstig verfügbar waren.

In der Zwischenzeit eroberte UNIX die Computerwelt – auf Großrechnern, Minis, Workstations und sogar PCs. Unsere größte Gruppe von Lehrbenutzern – CS-Studenten – erledigte den Großteil ihrer Arbeit auf den ATT 3B2 der Abteilungen, benötigte jedoch dringend eine zentralisierte, zuverlässige Umgebung mit akzeptabler Leistung, Backups, Service und allem anderen. Wir hatten bereits seit einigen Jahren UNIX auf einem VAX 750 (für interne Entwicklungsarbeiten) sowie Amdahl UTS auf einem IBM-Mainframe im Einsatz und hatten uns daher einige UNIX-Kenntnisse angeeignet.

Aus diesen Gründen haben wir beschlossen, dass es an der Zeit ist, mit der Umstellung von TOPS-20 auf UNIX zu beginnen. Aus finanziellen Gründen haben wir uns hierfür für einen VAX 8650 entschieden. Der DEC-20-Eintausch war attraktiv und wir konnten unsere alten Festplatten- und Bandlaufwerke behalten. Tatsächlich haben wir herausgefunden, dass der Kauf des VAX über einen Zeitraum von drei Jahren günstiger war, als den DEC-20 zu behalten. Und es war leistungsfähiger, mit einem größeren Adressraum und auf kleinerem Raum als das DEC-20, das es ersetzte.

VMS wurde aus mehreren Gründen nicht ausgewählt. Erstens fühlten wir uns durch den Verzicht von DEC auf TOPS-20 etwas betrogen und wollten uns in Zukunft nicht der gleichen Behandlung aussetzen. UNIX ist im Gegensatz zu VMS nicht an einen bestimmten Anbieter gebunden. Darüber hinaus verfügt UNIX über Netzwerke und Kommunikation für alle unsere Hauptanforderungen: Ethernet, TCP/IP, DECnet (unser erstes UNIX war Ultrix-32), BITNET (UREP), RS-232 und LAT-Terminals, Kermit. Und UNIX selbst bietet viele Vorteile: eine sehr leistungsstarke Anwendungsentwicklungsumgebung für erfahrene Programmierer, eine programmierbare Shell, Programm-Pipping und einfache, aber leistungsstarke Dienstprogramme.

UNIX ist jedoch bekanntermaßen knapp, kryptisch und unfreundlich, insbesondere für unerfahrene Computerbenutzer. Obwohl VMS das COMND JSYS des DEC-20 fehlt, ist es auf jeden Fall benutzerfreundlicher als UNIX und überaus ausführlich. Daher haben wir uns nicht ohne Bedenken an den Umbau gemacht.

Viele von uns DEC-20-Benutzern waren resistent gegen Veränderungen. Vertrautheit ist im Guten wie im Schlechten oft attraktiver als Unsicherheit. Die Umstellung auf UNIX zwang uns jedoch dazu, auf einige der Funktionen zu verzichten, die uns ursprünglich zum DEC-20 geführt haben.

Die „benutzerfreundliche“ Shell des TOPS-20 Exec, die denjenigen Hilfe bietet, die sie benötigen, aber erfahrene Benutzer nicht benachteiligt, ist wahrscheinlich die Funktion, die am meisten vermisst wurde. Unter UNIX sind die meisten Befehle Programme, bei denen davon ausgegangen wird, dass sie als Argumente nur Optionen oder Dateinamen enthalten. Das bedeutet, dass Sie kein „?“ haben dürfen. für Befehle und Argumente in der Shell, da die Programme, die auf die Hilfeanfrage reagieren würden, noch nicht einmal gestartet sind. Dies ist das Gegenteil von TOPS-20, bei dem die meisten wichtigen Funktionen in die Exec integriert sind, es jedoch nicht möglich ist, prägnante Bausteinprogramme zusammenzufassen, wie dies bei UNIX der Fall ist.

Um ein Beispiel für den radikalen Unterschied zwischen der TOPS-20- und der UNIX-Philosophie zu nennen: Angenommen, Sie möchten eine Prozedur erstellen, die eine Verzeichnisliste erstellt, diese in umgekehrter Reihenfolge nach Dateigröße sortiert und die Liste in nummerierte Seiten mit jeweils drei Spalten formatiert Seite, zum Ausdrucken geeignet. In TOPS-20 würden Sie eine Woche damit verbringen, ein Assemblerprogramm zu schreiben, um all dies zu erledigen. Unter UNIX sind die Tools bereits vorhanden und müssen nur noch in der gewünschten Weise kombiniert werden:

ls -s | sort -r | pr -3

Dadurch sieht UNIX ziemlich attraktiv aus. Aber das DEC-20-Programm wird, sobald es geschrieben ist, integrierte Hilfe, Befehls- und Dateinamenvervollständigung usw. enthalten, während die UNIX-Prozedur nur von denjenigen verwendet werden kann, die genau wissen, was sie tun. Wenn Sie „ls -s | sort“ eingegeben haben, aber nicht wissen, was die entsprechende Sortieroption ist, hilft die Eingabe eines Fragezeichens an dieser Stelle nichts, da das Sortierprogramm noch nicht ausgeführt wird.

Der DEC-20 verwendet (wie die meisten gängigen Betriebssysteme) Groß-/Kleinschreibung-unabhängige Befehle und Dateinamen. Die Abhängigkeit von der Groß-/Kleinschreibung ist jedoch ein Merkmal von UNIX, das von seinen Befürwortern energisch verteidigt wird. Für Benutzer anderer Betriebssysteme kann es ziemlich verwirrend sein. Im Allgemeinen unterscheiden sich UNIX-Befehle stark von den Befehlen, die in anderen Systemen verwendet werden. Selbst wenn das DEC-20 keine Menü-on-Demand-Hilfefunktion angeboten hätte, hätte der durchschnittliche Benutzer wahrscheinlich die richtigen Befehle erraten können – DELETE, um eine Datei zu löschen, COPY, um eine Datei zu kopieren, RENAME, um eine Datei umzubenennen usw. Wie löscht man unter UNIX eine Datei? LÖSCHEN? Nein... LÖSCHEN? Nein, es ist „rm“ (nur Kleinbuchstaben!).

Wie könnten Sie das herausfinden, ohne ein Handbuch zur Hand zu haben? Selbst wenn Sie „man -k“ kennen (Stichwortsuche im Online-Handbuch), bietet Ihnen UNIX keine große Hilfe: „man -k delete“ liefert nichts Relevantes, ebenso wenig wie „man -k erase“. . Aber zumindest weist „rm“ etwas auf das Wort „remove“ hin, und tatsächlich hätte „man -k remove“ den schwer fassbaren Befehl aufgedeckt (frühe Versionen von UNIX hatten einen noch schwer fassbaren Namen für diesen Befehl: dsw, eine Abkürzung für „do swedanya“, russisch für „Auf Wiedersehen“, transliteriert ins Polnische oder vielleicht Deutsche; dies ist nicht der einzige Ort, an dem der Zensor am Werk war ... Aktuelle „Standard“-Versionen von UNIX haben keinen „Hilfe“-Befehl, aber in frühere Veröffentlichungen,

Ich (fdc) kann mich nicht erinnern, wo ich den Hinweis „do swedanya“ ausgegraben habe, aber offensichtlich handelt es sich um eine urbane Legende. Dennis Ritchie sagte 1981 in einem Usenet-Beitrag, dass die eigentliche Etymologie „von Schaltern löschen“ sei; Das ursprüngliche PDP-7-DSW-Programm war ein Vorläufer von „rm -i“ (interaktiv entfernen), bei dem die CPU-Schalter für die Interaktion sorgten.

Ein besonderer Vorteil von TOPS-20 ist die Aufbewahrung mehrerer Generationen (Versionen) jeder Datei, sodass auf eine frühere Version zurückgegriffen werden kann, falls die neueste Version durch menschliches Versagen, Unsinn oder eine Tragödie beeinträchtigt wird. Dies, gepaart mit der Möglichkeit, eine Datei nach dem Löschen wiederzubeleben, vermittelt ein Gefühl von Komfort und Sicherheit, das man nur dann zu schätzen weiß, wenn man auf ein konventionelleres und unsichereres Dateisystem umsteigt. Wenn Sie unter UNIX eine Datei löschen oder eine neue Datei mit demselben Namen wie eine vorhandene erstellen, ist die alte Datei einfach verschwunden. Der Befehl „rm *“ unter UNIX ist einfach zu mächtig und zu leise. Ja, es hat getan, was Sie gesagt haben, aber woher wusste es, dass Sie meinten, was Sie sagten? UNIX schützt Benutzer nicht vor sich selbst.

Ein weiteres wichtiges Merkmal von TOPS-20 ist der logische Gerätename, der für das gesamte System und für jeden einzelnen Benutzer in unendlicher Vielfalt definiert werden kann. Jeder logische Name kann auf ein bestimmtes Gerät und/oder Verzeichnis oder auf eine ganze Reihe davon verweisen, die der Reihe nach durchsucht werden sollen. Diese sind in das Betriebssystem selbst integriert, während die Begriffe PATH und CDPATH nachträglich in die UNIX-Shell eingepfropft, nicht innerhalb von Programmen verfügbar und außerhalb ihrer begrenzten Einsatzbereiche nicht anwendbar sind.

Dann haben wir die Programmiersprachen, die nicht mehr verfügbar wären – ALGOL (60 & 68), APL, BASIC, BCPL, BLISS (10, 11 und 36), CPL (und „echtes“ PL/I), ECL, FOCAL , PPL, SAIL, SIMULA, SNOBOL, ... und TECO! Und MACRO und Midas und Fail ... Tatsächlich werden nur wenige Menschen eines davon vermissen, mit Ausnahme von APL (das in einigen Klassen verwendet wird) und SNOBOL (das auf ausgewählten Plattformen immer noch für UNIX zu finden ist).

Natürlich mussten alle unsere selbst entwickelten Anwendungen, die in Assemblersprache geschrieben wurden, für UNIX überarbeitet werden: Benutzer-ID-Eingabe und -Verwaltung (im Gegensatz zum Bearbeiten der passwd-Datei), Buchhaltung, Benutzerbeschränkungen (ACJ, Omega). Und eine Funktion, ohne die wir nie wieder leben könnten, ist MM, ein leistungsstarkes Mail-Management-System, das sowohl von Anfängern als auch von Experten verwendet werden kann.

Positiv zu vermerken ist, dass wir weder auf EMACS, Scribe, TeX, Kermit noch auf die TCP/IP-Dienstprogramme Telnet und FTP verzichten würden. Alle diese Programme sind in irgendeiner Form für UNIX verfügbar. Einige der UNIX-Implementierungen sind eindeutige Verbesserungen, wie beispielsweise GNU EMACS von der Free Software Foundation, ohne die Speicherbeschränkungen von TOPS-20 EMACS. Außerdem gibt es ein hochwertiges Fortran von DEC für unsere Ingenieure und natürlich die gesamten C- und LISP-Programmierumgebungen für CS-Studenten und andere Softwareentwickler sowie eine Reihe leistungsstarker Dienstprogramme zur Textbearbeitung wie sed, grep, awk, lex und yacc , deren Funktionen aus ihren Namen ersichtlich sein sollten.

Die VAX-Installation war viel schneller als die typische DEC-20-Installation. Die Leistung des 8650 war recht flott und seine Zuverlässigkeit ausgezeichnet. Nach einem Jahr wurde der 8650 verkauft und ein zweiter DEC-2065 gegen einen VAX 8700 bei DEC eingetauscht. Der 8700 hat ungefähr die gleiche Leistung wie der 8650, ist aber im Gegensatz zum 8650 mit den neuen BI-Geräten kompatibel. und auf ein größeres VAX-Modell aufrüstbar, falls ihm die Puste ausgeht.

Es stellte sich jedoch heraus, dass es bei einer Erweiterung kostengünstiger war, Sun-UNIX-Systeme zu kaufen, als den 8700 auf einen größeren VAX aufzurüsten. Dies ist eine Wahl, die Sie mit einem proprietären Betriebssystem wie TOPS-20, VMS usw. nicht haben. Die Konvertierung von VAX zu SUN erfordert einiges „Aufgeben“ (z. B. DECnet), aber bei weitem nicht so viel wie der Weg von DEC -20 zu VAX, und im Gegenzug erhalten Sie eine sehr leistungsstarke Maschine auf einem Bruchteil der Stellfläche des VAX – was der Jupiter hätte sein sollen, aber mit UNIX statt TOPS-20.

WICHTIGE KONVERTIERUNGSPROBLEME

[Denken Sie daran: Dies wurde 1988 geschrieben.]

Eine große Frage bei der Umstellung auf UNIX war die Benutzerschulung. UNIX hilft Benutzern nicht so wie TOPS-20. Es gibt keinen COMND-Stil? Hilfe, es gibt nicht einmal einen „Hilfe“-Befehl. Die Befehle selbst haben keine intuitiven Namen: Ein Benutzer würde kaum erraten, dass „mv“ der Befehl zum Umbenennen einer Datei, „cat“ zum Eingeben einer Datei usw. ist. Woher wissen Benutzer, wie sie auf die Stummschaltung reagieren sollen? „$“ (oder „%“) starrt ihnen ins Gesicht? Sollten wir eine benutzerfreundliche Shell für sie schreiben? Oder Unmengen von Tutorials und Referenzhandbüchern?

Bei aller kryptischen Kürze ist UNIX sehr beliebt geworden. UNIX-Systeme laufen auf Computern aller Art, vom PC bis zum Supercomputer. Folglich sind Computerbuchhandlungen voll mit Büchern der Sorte „Teach Yourself UNIX“. Unserer Meinung nach sollte UNIX, egal wie kryptisch und unfreundlich es auch sein mag, nicht geändert werden. Andernfalls verlieren wir die Kompatibilität mit anderen UNIX-Systemen, den Büchern und Artikeln, machen uns einem Wartungsalbtraum aus und lassen unsere Benutzer eine böse Überraschung erleben, sollten sie jemals auf ein echtes UNIX-System stoßen.

Ein weiteres Problem ist das Mailsystem. Als Mail-Agent auf Benutzerebene haben Sie die Wahl zwischen UNIX-Mail oder GNU EMACS RMAIL. UNIX-Mail ist primitiv und nicht intuitiv, und RMAIL ist nur für diejenigen zugänglich, die EMACS kennen. RMAIL hat den Vorteil einer konsistenten Benutzeroberfläche – kein Springen in den Editor und wieder heraus –, verfügt jedoch über ein relativ begrenztes Befehlsrepertoire.

Unsere Benutzer haben sich sehr gut an E-Mail gewöhnt, vor allem dank der Leistungsfähigkeit, Bequemlichkeit und Freundlichkeit von MM. Viele der größten Benutzer von MM sind Lehrkräfte oder Administratoren, die sich nicht mit einem neuen Mailsystem vertraut machen müssen. Aber ein so leistungsfähiges Programm wie MM benötigt viele Befehle, und wenn Sie über viele Befehle verfügen, benötigen Sie die integrierte Hilfe, die beim DEC-20 kostenlos zur Verfügung steht. Ähnliche Kommentare gelten für andere komplizierte Programme, zum Beispiel (auf unserem System) Benutzer-ID-Eingabe- und Verwaltungsprogramme, die Bedienerschnittstelle (wie OPR auf dem DEC-20) usw.

Aus diesem Grund haben wir beschlossen, „unser neues System in unser geliebtes altes zu verwandeln“, indem wir ein COMND-Paket für UNIX geschrieben haben. Dieses Paket, CCMD, wurde als Teil des „Hermit“-Projekts gestartet, einem von DEC finanzierten Forschungsprojekt der Columbia University in den Jahren 1983–87. Wir haben versucht, eine Netzwerkarchitektur zu entwerfen, die verschiedenen Arten von PCs – IBM, Rainbow, Pro-380, VAXstation, SUN, Macintosh usw. – den Zugriff auf die Dateien und Dienste unserer DEC-20- und IBM-Mainframes in einem einheitlichen und einheitlichen Rahmen ermöglicht transparenter Weg. Das Projekt scheiterte letztendlich, weil die Technologie an uns vorbeiging (billige Ethernet- und Token-Ring-Verbindungen und Gateways, Sun NFS, VAX-basierte Macintosh-Dateiserver usw.).

CCMD, vollständig in C geschrieben, führt alle COMND-Funktionen und mehr aus und analysiert das Terminal, eine Datei, eine umgeleitete Standardeingabe oder eine Zeichenfolge im Speicher. Es ist nicht auf eine bestimmte Tastatur oder einen bestimmten Bildschirm ausgerichtet. Es begünstigt weder den Anfänger noch den Experten. Es läuft unter 4.xBSD, Ultrix, AT&T System V, SunOS und MS-DOS und sollte problemlos auf VAX/VMS und jedes andere System mit einem C-Compiler portierbar sein.

CCMD ist eine vollständige COMND-Implementierung, die verkettete FDBs (z. B. das Parsen eines Dateinamens, einer Zahl oder eines Datums), die Umleitung von Befehlseingaben usw. ermöglicht. Zu den Ergänzungen zum DEC-20 COMND JSYS gehören „?“-Hilfelisten zum Abgleichen von Dateinamen, teilweise Vervollständigung von Dateinamen (bis zum ersten Zeichen, das nicht eindeutig ist), ein sehr flexibler Zeit- und Datumsparser und zusätzliche Datentypen.

Mithilfe von CCMD konnten die Programmierer von Columbia einen Klon von DEC-20 MM vollständig in C schreiben. Er verfügt über alle Funktionen von DEC-20 MM und einige weitere. Es verarbeitet eine Vielzahl von Mail-Dateiformaten, darunter DEC-20, Babyl (RMAIL) und mbox (UNIX-Mail). Es verwendet UNIX-Sendmail als Zustellungssystem und sollte an die Zustellungsdienste von Nicht-UNIX-Systemen anpassbar sein.

Die Autoren – und überraschend viele andere Menschen auf der ganzen Welt – nutzen Columbia MM auch heute noch als E-Mail-Client (aber leider seit 2015 nicht mehr bei Columbia). Es kann auf (mindestens) Linux, FreeBSD, OpenBSD, NetBSD, Solaris und SunOS erstellt und installiert werden. Sie können es HIER finden .

LETZTE WORTE...

[Denken Sie daran: Dies wurde 1988 geschrieben.]

Kolumbien ist stark dezentralisiert und leidet unter Budgetknappheit, die allen Hochschuleinrichtungen gemeinsam ist. Es gibt keinen zentralen Auftrag, auf jedem Schreibtisch teure Arbeitsplätze zu platzieren, die über Gigabit-Glasfasernetze verbunden sind. Studierende, Dozenten und Mitarbeiter verwenden zumeist eigene oder abteilungsinterne Mittel, um den besten PC zu bekommen, den sie nutzen können, typischerweise einen IBM PC oder Macintosh mit einer RS-232-Schnittstelle. Die meisten Benutzer kommunizieren nur sporadisch über DFÜ oder indem sie eine Diskette zu einem öffentlichen PC-Labor mitnehmen, wo PCs an das Netzwerk oder einen Laserdrucker angeschlossen sind.

Was bleibt zentral zu tun, wenn PCs immer günstiger und leistungsfähiger werden? Es gibt Leute, die behaupten, dass alles, was ein VAX oder DEC-20 kann, auch auf einem PC erledigt werden kann. Die einzigen Ausnahmen könnten sehr große Anwendungen, gemeinsam genutzte und/oder große und/oder sich ständig ändernde Datenbanken sowie die Kommunikation im Allgemeinen sein – Weitverkehrsnetze, E-Mail, gemeinsam genutzte Programmbibliotheken, Schwarze Bretter, Konferenzen usw.

Eine massive Dezentralisierung der Datenverarbeitung bedeutet jedoch eine enorme Verdoppelung des Aufwands und der Kosten für Hardware, Softwarelizenzen und Wartung. Jeder wird zum Systemmanager, der Backups durchführt, Fehler behebt, Software installiert und debuggt, berät, Schulungen durchführt und nach Ersatzteilen sucht. Forscher, die einst auf der Suche nach einem Heilmittel gegen Krebs oder AIDS waren, betätigen jetzt DIP-Schalter, führen Norton-Dienstprogramme auf ihren kaputten Festplatten aus und stöbern in den Rückseiten von BYTE nach Schnäppchen. Jede Person oder Gruppe verfügt möglicherweise über eine einzigartige Sammlung von Software und Hardware, was Unterricht, Zusammenarbeit und die meisten anderen Funktionen viel schwieriger macht als in Zeiten des Timesharings. Und Platz für die Computerausrüstung muss in praktisch jedem Büro und Wohnheimraum gefunden werden, und nicht in einem zentralen Bereich. Irgendwann mal, Die Haushaltsplaner bemerken möglicherweise die kumulative Wirkung all dieser verteilten Datenverarbeitung, und das Pendel beginnt, in die andere Richtung auszuschwingen. Wie lautet der Ausdruck „Skaleneffekte“?

Vor einigen Jahren gab es während der Treibstoffkrise einen Artikel in der Zeitung über die Rückkehr von Klipperschiffen ... Die großen DEC-Systeme, die Klipperschiffe der Timesharing-Ära, werden nie zurückkehren, aber sie werden in der Software, die sie hervorgebracht haben, weiterleben – EMACS, TeX, Scribe, Spell, MM, Kermit, erweiterte LISP-Dialekte und so weiter. Während die Computerindustrie unterdessen darum kämpft, PCs in Mehrbenutzersysteme umzuwandeln und Multiprozessor, Sicherheit und andere vergessene Konzepte neu zu erfinden, könnte es sinnvoll sein, innezuhalten und auf die vergangenen Jahrzehnte zurückzublicken, als die Kosten und Einschränkungen der Computerausrüstung Designer und Programmierer dazu zwangen Sei... na ja, schlauer.

EPILOG

(Januar 2001)

Wenn Sie heute in ein normales Einzelhandelsgeschäft gehen und einen Computer mit der 10-fachen Leistung (und dem 100-fachen Hauptspeicher und der 1000-fachen Festplattenkapazität) des größten und schnellsten KL10 aller Zeiten für unter 1000 US-Dollar kaufen können, schließen Sie ihn an Wenn wir eine gewöhnliche Wandsteckdose und einen Telefonanschluss (oder einen Kabelkasten usw.) anschließen und in wenigen Minuten mit vollfarbigen Grafiken, Videos, Ton und wer weiß was noch im Internet sind, könnten wir leicht vergessen, wie sich Computer aus großen Computern entwickelt haben Standalone-Rechner mit gespeicherten Programmen in „Kommunikatoren“ umzuwandeln. Zumindest für uns an der Columbia University begann der Wandel mit den großen DEC-Systemen, die uns alle auf einmal mit Filesharing, E-Mail sowie lokalen und Weitverkehrsnetzwerken vertraut machten und uns Möglichkeiten der Zusammenarbeit und Kommunikation bei der Arbeit und im Leben eröffneten: innerhalb des Computers, auf dem Campus und auf der ganzen Welt.

Die Obduktion des PDP-10 war langwierig und schmerzhaft (wer hat es getötet und warum, wie hätte es überleben können und wie würde die Welt heute aussehen, wenn es so gewesen wäre), aber diejenigen, die vielleicht noch einen Blick in die aufregenden Zeiten der 1970er Jahre werfen möchten Als Computer in den 1980er-Jahren zum ersten Mal ein kulturelles Phänomen und ein Kommunikationsmedium wurden, ist dies nun möglich, da mehrere softwarebasierte PDP-10-Emulationsprojekte im Gange sind. Das vielleicht größte Erbe dieser Zeit findet sich in der heutigen Open-Software-Bewegung, in der Entwickler auf der ganzen Welt an Projekten zusammenarbeiten, die von Betriebssystemen (Linux, FreeBSD usw.) bis hin zu Anwendungen aller Art reichen, genau wie das ursprüngliche PDP-10 ARPANET „Hacker“ haben es getan ( ob das ein tragfähiges Geschäftsmodell ist, ist eine andere Frage :-)

Unterdessen behalten viele von uns, die diese Ära erlebt haben, ihre alten Gewohnheiten bei und verwenden immer noch textbasierte Anwendungen wie EMACS und MM anstelle ihrer modischen, aber arbeitsintensiven GUI-Ersatzprodukte, allerdings auf UNIX-Plattformen wie Linux anstelle von PDP-10s. Jedes Mal, wenn ein neuer PC-Virus den gesamten Planeten in Chaos und Panik stürzt, bemerken wir es kaum . Es gibt etwas für die alten Gewohnheiten.