Zusammenfassung

  • LAP6 zeigte ein langes Manuskript als bewegliche Schriftrolle: Nutzer konnten an der aktuellen Stelle Zeilen einfügen oder löschen und sahen den geänderten Text unmittelbar im Zusammenhang.
  • Das Ablegen schrieb einen benannten LINCtape-Eintrag; Umwandlung, Laden, Ausführung und die Gültigkeit eines Experiments blieben nachfolgende, voneinander getrennte Prüfungen.
  • Wilkes schrieb LAP6. Die Quellen nennen zugleich Mishell J. Stucki und Severo M. Ornstein für die Bandtechnik des Editors, Wesley Clark und sein Team für den LINC-Kontext sowie Nutzer und Kollegen der Washington University für Anforderungen und Erprobung.

Eine Quellcodezeile erscheint auf dem Bildschirm des LINC. Die Bedienerin steuert sie an, löscht sie und tippt eine neue. Die folgenden Zeilen rücken auf; ihre Nummern ändern sich; die Korrektur steht sichtbar im Kontext. Auf einer Maschine mit nur 2.048 12-Bit-Wörtern war dies kein dekoratives Bedienkonzept, sondern das Zentrum eines Entwicklungssystems.

Mary Allen Wilkes beschrieb LAP6 1970 in „Conversational Access to a 2048-Word Machine“ als Online-Umgebung für Textbearbeitung, automatische Ablage, Dateipflege, Programmvorbereitung und Assemblierung. Die Leistung bestand darin, diese Tätigkeiten zu verbinden, ohne sie als denselben Vorgang auszugeben.

Das Manuskript war ein sichtbares Arbeitsobjekt

Ein LAP6-Manuskript konnte jede sinnvolle Folge von Tastaturzeichen enthalten. Quellprogramme waren typisch, aber kein vorgeschriebenes Format. Die Standardschriftrolle umfasste 45 Bandblöcke beziehungsweise 23.040 Zeichen; jeweils nur ein kleiner Teil musste im Kernspeicher bearbeitet werden.

Während der Eingabe bewegte sich das Manuskript weiter. Ein Potentiometer bestimmte die Zahl der sichtbaren Zeilen. Zeilennummern waren relative Orientierungspunkte und wurden nach Änderungen neu vergeben. Für große Sprünge diente eine Zeilennummer, für die nähere Positionierung bewegten Tastenkombinationen die Schriftrolle um ein Bild oder eine Zeile in beide Richtungen. Zum Editieren brauchte es keine eigene Kommandosprache: An der aktuellen Stelle wurde eine Zeile eingefügt oder entfernt, und die Anzeige integrierte die Änderung.

Wilkes' eigener Aufsatz über das Scroll-Editing erläutert den Mechanismus. Der Text blieb eine fortlaufende Zeichenkette an festen Bandadressen. Ein 512 Zeichen großer Arbeitsbereich am Trennpunkt nahm Einfügungen und Löschungen auf; beim Verschieben der Schriftrolle wurde das Material wieder eingegliedert. Der Algorithmus bearbeitete den Text direkt, statt eine verborgene Änderungsliste für einen späteren Abgleich anzulegen.

Die sichtbare Änderung bewies daher genau eines: Das aktuelle Manuskript hatte einen neuen Zustand. Sie bewies nicht, dass eine benannte Kopie auf Band geändert worden war, dass sich der Text assemblieren ließ oder dass das Ergebnis das beabsichtigte Verhalten zeigte.

Die Ablage schuf einen weiteren Zustand und eine weitere Fehlergrenze

Ein Zwei-Block-Index verwaltete die LAP6-Dateien. Ein Eintrag konnte Manuskript oder Binärprogramm sein; beide Typen durften sogar denselben Namen tragen, ohne dass sie dasselbe Objekt waren. Der Speicherbefehl übertrug das aktuelle Manuskript oder einen ausgewählten Abschnitt in einen Eintrag. Kopierbefehle bewegten Manuskripte, Binärdateien oder alle noch nicht vorhandenen Einträge zwischen zwei Bändern.

