Aktivieren bzw. Wiederanlauf

Die Aktivierung eines Subsystems wird gesteuert durch die Attribute, die im Subsystemkatalog mit der SSCM-Anweisung SET-SUBSYSTEM-ATTRIBUTES definiert wurden.

Die Aktivierung erfolgt durch eine der folgenden Möglichkeiten:

• automatisch während des ersten DSSM-Aufrufs der Startup-Routine, wenn CREATION-TIME=*BEFORE-DSSM-LOAD oder *AT-DSSM-LOAD definiert wurde;
  die Aktivierung muss dabei erfolgreich abgeschlossen werden
  (*BEFORE-DSSM-LOAD bedeutet dabei, dass das Subsystem bereits geladen ist, bevor DSSM erstmals durch die Startup-Routine aufgerufen wurde. Nach dem Aufruf von DSSM wird dieses Subsystem wie jedes andere verwaltet. Versionsaustausch oder Versionskoexistenz mit einer anderen Version, die mit CREATION-TIME=*AT-DSSM-LOAD definiert wurde, ist erlaubt. Es liegt in der Verantwortung der Systembetreuung dafür zu sorgen, dass zu jeder Zeit eine Version des Subsystems verfügbar ist.)

• automatisch während des zweiten DSSM-Aufrufs der Startup-Routine, wenn CREATION-TIME=*MANDATORY-AT-STARTUP definiert wurde; die Aktivierung muss dabei erfolgreich abgeschlossen werden

• automatisch während des zweiten DSSM-Aufrufs der Startup-Routine, wenn CREATION-TIME=*BEFORE-SYSTEM-READY definiert wurde (synchron)

• automatisch nach dem zweiten Rücksprung zur Startup-Routine, wenn CREATION-TIME=*AFTER-SYSTEM-READY definiert wurde (asynchron)

• explizit durch das Kommando START-SUBSYSTEM

• explizit beim Aufruf der $ESMCRE-Schnittstelle

• implizit nach dem ersten SVC-Aufruf für ein Subsystem, das mit CREATION-TIME=*AT-SUBSYSTEM-CALL(ON-ACTION=*STD oder *ANY) definiert wurde
  bzw. implizit nach dem ersten ISL-Aufruf für ein Subsystem, das mit CREATION-TIME= *AT-SUBSYSTEM-CALL(ON-ACTION=*ISL-CALL oder *ANY) definiert wurde

Zum Startzeitpunkt für Subsysteme siehe auch die SSCM-Anweisung SET-SUBSYSTEM-ATTRIBUTES.

Die Programm- oder Bindemodulbibliothek (OML), die REP- und die „NOREF“-Datei von DSSM müssen ebenso wie die anderen für die DSSM-Initialisierung benötigten Dateien (z.B. der SSMCAT) und die Dateien, die für die Aktivierung von Startup-gebundenen Subsystemen benötigt werden, unter der Kennung TSOS auf dem Home-Pubset eingerichtet und während des Startup verfügbar sein.

Startup-gebunden sind solche Subsysteme, deren Aktivierungszeitpunkt mit den folgenden Werten angegeben wurden:

• *BEFORE-SYSTEM-READY

• *AFTER-SYSTEM-READY

• *BEFORE-DSSM-LOAD

• *AT-DSSM-LOAD

• *MANDATORY-AT-STARTUP

Voraussetzung für das Aktivieren ist in jedem Fall, dass das Subsystem bekannt, d.h. im globalen oder lokalen Subsystemkatalog deklariert ist.

Die Aktivierung läuft in folgenden Stufen ab:

