TR 440

TR 440 (gesprochen: T-R-4-40) ist die Bezeichnung des von AEG-Telefunken, Fachbereich Informationstechnik, aus dem „Telefunken-Rechner TR 4“ weiterentwickelten Großrechners. AEG-Telefunken lieferte 1969 den ersten TR 440 an das Deutsche Rechenzentrum. Als der TR 440 herauskam, war er der schnellste Rechner, der je in Europa entwickelt worden war. Bis zum Jahr 1974 wurden insgesamt 46 Anlagen vom Typ TR 440 gebaut.

Operateur-Arbeitsplatz eines TR 440

Das Gesamtsystem aus Hardware, BS 3 und Programmiersystem wurde auch unter dem Namen TNS 440 (Teilnehmer-System 440) vermarktet.

Der (auch: die) TR 440 oder TR440 (Schreibweise uneinheitlich) wurde an mehr als zwanzig deutschen Universitäten und regionalen Rechenzentren eingesetzt, unter anderem Ruhr-Universität Bochum (1970), Friedrich-Alexander-Universität Erlangen-Nürnberg und Universität Kaiserslautern; an Forschungseinrichtungen wie dem DLR oder der GKSS; bei Behörden wie der PTB und dem RZF NRW; sowie bei der Bundeswehr an zwei Standorten. AEG-Telefunken und später CGK betrieben TR 440 für eigene Zwecke an fünf Standorten.

Der Erlanger Rechner war als einziger mit einem Dreifach-Prozessor ausgerüstet, die anderen liefen in der Endphase teilweise mit Doppelprozessoren.

Ein Nachfolgeprodukt, der TR 550, wurde zwar konzipiert, aber nicht mehr entwickelt.

Geschichte

Am 23. September 1965 begann AEG-Telefunken, einen neuen Großrechner als Nachfolger des TR 4 zu entwickeln. Zunächst war an eine weitgehend dem TR 4 nachempfundene Architektur mit integrierten Schaltkreisen (10‑fache Taktfrequenz) gedacht. Aufgrund der Wünsche potenzieller Kunden wurde der TR 440 ab Winter 1965–66 für den Teilnehmerbetrieb konzipiert; hardwareseitig mussten dazu die Voraussetzungen für eine Virtuelle Speicherverwaltung, abgestufte Rechte für den Speicherzugriff und effiziente Prozess-Umschaltung geschaffen werden. Außerdem wurde das bereits umfangreiche Befehls-Repertoire des TR 4 um weitere Befehle ergänzt; ein spezieller Befehlsmodus erlaubt, den TR 4 zu emulieren. Softwareseitig wurde eine dialogfähige Benutzerschnittstelle konzipiert, mit einer einheitlichen Kommandosprache für Stapelverarbeitung und Dialogbetrieb und mit dialogfähigen Testhilfen.

Das Konzept für das Betriebssystem BS1 erwies sich als zu ambitioniert; die Entwicklung wurde Anfang Oktober 1969 eingestellt und die Entwicklung des BS 3 begonnen. Der geplante Liefertermin für den ersten TR 440 (1. Juli 1968) war da bereits verstrichen; der Rechner wurde Ende 1968 an das DRZ mit einem kurzfristig entwickelten Betriebssystem ausgeliefert, das zwei virtuelle TR 4 auf einem TR 440 realisierte, und im Februar 1969 offiziell in Betrieb genommen. Eine erste Version des BS 3 (nur Stapelbetrieb mit zwei gleichzeitig aktiven Benutzer-Aufträgen) wurde schon am 7. November 1969 in Konstanz vorgeführt; das erste (dialogfähige) TNS 440 wurde im Juni 1970 an die RUB ausgeliefert. In den Folgejahren wurde das TNS 440 laufend erweitert und verbessert; bis Ende 1979 wurden insgesamt 20 Maintenance-Versionen ausgeliefert.

Der TR 440 wurde hauptsächlich für technisch-wissenschaftliche Anwendungen eingesetzt; lediglich bei der Finanzverwaltung Nordrhein-Westfalen und bei AEG-Telefunken selbst wurde der TR 440 in größerem Umfang für kaufmännisch-administrative Aufgaben eingesetzt. Es gelang weder AEG-Telefunken noch dem Nachfolger Telefunken Computer, weitere Kundschaft in diesem Anwendungsbereich zu gewinnen.

Zur Erhöhung der nutzbaren Rechenleistung wurde zunächst der Betriebsmittelbedarf des BS 3 verringert; ab Juni 1972 konnte der TR 440 als Doppelprozessor-Anlage betrieben werden. Außerdem wurden neue, verbesserte Peripheriegeräte ins System integriert. Trotzdem konnte der TR 440 ab Mitte oder Ende der 1970er-Jahre die gestiegenen Anforderungen an die Rechenleistung nicht mehr erfüllen. Am 19. Juli 1974 übernahm die Siemens AG den Hersteller des TR 440 als Tochterfirma Computer Gesellschaft Konstanz (CGK). In der Folge wurde die Entwicklung am Nachfolgerechner TR 550 eingestellt und die Weiterentwicklung des TNS 440 auf die unbedingt notwendige Pflege eingeschränkt. Ab 1977 bot Siemens Computersysteme der Serie 7.700 mit dem Betriebssystem BS2000 in direkter Nachfolge zum TR 440 an.

1986 gab die Universität Tübingen ihren TR 440 an die Universität Toruń (Polen) ab; danach waren in Deutschland außerhalb der CGK noch vier TR 440 in Betrieb. Mitte 1988 legte die Universität Osnabrück ihren TR 440 still; der letzte TR 440 wurde 1989 im Rechenzentrum der CGK stillgelegt.

Die möglichen Nachfolgesysteme waren weit weniger benutzerfreundlich als das TNS 440; insbesondere gegen die Beschaffung von 7.700-Rechnern mit BS2000 gab es große Widerstände trotz der von Siemens angebotenen Umstellungshilfen. Die Wertschätzung für das TNS 440 bei den Nutzern ging wesentlich auf dessen Systemsoftware zurück: Das Betriebssystem bietet eine Virtuelle Speicherverwaltung mit Speicherschutz und Mehrfachzugriff, das Programmiersystem eine flexible, übersichtliche Kommandosprache, eine gute Ausstattung an Programmiersprachen (einschließlich Sprachverknüpfung) und Programmbibliotheken, sowie innovative Testhilfen für die Programmentwicklung.

„Hinsichtlich des – gerade für ein Hochschulrechenzentrum so wichtigen – Aspektes Komfort der Benutzerschnittstelle ist der TR 440 ein großer Fortschritt gegenüber fast allen Großrechnern, die ihn ersetzt haben.“

– Thomas Haarmann

Historische Relevanz

