CP01: Unterschied zwischen den Versionen

Aktuelle Version vom 20. Januar 2016, 01:38 Uhr

CP01 / TSMON ein "Steuersystem zur zentralen Bedienung mehrerer Anwendungen", also ein 'Windows' für zeilenorientierte Bildschirme an Mainframes. Das Programm ist in BS2000 Assembler geschrieben und war ablauffähig ab den Prozessormodellen 7.760 (Mono-) und 7.761/2 (Bi-) von Siemens, wurde dann Anfang 90er Jahre für den 31-Bit Adressressraum fit gemacht um dann auf den H60, H90 und VM2000 Modellen im XS-Modus lauffähig zu sein.

Für die Systemtechniker und den Systemsupport gab es, etwa mit den 31-Bit-Modellen, einen sogenannten Serviceprozessor der vollkommen unabhängig vom Hauptrechner diesen überwachen und steuern konnte.
Dafür kaufte Siemens Deutschland von Siemens Schweiz den CP01-Fork TSMON mit dem sich die System-Spezialisten von einem Terminal aus gleichzeizig auf viele Kundenrechner am Serviceprozessor einloggen und arbeiten und zwischen diesen switchen konnten (Teleservice).

CP01 arbeitete rein asynchron in sogenannten Contingencies, also ereignisgesteuerten Routienen, und diese waren vollkommen reentrant programmiert. Rein asynchron in dem Sinne, dass es keine 'Hauptschleife' gab, die sich dreht bis etwas passiert, sondern wenn nichts zu tun war stand die Zeit für den Prozess still. Reentrant [1], also wiedereintrittsinvariant, mussten die Routinen sein da sie zu jedem Zeitpunkt irgendwo im Code unterbrochen werden konnten und bei Wiederanlauf natürlich die Register und Speicherbereiche den Zustand bei Unterbruch wieder aufnehmen mussten.
Das war auch notwendig, da jede Contingency parallel ablaufen konnte und CP01 bis zu 44 reale Terminals und theoretisch, nur durch Systemkomponenten begrenzt - zu dieser Zeit etwa 250-2000 -, unendlich viele Verbindungen pro Terminal aufbauen konnte; bei der Nutzung von nur einem Prozess.
Heute werden diese Aufgaben im Allgemeinen vom System und der jeweiligen Programmiersprache resp. ihrer Bibliotheken in Form von Threads übernommen. Einerseits Schade, denn interressant so etwas zu programmieren ist es halt schon, andererseits ist es sehr fehleranfällig und aufwändig und darum ist heute ohne Frage die Wahl der Threads oder ähnlichen Mechanismen die richtige.

Das Programm ist, wie es sich für Assembler gehört, statisch gebunden und besteht in etwa aus den folgenden Modulen :

Doku - die Dokumentation

mcp002 - das Hauptprogramm (Main sozusagen)

cpbufh - eine Ringpuffer Verwaltung

yrecasy - asynchroner Datenempfang eines Partnerprogramms

cpclock - Timer STXIT für automatischen Lock

cpcstat - residente Class-6 Speicherseiten allozieren

cpadmin - CP01 Administrations Module

cpauser - Hardcopy Admin Module

cpbltin - Bulletin-Datei bereitstellen

cpkmask - Login Maske

cplogin - Benutzer Login Bearbeitung

cpsysfl - System Logging Module

cpcopy - Sequenzdatei neu laden

cphelp - Help und Message Module

cpinf - Zustandsinformationen über reelle und virtuelle Terminals und Applikationen

hcinit - Bildschirm-Hardcopy aufbereiten

hcprco - Bildschirm-Hardcopy drucken

stxerr - STXIT Fehlerbehandlungsroutine, meist Speicher-Adressfehler

statein - DSECT, Stations-Tabelle für ein Terminal. Wird für jedes Terminal einem reservierten Speicherbereich überlagert.

userein - DSECT, Tabelle für ein virtuelles Terminal, eine Applikation. Wird für jede Verbindung einem reservierten Speicherbereich überlagert.

cp.p.assemb - Assembler Prozedur zum Übersetzen der einzelnen Module

cp.p.link - Binder Lauf zum Erstellen des ablauffähigen Programms