1. Prüfen des Auftrags, insbesondere Abhängigkeiten zu anderen Subsystemen (synchron)

   Hat ein Subsystem Komponenten, die mit dem Attribut *INSTALLED deklariert und mit IMON installiert wurden, ruft DSSM während der Prüfphase IMON-GPN auf, um die Pfadnamen der Dateien zu erhalten.

   Abhängig von der Verfügbarkeit von IMON-GPN und dem Status der installierten Liefergruppe (siehe Operand INSTALLATION-UNIT) verhält sich DSSM wie folgt:

   • Die INSTALLATION-UNIT existiert und ein Dateiname kann mit dem angegebenen logischen Namen assoziiert werden:
     DSSM wird diesen Dateinamen solange benutzen, wie das Subsystem aktiv ist (bis STOP-SUBSYSTEM) oder bis durch das Kommando MODIFY-SUBSYSTEM-PARAMETER ein anderer Dateiname festgelegt wurde.

   • In folgenden Situationen greift DSSM auf den im Katalog definierten DEFAULT-NAME zu, wenn vorhanden:

     • IMON-GPN ist nicht verfügbar

     • die INSTALLATION-UNIT existiert nicht in den IMON-GPN-Daten

     • die INSTALLATION-UNIT existiert in den IMON-GPN-Daten, jedoch ohne Verbindung zu einem logischen Namen (LOGICAL-ID)

   Die Meldung ESM0665 informiert über die Vorgehensweise:

   ESM0665  'DEFAULT-NAME' FUER DATEIEN DES SUBSYSTEMS '(&00)' VERWENDET

   • Die INSTALLATION-UNIT existiert in den IMON-GPN-Daten mit einigen zugehörigen Pfadnamen, aber der angefragte logische Name existiert nicht. DSSM nimmt nun an, dass die Datei nicht existiert. Zwei Fälle sind zu unterscheiden:

     • Subsysteme die mit den Attributen *AT-DSSM-LOAD oder *MANDATORY-AT-STARTUP definiert wurden:
       Während dem Startup wird eine Frage an der Bedienstation ausgegeben, die beantwortet werden muss. Der Operator kann nun entweder für die erforderliche Datei (Informationsdatei, Modulbibliothek oder Rep-Datei mit dem Attribut REP-FILE-MANDATORY=*YES) einen neuen, gültigen Namen angeben oder die Aktivierung des Subsystems stoppen.

     • Subsysteme die mit den Attributen *AT-CREATION-REQUEST, *AFTER-SYSTEM-READY oder *BEFORE-SYSTEM-READY definiert wurden:
       Fehlt eine der Dateien (Modulbibliothek, Informationsdatei oder Rep-Datei mit dem Attribut REP-FILE-MANDATORY=*YES), wird das Subsystem nicht aktiviert, was durch eine Meldung angezeigt wird. Fehlt die Meldungsdatei oder die Rep-Datei (mit Attribut REP-FILE-MANDATORY=*NO), wird das Subsystem aktiviert; es wird trotzdem eine Warnung ausgegeben.

2. Laden in eine Holdertask (asynchron)
   Das Laden des Subsystemcodes wird durch die Holdertask veranlasst.
   Zusätzlich stellt sie ihren lokalen Adressraum (Benutzeradressraum) für die Subsysteme zur Verfügung, die mit MEMORY-CLASS=*LOCAL-PRIVILEGED/*LOCAL-UNPRIVILEGED definiert wurden. Das Laden von Subsystemen mit MEMORY-CLASS=*SYSTEM-GLOBAL wird zwar ebenfalls von der Holdertask veranlasst, sie werden aber nicht in den Benutzeradressraum der Holdertask, sondern in den gemeinsam benutzbaren Systemadressraum geladen.

   Bei der Aktivierung von TU-Subsystemen mit MEMORY-CLASS=*BY-SLICE wird der mehrbenutzbare Programmbereich in den gemeinsam benutzbaren
   Systemadressraum geladen, der nicht-mehrbenutzbare Programm- und/oder Datenbereich in den Benutzeradressraum der Holdertask.

   Stellt eine Task den Anschluss zu einem solchen Subsystem her, wird nur noch der bereits im Benutzeradressraum der Holdertask geladene Datenbereich in die privaten Benutzeradressräume der angeschlossenen Tasks an dieselbe Adresse kopiert. Dadurch sind adressbezogene Referenzen zwischen Programm- und Datenbereich immer möglich. Die Performance wird durch diese Art der Adressraumaufteilung wesentlich erhöht, weil beim Anschluss einer Task an das Subsystem kein Zugriff zur Programm- oder Bindemodulbibliothek erfolgt und Externverweise nicht aufgelöst werden müssen.

   Wenn ein Subsystem mit MEMORY-CLASS=*BY-SLICE definiert wurde und erstmals gestartet wird, informiert DSSM das Subsystem BLSSERV darüber, dass mit dem Makro VSVI1 auf die Kopie des Datenbereichs im privaten Benutzeradressraum zugegriffen werden kann.
   Das Makro VSVI1 informiert den Anwender über Einträge in den Tabellen des DBL. Einzelheiten zum Makro siehe Handbuch „BLSSERV“ [4].

   Die Holdertask kann auch als Arbeitstask dienen.

3. nur für TPR-Subsysteme: Starten der Subsystemaktivierung in der Holdertask, falls eine INIT-Routine definiert ist (asynchron)

4. Nach abgeschlossener Aktivierung Öffnen des Subsystems für Anschlüsse von berechtigten Benutzern (asynchron)

Der Wiederanlauf eines Subsystems (RESUME-SUBSYSTEM) nach einem vorhergehenden HOLD-SUBSYSTEM besteht aus den Stufen 1, 3 und 4.
Bei Stufe 1 entfällt das Aufrufen von IMON-GPN.

Wenn die Aktivierung bzw. der Wiederanlauf eines Subsystems explizit durch das Kommando START- bzw. RESUME-SUBSYSTEM erfolgte, kann an Stelle des asynchronen der synchrone Verarbeitungsmodus gewählt werden.