Wenn immer mehr Benutzer sich die vorhandenen Ressourcen teilen müssen, verschlechtert sich als Folge des notwendigen Ausbaus des Gesamtsystems die Performance oft erheblich. Wofgang Seidelmann* schildert die Überlegungen, die bei Triumph-Adler zur Entwicklung des Rechners 1900 führten. Mit verteilter Rechnerleistung und verteiltem Betriebssystem soll eine überlastete CPU bald der Vergangenheit angehören.
Bei der Entwicklung standen kommerzielle Anwendungen im Bereich dezentraler Organisationsstrukturen im Vordergrund. Insbesondere die kostenoptimale Erstellung und Pflege der Anwendung in üblichen kommerziellen Sprachen. Außerdem sollten bereits vorhandene Ressourcen wie beispielsweise existierende Anwendungen oder vorhandenes Mitarbeiter Know-how weitestgehend genutzt werden können. Darüber hinaus sollte - unabhängig von der jeweiligen Konfiguration in der Geschäftsstelle oder im Zweigwerk - eine einheitliche (code-identische) Software im gesamten Netzwerk einzusetzen sein. Weitere zu realisierende Forderungen waren eine geräteunabhängige Anwendungssoftware, optimale Kommunikationseigenschaften zur Nutzung der diversen Postdienste, eine problemlose Einbindung in bereits installierte Netzwerkkonzepte sowie optimale Benutzerfreundlichkeit.
Die Systemarchitektur der TA 1900 ist laut TA so konzipiert, daß sich Anwendungsprogrammierer nicht mit Fragen zu den Gerätschaften (zum Beispiel welche Drucker, Gleitzeitterminals, Bildschirmgeräte, Platten, BDE-Terminals etc. sind zu programmieren) beschäftigen müssen. Andererseits wollen die Benutzer verständlicherweise unterschiedliche Spezialendgeräte für bestimmte Funktionen einsetzen. Zu diesem Zweck wurden Peripheriemoduln entwickelt, die es ermöglichen, beiden Seiten gerecht zu werden.
P-Modulübersetzer
Jedes P-Modul ist ein in sich autarker Rechner mit eigener CPU (Mikroprozessor), eigenem Betriebssystem sowie eigenem Daten- und Programmspeicher. Anders ausgedrückt: Es ist der Übersetzer zwischen dem Anwendungsprogrammierer, der beispielsweise in Cobol mit Call-"Gerät" arbeitet, und den spezifischen Funktionen seines Gerätes. Um diese Funktion erfüllen zu können, wurde in der Design-Phase eine generalisierte file-orientierte J/O-Schnittstelle definiert, nach der sich jeder Entwickler eines P-Moduls uneingeschränkt zu richten hat. Auf diese Weise wurde nicht nur der Anwenderforderung nach Geräteunabhängigkeit und damit Nutzungsmöglichkeit von Spezielperipherie entsprochen, sondern auch die Gelegenheit geschaffen, bestehende Anwendungen mit sehr geringem Übernahmeaufwand auf der TA 1900 lauffähig zu machen.
Das Problem jedes Rechners, der mit einer CPU und einem zentralen Betriebssystem (System Supervisor) arbeitet, liegt im Falle der Hochkonfiguration klar auf der Hand. Immer mehr Geräte (Bildschirme, Platten, Drucker etc.) und damit auch Benutzer teilen sich die vorhandenen Ressourcen.
Viele Anwender mußten hier bereits die bittere Erfahrung machen, daß sich bei einem Ausbau die Performance des Gesamtsystems erheblich verschlechtert. Die typischen Symptome aus der Sicht des Benutzers sind die Verlängerung der Antwortzeiten, schlechte Verfügbarkeit des Systems etc.
Die Designer der TA 1900 hatten daraus die Konsequenz gezogen, auch die Rechnerleistung des Systems auf Moduln aufzuteilen. Bei Ausbau des Systems mit Peripherie und Anwendungen werden diese ebenfalls nachgerüstet. Das Ergebnis:
- Statt einer CPU beliebig viele PUs, die Taskmoduln genannt werden.
- Statt eines zentralen Betriebssystems ein verteiltes Betriebssystem und zwar verteilt auf alle P- und Taskmoduln.
- Statt eines ladbaren Betriebssystems ein "gepromtes" Betriebssystem, das beim Stecken der Hardware (Modul) dann schon generiert ist und nicht überschrieben werden kann (Sicherheit!).
Ein interessanter Nebeneffekt dieser Betriebssystemarchitektur ergibt sich bei Konfigurationen, die peripherie- und/oder bedienerlos arbeiten sollen.
Noch eine weitere Anwenderforderung stand Pate bei der Entwicklung dieser Taskmoduln: die Nutzung vorhandener Software oder zumindest vorhandener Werkzeuge und des vorhandenen Know-hows.
Die Taskmoduln haben die Aufgabe, Programme (Tasks) zu exekutieren, deren Objekt-Code im Hauptspeicher der TA 1900 liegt. Statt nun einen eigenen neuen Code zu erfinden, entschloß man sich, den Maschinencode der großen IBM/Siemens-Mainframe-Systeme zu verwenden. Dies hat zur Folge, daß entweder vorhandene Software emuliert oder bei Neuentwicklungen auf dem beim Anwender bereits vorhandenen Entwicklungssystem mit all seinen Werkzeugen gearbeitet werden kann. Dies ist ein ganz erheblicher Vorteil für Anwender, die Programme für Netzwerke zu schreiben haben, in denen ja außer den dezentral eingesetzten TA 1900-Systemen auch immer zentrale Host-Computer stehen.
Darüber hinaus ist es jederzeit möglich, über einen zusätzlichen Emulator im Taskmodul auch andere Objekt-Codes als die zur Zeit verwendeten durch die TA 1900 ausführen zu lassen. Dies hat zur Folge, daß neue Sprachen und Werkzeuge sehr leicht und vor allem zusätzlich zu bestehenden Cobolanwendungen verwendet werden können. Es werden dann einfach zwei verschiedene Taskmoduln gesteckt.
Es stehen somit drei verschiedene Arten von Moduln zur Verfügung:
- passive Hauptspeichermoduln, die bis zu maximal 16 MB Anwenderspeicher gesteckt werden können
- aktive Peripheriemoduln, die beliebig gesteckt werden können
- aktive Taskmoduln, von denen so viele gesteckt werden, daß die vom Benutzer gewünschte Performance erreicht wird.
Damit diese Moduln der TA 1900 zusammenarbeiten können, mußte noch ein Kommunikationsweg und ein Protokoll entwickelt werden. Realisiert wurde dies mit einem Systembus, der jeweils 18 Moduln miteinander verbindet (für sehr große Konfigurationen können mehrere Bussysteme miteinander gekoppelt werden) und einem Protokoll (ITC-Protokoll).-Diese Lösung ermöglicht den Rechnern (Moduln) des Systems eine abgesicherte Kommunikation mit Hilfe einer eigenen Sprache (MCW-Modul Command Words), die der Anwender nicht kennen muß.
*Wolfgang Seidelmann, Leiter des Projektbereiches TA 1900, Triumph-Adler AG, Nürnberg.