Obwohl die ursprünglich angestrebte Geschwindigkeit nicht erreicht wurde, war der TR 440 bei seiner Fertigstellung 1969 als einer der ersten großen Rechner die schnellste bisher in Europa entwickelte und produzierte Maschine. Die Leistung des Prozessors betrug knapp 1 MIPS; der GAMM-Mix betrug 4,4 µs (Assembler) bis 6,4 µs (Algol 60). Die Hauptspeicherkapazität betrug bis zu 1,5 MB mit einer mittleren Zugriffszeit von 0,125 µs beim Schreiben und 0,375 µs beim Lesen.

Das TNS 440 hatte große Bedeutung für die Entwicklung der Informatik in Deutschland: Von den 14 Lehrstühlen, die bis 1977 im Rahmen des Überregionalen Forschungsprogramms Informatik im Bereich der Kerninformatik eingerichtet wurden, hatten neun (also fast zwei Drittel) Zugriff auf TR-440-Anlagen, teils im eigenen Institut, teils im Rechenzentrum der jeweiligen Universität. 1980 ergab eine Umfrage in der Fachgruppe Künstliche Intelligenz in der Gesellschaft für Informatik, dass der TR 440 der bei den Mitgliedern dieser Gruppe am weitesten verbreitete Rechner war und dass darauf die Programmiersprachen Maclisp, Fortran (gemeint war FORTRAN IV), Algol 60, Pascal, Logo, Snobol und BCPL zur Verfügung standen. Die STARG veranstaltete jährlich Benutzertagungen, die mit ihrem reichhaltigen Programm als Treffpunkt eines erweiterten Kreises von TR-440-Anwendern großen Zuspruch fanden.

Auch das beim Hersteller des TR 440 angesammelte Wissen über Software-Entwicklung und das Management großer Projekte kam der Informatik in Deutschland zugute.

Hardware

Rechnerkern RD 441

Technische Einzelheiten

Steckeinheit von der Zentraleinheit des TR 440

• monolithische Schaltkreise,
• Kernspeicher-Module von bis zu 16 K Wörtern zu je 52 Bit (später Halbleiterspeicher),
• Zykluszeit 0,9 µs, bei Zyklenüberlappung 0,125 µs; das ergibt ca. 800 000 Operationen/Sekunde.

Als Vertreter der CISC-Architektur hat der Rechnerkern RD 441 Register mit unterschiedlichen Funktionen. Im Rechenwerk fassen die meisten Register 48 Bit Typenkennung, im Einzelnen der Akkumulator RA, das Quotientenregister RQ, das Multiplikandenregister RD und das Hilfsregister RH, dazu kommen noch der Schiftzähler RY mit 8 Bit und das Markenregister RM mit 1 Bit. In RA werden Transport- und Rechen-Operationen ausgeführt; RA und RQ können für Multiplikation und Division zum doppeltlangen Register RAQ verbunden werden; RH enthält bei Vergleichen den zweiten Operanden und dient sonst als kurzfristiger Zwischenspeicher. Im Befehlswerk gibt es das Bereitadressenregister BB (24 Bit), das Befehlsfolgeregister BF (24 Bit), das Indexbasisregister BXB (22 Bit), das Merklichterregister BK_links (8 Bit), das Unterprogrammregister BU (8 Bit), den Wecker BW (16 Bit), die Uhr BG (24 Bit) und das Testregister BT (24 Bit). BF enthält stets die Adresse des Befehls, der als nächster ausgeführt werden soll. BXB enthält die Anfangsadresse eines Bereiches von 256 Halbwörtern des Hauptspeichers, die einem Programm als Indexspeicher dienen; BU enthält den Pegel eines Kellers für Unterprogramm-Rücksprungadressen, der innerhalb dieses Indexspeichers angelegt werden kann. Der Inhalt von BK_links wird laufend am Kontrollpanel angezeigt.

Das Befehlswerk arbeitet unabhängig vom Rechenwerk: während letzteres einen zeitaufwendigen Befehl durchführt, etwa eine Gleitkommaoperation oder einen Tabellensuchbefehl, kann des Befehlswerk bereits nachfolgende Befehle ausführen, sofern diese das Rechenwerk nicht benötigen. Das Ein-Ausgabe-Werk arbeitet unabhängig von Befehls- und Rechenwerk und kann nur im Systemmodus angesprochen werden.

Informationsdarstellung

Das Ganzwort enthält 52 Bit: zwei für die Dreierprobe, zwei für die Typenkennung und die restlichen 48 Bit für die eigentliche Information.

Zahlen werden im Einerkomplement dargestellt, Gleitkommazahlen mit 8 Bit Exponent zur Basis 16 und 39 Bit Mantisse (85 Bit bei doppelter Genauigkeit), jeweils einschließlich Vorzeichen. Bei Gleit- und Festkommazahlen sind in den Rechenwerksregistern zwei Bit für die Darstellung des Vorzeichens vorgesehen; das zusätzliche Vorzeichenbit dient zum Erkennen eines arithmetischen Überlaufs. Im Speicher ist – im Gegensatz zu den Rechenwerksregistern – dieser Überlauf-Schutz unnötig; hier steht das zusätzliche Vorzeichenbit als Marke zur Verfügung, etwa zur Kennzeichnung des letzten Koeffizienten eines Polynoms.

Die Typenkennung (TK) zeigt an, wie der Inhalt des Ganzworts zu interpretieren ist: Gleitkommazahlen und der höherwertige Teil doppelt genauer Gleitkommazahlen haben TK=0; Festkommazahlen und der niederwertige Teil doppelt genauer Gleitkommazahlen haben TK=1; Ganzwörter, die zwei Befehle enthalten, haben TK=2; Zeichenketten oder beliebige Bitmaterie haben TK=3; Ganzwörter, die zwei Adressen enthalten, haben beliebige Typenkennung. Eine architektonische Besonderheit sind typenkennungsabhängige Maschinenbefehle: Einige Befehle des Befehlssatzes arbeiten unterschiedlich, je nach der Typenkennung der Operanden, andere sind nur auf Operanden mit bestimmter Typenkennung anwendbar. Beispiele:

• Der Befehl B (für Bringe) kopiert ein Wort aus dem Speicher ins RA-Register. Hat dieses Wort TK=0 oder TK=1, so wird dessen Markenbit ins RM kopiert und das linke Vorzeichenbit im RA ans rechte angeglichen; bei TK=2 oder TK=3 bleibt dagegen RM unverändert und sämtliche Bits des Operanden werden nach RA übertragen.
• Der Befehl SG (für Springe wenn größer) vergleicht den Inhalt der Register RA und RH. Wenn mindestens eines dieser Register TK=2 oder TK=3 hat, werden die Inhalte als vorzeichenlose Binärzahlen verglichen; wenn eins der beiden Register TK=1 und das andere TK=1 oder TK=0 hat, als Festkommazahlen (mit Berücksichtigung des Vorzeichens); wenn beide Register TK=0 haben, als Gleitkommazahlen (mit Berücksichtigung von Vorzeichen und Exponent).
• Der Befehl S (für Springe) muss auf ein Halbwort in einem Wort mit TK=2 führen, andernfalls wird eine Programmunterbrechung, der so genannte Befehls-Alarm, ausgelöst; der Befehl GA (für Gleitkomma-Addition) erwartet zwei Operanden mit TK=0, andernfalls wird der so genannte TK-Alarm ausgelöst.

