Die Systemeinleitung von BS2000 läuft als „Bootstrapping“ ab, d.h. es werden schrittweise immer mächtigere Funktionseinheiten geladen und gestartet, bis BS2000 betriebsbereit ist.
Der Anstoß zum Ablauf der verschiedenen Routinen erfolgt hardware-abhängig über den Serviceprozessor (SVP) auf SU /390 oder X2000 auf SU x86 bzw. die Restart-Verarbeitung bei automatischem Restart. Mit diesem Urladen (IPL, Initial Program Load) wird die Systemeinleitung gestartet. Dabei wird neben der IPL-Platte auch die Art der Systemeinleitung festgelegt. Durch die Einstellung der Ladeoptionen für BS2000 wird festgelegt, ob der Systemstart komfortabel oder flexibel ablaufen soll.
Für einen komfortablen, weitgehend automatischen Ablauf stehen dem Operator die Modi FAST und AUTOMATIC, für den flexiblen, dialogorientierten Ablauf steht ihm der Modus DIALOG zur Verfügung (siehe Abschnitt „Arten der Systemeinleitung").
Für ein VM2000-Gastsystem wird die Systemeinleitung über den SE Manager (siehe Handbuch „Bedienen und Verwalten“ [57]) oder durch das VM2000-Kommando START-VM (siehe Handbuch „VM2000“ [60]) ausgelöst. Das VM2000-Gastsystem kann auf SU x86 auch über die SVP-Funktionen der KVP-Konsole, die der virtuellen Maschine zugeordnet ist, gestartet werden.
Die wichtigsten Funktionsabläufe während der Systemeinleitung von der Bereitstellung der Hardware bis zum eigentlichen Abschluss des Startups, bis „System Ready“ sind:
Bild 2: Funktionsabläufe bei der Systemeinleitung von BS2000
Die Systemeinleitung für BS2000 kann beginnen, wenn die dazu notwendigen Hardware-Einheiten (MU, Server Units, periphere Geräte) eingeschaltet und betriebsbereit sind. Der Ablauf dieser Schritte (Einschalten der Stromversorgung, Laden der Firmware usw.) ist ausführlich in den Betriebsanleitungen für die SE Server beschrieben.
Der interne Ablauf der Systemeinleitung für BS2000 beginnt mit dem Laden des „Urladers“ (SYSBOOT). Dies ist die eigentliche Aufgabe der Routine HW-IPL (Vorgang (1) in Bild 2).
SYSBOOT ist das erste Programm der Systemeinleitung, das elementare Prüfungen vornimmt und eine weitere Laderoutine anstößt (Vorgang (2) in Bild 2).
Diese von SYSBOOT geladene und gestartete Routine ist SYSIPL, die die Aufgabe hat, die Optionen im Modus DIALOG abzufragen und die aktuelle Platten- und CPU-Konfiguration zu ermitteln (Vorgang (3) in Bild 2). Die Zeitbasis der Systemzeit wird festgelegt. Die Plattenkonfiguration wird auf Vollständigkeit und Eindeutigkeit geprüft. Bei DRV-Platten im Home-Pubset werden die zusammengehörigen Plattenpaare ermittelt. Außerdem wird von dieser Routine entweder SYSSTART oder SLED geladen und jeweils korrigiert.
Die beiden Programme SYSBOOT und SYSIPL und die IPL-Rep-Datei befinden sich auf festen Plätzen eines bestimmten Plattenspeichers, der IPL-Platte. Die IPL-Platte kann ein gemeinschaftlicher Plattenspeicher – die Platte eines Pubsets – oder eine Privatplatte sein. Sie muss für FAST- und AUTOMATIC-Startup eine der Platten des Home-Pubsets sein.
Nur bei DIALOG-Startup ist ein IPL von Privatplatte möglich. Dabei muss der Operator im späteren Verlauf der Systemeinleitung angeben, welcher Pubset der Home-Pubset für den Systemlauf sein soll.
Beim IPL von gemeinschaftlicher Platte wird der Pubset, zu dem die Platte gehört, automatisch zum Home-Pubset gewählt. Nur bei Dialog-Startup mit der Option ALLDISK kann der Operator den Pubset noch wechseln.
Wenn die IPL-Platte nicht zum späteren Home-Pubset gehört, ist insbesondere darauf zu achten, dass Versionen und Korrekturstände auf beiden gleich sind.
Das Einrichten von IPL-Platten ist Aufgabe der Systembetreuung und wird mit Hilfe des Dienstprogramms SIR vorgenommen, das ausführlich im Handbuch „Dienstprogramme“ [15] beschrieben ist.
Eine IPL-Platte kann entweder für SU /390 oder für SU x86 verwendet werden.
Beim Laden von SYSBOOT und SYSIPL/SLED stehen die Dateiverwaltungs-Funktionen von BS2000 noch nicht zur Verfügung. Die notwendigen Dateien können daher nur gefunden werden, wenn sie zuvor auf der IPL-Platte „verankert“ worden sind. Dies geschieht mit der Anweisung CREATE-IPL-VOLUME des Dienstprogramms SIR und beinhaltet folgende Einzelschritte:
Die zum Laden von SYSBOOT und SYSIPL/SLED nötigen Dateien werden auf die IPL-Platte kopiert.
Die von SYSBOOT und SLED verwendeten Sicherstellungsdateien werden auf der IPL-Platte erzeugt.
Im SVL der IPL-Platte wird je ein unmittelbarer Verweis auf jede dieser Dateien eingetragen:
Original-Datei
von SIR erzeugte Datei
---
SYSDAT.IPL-CONF.DSKnnn
---
SYSPRG.BOOT.DSKnnn.SAVE
SYSPRG.IPL.<ver>
SYSPRG.IPL.DSKnnn
---
SYSPRG.SLED.DSKnnn.SAVE
SYSREP.IPL.<ver>
SYSREP.IPL.DSKnnn
SYSREP.SLED.<ver>
SYSREP.SLED.DSKnnn
„nnn“ steht jeweils für die Nummer der IPL-Platte innerhalb des Pubsets. Handelt es sich bei der IPL-Platte um eine Privatplatte, wird statt des Namensteils DSKnnn die VSN der Privatplatte eingesetzt.
Sofern noch nicht auf einer anderen Platte des Pubsets vorhanden, wird die Sicherstellungsdatei für Systemkorrekturen SYS.NSI.SAVEREP erzeugt (nicht bei Privatplatten).
Die Original-Dateien werden zur Systemeinleitung nicht mehr gebraucht und können im laufenden System gefahrlos geändert werden, z.B. zur Übernahme eines neuen Korrekturstandes. Alle Änderungen werden für die Systemeinleitung jedoch erst wirksam, nachdem mit SIR neue Kopien erzeugt und verankert worden sind.
Die verankerten Dateien dürfen im laufenden System weder geändert noch gelöscht werden, weil dadurch i.A. die IPL-Fähigkeit der Platte zerstört wird. Sie werden seitens SIR durch BACKUP-CLASS=E und MIGRATE=INHIBITED vor Verlagerung und Verdrängung geschützt.
Alle weiteren für die Systemeinleitung benötigten Routinen befinden sich als „normale Dateien“ auf einem Pubset oder einer Privatplatte.
Die Konfigurationstabellen werden dynamisch erzeugt.
SYSSTART (Vorgang (4) in Bild 2) ist ein Programm, das die eigentliche Systemeinleitung für BS2000 vorbereitet und durchführt. In der Vorbereitung werden i.W. die Parameter für BS2000 eingelesen, die Objektcodekorrekturen für Klasse-1-Exec ermittelt, sowie die Versionsstände von SYSSTART und BS2000 auf Konsistenz geprüft. In der Durchführung werden die einzelnen Initialisierungsfunktionen von BS2000 tabellengesteuert aufgerufen. Zu diesen Initialisierungsfunktionen gehören auch die Datenstrukturen der virtuellen Speicherverwaltung und die Initialisierung der Paging-Bereiche, womit SYSSTART auch den Übergang in den virtuellen Adressierungsmodus von BS2000 vorbereitet.
Von SYSSTART wird schließlich das BS2000-Ladesystem (Vorgang (5) in Bild 2), das aus den beiden Teilen „Klasse-1-Exec“ (resident) und „Klasse-2-Exec“ (seitenwechselbar) besteht, aufgerufen.
Auf dieser Stufe der Systemeinleitung werden u.a. bei der Geräteverwaltung Zugriffsrechte für die Geräte der Systemeinleitung beantragt (Platten des Home-Pubsets und der Paging-Pubsets). Nach Durchlauf dieser Systemeinleitungs-Phase liegt das BS2000-Ladesystem geladen, korrigiert und parametrisiert vor.
Geladen heißt, dass sich dieser Teil von BS2000 nach dem Ladevorgang vollständig im Hauptspeicher befinden. Es werden zuerst die hauptspeicherresidenten Teile (Klasse-1-Exec) geladen. Die restlichen Teile sind seitenwechselbar. Diese Routinen werden von SYSINIT über den Hauptspeicher auf den Seitenwechselspeicher kopiert.
Korrigiert heißt, dass Module dieser Teile von SYSSTART während der Systemeinleitung mittels so genannter Rep-Sätze modifiziert werden. Die Rep-Sätze können von max. vier katalogisierten Plattendateien in beliebiger Reihenfolge eingelesen werden. Die Konsole kann – außer für Reps für SYSIPL – zusätzlich als Eingabegerät definiert werden. Bei der Systemeinleitung werden alle verarbeiteten Rep-Sätze von Platte und Konsole in die Sicherstellungsdatei SYS.NSI.SAVEREP geschrieben und später in der Datei
$SYSAUDIT.SYS.REPLOG.<datum>.<session-nr>.01 protokolliert.
Parametrisiert heißt, dass eine Menge von Parametersätzen, die Anweisungen für die Initialisierungsroutinen von BS2000 enthalten, eingelesen werden. Die gesamte Parametereingabe besteht aus einer Folge von Abschnitten, die – durch spezifische Schlüsselwörter gekennzeichnet – jeweils bestimmte Funktionseinheiten betreffen und von diesen ausgewertet werden (siehe Kapitel „Parameterservice").
Der Operator kann durch eine Voreinstellung beim Systemstart entscheiden, ob das Laden, Korrigieren und Parametrisieren weitestgehend automatisch und dialogfrei ablaufen soll (in diesem Fall werden jeweils Dateien mit Standardnamen herangezogen), oder ob der Ablauf flexibel – im Dialog mit dem Operator – gesteuert werden soll.
Abschließend wird mit E2START die letzte Phase der Systemeinleitung für BS2000 gestartet (Vorgang (6) in Bild 2). Diese Routine läuft bereits unter BS2000 und bestimmt zunächst den Namen der Kommandodatei (CMDFILE), die nach „System Ready“ automatisch angestartet werden soll.
Zur Erreichung eines funktionstüchtigen BS2000 laufen in dieser Phase Initialisierungsroutinen für die folgenden Funktionseinheiten ab:
Aktivierung des Task-Schedulers
Öffnen der Systemdateien (Benutzerkatalog, SYSEAM, usw.)
Bereitstellung der Dateikatalogverwaltung
Aktivierung des dynamischen Bindeladers (DBL)
Aktivierung der Bibliothekszugriffsmethode PLAM
Start der Funktionen zur Überwachung von Platten- und Bandgeräten
Aktivierung der SERSLOG-Funktion
Start der Dynamischen Subsystemverwaltung DSSM 1)
Nach Freigabe des von der Systemeinleitung belegten Speichers und Start des Job-Schedulers ist „System Ready“ erreicht und die Abarbeitung der in der Kommandodatei CMDFILE hinterlegten Kommandos wird angestoßen. Zwar ist die Verwendung einer Kommandodatei – deren Name frei wählbar ist – nicht zwingend erforderlich, doch wegen der Forderung nach Automatisierung der Abläufe unbedingt zu empfehlen.
Die Verwendung einer Kommandodatei gewährleistet u.a. die automatische Aktivierung derjenigen Systemkomponenten und -einstellungen, die für die Funktionstüchtigkeit des spezifischen Systems relevant sind:
Inbetriebnahme von optionalen Subsystemen
Starten des BS2000-Datenkommunikationssystems 2)
Laden des SPOOL-Systems 3)
Spezifische Lastregulierung
Aktivierung spezieller Programme über Enter-Dateien
Hinweise
1) DSSM:
Während der Systemeinleitung erhält die Dynamische Subsystemverwaltung die Steuerung. Diese initialisiert sich mit dem vorgegebenen Subsystemkatalog und aktiviert Subsysteme bzw. leitet die Aktivierung von Subsystemen ein. Der Startzeitpunkt eines Subsystems (vor oder nach „System Ready“) wird von der Systembetreuung bei der Deklaration festgelegt. Auf diese Weise können Subsysteme automatisch aktiviert werden.
Beim Start eines Subsystem ermittelt DSSM über IMON-GPN die Pfadnamen aller Dateien des Subsystems aus dem aktuellen SCI. Ist IMON-GPN nicht verfügbar (wird bereits beim Start von DSSM geladen) oder existiert keine Datei unter dem ermittelten Pfadnamen, verwendet DSSM die im Subsystemkatalog eingetragenen Standard-Namen. Bei Verwendung des Standard-Namens wird die Meldung ESM0665 ausgegeben.
2) Datenkommunikationssystem (DCM):
Für den Start des Datenkommunikationssystems noch vor „System Ready“ kann das DCSTART-Kommando auch als BCAM-Parameter in der Startup-Parameterdatei vorgegeben werden (siehe Handbuch „BCAM“ [4], Abschnitt BCAM-BS2000-Parameterdatei).
Ist das nicht der Fall, muss nach jeder Systemeinleitung das Datenkommunikationssystem gesondert in Betrieb genommen werden. Dies geschieht mit dem Kommando DCSTART, das dann zweckmäßigerweise in der CMDFILE hinterlegt wird.
Mit dem Kommando DCSTART wird automatisch die Eröffnung der folgenden internen, privilegierten Anwendungen des Systems eingeleitet:
$DIALOG (Anwendung für Dialogverarbeitung (TIAM))
$CONSOLE (Anwendung für logische Konsolen, siehe "Operatorfunktionen")
$BCAM (Anwendung für den DCM-Informationsdienst)
Erfolgt das erste DCSTART-Kommando später als 10 Min. nach „System Ready“ oder wird bei laufendem BS2000 das DCM beendet (Kommando BCEND) und neu gestartet, dann muss die Anwendung $DIALOG vom Operator mit dem Kommando START-DIALOG-APPLICATION manuell gestartet werden. Eine andere Möglichkeit wäre die Aufnahme von /START-DIALOG-APPLICATION in die SOF (Start Option File) von BCAM. Voraussetzung dafür ist die Einrichtung eines Konsolzugangs für BCAM mit der Berechtigung für START-DIALOG-APPLICATION (siehe Handbuch „BCAM“ [4]).
Weil im Bedienmodus mit Operator-Logon der Operator nach „System Ready“ erst ein SET-LOGON-PARAMETERS- und ein REQUEST-OPERATOR-ROLE-Kommando eingeben muss, um weitere Kommandos eingeben zu können, empfiehlt es sich, die Voraussetzungen für die ersten beiden Kommandos ebenfalls aus der CMDFILE heraus zu schaffen. Diese Voraussetzungen sind:
die Operatorkennung muss entsperrt sein
eine Operatorrolle muss eingerichtet sein
die Operatorrolle muss der Operatorkennung zugeordnet sein
Da das Entsperren der Operatorkennung unter der Kennung TSOS geschehen muss, das Einrichten einer Operatorrolle und das Zuordnen zu einer Operatorkennung aber nur unter SYSPRIV durchgeführt werden kann, empfiehlt es sich, aus der CMDFILE einen ENTER-Job aufzurufen, der das UNLOCK-USER-Kommando absetzt und eine weitere Prozedur zum Einrichten und Zuordnen der Operatorrollen unter der Kennung SYSPRIV aufruft.
Der gesamte Ablauf könnte etwa folgendermaßen aussehen:
Aufruf aus der CMDFILE:
/ENTER-JOB E.OPR-LOGON.TSOS
Inhalt der Datei E.OPR-LOGON.TSOS
/SET-LOGON-PARAMETERS / UNLOCK-USER SYSPRIV / SET-JOB-STEP / UNLOCK-USER SYSOPR / SET-JOB-STEP / ENTER-JOB FROM-FILE=$TSOS.E.OPR-LOGON.SYSPRIV,- / PROC-ADMISS=*PAR(USER-ID=SYSPRIV,- / ACC=SYSACC,- / PASS=*NONE) /EXIT-JOB
Inhalt der Datei E.OPR-LOGON.SYSPRIV
/SET-LOGON-PARAMETERS / CREATE-OPERATOR-ROLE OPERATOR-ROLE=SYSADM,ROUT-CODES=*ALL / SET-JOB-STEP / MODIFY-OPERATOR-ATTR USER-ID=SYSOPR,ADD-OP-ROLE=SYSADM / SET-JOB-STEP / INFORM-OPERATOR,- / MSG='*** OPERATOR-ROLE SYSADM CREATED AND ADDED ***' / INFORM-OPERATOR,- / MSG='+------------------------------------------------------+' / INFORM-OPERATOR,- / MSG='! THE FIRST OPERATOR COMMANDS AFTER SYSTEM READY !' / INFORM-OPERATOR,- / MSG='! (BEFORE /DCSTART ... ) MUST BE: !' / INFORM-OPERATOR,- / MSG='! /SET-LOGON-PARAMETERS SYSOPR,SYSACC !' / INFORM-OPERATOR,- / MSG='! /REQUEST-OPERATOR-ROLE OP-ROLE=SYSADM !' / INFORM-OPERATOR,- / MSG='+------------------------------------------------------+' /EXIT-JOB
Erst dann ist BS2000 kommunikationsfähig.
3) SPOOL:
Nach jeder Systemeinleitung muss SPOOL gesondert geladen und initialisiert werden. Der SPOOL-Startup wird durch das Kommando START-SUBSYSTEM eingeleitet.
Mit dem Operanden SUBSYSTEM-PARAMETER kann festgelegt werden, ob für SPOOL ein Warm- oder Kaltstart durchgeführt werden soll und ob zusätzlich das Softwareprodukt RSO geladen werden soll. Dieses Kommando sollte entweder gleich nach „System Ready“ gegeben werden oder in der Kommandodatei CMDFILE enthalten sein. Ist SPOOL nicht geladen, können keine SPOOLIN- und SPOOLOUT-Jobs durchgeführt werden. SPOOL-Anforderungen des Operators (z.B. Kommandos START-PRINTER-OUPUT, MODIFY-PRINTER-OUTPUT-STATUS,...) werden entweder abgewiesen, ignoriert oder zurückgestellt.
Zusammenfassend besteht die Systemeinleitung aus folgenden internen Schritten:
HW-IPL: | - Laden des 1. Blocks von SYSBOOT |
SYSBOOT: | - Laden des 2. Blocks von SYSBOOT |
SYSIPL: | - eigene Korrektur |
SYSSTART: | - Einlesen der Parameter |
Klasse-1-Exec: | - Initialisierung des residenten Teils von BS2000 |
Klasse-2-Exec: | - Initialisierung der seitenwechselbaren Teile |
SYSINIT | - Ermittlung der Kommandodatei und Aufruf von Initalisierungsfunktionen für BS2000-Funktionseinheiten (DSSM, PLAM, usw.) |
„System Ready“ | |
1 Während des Startups werden automatisch alle Public-Platten des Home-Pubsets und alle Pubsets, die Paging-Platten enthalten und die beim Parameterservice angegeben wurden, dem System zugeschaltet, auch wenn sie explizit DETACHED generiert worden sind. Die Geräte des Home-Pubsets bleiben während des gesamten Systemlaufs ATTACHED.
Mit dem Kommando SHOW-SYSTEM-INFORMATION können Informationen über die Systemkonfiguration, die eingesetzte VM2000-Version, das Monitorsystem und die Parameter der Zeiteinstellung eingeholt werden.