CP01: Unterschied zwischen den Versionen
Sigi (Diskussion | Beiträge) |
Sigi (Diskussion | Beiträge) |
||
| Zeile 6: | Zeile 6: | ||
Dafür kaufte Siemens Deutschland von Siemens Schweiz den Fork TSMON mit dem sich die Spezialisten von einem Terminal aus gleichzeizig auf viele Kundenrechner am Serviceprozessor einloggen und arbeiten konnten (Teleservice). | Dafür kaufte Siemens Deutschland von Siemens Schweiz den Fork TSMON mit dem sich die Spezialisten von einem Terminal aus gleichzeizig auf viele Kundenrechner am Serviceprozessor einloggen und arbeiten 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 drehte bis etwas passiert, sondern wenn nicht 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. | + | 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 drehte bis etwas passiert, sondern wenn nicht 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, unendlich viele Verbindungen pro Terminal aufbauen konnte; bei der Nutzung von nur einem Prozess. [https://de.wikipedia.org/wiki/Parallele_Programmierung siehe auch] | Das war auch notwendig, da jede Contingency parallel ablaufen konnte und CP01 bis zu 44 reale Terminals und theoretisch, nur durch Systemkomponenten begrenzt, unendlich viele Verbindungen pro Terminal aufbauen konnte; bei der Nutzung von nur einem Prozess. [https://de.wikipedia.org/wiki/Parallele_Programmierung siehe auch] | ||
| + | <br /> | ||
Das Programm ist, wie es sich für Assembler gehört, statisch gebunden und besteht in etwa aus den folgenden Modulen : | Das Programm ist, wie es sich für Assembler gehört, statisch gebunden und besteht in etwa aus den folgenden Modulen : | ||
Version vom 19. Januar 2016, 01:00 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 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 Fork TSMON mit dem sich die Spezialisten von einem Terminal aus gleichzeizig auf viele Kundenrechner am Serviceprozessor einloggen und arbeiten 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 drehte bis etwas passiert, sondern wenn nicht 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, unendlich viele Verbindungen pro Terminal aufbauen konnte; bei der Nutzung von nur einem Prozess. siehe auch
Das Programm ist, wie es sich für Assembler gehört, statisch gebunden und besteht in etwa aus den folgenden Modulen :
Doku - die Dokumentation
mcp001 - 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
statein - DSECT, Stations-Tabelle für ein Terminal
userein - DSECT, Tabelle für ein virtuelles Terminal, eine Applikation