Außer Ganzwörtern können durch spezielle Befehle auch Halb- und Doppelwörter, Bytes (wahlweise zu 4, 6, 8 oder 12 Bit) oder (gesteuert durch eine Maske) beliebige Ausschnitte eines Ganzwortes transportiert werden.

Adressierung

Jedes Halbwort im Hauptspeicher kann direkt adressiert werden; einem Ganzwort sind also zwei aufeinander folgende Adressen zugeordnet, von denen die kleinere, die stets gerade ist, als Ganzwortadresse gilt. Die Befehle BNZ und CNZ (Bringe/Speichere nächstes Zeichen) arbeiten mit einer Kombination von Ganzwort-Adresse und Position innerhalb des Wortes; nur die Befehle TOK (Transportiere Oktaden) und ZK (Zeichenkettenverarbeitung) verwenden Sechstelwort-Adressen.

Der Adressteil der Maschinenbefehle ist 16 Bit lang, damit können also 2¹⁵ Ganzwörter, eine sogenannte Großseite, adressiert werden. Indirekte Adressen sind 22 Bit lang und werden in Halbwörtern (24 Bit) gehalten. Befehle und Operanden (Konstanten und Variable) können in unterschiedlichen Großseiten mit jeweils eigenen 16-Bit-Adressräumen abgelegt werden. Während der 16-Bit-Adressraum für Operanden stets am Anfang des 22-Bit-Adressraums liegt, können 16-Bit-Adressräume für Befehle bei Bedarf auch bei höheren 22-Bit-Adressen liegen.

Der RD 441 kennt vier verschiedene Adressierungsmodi: der Systemmodus verwendet reale Hauptspeicheradressen, die übrigen drei verwenden virtuelle Speicheradressen mit Zugriffsschutz; im Systemmodus laufen nur der Systemkern (Hauptspeicherverwaltung, Ein- und Ausgabe), die Warteschleife, die Notschleife und der Operateurvermittler; so sind auch die übrigen Teile des Betriebssystems vor unberechtigten Speicherzugriffen (durch eventuelle Programmierfehler) geschützt.

Im Normalmodus, in dem die Benutzerprogramme abgewickelt werden, sind die Adressräume der einzelnen Benutzer-Aufträge voneinander abgeschottet, um gegenseitige Beeinflussung – versehentliche oder absichtliche – auszuschließen; ebenso sind die Adressräume der diversen Systemteile vom Benutzerprogramm abgeschottet. Befehle und Konstanten von Programmen, die gleichzeitig von mehreren Benutzeraufträgen genutzt werden (etwa Kommandoentschlüssler oder Compiler), liegen dabei nur einmal im realen Hauptspeicher (sogenannter Mehrfachzugriff; ab Februar 1972); die variablen Teile eines aktiven Programms stehen selbstverständlich dem betreffenden Programmlauf individuell zur Verfügung.

Satellitenrechner

Die Kommunikation mit der Dialog-Peripherie (Fernschreiber und Sichtgeräte) und die Datenfernverarbeitung wird von einem Prozessrechner TR 86 erledigt. Dieser Satellitenrechner puffert die zeichenweisen Ein- und Ausgaben, tauscht mit dem Zentralrechner nur vollständige Aufträge und Dialogeingaben bzw. Ausgabeaufträge und Dialogausgaben aus und entlastet ihn dadurch von der zeitaufwendigen Reaktion auf die Übertragung einzelner Zeichen. Außerdem codiert der Satellitenrechner die Eingaben aus den unterschiedlichen Gerätecodes in den einheitlichen ZC 1 um und entsprechend die Ausgaben vom ZC 1 in die unterschiedlichen Gerätecodes.

Mehrere Satellitenrechner können parallel oder in Kaskade angeschlossen sein (ab Februar 1972); ab Juni 1973 können Satellitenrechner auch über gemietete Postleitungen miteinander gekoppelt werden.

Peripheriegeräte

• Fernschreiber FSR 105 (für abgesetzte Arbeitsplätze, angeschlossen mit 200 Baud)
• ab Februar 1972: Sichtgerät SIG 100 (Vektorgrafik, auch für Zeichen- und Buchstabendarstellung, Kleinbuchstaben nur als Kapitälchen)

  

  Rollkugel RKS 100-86

Unterseite der Rollkugel RKS 100-86

• RKS 100-86 (optionale Ergänzung zum SIG 100, die erste Computermaus weltweit)

• ab Juni 1972: Sichtgerät SIG 50 (Text im Blockmodus); ab Juni 1974: Sichtgerät SIG 51
• Trommelspeicher TSP 500
• Plattenspeicher PSP 600
• ab Dezember 1972: Wechselplattenspeicher WSP 414; ab Dezember 1974: Wechselplattenspeicher WSP 430
• Magnetbandeinheit MDS 252 oder MDS 254
• Lochkartenleser LKL 720
• Lochkartenstanzer LKS 145
• Lochstreifenleser LSL 195
• Lochstreifenstanzer LSS 150
• Schnelldrucker SDR 176
• Plotter ZCH 230 oder ZCH 233

Sichtgeräte und Fernschreiber werden über den Satellitenrechner angeschlossen, Trommel-, Plattenspeicher und Magnetbandeinheiten direkt am Zentralrechner. Lochkartenleser und ‑stanzer, Lochstreifenleser und ‑stanzer, Schnelldrucker und Plotter können wahlweise am Zentralrechner oder – bei Datenfernverarbeitung – über den Satellitenrechner angeschlossen werden.

Zentrales Bedienelement für die Operateure und zugleich Protokolldrucker ist eine Kugelkopfschreibmaschine IBM Selectric, die über den sogenannten Prüfkanal direkt am RD 441 angeschlossen ist. Um den Rechner neu zu starten, kann der Lochstreifenleser von einem Standardkanal auf den Prüfkanal umgeschaltet werden.

Betriebssystem BS 3

Das Betriebssystem verwaltet die Benutzer-Aufträge und teilt diesen die Betriebsmittel (Speicherbereiche, Rechenkapazität, Magnetband- und Wechselplatten-Laufwerke) zu. Das BS 3 wickelt gleichzeitig mehrere parallel ablaufende Aufträge in Stapelverarbeitung (sogenannte Abschnitte) und bis zu 48 Aufträge im Dialogbetrieb (sogenannte Gespräche; 96 ab Juni 1972) ab.

