Bei der Installation einer Liefereinheit wird die Aktivierung für den nächsten Systemlauf vorbereitet. Für Subsysteme wird neben der Aktivierung der Meldungs- und Syntaxdateien für den nächsten Systemlauf nur der statische Subsystemkatalog aktualisiert. Der dynamische Subsystemkatalog des laufenden Systems wird nicht verändert.
Mit der Funktion „Dynamische Aktivierung“ kann eine neu installierte Liefereinheit (bzw. die entsprechenden Installation-Units) bereits im laufenden System, d.h. unterbrechungsfrei zur Verfügung gestellt werden. Die dynamische Aktivierung beinhaltet:
Aktivierung der Syntaxdateien im laufenden System
Aktivierung der Meldungsdateien im laufenden System
Aktivierung der POSIX-Dateien im aktuellen System: Die POSIX-Kommandos, die notwendig sind um die aktivierte Unit direkt im POSIX-System über das Kommando /START-POSIX-INSTALLATION zu registrieren, werden in der Aktivierungsprozedur generiert.
Starten der Subsysteme aus dem Subsystemkatalog der Installation-Unit (bei „Nicht-Subsystemen“ entfällt dieser Punkt)
Die dynamische Aktivierung kann für jede Liefereinheit (bzw. Installation-Unit) durchgeführte werden, die das Attribut „aktivierbar“ besitzt. Die Auswahl der zu aktivierenden Liefereinheiten (bzw. Installation-Units) erfolgt entweder aus dem geöffneten Standard-SCIs, aus einer geöffneten Lieferung oder aus dem letzten Installationsprozess.
Definition der Aktivierbarkeit
Liefereinheiten und Installation-Units besitzen das Attribut „aktivierbar“ bzw. „nicht aktivierbar“, das mit „Activable=Yes“ bzw. „Activable=No“ im SCI eingetragen ist und das bei der entsprechenden Informationsausgabe angezeigt wird (siehe Beispiel für Liefereinheit auf "Liefereinheit (Supply-Unit) " bzw. für Installation-Unit auf "Installation-Unit (IU) ").
Eine Liefereinheit ist aktivierbar, wenn sie mindestens eine aktivierbare Installation-Unit enthält.
Aktivierbarkeit einer Installation-Unit
Für Installation-Units wird bei der Zuordnung des Attributs zunächst unterschieden, ob die Installation-Unit ein Subsystem oder kein Subsystem („Nicht-Subsystem“) ist. „Nicht-Subsysteme“ werden in jedem Fall als „aktivierbar“ eingestuft.
Subsysteme werden bezüglich der Aktivierbarkeit in fünf Stufen unterteilt. Die Aktivierungsstufe ist als zusätzliches Attribut im SCI eingetragen (Informationsausgabe im Feld „Level“):
Level 1: | das Subsystem ist aktivierbar |
Level 2: | das Subsystem ist aktivierbar, wobei das Subsystemattribut Creation-Time geändert wird |
Level 3: | das Subsystem ist nur eingeschränkt aktivierbar |
Level 41: | das Subsystem besitzt Abhängigkeiten zu anderen Subsystemen, ist aber aktivierbar |
Level 42: | das Subsystem besitzt Abhängigkeiten zu anderen Subsystemen und ist nur unter bestimmten Bedingungen aktivierbar |
Die Zuordnung der Aktivierungsstufe ist abhängig von den im Subsystemkatalog definierten Subsystemattributen:
In Level 1 erlauben die Subsystemattribute die dynamische Aktivierung:
creation-time = at-creation-request / at-subsystem-call version-exchange = allowed / forbidden version-coexistence = allowed / forbidden state-change-cmds = allowed subsystem-hold
=
allowed
Im Abschnitt FUNCTIONAL DEPENDENCE WITH SUBSYSTEMS der Katalogdefinitionen existieren keine Subsystem-Einträge.
Im Abschnitt REFERENCED SUBSYSTEMS der Katalogdefinitionen existieren außer für CP keine weiteren Subsystem-Einträge.
In Level 2 erlauben die Subsystemattribute die dynamische Aktivierung, wenn vorher Attribute geändert werden:
creation-time
=
at-dssm-load / before-dssm-load / before-system-ready /
after-system-ready / mandatory-at-startup
version-exchange = allowed / forbidden version-coexistence = allowed / forbidden state-change-cmds = allowed subsystem-hold = allowed Im Abschnitt FUNCTIONAL DEPENDENCE WITH SUBSYSTEMS der Katalogdefinitionen existieren keine Subsystem-Einträge.
Im Abschnitt REFERENCED SUBSYSTEMS der Katalogdefinitionen existieren außer für CP keine weiteren Subsystem-Einträge.
In Level 3 verhindert folgendes Subsystemattribut, das ein in enthaltenes Subsystem gestartet oder beendet wird:
state-change-cmds
In Level 41 erlauben die Subsystemattribute die dynamische Aktivierung:
creation-time
=
at-creation-request / at-subsystem-call
version-exchange = allowed / forbidden version-coexistence = allowed / forbidden state-change-cmds = allowed subsystem-hold = allowed Es existieren Subsystem-Einträge im Abschnitt FUNCTIONAL DEPENDENCE WITH SUBSYSTEMS bzw. im Abschnitt REFERENCED SUBSYSTEMS der Katalogdefinitionen.
In Level 42 erlauben die Subsystemattribute die dynamische Aktivierung, wenn vorher Attribute geändert werden:
creation-time
=
at-dssm-load / before-dssm-load / before-system-ready /
after-system-ready / mandatory-at-startup
version-exchange
= allowed / forbidden version-coexistence = allowed / forbidden state-change-cmds = allowed subsystem-hold = allowed Es existieren Subsystem-Einträge im Abschnitt FUNCTIONAL DEPENDENCE WITH SUBSYSTEMS bzw. im Abschnitt REFERENCED SUBSYSTEMS der Katalogdefinitionen.
Die dynamische Aktivierung wird durch die IMON-Funktion „Bearbeiten: Aktivieren“ bzw. die Anweisung ACTIVATE-UNITS ausgelöst. Sie wird in zwei Phasen aufgeteilt:
| Vorbereitung der dynamischen Aktivierung eigentliche Durchführung |
Vorbereitung der dynamischen Aktivierung
Auswahl der zu aktivierenden Liefereinheiten bzw. Installation-Units
Zuerst werden die Liefereinheiten bzw. Installation-Units ausgewählt, die dynamisch aktivert werden sollen. Im Menü-Modus erfolgt die Auswahl vor Aufruf der IMON-Funktion „Bearbeiten: Aktivieren“, im SDF-Modus direkt in der Anweisung ACTIVATE-UNITS. Es bestehen folgende Auswahlmöglichkeiten:
Der Benutzer gibt die zu aktivierenden Objekte explizit im Operanden UNIT-NAME an bzw. markiert sie direkt im Arbeitsbereich.
Der Benutzer lässt sich nur die aktivierbaren Objekte anzeigen (im Operanden UNIT-NAME=*BY-DIALOG bzw. im Menü-Modus Auswahl:Liefereinheiten (Supply-Units)) und
Aktivierbar=2 (Ja) in der Dialogbox Liefereinheiten (Supply-Units) Auswahl). Dann wählt er die gewünschten Objekte im Arbeitsbereich direkt aus.
Die Menge der aktivierbaren Objekte lässt sich durch folgende Auswahlkriterien weiter eingrenzen:
Auswahl einer oder mehrere Lieferungen (Angabe von Paketname und Kundenkennzeichen im Operanden SELECT=*SOLIS2-DELIVERY(...) bzw. in der Dialogbox Liefereinheiten (Supply-Units) Auswahl)
Auswahl der Objekte der zuletzt durchgeführten Installation (entspricht bereits der Vorbelegung: Operand SELECT=*LAST-INSTALLED bzw. Letzte Installation=1 (Ja) in der Dialogbox Liefereinheiten (Supply-Units) Auswahl)
Enthält die Auswahl eine Installation-Unit mehrmals, wird die Installation-Unit für die Aktivierung nur einmal berücksichtigt. Bei verschiedenen Versionen derselben Installation-Unit wird nur die höchste Version berücksichtigt.
Nach erfolgter Auswahl identifiziert IMON die Art der dynamischen Aktivierung. Es gibt drei Arten:
Ein neues Subsystem wird aktiviert.
Die Korrekturversion eines Subsystems wird aktiviert.
Die zu aktivierende Version des Subsystems ersetzt ein bestehendes Subsystem.
Anschließend generiert IMON folgende zwei Dateien:
die Protokolldatei
$SYSSAG.<prefix>.<time-stamp>.RP, die alle DSSM-Kommandos(STOP-, REMOVE-, ADD- und START-SUBSYSTEM) für die aktivierbaren Subsysteme enthält
die Aktivierungsprozedur
$SYSSAG.<prefix>.<time-stamp>.DA, die alle notwendigen Kommandos und Anweisungen für die dynamische Aktivierung der ausgewählten Objekte enthält
Der Präfix ist im Standardfall die Zeichenfolge IMONACU (siehe auch „Wichtige Dateien bei der Aktivierung" (Fehlerbehandlung und Restart der Aktivierung )).
Nach Generierung der beiden Dateien unterbricht IMON die Vorbereitungsphase mit einer Fragemeldung. Der Benutzer kann die Protokolldatei überprüfen und anschließend durch Beantworten der Fragemeldung (Antwort „1“ oder „2“) entscheiden, ob der Aktivierungsprozess fortgesetzt werden soll:
Antwort | Auswirkung |
1 | bricht den Aktivierungsprozess ab. Protokolldatei und Aktivierungsprozedur werden gelöscht. |
2 | setzt den Aktivierungsprozess fort (siehe auch „Eigentlicher Aktivierungsvorgang" "Dynamische Aktivierung "). Gemäß der gewählten Aufrufoption wird die Aktivierungsprozedur automatisch gestartet oder der Aktivierungsprozess wird normal beendet und die Aktivierungsprozedur kann zu einem späteren Zeitpunkt manuell gestartet werden. |
Struktur der Protokolldatei
Die Protokolldatei ist in zwei Teile aufgeteilt:
Teil 1 listet alle zur Aktivierung ausgewählten Liefereinheiten bzw. Installation-Units und ggf. die bei ihrer Bearbeitung aufgetretenen Fehler oder Warnungen.
Teil 2 enthält alle DSSM-Kommandos zur Aktivierung der Subsysteme, bei denen im ersten Teil kein Fehler gemeldet wurde. Die Informationen werden spaltenweise aufgelistet:
Spalte | Bedeutung und mögliche Werte |
1 | Typ des Subsystems; mögliche Werte
|
2 | Name des Subsystems |
3 | Version des Subsystems |
4 | DSSM-Kommando (abgekürzter Name), das für das Subsystem auszuführen ist (mögliche Werte: STOP, REMOVE, ADD, START) |
5 - 8 | Identifikation der Installation-Unit, die das betreffende Subsystem enthält |
Struktur der Aktivierungsprozedur
Die Aktivierungsprozedur unterteilt sich in einzelne Bearbeitungsschritte, die im Fehlerfall einen Restart/Recovery-Mechanismus ermöglichen (siehe Abschnitt „Fehlerbehandlung und Restart der Aktivierung" (Fehlerbehandlung und Restart der Aktivierung )). Folgende Bearbeitungsschritte sind möglich:
Sperre für Installation-Unit aufheben
Dieser Aktivierungsschritt gruppiert alle UNLOCK-PRODUCT-VERSION-Kommandos für die ausgewählten Installation-Units bzw. die in den ausgewählten Liefereinheiten enthaltenen Installation-Units.
Subsystemkatalog erstellen
Dieser Aktivierungsschritt gruppiert alle SSCM-Anweisungen, die zur Erstellung der Kataloge für alle betroffenen Subsysteme notwendig sind.
Zu löschendes Subsystem anhalten
Dieser Aktivierungsschritt gruppiert alle STOP-SUBSYSTEM-Kommandos, die zum Anhalten der zu löschenden Subsysteme notwendig sind (falls Installation-Items vom Typ SSC vorhanden sind).
Syntaxdateien des zu löschenden Subsystems deaktivieren
Dieser Aktivierungsschritt gruppiert alle MODIFY-SDF-PARAMETERS-Kommandos, die zur Deaktivierung der Syntaxdateien von zu löschenden Subsystemen notwendig sind (falls Installation-Items vom Typ SDF vorhanden sind).
Substem anhalten
Dieser Aktivierungsschritt gruppiert alle STOP-SUBSYSTEM-Kommandos für die aus der Auswahl resultierenden Subsysteme. Zur Überprüfung, ob die Subsysteme angehalten sind, generiert IMON für jedes der
Subsysteme einen Aufruf der internen Funktion
WAIT-SUBSYSTEM-STATUS. Diese Funktionsaufrufe werden ohne Fehler beendet, wenn sich alle Subsysteme im ZustandNOT CREATEDbefinden. Sobald sich eines der Subsysteme in einem anderen Zustand befindet, schlägt der betreffende Funktionsaufruf fehl und der Aktivierungsprozess wird unterbrochen.Hinweis
Die anzuhaltenden Subsysteme werden in zwei Untergruppen eingeteilt:
die in der Auswahl enthaltenen Subsysteme, die sich noch einmal in die Subsysteme des Levels 4 und in die Subsysteme der Level 1 und 2 unterteilen.
Subsysteme, die Abhängigkeiten zu den ausgewählten Subsystemen besitzen. Diese Subsysteme müssen vor den ausgewählten Subsystemen angehalten
werden.
Subsystem löschen
Dieser Aktivierungsschritt gruppiert alle REMOVE-SUBSYSTEM-Kommandos für die aus der Auswahl resultierenden Subsysteme.
- Meldungsdatei aktivierenDieser Aktivierungsschritt gruppiert alle MODIFY-MSG-FILE-ASSIGNMENT-Kommandos für alle in der Auswahl enthaltenen Meldungsdateien.
- Syntaxdatei aktivieren
Dieser Aktivierungsschritt gruppiert alle MODIFY-SDF-PARAMETERS-Kommandos für alle in der Auswahl enthaltenen Syntaxdateien. - Neuen Subsystemkatalog hinzufügen
Dieser Aktivierungsschritt gruppiert alle ADD-SUBSYSTEM-Kommandos für die im AktivierungsschrittWAIT-SUBSYSTEM-STATUS. Diese Funktionsaufrufe werden ohne Fehler beendet, wenn sich alle Subsysteme im ZustandNOT CREATEDbefinden. Sobald sich eines der Subsysteme in einem anderen Zustand befindet, schlägt der betreffende Funktionsaufruf fehl und der Aktivierungsprozess wird unterbrochen. - Subsystem starten
Dieser Aktivierungsschritt gruppiert alle START-SUBSYSTEM-Kommandos für die ausder Auswahl resultierenden Subsysteme. Zur Überprüfung, ob die Subsysteme gestartet sind, generiert IMON für jedes der Subsysteme einen Aufruf der internen FunktionWAIT-SUBSYSTEM-STATUS. Diese Funktionsaufrufe werden ohne Fehler beendet, wenn sich alle Subsysteme im ZustandCREATEDbefinden. Sobald sich eines der Subsysteme in einem anderen Zustand befindet, schlägt der betreffende Funktionsaufruf fehl und der Aktivierungsprozess wird unterbrochen.
Hinweis
Die anzuhaltenden Subsysteme werden in zwei Untergruppen eingeteilt:
- die in der Auswahl enthaltenen Subsysteme, die sich noch einmal in die Subsysteme des Levels 4 und in die Subsysteme der Level 1 und 2 unterteilen.
- Subsysteme, die Abhängigkeiten zu den ausgewählten Subsystemen besitzen. Diese Subsysteme müssen vor den ausgewählten Subsystemen gestartet werden. - POSIX-Verarbeitung durchführen
Dieser Aktivierungsschritt gruppiert alle POSIX-Verarbeitungsprozesse für alle in der Auswahl enthaltenen Installation-Items vom Typ *PS oder *NP. - Subsystemattribute für Subsystem des Levels 2 zurücksetzen
Dieser Aktivierungsschritt gruppiert alle MODIFY-SUBSYSTEM-PARAMETER-Kommandos für die mit Level 2 eingestuften Subsysteme. - Zustand eines wegen Abhängigkeit angehaltenen Subsystems wiederherstelle
Dieser Aktivierungsschritt gruppiert alle START-SUBSYSTEM-Kommandos für die Subsysteme, die wegen bestehender Abhängigkeiten angehalten wurden (siehe Aktivierungsschritt
Eigentlicher Aktivierungsvorgang
Der eigentliche Aktivierungsvorgang erfolgt bei Ablauf der generierten Aktivierungsprozedur. Die Aktivierungsprozedur kann nur gestartet werden, wenn der Benutzer die von IMON unterbrochene Vorbereitungsphase nach Überprüfung der Protokolldatei mit der Antwort„2“ fortsetzt. Bei Abbruch mit der Antwort „1“ löscht IMON die generierten Dateien.
Standardmäßig wird die Aktivierungsprozedur automatisch gestartet. Optional kann die Prozedur auch manuell mit dem Kommando ENTER-PROCEDURE gestartet werden (Operand START=*BY-USER in der Anweisung ACTIVATE-UNITS bzw. Start = 2 (Benutzergesteuert) in der Dialogbox Aktivierungsparameter). Zur Behandlung von Fehlern, die beim Ablauf der Aktivierungsprozedur auftreten können, siehe Abschnitt „Fehlerbehandlung und Restart der Aktivierung".