LAP6 suchte zusammenhängende freie Blöcke in der Nähe des Index. Beim Ersetzen mussten nicht dieselben physischen Blöcke verwendet werden. Existierte der Name bereits, zeigte das System REPLACE? und verlangte eine Entscheidungstaste. Diese Rückfrage schützte den Namen vor unbedachtem Überschreiben; sie war kein Zertifikat für eine unteilbare Transaktion.

Das LAP6 Handbook benennt die Grenze offen. Sobald LAP6 den Index aktualisiert hat, macht eine Unterbrechung den Ablagevorgang nicht mehr rückgängig. Zudem schreibt LAP6 den Index vor dem zugehörigen Dateieintrag. Ein Bandfehler dazwischen kann deshalb einen Index hinterlassen, der einen nicht vorhandenen Eintrag beschreibt. Eine Sicherungskopie des Index gab es nicht.

Eine erfolgreiche Ablage sagte somit mehr aus als eine korrigierte Anzeige: LAP6 hatte einen benannten Eintrag bearbeitet. Für verlässliche Nutzung mussten Band, Index und Nutzdaten aber weiterhin übereinstimmen. Die Wiederherstellungsanweisungen des Handbuchs existieren, weil genau diese Übereinstimmung scheitern konnte.

Assemblieren und Ausführen waren keine Synonyme für Speichern

Bei Quellprogrammen assemblierte CONVERT das aktuelle Manuskript in Binärform. LAP6 konnte Symbolfehler mit Manuskriptzeilen, den benötigten Speicherbereich und die Symbolzuordnungstabelle anzeigen. Trat ein Fehler auf, kehrte der Nutzer zum Manuskript zurück, korrigierte es und konvertierte erneut.

LOAD war ein weiterer Vorgang. Er übertrug das aktuelle oder ein abgelegtes Binärprogramm in den Speicher und startete es nach der dokumentierten Konvention. Blieb das LAP6-Band eingelegt, konnte man rasch zu Manuskript und Symboltabelle zurückkehren, korrigieren und neu assemblieren. Der kurze Weg verringerte Binär-Patches; er machte eine Quelltextänderung nicht zum Laufzeitergebnis.

Die Beweiskette blieb geordnet: Die Anzeige belegte den Quellzustand, die Ablage einen benannten Eintrag, die Konvertierung ein Binärprogramm samt Diagnosen, das Laden ein bestimmtes Binärprogramm im Speicher und der Test sein beobachtetes Verhalten. Ob ein angeschlossenes Instrument und das Experiment ein gültiges Ergebnis lieferten, musste weiterhin ein externes Protokoll zeigen.

Auch die Grenze der Urheberschaft zählt

Laut ihrer Oral History im Computer History Museum schrieb Wilkes den größten Teil von LAP6 im Jahr 1965 auf einem LINC im Wohnzimmer ihrer Eltern in Baltimore. Sie entwickelte das System nach eigener Erinnerung weitgehend neu, übernahm ausgewählte frühere Routinen und schickte die LAP5-Fassung vor der allgemeinen Freigabe für mehrere Monate nach St. Louis.

Das ist starke Evidenz für ihre Urheberschaft, aber kein Grund, das Umfeld zu tilgen. Wesley Clark leitete das LINC-Projekt und verfasste mit Wilkes „Programming the LINC“. Das Handbuch nennt Mishell J. Stucki und Severo M. Ornstein ausdrücklich als Urheber der im Editor verwendeten Bandbehandlungstechnik. Kollegen der Washington University prüften Vorabfassungen; Besuche in LINC-Laboren prägten die Anforderungen. Das MIT Lincoln Laboratory stellte das frühere Umfeld für LINC und Simulator bereit.

Sekundäre Erzählungen verwischen bisweilen auch Namen. Die geprüften Primärquellen nennen Mishell J. Stucki und Severo M. Ornstein. Sie belegen keine eigenständigen LAP6-Beiträge von Personen namens „Philip Mishell“ oder „Ted Severo“. Verantwortliche Geschichtsschreibung lässt diese Unklarheit stehen, statt Identitäten oder Rollen zu erfinden.

Quellen