Das Betriebssystem verwaltet auch die Daten der Benutzer in den Speichermedien. Auf Trommel- und Plattenspeichern sind die Daten in Dateien organisiert. Benutzerdateien können in der sogenannten LFD (langfristige Datenhaltung) gelagert werden und so zwischen den Aufträgen desselben Benutzers übertragen und wahlweise auch anderen Benutzern zugänglich gemacht werden. Eingabe von Lochkarten und -streifen, sowie Ausgabe auf Lochkarten, -streifen, Drucker und Plotter sind vom Benutzerauftrag entkoppelt; dabei übernimmt das BS 3 bzw. das Satellitenprogramm die Umcodierung der Datenströme. Auch auf Magnetbändern organisiert das BS 3 wahlweise die Dateien und erledigt die Umcodierung.

Zeichencodierung

Innerhalb des Betriebssystems und des darunter ablaufenden Programmiersystems sind Zeichenketten durchgängig im Zentralcode 1 (ZC 1) codiert. Dieser Code sah als erster 8-Bit-Code unterschiedliche Codepositionen für Umlaute und eckige bzw. geschweifte Klammern vor; so können Programme in Algol 60 (eckige Klammern) mit deutschsprachigen Kommentaren und Zeichenketten-Literalen (Strings) formuliert werden. Auch hier war das TNS 440 seiner Zeit voraus: Die Codierungen anderer Hersteller litten bis in die 90er-Jahre unter der Mehrdeutigkeit der Codepositionen für die Klammern und die Umlaute, was sich besonders beim Datenaustausch und bei der Interpretation von Quelltext durch Standard-Software manifestierte.

Zentralcode ZC 1 gemäß Werknorm 2N 0812.511 (Juli 1972)

