CP01: Unterschied zwischen den Versionen
Sigi (Diskussion | Beiträge) |
Sigi (Diskussion | Beiträge) |
||
(16 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
− | CP01 ist in | + | 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.<br /> | ||
− | + | 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.<br /> | |
− | + | 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). | |
− | + | <br /><br /> | |
+ | 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 [https://de.wikipedia.org/wiki/Eintrittsinvarianz ], 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.<br /> | ||
+ | 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. | ||
+ | <br /> | ||
+ | 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. | ||
+ | |||
+ | <br /> | ||
+ | |||
+ | Das Programm ist, wie es sich für Assembler gehört, statisch gebunden und besteht in etwa aus den folgenden Modulen : | ||
+ | <br> | ||
+ | <br> | ||
+ | [[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 |
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