Code	…0	…1	…2	…3	…4	…5	…6	…7	…8	…9	…A	…B	…C	…D	…E	…F
0…	NUL						SOH	STX	ETX	EOT	ENQ	ACK	DLE	NAK	SYN	ETB
1…						NL	CR	NF	VT
2…	SUB	EM	CAN			TE						HT	BS	ESC	SO	SI
3…	BEL	DC1	DC2	DC3	DC4	FL							IS4	IS3	IS2	IS1
4…
5…
6…	"	'	´	`		^	°	~				\	ʿ	ʾ	_	¯
7…	%	§	#	$	¢		@	&	*				⯏			π
8…	∧	∨	¬				↑					|		⏨
9…		-		/				=	≠			<	>	≤	≥
A…	(	)	[	]			〈	〉	}	.	,	:	;	!	?	SP
B…	0	1	2	3	4	5	6	7	8	9						{
C…	A	B	C	D	E	F	G	H	I	J	K	L	M	N	O	P
D…	Q	R	S	T	U	V	W	X	Y	Z	Ä	Ö	Ü
E…	a	b	c	d	e	f	g	h	i	j	k	l	m	n	o	p
F…	q	r	s	t	u	v	w	x	y	z	ä	ö	ü	ß		DEL

Einige heute ungebräuchliche Zeichen

7C : Kissen ⯏ (oder Raute ◊); lesbare Darstellung des Fluchtsymbols

6C : in Algol 60 öffnende Stringklammer

6D : in Algol 60 schließende Stringklammer

8D : in Algol 60 Trenner zwischen Mantisse und Exponent einer Gleitkommazahl in dezimaler Schreibweise

Steuerzeichen, soweit nicht vom ASCII bekannt

NF  : Neues Formular (wie ASCII-Zeichen FF)

FL  : Fluchtsymbol, markiert in der Kommandosprache den Beginn eines Kommandos oder das Ende eines Fremdstrings

IS1–IS4: entsprechen den ASCII-Zeichen FS, GS, RS und US

TE  : Textende (Programmiersystem-Konvention, steht 1972 nicht mehr in der ZC1-Norm)

Dateisystem

Das BS 3 unterstützt Dateien im Hauptspeicher, auf Trommel- und Plattenspeicher und auf Magnetbändern. Jedem Benutzer steht ein Plattenspeicher-Bereich in der Langfristigen Datenhaltung (LFD) zur Verfügung, in dem er Dateien außerhalb seiner Aufträge speichern und zwischen Aufträgen übergeben kann. Auf den übrigen Peripheriegeräten werden keine Dateien unterstützt: Eingabedaten sind Teil des Benutzerauftrags im Abschnitts- oder Dialogbetrieb; Ergebnisse der einzelnen Programmläufe können ins Ablaufprotokoll des jeweiligen Auftrags geschrieben, als Ausgabe-Aufträge an Drucker, Lochkarten- oder Lochstreifenstanzer oder Plotter geschickt oder im Dialog direkt angezeigt werden. Auf Magnetbändern werden Dateien nach Telefunken-, ISO- und IBM-Norm unterstützt; eine Datei kann sich auch über mehrere Magnetbänder erstrecken (sogenannte Bandreihe).

Als Dateibezeichnung sind bis zu zwölf beliebige Zentralcode-Zeichen zulässig, optional gefolgt von einer 4-stelligen Generations- und einer 2-stelligen Versionsnummer; die Kommandosprache beschränkt jedoch die Dateibezeichnung auf die Großbuchstaben A–Z, die Ziffern und fünf Sonderzeichen. Wird die Generations- und Versionsnummer nicht angegeben, so wird eine Datei mit einer neuen Nummer kreiert, die Datei mit der höchsten Nummer bearbeitet, bzw. die Datei mit der Nummer 1.0 gelöscht. Dieses System kann als rudimentäre Versionsverwaltung betrachtet werden, allerdings führt das BS3 keinerlei Historie der vergebenen Generations- und Versionsnummern mit und speichert auch keine Deltas.

Im BS 3 sind Dateien in Datensätzen (Storage Records) organisiert; bei Texten entspricht ein Datensatz einer Zeile. Das System unterscheidet folgende Typen von Datensätzen:

• Ausgabezeichen: Textzeile mit Vorschubsteuerung für den Drucker
• Oktaden: Textzeile,
• Ganzwörter: Ganzwörter mit Typenkennung,
• Viertelwörter: Viertelwörter mit Typenkennung,
• Ganzwörter oder Oktaden (datensatzweise unterschiedlich),
• Viertelwörter oder Oktaden (datensatzweise unterschiedlich).

Das System erlaubt sequenziellen oder wahlfreien Zugriff auf die Datensätze (auf Magnetbändern natürlich nur sequenziellen Zugriff). Die Zugriffsmethode (genannt Datei-Typ) wird bei der Kreation der Datei festgelegt, im Einzelnen:

• SEQ: sequenzieller Zugriff,
• RAN: wahlfreier Zugriff über Satznummern (ab 1, mit kleinen Lücken),
• RAM: wahlfreier Zugriff über Satzmarken (je ein Ganzwort mit TK=3),
• RAS: wahlfreier Zugriff über Satzschlüssel (mehr als ein Ganzwort; ab Juni 1974)
• PHYS: Zugriff auf Datenblöcke (ohne Berücksichtigung der Datensatz-Organisation).

Auch aus Dateien mit wahlfreiem Zugriff kann das BS 3 die Sätze sequenziell (ab einer beliebigen Position) lesen; in RAN-Dateien kann es auch sequenziell schreiben.

Vermittler

Die Komponenten des BS 3, die die Ein- und Ausgabe von Aufträgen im Abschnitts- und Gesprächsbetrieb erledigen, heißen Vermittler. Auf Lochkarten stehen vier verschiedene Codes zur Auswahl, auf 5-Spur-Lochstreifen und Fernschreiber drei verschiedene Codes; für 8-Spur-Lochstreifen und Sichtgeräte liegt der Code jeweils fest. Lochkarten und ‑streifen können außerdem auch binär gelesen und gestanzt werden, dabei werden sämtliche möglichen Lochpositionen auf einzelne Bits der Intern-Darstellung abgebildet.

Die Eingabe- und Gesprächs-Vermittler werden mit sogenannten Vermittler-Kommandos und ‑Anweisungen gesteuert. Die Syntax der Vermittler-Kommandos ähnelt den Tätigkeitskommandos des Programmiersystems, ist aber vereinfacht. Vermittleranweisungen bestehen aus einem Fluchtsymbol mit einem nachfolgenden Sonderzeichen bzw. drei nachfolgenden Ziffern.

Zwei verschiedene Vermittlerkommandos markieren den Beginn der Auftragseingabe im Abschnitts- bzw. Dialogbetrieb, eines deren Ende (wobei etwa noch anstehende Bearbeitungsschritte im Abschnittsbetrieb zu Ende geführt werden). Ein Vermittlerkommando legt den Code für nachfolgende Eingaben fest; damit kann der Code innerhalb einer Auftragseingabe beliebig oft gewechselt werden.

Eine Vermittleranweisung gestattet die Eingabe eines beliebigen Zeichens über dessen Position im ZC 1. Zwei Vermittleranweisungen gestatten die Eingabe einer verkürzten bzw. verlängerten Zeile von Lochkarten. Eine Vermittler-Anweisung beendet die Teil-Eingabe am Fernschreiber und übergibt damit die Kontrolle des Dialogs an das BS 3; am Sichtgerät wird die Teil-Eingabe stattdessen durch eine Eingabetaste beendet.

Weitere Vermittler-Kommandos und ‑Anweisungen steuern den Anschluss von Wählgeräten zur Datenfernverararbeitung, gestatten den Abbruch einer Ausgabe am Terminal, sowie die Korrektur von Tippfehlern am Fernschreiber.

Programmiersystem

Das Programmiersystem führt die eigentliche Datenverararbeitung unter der Regie des Benutzers durch; dazu gehören der Kommando-Entschlüssler, die Werkzeuge zur Programmentwicklung, sowie die Anwendungsprogramme.

Kommandosprache

Den Ablauf des Auftrags steuert der Benutzer mittels der Kommandosprache. Im Abschnitt besteht die gesamte Auftrags-Eingabe, im Dialog die erste Teileingabe, aus einer Folge von Kommandos in dieser Sprache. Der sogenannte Entschlüssler interpretiert sämtliche Kommandos und veranlasst die entsprechenden Bearbeitungsschritte; wenn im Dialogbetrieb eine eingegebene Kommandofolge abgearbeitet ist, fordert er weitere Kommandos an.

Wenn bei der Bearbeitung eines Kommandos im Dialogbetrieb ein Fehler auftritt, so geht der Entschlüssler in die sogenannte Vorrangstufe, in der der Benutzer Anweisungen zur Behebung des Fehlers geben oder zusätzliche Kommandos einschieben kann. Im Abschnittsbetrieb kann man das Verhalten im Fehlerfall mit den Kommandos FEHLERHALT und SPRINGE bestimmen.

Die Kommandosprache ist formatfrei: Leerzeichen und Zeilenwechsel sind bedeutungslos; statt durch Zeilenwechsel (wie in anderen zeitgenössischen Systemen) wird der Beginn eines Kommandos durch das sogenannte Fluchtsymbol markiert, das in der Dokumentation als Raute »◊« erscheint.

Die eigentliche Datenverarbeitung wird durch sogenannte Tätigkeitskommandos ausgelöst. Ein Tätigkeitskommando besteht aus einem Tätigkeitsnamen, optional gefolgt von, durch Kommata getrennten, Spezifikationen. Die Spezifikationen können über ihren Namen oder über ihre Reihenfolge identifiziert werden. Tätigkeits‑ und Spezifikationsnamen können abgekürzt werden, soweit Eindeutigkeit besteht. Jeder Spezifikationswert ist − (in der Bedeutung: »nichts«), −STD− (in der Bedeutung: »das Übliche«) oder eine Reihe von, durch Apostroph getrennten, Teilwerten (mit spezifischen Bedeutungen). Die folgenden Beispiele zeigen unterschiedliche Schreibweisen für dasselbe Kommando, das zwei Dateien aus der LFD holt, daneben, getrennt durch ◊=, jeweils die Erläuterung:

◊KOPIERE, DATEI=JORINDE'JORINGEL, QUELLTRAEGER=LFD, ZIELTRAEGER=−STD−, PROTOKOLL=−
◊KOPIERE, JORINDE'JORINGEL, LFD, −STD−, PROTOKOLL=−   ◊= Spezifikationsnamen können entfallen, wenn die Reihenfolge eingehalten wird
◊KOPIERE, JORINDE'JORINGEL, LFD, PROTOKOLL=−   ◊= Für die fehlende Spezifikation setzt der Entschlüssler eine Voreinstellung ein
◊KOP., JORINDE'JORINGEL, LFD, P.=−   ◊= Tätigkeits‑ und Spezifikationsnamen können abgekürzt werden

Falls anschließend dieselbe Tätigkeit mit geänderten Spezifikationen ausgeführt werden soll, kann man das wahlweise durch ein sekundäres Teilkommando (aber auch durch ein weiteres vollständiges Tätigkeitskommando) verlangen. Soll beispielsweise je eine Datei aus der LFD und von einem Magnetband geholt werden, so kann man das folgendermaßen ausdrücken:

◊KOP., ASCHENPUTTEL, LFD, -STD-, P.=− ◊D.=RAPUNZEL, MB(GRIMM)   ◊= ZIELTRAEGER und PROTOKOLL wie im primären Teilkommando

Auch eine beliebige Zeichenfolge, die nicht der Syntax der Kommandosprache genügt und bei der Leerzeichen und Zeilenwechsel relevant sind, etwa ein Quellprogramm in einer Programmiersprache, kann Spezifikationswert oder ‑teilwert sein. Eine derartige Zeichenfolge heißt Fremdstring; sie wird zwischen / und ◊/ eingeschlossen, beispielsweise:

◊UEBERSETZE, QUELLE=/.BEGIN print(("Grüß Gott!", new line)) .END◊/, SPRACHE=ALG68   ◊= Fremdstring gelb markiert

Da das Ende eines Fremdstrings markiert wird, kann ein Kommando auch mehrere Fremdstrings enthalten, etwa das RECHNE-Kommando, das ein Quellprogramm kompiliert und mit den angegebenen Eingabedaten ausführt. Beispiel:

◊RECHNE, QU.=/(.LOC .INT i, k; read((i, k)); print((i, "   ", k, " = ", i k, new line)))◊/, SPR.=ALG68, DATEN=/2 2◊/

Für jede Tätigkeit sind nur bestimmte Spezifikationen möglich, für jede Spezifikation nur bestimmte Werte. Beispielsweise sind für die Spezifikation DATEI des KOPIERE-Kommandos nur die Angabe −STD− (das bedeutet: alle Dateien auf dem Quellträger) oder eine Liste von Dateibezeichnungen erlaubt; bei dessen Spezifikation PROTOKOLL kann entweder ein Protokoll verlangt (P.=−STD−) oder abbestellt (P.=−) werden; für die Spezifikationen QUELLE des UEBERSETZE- bzw. RECHNE-Kommandos ist wahlweise eine Dateibezeichnung oder ein Fremdstring zulässig. Der Entschlüssler prüft die Einhaltung dieser Regeln, meldet gegebenenfalls Syntaxfehler und reicht die Spezifikationswerte in einer einheitlichen internen Form an das jeweils zu startende Programm weiter.

Die Menge der Tätigkeiten, Spezifikationen, möglichen Spezifikationswerte und Voreinstellungen ist nicht starr, sondern kann mit Wirkung für den aktuellen Auftrag modifiziert, eingeschränkt, erweitert, sowie mittels des Kommandos GEDAECHTNIS archiviert (und so anderen Aufträgen zugänglich gemacht) werden.

Programmiersprachen

Ein Schwerpunkt des TNS 440 liegt auf der Entwicklung von Anwendungsprogrammen durch die Benutzer. Das wichtigste Hilfsmittel dazu sind die Compiler für folgende Programmiersprachen:

• TAS (für maschinennahe Programmierung)
• Algol 60 (hauptsächlich für mathematisch-naturwissenschaftliche Anwendungen)
• FORTRAN IV (hauptsächlich für naturwissenschaftliche Anwendungen)
• COBOL 68 (hauptsächlich für kaufmännisch-administrative Anwendungen)
• RPG II (für einfache kaufmännisch-administrative Anwendungen)
• BCPL (zur Systemprogrammierung)
• ab 1976 auch PL/I (als Nachfolger für Algol 60, FORTRAN und COBOL)

Diese Compiler fügen sich in einen gemeinsamen Rahmen: sie werden durch dasselbe Kommando aufgerufen, bieten ähnliche Testhilfen, und Programmteile aus unterschiedlichen Quellsprachen können kombiniert werden.

Eine Sonderstellung nehmen drei Programmiersprachen ein: sie werden nicht compiliert, sondern interpretiert:

• BASIC (für einfache Programmieraufgaben)
• FORTRAN kann wahlweise compiliert oder interpretiert werden
• GPSS (Simulation von Warteschlangen-Netzwerk-Modellen)

Rechenzentren und Anwender haben weitere Programmiersprachen für das TNS 440 verfügbar gemacht, unter anderem:

• Algol 68 (RUB)
• ELAN
• Maclisp
• Pascal
• PS 440, Ersatz oder Ergänzung für TAS, mit Syntaxelementen höherer Programmiersprachen (TUM)

Die folgenden Sprachen werden interpretiert:

• AIDA soll einen „hürdenfreien“ Zugang zum Rechner ermöglichen, hat einen Tischrechner-Modus, gestattet aber auch die Programmierung mit Algol‑60-Sprachmitteln (RUB)
• EXAPT zur numerischen Steuerung von Werkzeugmaschinen (RHRK)

Werkzeuge zur Programmentwicklung

Die Programmentwicklung und Fehlersuche wird durch statische (beim Kompilieren) und dynamische Hilfen (beim Programmlauf) unterstützt; auch hier war das TNS 440 seiner Zeit weit voraus. Die Testhilfen können beim Kompilieren einzeln gefordert oder (außer die Syntaxfehlermeldungen) abbestellt und beim Programmlauf einzeln aktiviert oder abgeschaltet werden. Alle Meldungen von Testhilfen beziehen sich auf die Bezeichnungen und Zeilennummern des Quellprogramms in der Nomenklatur der jeweiligen Quellsprache.

Die statischen Testhilfen im Einzelnen:

• alle Compiler liefern zeichengenau lokalisierte und verständliche Syntaxfehlermeldungen;
• die Compiler liefern auch Warnungen vor Tippfehlern und ähnlichen Irrtümern, z. B. in FORTRAN eine Variable, die nur einmal im Programm vorkommt;
• FORTRAN- und COBOL-Compiler melden, wenn TR-440-spezifische Sprachmittel genutzt werden, die über die einschlägige Sprachnorm hinausgehen;
• die sogenannte Referenzliste weist die Deklaration und Verwendung aller Bezeichner (z. B. Konstanten, Variable, Prozeduren) im Quellprogramm nach; das ist besonders nützlich für Programmiersprachen mit impliziter Deklaration (z. B. FORTRAN), bei denen durch Tippfehler unbeabsichtigt Variable deklariert werden können, oder mit Blockstruktur (z. B. Algol), bei denen unterschiedliche Variable oder Prozeduren gleich benannt sein können;
• die sogenannte Entzerrung bringt Algol‑60-Quellen in eine übersichtliche Form, die die Blockverschachtelung hervorhebt.

Die dynamischen Testhilfen im Einzelnen:

• Arithmetischer Überlauf, Wertzuweisungen an Konstanten (Literale), Speicherzugriffe außerhalb des zugewiesenen Adressraums und Sprünge in Datenbereiche werden durch die Hardware abgefangen;
• die dynamischen Kontrollen prüfen weitere Regelverstöße, die beim Kompilieren nicht erkannt werden können, z. B. Zugriff auf nicht initialisierte Variable, Überschreitung von Indexgrenzen oder (in Pascal) von deklarierten Wertebereichen, inkompatible Parameterversorgung beim Aufruf getrennt übersetzter Prozeduren;
• der Trace protokolliert den Ablauf des Programms (Wertzuweisungen, Schleifen, Fallunterscheidungen, Funktions- und Prozeduraufrufe und ‑abschlüsse, Sprünge);
• der Überwacher für TAS- und PS440-Programme protokolliert die ausgeführten Maschinen-Befehle und die daraus resultierenden Registerstände;
• der Rückverfolger protokolliert bei Programmabbruch oder auf Anforderung die aktuelle Verschachtelung der Unterprogramm-Aufrufe, auch über Sprachgrenzen hinweg;
• der Backtrace protokolliert bei Programmabbruch oder auf Anforderung die letzten 20 Trace- oder Überwacher-Schritte;
• der quellsprachbezogene Dump protokolliert bei Programmabbruch oder auf Anforderung die aktuellen Werte aller oder einzelner Variabler, oder ändert auf Anforderung die Werte einzelner Variabler;
• ein Kontrollereignis ist eine Stelle im Programm, bei deren Erreichen während des Programmlaufs die übrigen dynamischen Testhilfen einzeln aktiviert oder deaktiviert werden können.

Compiler mit präzisen Meldungen, Rückverfolger und quellsprachbezogenen Dump gab es schon am TR 4; neu am TR 440 sind die Dialog-orientierten Testhilfen wie Abfragen und Setzen einzelner Variabler, Backtrace und vor allem das Kontrollereignis mit seinen Steuerungsmöglichkeiten.

Weitere Software-Angebote

Die Mathematische Programm-Bibliothek umfasst Numerik-, Statistik und Grafik-Unterprogramme für Algol-60- und FORTRAN-Programme (neben den Standardfunktionen dieser Sprachen). Im Einzelnen:

• Numerik: lineare Algebra, Differenzialgleichungen, numerische Integration, Polynom-Arithmetik, spezielle Funktionen (Γ, Bessel, elliptische Integrale, …), Intervallarithmetik
• Statistik: Verteilungen, Konfidenzintervalle, Parameter- und Anpassungstests, Korrelations-, Regressions-, Faktoren- und Diskriminanzanalyse, …
• Grafik: Grafik-Grundprogramme (in Anlehnung an die Calcomp-Grundsoftware), Darstellung von Funktionen und Funktionsscharen, grafischer Dialog am SIG100

Weitere Programm-Bibliotheken standen im Rahmen des Programmaustauschs zur Verfügung.

Das Datenbankmanagementsystem DBS 440 wird vorzugsweise von COBOL- und TAS-Programmen gesteuert. Folgende Datenbank-Anwendungen bauen darauf auf:

• Dokumentationssystem TELDOK
• Produktionsplanungs- und -steuerungssystem PSS'
• Computerunterstützter Unterricht PLANIT
• Netzplan-Programmsystem BKN
• Personaldaten-Informationssystem PDI

Mitwirkung der Benutzer

In der Anwendergruppe STARG trafen sich von 1970 bis 1986 regelmäßig Vertreter der TR-440-Rechenzentren und des Herstellers, um Erfahrungen mit dem TNS 440 und Wünsche zu dessen Weiterentwicklung auszutauschen.

Den Rechenzentren waren die Programmquellen von Betriebs- und Programmiersystem zugänglich, außerdem Dokumentation der internen Schnittstellen des Programmiersystems (Kapitel IV der Entwicklungsdokumente, kurz: Status IV). Damit konnten sie wesentliche Beiträge zur Erweiterung und Ergänzung des Programmiersystems leisten. Einige Beispiele:

• von der TU München die Definition der Programmiersprache PS440 samt Compiler (Trace von der Universität Stuttgart);
• Adaption der NAG-Bibliothek
• Adaption der Statistik-Pakete SPSS, BMDP und SAS
• von der Universität Tübingen das Programmpaket TUSTEP zur wissenschaftlichen Textverarbeitung
• von der Ruhr-Universität Bochum der Algol-68-Compiler;
• von der Universität Konstanz die Adaption des Torrix-Pakets;
• von der Ruhr-Universität Bochum EDIERE, ein programmierbarer, zeilenorientierter Editor;
• zur Version MV 19 (1978) des TNS 440 hat eine gemeinsame Arbeitsgruppe der STARG und des Herstellers das Hilfe-System überarbeitet: gemeinsam hat man dessen Funktionsweise neu konzipiert, der Hersteller hat das einschlägige Kommando INFORMIERE erweitert und die STARG hat die Gliederung der Information entworfen und die einzelnen Hilfe-Texte formuliert.

Trivia

Rechnerkern, Hauptspeicher und Satellitenrechner waren in Schränken mit Türen aus Palisanderholz untergebracht. Am TR 4 war es noch Teakholz gewesen, was ihm den Spitznamen Teakholz-Rechner 4 eingebracht hatte; trotz der anderen Holzfarbe wurde auch der TR 440 gelegentlich als Teakholz-Rechner apostrophiert. Anlässlich der 1982 erfolgten Verschrottung des Stuttgarter TR 440 hat ein Mitarbeiter einen derartigen Schrank zum Kleiderschrank für seine Privatgemächer umgebaut.

Das BS 3 war – trotz seines Namens – nicht das dritte Betriebssystem für den TR 440. Die Entwicklung des BS 1 wurde 1969 abgebrochen; das BS 2 wurde zwar angekündigt, hat es aber nicht bis zur Marktreife geschafft. Am ersten ausgelieferten TR 440 in Darmstadt lief zunächst ein Betriebssystem, das zwei parallel laufende TR 4 mit jeweils eigener Peripherie emulierte; weil es einen provisorischen Betrieb des TR 440 ermöglichte, bekam es den Spitznamen Fallschirm-System. Als Testrahmen für die Compiler-Entwicklung diente das Wartungs-System WV1, das eigentlich zum Test der Peripheriegeräte vorgesehen war; auf dessen Grundlage wurde das BS 3 entwickelt. Gerechterweise müsste das BS 3 also BS 5 heißen.

Die COBOL-Anweisung MOVE kopiert eine Folge von Bytes (Sechstelwörtern, Oktaden) von einer beliebigen Stelle im Speicher an eine andere, beliebige Stelle. Mit dem ganzwortweise strukturierten Speicher des TR 440 ist das etwas umständlich zu realisieren; folglich wurde in einer integrierten Hardware-Software-Entwicklung der Maschinen-Befehl TOK (für Transportiere Oktaden) kreiert. Seither multipliziert die Software (in Gestalt des COBOL-Compilers oder des TAS-Assemblers) die Speicher-Adressen mit 3, um Oktaden-Adressen zu berechnen, und die Hardware dividiert die wieder durch 3, um die richtige Speicherzelle anzusprechen …

Der Trommelspeicher des Stuttgarter TR 440 machte den Technikern so viel Kummer, dass sie ihm den Spitznamen Zigeunerbaron verpassten.

Testlauf des umgebauten Kontroll-Panels an der Universität Hamburg

Nach der Verschrottung der Hamburger Maschine überlebte deren Kontrollpanel als „Kunst am Bau“ und zierte jahrzehntelang das Foyer des Rechenzentrums. Im Herbst 2020 wurde es restauriert mit dem Ziel, das Erscheinungsbild originaler Programmabläufe darzustellen. Ende 2024 soll das Panel wieder ausgestellt werden.

Hardware und Betriebssystem verhindern unberechtigte Zugriffe auf Speicherbereiche anderer Benutzer oder von Systemteilen. Ein Stuttgarter Informatik-Student, der zwei Lücken in diesem Sicherheitskonzept entdeckt hatte (die dann vom Hersteller behoben wurden), antwortete auf die Frage, wieso er solche Lücken nur am TR 440 und nicht an den andern Rechnern des Instituts gesucht habe: „Bei den anderen ist das ja keine Herausforderung, die wehren sich nicht.“

Im Jahr 2007 reiste der längst stillgelegte Kasseler TR 440, der in Frankfurt eingelagert ist, für ein paar Tage für Filmaufnahmen nach Berlin. Die Filmcrew hatte für die Aufnahmen einen passenden, holzgetäfelten Raum gemietet – leider hat der Kasseler TR 440 Fronttüren aus Blech …

In seiner Trauerrede zur Stilllegung des Marburger TR 440 schilderte Peter Zöfel einige frustrierende Erlebnisse mit dem neuen Rechner Sperry 1100/60 unter dem Betriebssystem OS/1100 und schloss dann mit den Worten: »Gottes Segen kann ich Euch nicht geben, aber Ihr werdet ihn bitter nötig haben!«

Literatur

• Hans Rüdiger Wiehle: Rechnerbetrieb aus Benutzersicht: Auf dem Weg zu den großen dialogfähigen Timesharing-Systemen. In: Informatik – Forschung und Entwicklung. Band 22. Springer-Verlag, Oktober 2008, ISSN 0949-2925, S. 203–216, doi:10.1007/s00450-008-0045-5 (researchgate.net). 
• Hans Rüdiger Wiehle: External Characteristics of Computer Operations: Toward Large Conversational Time-Sharing Systems. In: IEEE Annals of the History of Computing. Band 32, Nr. 3. IEEE, 22. September 2009, ISSN 1934-1547, S. 4–18, doi:10.1109/mahc.2009.56 (englisch). 
• Eike Jessen, Dieter Michel, Heinz Voigt: AEG-Telefunken TR 440: Struktur und Technologie. In: Informatik – Forschung und Entwicklung. Band 22. Springer-Verlag, Oktober 2008, ISSN 0949-2925, S. 227–235, doi:10.1007/s00450-008-0047-3 (researchgate.net). 
• Eike Jessen, Dieter Michel, Heinz Voigt: Structure, Technology, and Development of the AEG-Telefunken TR 440 Computer. In: IEEE Annals of the History of Computing. Band 32, Nr. 3. IEEE, 22. September 2009, ISSN 1934-1547, S. 30–39, doi:10.1109/MAHC.2009.64 (englisch). 
• Hans-Jürgen Siegert: AEG-Telefunken TR 440: Software und Software-Entwicklung. In: Informatik – Forschung und Entwicklung. Band 22. Springer-Verlag, Oktober 2008, ISSN 0949-2925, S. 237–266, doi:10.1007/s00450-008-0046-4 (Online [abgerufen am 22. August 2020]). 
• Hans-Jürgen Siegert: The German TR 440 Computer: Software and Its Development. In: IEEE Annals of the History of Computing. Band 32, Nr. 3. IEEE, 22. September 2009, ISSN 1934-1547, S. 40–73, doi:10.1109/mahc.2009.61 (englisch). 
• Timo Leimbach: Die Geschichte der Softwarebranche in Deutschland – Entwicklung und Anwendung von Informations‐ und Kommunikationstechnologie zwischen den 1950ern und heute. Inaugural-Dissertation zur Erlangung des Doktorgrades der Philosophie an der Ludwig-Maximilians-Universität München. München 2010 (Online [PDF; 3,8 MB; abgerufen am 22. August 2020]). 

Vom TR 4 zum TR 440 – AEG-Telefunken und die Großrechner. ebd. S. 110–114 (Online). 

Der Fall (von) AEG-Telefunken. ebd. S. 203–204 (Online). 

Die Betriebssystementwicklung des TR 440 – eine deutsche software crisis. ebd. S. 204–207 (Online). 

Die Gründung der Nutzergruppe STARG 440. ebd. S. 207–208 (Online). 

Auf der Suche nach Partnern – AEG-Telefunken, Nixdorf und am Ende Siemens. ebd. S. 208–210 (Online). 

STARG 440 und das Weiterleben nach dem Ende von Telefunken. ebd. S. 210–212 (Online). 

• Otto Fröhlich: Das Rechenzentrum der Philipps-Universität. In: alma mater philippina. Sommersemester 1977. Marburger Universitätsbund, 1977, ISSN 0569-082X, S. 9–12 (Scan [PDF; 1,2 MB; abgerufen am 20. Oktober 2021]). 
• Hans-Joachim Albinus: Das Hardwaremuseum (XII): AEG-Telefunken TR440 – Ein deutscher Großrechner. In: Die Zeit. 8. November 1996, ISSN 0044-2070 (Scan [PDF; 179 kB; abgerufen am 31. Mai 2020]). 
• Gernot Gwehenberger: Anwendung einer binären Verweiskettenmethode beim Aufbau von Listen. In: Elektronische Rechenanlagen. Band 10, Nr. 5. Oldenbourg, 26. Juni 1968, ISSN 0013-5720, S. 223–226 (Scan [abgerufen am 13. Juli 2020] beschreibt eine Suchmethode und Datenstruktur, die für die Realisierung des TAS-Assemblers entwickelt wurde). 

Weblinks

Commons: TR 440 – Sammlung von Bildern

• Bernd Ulmann: Historic Computers: Telefunken TR-440. 18. August 2013, abgerufen am 31. Mai 2020 (englisch, Seite im Aufbau, bisher nur eine Abbildung vom Rechenzentrum der Uni Kaiserslautern). 
• Datenverarbeitung. In: Beihefte der technischen Mitteilungen AEG Telefunken. 3. Jahrgang, Heft 3, 1970 (Scan [PDF; 1,8 MB; abgerufen am 9. September 2020]).  Das Heft enthält ausführliche Darstellungen zum System TR 440 und seinen Komponenten.
• Technische Dokumente. (PDF FTP) Abgerufen am 31. Mai 2020.  Enthält diverse Digitalisate von technischer Dokumentation.
• TR440/Doku. (FTP) Universität Stuttgart, Fachbereich Informatik, abgerufen am 8. Juli 2020.  Enthält diverse Digitalisate von technischer Dokumentationund Kurzbeschreibungen.
• Rainard Buchmann: TR440-Emulator. für Windows. Software-Entwicklung Buchman, 13. Juni 2018, abgerufen am 31. Mai 2020. 
• Rainard Buchmann: Dokumentationen zum TR440 und zum Emulator. Abgerufen am 9. September 2020 (Gut lesbare Scans von TR-440-Handbüchern, Informationsmaterial, weiterer Literatur). 
• Joachim Backes: TR440/BS3 – Eine Erfolgsstory? (PDF; 1.425 kB) 27. Juli 2009, abgerufen am 13. Juli 2020 (Liste der TR-440-Installationen unvollständig). 
• Gerd Isenberg: TR 440. In: Chess Programming Wiki. Mark Lefler, 28. Mai 2018, abgerufen am 23. Juni 2020 (englisch). 
• Die Entwicklung eines Schachprogramms als Beispiel für eine spezielle Form der künstlichen Intelligenz. In: Projektdatenbank. Stiftung Jugend forscht e. V., 1980, abgerufen am 6. Januar 2023. 
• Trivia aus dem Usenet. (PDF TXT; 10 kB) Abgerufen am 30. Mai 2020.