Eigenschaften von Subsystemen verändern
Funktionsbeschreibung
Mit dieser Anweisung können alle Eigenschaften und Einsprungstellen, die mit der Anweisung SET-SUBSYSTEM-ATTRIBUTES definiert wurden, verändert werden.
Bei der Veränderung einer Definition ist auf Folgendes zu achten:
Das Subsystem - identifiziert durch Name und Version - muss im aktuell geöffneten Katalog gefunden werden
Der Versuch, einen bereits bestehenden Auftragseingang oder bereits bestehende Beziehungen hinzuzufügen, wird abgewiesen
Nicht zulässig ist, einen noch nicht bestehenden Auftragseingang oder noch nicht definierte Beziehungen zu verändern oder zu löschen
Der Modus eines Auftragseingangs darf nur verändert werden, wenn alle Parameter angegeben werden; die Standardwerte *UNCHANGED werden zurückgewiesen
Die Speicherklasse eines Subsystems darf nur verändert werden, wenn alle Parameter angegeben werden; die Standardwerte *UNCHANGED werden zurückgewiesen
MODIFY-SUBSYSTEM-ATTRIBUTES wird abgewiesen, wenn vorher keine der folgenden Anweisungen ausgeführt wurde:
START-CATALOG-CREATION
START-CATALOG-MODIFICATION
Hinweis zur Syntax
Für die Namen der Einsprungstellen in den folgenden Operanden (im Format ist der Datentyp <name> angegeben) kann auch der spezielle Datentyp <symbol> verwendet werden, der im Handbuch „BLSSERV“ [4] ausführlich beschrieben ist:
LINK-ENTRY
DYNAMIC-CHECK-ENTRY
INIT-ROUTINE
CLOSE-CTRL-ROUTINE
STOPCOM-ROUTINE
DEINIT-ROUTINE
INTERFACE-VERSION
ADD-SUBS-ENTRIES
MODIFY-SUBS-ENTRIES
REMOVE-SUBS-ENTRIES
Format
MODIFY-SUBSYSTEM-ATTRIBUTES | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Operandenbeschreibung
Der Standardwert *UNCHANGED bedeutet jeweils, dass der in der Anweisung SET-SUBSYSTEM-ATTRIBUTES eingestellte Wert gültig bleiben soll.
Wird der Typ des vereinbarten Auftragseingangs (Operand MODE) oder der subsystemspezifische Adressraum (Operand MEMORY) verändert, müssen alle Unteroperanden von MODE bzw. MEMORY explizit mit einem Wert versehen werden (der Operandenwert *UNCHANGED (Voreinstellung) wird abgewiesen).
SUBSYSTEM-NAME = <structured-name 1..8>(...)
Vereinbart Name und Version des Subsystems, dessen Definition verändert werden soll.
VERSION = <c-string 3..8> / <text 3..8>
Die Version des Subsystems ist im Format „[V][m]m.n[aso]“ zu vereinbaren, wobei die Textteile folgende Bedeutung besitzen:
mm: Hauptversion (numerisch)
n: Nachtragsversion (numerisch)
aso: Änderungsstand (a: Buchstabe, Freigabestand; so: numerisch, Korrekturstand)
INSTALLATION-UNIT =
Legt den Namen der installierten Liefergruppe fest. Für alle mit IMON zu installierenden Subsysteme muss ein Wert ungleich *NONE angegeben werden, ebenso, wenn bei den Operanden SUBSYSTEM-LIBRARY, REP-FILE, SUBSYSTEM-INFO-FILE, MESSAGE-FILE und SYNTAX-FILE der Wert *INSTALLED(LOGICAL-ID=...) definiert wurde.
Die im Handbuch „IMON“ [18] dargestellten Syntaxregeln sind bei der Festlegung des Namens zu beachten.
INSTALLATION-UNIT = *NONE
Es wird kein Name vergeben. Für alle mit IMON installierten Subsysteme ist diese Angabe nicht erlaubt.
INSTALLATION-UNIT = *STD
Der beim Operanden SUBSYSTEM-NAME angegebene Name wird als neuer Name der installierten Liefergruppe genutzt.
INSTALLATION-UNIT = <text 1..30>
Neuer Name der installierten Liefergruppe.
INSTALLATION-USERID =
Vereinbart eine Benutzerkennung, unter der die zuständige DSSM-Task die Nebenkomponenten des Subsystems (Rep-Datei, Objektmodulbibliothek, Meldungsdatei, Syntaxdatei und Subsystem-Informationsdatei) erwartet, falls diese Dateien noch keiner Benutzerkennung zugeordnet sind, d.h. der Dateiname ohne Benutzerkennung angegeben wurde.
INSTALLATION-USERID = *NONE
Die Dateien werden nicht unter einer bestimmten Benutzerkennung erwartet.
INSTALLATION-USERID = *DEFAULT-USERID
Die Dateien werden unter der System-Standardkennung erwartet (Prefix „$.“) bzw. unter der Benutzerkennung der aufrufenden Task, wenn es ein lokales Subsystem ist.
INSTALLATION-USERID = <name 1..8>
Benutzerkennung, unter der die Nebenkomponenten erwartet werden.
Gilt die Anweisung für ein SSD-Object, werden die Dateien nur dann unter der hier angegebenen Benutzerkennung erwartet, wenn in der Anweisung ADD-CATALOG-ENTRY (Übernahme von Subsystemdefinitionen aus dem SSD-Object in den Katalog) keine Benutzerkennung angegeben wurde. Die Angabe bei ADD-CATALOG-ENTRY hat Vorrang.
COPYRIGHT =
Vereinbart, ob und welche Copyright-Meldung beim Starten des Subsystems ausgegeben werden soll.
COPYRIGHT = *NONE
Es soll keine Copyright-Meldung ausgegeben werden.
COPYRIGHT = <c-string 1..54>(...)
Text der Copyright-Meldung, die zusammen mit dem Datum der Erstellung beim Starten ausgegeben wird.
YEAR = *YEAR-1990 / <c-string 4..4>
Jahreszahl, die in der Copyright-Meldung als Datum der Erstellung erscheinen soll. Eine semantische Prüfung findet nicht statt.
LIBRARY =
Vereinbart einen neuen Namen für die Programm- oder Bindemodulbibliothek (OML), aus der der Objectcode des Subsystems bei dessen Aktivierung geladen werden soll.
LIBRARY = *STD
Der Objectcode wird beim Starten automatisch aus der Bibliothek SYSLNK.<subsysname>.<subsysvers#> geladen. Sie ist auf der Benutzerkennung abgelegt, unter der die Holdertask läuft; also auf der Benutzerkennung des Aufrufers bei lokalen Subsystemen und auf TSOS bei globalen Subsystemen.
Der Wert von „subsysvers#“ ist dreistellig und setzt sich aus den beim Operanden SUBSYSTEM-NAME=...(VERSION=...) angegebenen Teilen „mmn“ zusammen.
LIBRARY = *CPLINK
Das zu definierende Subsysteme ist mit dem Basissystem des BS2000 verknüpft (CP=Control Program) und muss bereits vor der Aktivierung von DSSM geladen sein.
Der Operand darf nur in Verbindung mit dem Operanden CREATION-TIME=*BEFORE-DSSM-LOAD verwendet werden.
LIBRARY = *INSTALLED(...)
Der Bibliotheksname muss durch den Aufruf von IMON-GPN (Verwaltung von Installationspfaden) bestimmt werden.
Wird eine der Nebenkomponenten mit einem logischen Namen angesprochen, müssen bei allen zu diesem Subsystem gehörenden Nebenkomponenten logische Namen angegeben werden. Wird ein logischer Name vergeben, muss beim Operanden INSTALLATION-UNIT ein Wert ungleich *NONE vergeben werden.
LOGICAL-ID = <filename 1..30 without-catid-userid-gen-vers>
Logischer Name der Programm- oder Bindemodulbibliothek.
DEFAULT-NAME = <filename 1..54 without-gen-vers>
Bibliotheksname bei Nichtverfügbarkeit von IMON-GPN oder wenn der logische Name unbekannt ist.
LIBRARY = <filename 1..54 without-gen-vers>
Vollqualifizierter Dateiname der Bindemodulbibliothek, aus der der Objectcode für das Subsystem geladen werden soll.
SUBSYSTEM-LOAD-MODE =
Bestimmt den Lademodus des Subsystems (über die BLS-DSSM-Schnittstelle $PBBND1).
SUBSYSTEM-LOAD-MODE = *STD
Das BLS wird im STD-Run-Mode aufgerufen und lädt das Subsystem als Objektmodul.
SUBSYSTEM-LOAD-MODE = *ADVANCED
Das BLS wird im ADVANCED-Run-Mode aufgerufen und lädt das Subsystem als Bindelademodul (LLM).
REP-FILE =
Legt fest, ob System-Reps für das zu definierende Subsystem benötigt werden und in welcher Datei diese hinterlegt sind. Diese Korrekturanweisungen werden während der Aktivierung des Subsystems ausschließlich auf die in der Bindemodulbibliothek hinterlegten und geladenen Module angewandt, nicht auf andere Subsysteme oder BS2000-CP. Eine Rep-Datei kann auch für Module eines nicht-privilegierten Subsystems vereinbart werden.
REP-FILE darf nicht zusammen mit LIBRARY=*CPLINK angegeben werden.
REP-FILE = *STD
Standardmäßig werden die System-Reps aus der Rep-Datei mit dem Namen
SYSREP.<subsysname>.<subsysvers#> geladen. Diese Datei ist auf der Benutzerkennung abgelegt, unter der die Holdertask läuft; also auf der Benutzerkennung des Aufrufers bei lokalen Subsystemen und auf TSOS bei globalen Subsystemen.
Der Wert von „subsysvers#“ ist dreistellig und setzt sich aus den beim Operanden SUBSYSTEM-NAME=...(VERSION=...) angegebenen Teilen „mmn“ zusammen.
REP-FILE = *NO
Für das Subsystem soll keine Rep-Datei verarbeitet werden.
REP-FILE = *INSTALLED(...)
Der Name der Rep-Datei muss durch den Aufruf von IMON-GPN (Verwaltung von Installationspfaden) bestimmt werden.
Wird eine der Nebenkomponenten mit einem logischen Namen angesprochen, müssen bei allen zu diesem Subsystem gehörenden Nebenkomponenten logische Namen angegeben werden. Wird ein logischer Name vergeben, muss beim Operanden INSTALLATION-UNIT ein Wert ungleich *NONE vergeben werden.
LOGICAL-ID = <filename 1..30 without-catid-userid-gen-vers>
Logischer Name der Rep-Datei.
DEFAULT-NAME =
Name der Rep-Datei bei Nichtverfügbarkeit von IMON-GPN oder wenn der logische Name unbekannt ist.
DEFAULT-NAME = <filename 1..54 without-gen-vers>
Es wird ein neuer Name vergeben.
DEFAULT-NAME = *NONE
Es wird kein neuer Name vergeben.
REP-FILE = <filename 1..54 without-gen-vers>
Vollqualifizierter Name der Rep-Datei, aus der die Korrekturanweisungen gelesen werden.
REP-FILE-MANDATORY =
Legt fest, ob eine mit dem Operanden REP-FILE deklarierte Rep-Datei beim Laden des Subsystems abgearbeitet werden muss oder nicht.
REP-FILE-MANDATORY = *NO
Der Einsatz einer Rep-Datei ist nicht Pflicht, d.h. weder die Rep-Datei noch deren Einträge sollen beim Aktivieren des Subsystems geprüft werden. Sollte die Rep-Datei nicht zugreifbar oder einzelne Korrekturanweisungen fehlerhaft sein, wird das Subsystem auch in diesem Fall gestartet.
REP-FILE-MANDATORY = *YES
Sollte es bei der Bearbeitung der Rep-Datei zu folgenden Fehlern kommen, wird der Versuch, das Subsystem zu laden, abgebrochen:
Die Rep-Datei ist nicht katalogisiert oder kann nicht gelesen werden
Die Prüfung der Korrekturanweisungen zeigt einen Fehler an
Der Name der Korrekturanweisungen ist fehlerhaft
Das DMS meldet einer Fehler beim Zugriff auf die NOREF-Datei (diese Datei wird während des Ladens eines Subsystems benutzt, um zu verhindern, dass ungültige System-Reps an der Bedienstation protokolliert werden)
MESSAGE-FILE =
Bestimmt, ob es eine subsystemspezifische Meldungsdatei gibt, die beim Laden des Subsystems automatisch aktiviert wird.
Für Subsysteme, die mit dem Startzeitpunkt AT-DSSM-LOAD definiert werden, ist im Operanden RELATED-SUBSYSTEM eine Abhängigkeitsbeziehung zum Subsystem MIP zu vereinbaren.
MESSAGE-FILE = *NO
Es soll keine Meldungsdatei aktiviert werden. Dieser Wert ist verpflichtend für alle Subsysteme, die mit dem Startzeitpunkt BEFORE-DSSM-LOAD definiert werden (siehe auch Operand CREATION-TIME), da zu diesem Zeitpunkt noch keine Meldungsdatei aktiviert werden kann.
MESSAGE-FILE = *INSTALLED(...)
Der Name der Meldungsdatei muss durch den Aufruf von IMON-GPN (Verwaltung von Installationspfaden) bestimmt werden.
Wird eine der Nebenkomponenten mit einem logischen Namen angesprochen, müssen bei allen zu diesem Subsystem gehörenden Nebenkomponenten logische Namen angegeben werden. Wird ein logischer Name vergeben, muss beim Operanden INSTALLATION-UNIT ein Wert ungleich *NONE vergeben werden.
LOGICAL-ID = <filename 1..30 without-catid-userid-gen-vers>
Logischer Name der Meldungsdatei.
DEFAULT-NAME =
Name der Meldungsdatei bei Nichtverfügbarkeit von IMON-GPN oder wenn der logische Name unbekannt ist.
DEFAULT-NAME = <filename 1..54 without-gen-vers>
Es wird ein neuer Name vergeben.
DEFAULT-NAME = *NONE
Es wird kein neuer Name vergeben.
MESSAGE-FILE = <filename 1..54 without-gen-vers>
Vollqualifizierter Name der Meldungsdatei. Diese wird beim Laden des Subsystems (Kommando START-SUBSYSTEM) automatisch aktiviert, beim Entladen des Subsystems (Kommando STOP-SUBSYSTEM) automatisch deaktiviert.
SUBSYSTEM-INFO-FILE =
Bestimmt, ob eine Subsysteminformationsdatei (SSINFO) vorhanden ist. In dieser Datei sind subsystemspezifische Daten (Nebenkomponenten und Konfigurationsdaten) enthalten, die nicht von DSSM zentral bearbeitet werden können.
SUBSYSTEM-INFO-FILE = *NO
Eine Informationsdatei für das Subsystem ist nicht verfügbar.
SUBSYSTEM-INFO-FILE = *INSTALLED(...)
Der Name der Informationsdatei muss durch den Aufruf von IMON-GPN (Verwaltung von Installationspfaden) bestimmt werden.
Wird eine der Nebenkomponenten mit einem logischen Namen angesprochen, müssen bei allen zu diesem Subsystem gehörenden Nebenkomponenten logische Namen angegeben werden. Wird ein logischer Name vergeben, muss beim Operanden INSTALLATION-UNIT ein Wert ungleich *NONE vergeben werden.
LOGICAL-ID = <filename 1..30 without-catid-userid-gen-vers>
Logischer Name der Informationsdatei.
DEFAULT-NAME =
Name der Informationsdatei bei Nichtverfügbarkeit von IMON-GPN oder wenn der logische Name unbekannt ist.
DEFAULT-NAME = <filename 1..54 without-gen-vers>
Es wird ein neuer Name vergeben.
DEFAULT-NAME = *NONE
Es wird ein neuer Name vergeben.
SUBSYSTEM-INFO-FILE = <filename 1..54 without-gen-vers>
Vollqualifizierter Name der Informationsdatei. Der Name wird automatisch an die Aktivierungs- und Deaktivierungsroutinen (Operanden INIT-/DEINIT-/CLOSE-CTRL-ROUTINE) übergeben, wenn diese aufgerufen werden.
SYNTAX-FILE =
Bestimmt, ob eine Syntaxdatei mit dem Subsystem verknüpft ist, die beim Laden des Subsystems automatisch aktiviert wird. Für Subsysteme, die mit dem Startattribut MANDATORY-AT-STARTUP definiert werden, ist im Operanden RELATED-SUBSYSTEM eine Abhängigkeitsbeziehung zum Subsystem SDF zu deklarieren.
SYNTAX-FILE = *NO
Es soll keine Syntaxdatei aktiviert werden. Dieser Wert ist verpflichtend für alle Subsysteme, die mit dem Startzeitpunkt BEFORE-DSSM-LOAD oder AT-DSSM-LOAD definiert werden (siehe auch Operand CREATION-TIME), da zu diesem Zeitpunkt noch keine Syntaxdatei aktiviert werden kann.
SYNTAX-FILE = *INSTALLED(...)
Der Name der Syntaxdatei muss durch den Aufruf von IMON-GPN (Verwaltung von Installationspfaden) bestimmt werden.
Wird eine der Nebenkomponenten mit einem logischen Namen angesprochen, müssen bei allen zu diesem Subsystem gehörenden Nebenkomponenten logische Namen angegeben werden. Wird ein logischer Name vergeben, muss beim Operanden INSTALLATION-UNIT ein Wert ungleich *NONE vergeben werden.
LOGICAL-ID = <filename 1..30 without-catid-userid-gen-vers>
Logischer Name der Syntaxdatei.
DEFAULT-NAME =
Name der Syntaxdatei bei Nichtverfügbarkeit von IMON-GPN oder wenn der logische Name unbekannt ist.
DEFAULT-NAME = <filename 1..54 without-gen-vers>
Es wird ein neuer Name vergeben.
DEFAULT-NAME = *NONE
Es wird kein neuer Name vergeben.
SYNTAX-FILE = <filename 1..54 without-gen-vers>
Vollqualifizierter Name der Syntaxdatei, die beim Laden des Subsystems automatisch aktiviert werden soll.
DYNAMIC-CHECK-ENTRY =
Vereinbart, ob eine dynamische Identitätsprüfung des Subsystems vorgenommen werden soll. Zu diesem Zweck muss eine Einsprungstelle angegeben werden, an der sowohl der Subsystemname (acht Zeichen) als auch die Versionsnummer (vier bzw. sieben Zeichen) stehen muss. DSSM prüft, ob die bei der Definition vergebene Identifikation mit dem geladenen Subsystem übereinstimmt.
DYNAMIC-CHECK-ENTRY = *STD
Es soll gelten, dass die bei dem Operanden LINK-ENTRY spezifizierte Einsprungstelle für die Identitätsprüfung herangezogen werden soll.
DYNAMIC-CHECK-ENTRY = *NO
Eine Überprüfung soll nicht stattfinden. Dieser Operandenwert darf allerdings für solche Subsysteme, die vor der Aktivierung von DSSM geladen sein sollen (CREATION-TIME=*BEFORE-DSSM-LOAD), nicht verwendet werden.
DYNAMIC-CHECK-ENTRY = <text 1..8 without-sep>
Name der Einsprungstelle, die für die Identitätsprüfung herangezogen werden soll.
CREATION-TIME =
Legt den Zeitpunkt fest, an dem die Aktivierung des Subsystems (CREATE-Routine) angestoßen wird.
Während der Systemeinleitung sind zwei Phasen zu unterscheiden, in denen DSSM nach Aufruf durch die Startup-Routine die Steuerung der Systemeinleitung übernimmt:
Phase 1: | Der DSSM-Code wird geladen, die DSSM-Task generiert und gestartet. Die Task reserviert Klasse-5-Speicher, liest den Subsystemkatalog ein und startet die Subsysteme, Nach dem Laden dieser Subsysteme geht die Steuerung der Systemeinleitung an die Startup-Routine zurück. |
Phase 2: | Nach erneutem Aufruf werden alle Subsysteme geladen, die mit den Startattributen MANDATORY-AT-STARTUP, BEFORE-SYSTEM-READY und AFTER-SYSTEM-READY definiert wurden. Die Steuerung der Systemeinleitung geht an die Startup-Routine zurück. |
Sollen verschiedene Versionen eines Subsystems definiert werden, können die Startattribute, die für die Phasen 1 und 2 der Systemeinleitung vorgesehen sind, nur für eine dieser Versionen vergeben werden.
CREATION-TIME = *AT-CREATION-REQUEST
Das Subsystem muss explizit mit dem Kommando START-SUBSYSTEM geladen werden.
CREATION-TIME = *AT-SUBSYSTEM-CALL(...)
Das Subsystem soll automatisch beim ersten SVC- oder ISL-Aufruf geladen werden. Dieser Operandenwert ist reserviert für Subsysteme, die über SVC oder ISL aufgerufen werden.
Sind mehrere Versionen eines Subsystems mit diesem Operandenwert definiert, muss für alle diese Versionen VERSION-COEXISTENCE=*ALLOWED angegeben werden sowie FUNCTION-NUMBER und FUNCTION-VERSION für ihre SVC- bzw. ISL-Einsprungstellen, die mit CONNECTION-ACCESS ungleich *SIH deklariert wurden.
Mindestens eines der angegebenen Subsysteme muss mit SUBSYSTEM-ENTRIES ...,MODE=*SVC oder *ISL deklariert worden sein (übereinstimmend mit dem Wert des Operanden ON-ACTION).
ON-ACTION =
Bestimmt, wodurch das automatische Laden des Subsystems veranlasst wird.
ON-ACTION = *STD
Voreinstellung: das Laden beginnt beim Aufruf einer beliebigen, zum Subsystem gehörenden SVC-Einsprungstelle.
ON-ACTION = *ISL-CALL
Das Laden beginnt beim Aufruf einer beliebigen, zum Subsystem gehörenden ISL-Einsprungstelle.
ON-ACTION = *ANY
Das Laden beginnt beim Aufruf einer beliebigen, zum Subsystem gehörenden SVC- oder ISL-Einsprungstelle.
CREATION-TIME = *AT-DSSM-LOAD
Das Subsystem soll während der Systemeinleitung (Phase 1) unter der Kontrolle der DSSM-Task geladen werden.
Das Subsystem muss privilegiert sein und darf nur Adress- oder Abhängigkeitsbeziehungen zu Subsystemen aufweisen, die ebenfalls mit diesem Startattribut definiert sind oder das Startattribut BEFORE-DSSM-LOAD besitzen.
Die Dateien für dieses Subsystem müssen unter der Benutzerkennung TSOS auf dem Home-Pubset angelegt sein, da zum Startzeitpunkt weder der Benutzerkatalog zugreifbar, noch die IMPORT-PUBSET-Verarbeitung abgeschlossen ist.
Für diese Subsysteme ist das Einbinden einer Syntaxdatei nicht zulässig.
CREATION-TIME = *BEFORE-DSSM-LOAD
Das Subsystem soll während der Systemeinleitung (Phase 1), aber nicht unter der Kontrolle der DSSM-Task geladen werden.
Solche Subsysteme sind mit dem Organisationsprogramm verknüpft und brauchen - bei der Aktivierung - nicht mit der DSSM-Task synchronisiert werden. Nach dem Laden des Subsystems läuft dieses allerdings wieder unter der Kontrolle von DSSM und kann aus Sicht des Anwenders wie andere Subsysteme gesteuert werden.
Adress- oder Abhängigkeitsbeziehungen zu Subsystemen, die mit einem anderen Startattribut definiert wurden, sind nicht möglich. Auch die Einbindung einer Meldungs- oder Syntaxdatei ist nicht zulässig. Alle Auftragseingänge (Operand SUBSYSTEM-ENTRIES) müssen deklariert sein, da DSSM die (privilegierte) Verbindung zu diesen Auftragseingängen herstellt. Es liegt in der Verantwortung des Subsystem-Entwicklers, sicherzustellen, dass zu jedem Zeitpunkt mindestens eine Version dieses Subsystems verfügbar ist.
Der Name des Link-Kontextes für diese Subsysteme muss eindeutig sein, da DSSM eine Entlade-Anforderung erfüllen muss, selbst wenn DSSM den Subsystem-Code nicht geladen hat. Eine Einsprungstelle (Operand DYNAMIC-CHECK-ENTRY) muss angegeben sein.
CREATION-TIME = *BEFORE-SYSTEM-READY
Das Subsystem soll während der Systemeinleitung (Phase 2) geladen werden. Die Aktivierung wird synchron angestoßen; die Steuerung geht erst nach dem vollständigen Laden (oder nach Lade-Fehler) an die Startup-Routine zurück, die dann „SYSTEM READY“ melden kann.
Das Subsystem muss privilegiert sein und darf nur Adress- oder Abhängigkeitsbeziehungen zu Subsystemen aufweisen, die mit dem gleichen oder den Startattributen BEFORE-DSSM-LOAD, AT-DSSM-LOAD oder MANDATORY-AT-STARTUP definiert wurden.
Die Dateien für dieses Subsystem müssen auf dem Home-Pubset katalogisiert sein.
Wird ein nicht-privilegiertes Subsystem mit diesem Operandenwert deklariert, bekommt es implizit den Wert *AFTER-SYSTEM-READY zugewiesen. SSCM gibt eine Meldung aus.
CREATION-TIME = *MANDATORY-AT-STARTUP
Das Subsystem muss während der Systemeinleitung (Phase 2) geladen werden. Die Aktivierung wird - wie bei BEFORE-SYSTEM-READY - synchron angestoßen. Im Unterschied zum oben genannten muss das Laden des Subsystems allerdings erfolgreich abgeschlossen werden. Andernfalls geht eine Meldung an die Startup-Routine, dass ein verpflichtendes Subsystem nicht geladen werden konnte. Die Startup-Routine entscheidet in diesem Fall, ob die Verarbeitung fortgesetzt oder abgebrochen wird.
Das Subsystem muss privilegiert sein und darf nur Adress- oder Abhängigkeitsbeziehungen zu Subsystemen aufweisen, die mit dem gleichen oder den Startattributen BEFORE-DSSM-LOAD oder AT-DSSM-LOAD definiert wurden. Die Dateien für dieses Subsystem müssen auf dem Home-Pubset liegen.
CREATION-TIME = *AFTER-SYSTEM-READY
Das Laden des Subsystems wird während der Systemeinleitung (Phase 2) angestoßen. Die Durchführung dieses Auftrags wird nicht mit der Startup-Routine synchronisiert, die vor dem Abschluss des Ladens „SYSTEM READY“ melden kann.
Das Subsystem darf nur Adress- oder Abhängigkeitsbeziehungen zu Subsystemen aufweisen, die mit dem gleichen oder den Startattributen BEFORE-DSSM-LOAD, AT-DSSM-LOAD, MANDATORY-AT-STARTUP oder BEFORE-SYSTEM-READY definiert wurden. Die Dateien für dieses Subsystem müssen auf dem Home-Pubset liegen.
INIT-ROUTINE =
Legt fest, ob eine Initialisierungsroutine für das Subsystem durchlaufen werden soll, wenn es gestartet oder fortgesetzt wird. In diesem Fall muss der Name einer Einsprungstelle bekannt sein und DSSM delegiert die Initialisierung an die Holdertask des betreffenden Subsystems.
Für alle Subsysteme mit dem Startattribut BEFORE-DSSM-LOAD wird die Angabe einer Einsprungstelle unbedingt empfohlen. Beim Laden des Subsystems (d.h. dem Durchlaufen der Initialisierungsroutine) erhält dieses dann Kenntnis davon, dass DSSM die Kontrolle über Anschluss und Abbau von Beziehungen übernehmen kann.
INIT-ROUTINE = *NO
Es soll keine Initialisierungsroutine durchlaufen werden.
INIT-ROUTINE = <text 1..8 without-sep>
Name der Einsprungstelle der Initialisierungsroutine.
Der Initialisierungsroutine wird in der Holdertask die Steuerung übergeben, damit sich das Subsystem initialisieren kann. Dazu werden ihr übergeben:
der Name und die Version des Subsystems, wie im SSMCAT definiert
der Name der SSINFO-Datei, falls dieser im Operanden SUBSYSTEM-INFO-FILE spezifiziert wurde
die Adresse der beim Laden und Binden angegebenen Einsprungstelle (LINK-ENTRY)
der vom Dynamischen Bindelader verwendete Binder-Kontext-Name
der Name des Memory-Pools (für Subsysteme im Klasse-5- oder Klasse-6-Speicher), damit sich das Subsystem beim Nachladen eigener Selectable Units/Load Units darauf beziehen kann
der Name der Meldungsdatei
die Adresse des Operanden SUBSYSTEM-PARAMETER, falls im Kommando START-SUBSYSTEM ein String angegeben wird
Am Ende der Initialisierung wird eine Rückmeldung des Subsystems erwartet, ob die Initialisierung erfolgreich durchgeführt wurde und ob die Holdertask als Arbeitstask genutzt werden soll (wird in der Anweisung ASSIGN-HOLDER-TASK vereinbart). Abhängig davon steht die Task dann weiter unter DSSM-Kontrolle oder unter Kontrolle des Subsystems.
CLOSE-CTRL-ROUTINE =
Legt fest, ob eine Routine in das Subsystem eingebunden ist, die das Anhalten/Deaktivieren des Subsystems steuert.
Wird ein Subsystem (mit STOP-SUBSYSTEM oder HOLD-SUBSYSTEM) deaktiviert, so erhält es von DSSM in der Holdertask an der bezeichneten Einsprungstelle die Kontrolle oder es wird (bei *DYNAMIC) über Börsen- bzw. FITC-Linkage benachrichtigt (gesteuert von Rückmeldungen bei der Initialisierung).
Die übergebenen Parameter sind die gleichen wie bei INIT-ROUTINE. Beim Ansprung dieser Routine wird sichergestellt, dass noch Verbindung zum Subsystem besteht.
Existiert eine CLOSE-CTRL-Routine, tritt bei einem Versionswechsel während der BS2000-Session keine Unterbrechung auf. Es existiert zu jedem Zeitpunkt genau eine gültige Version (entweder die alte Version ist noch verfügbar oder die neue Version ist bereits verfügbar). Ohne eine solche Routine beinhaltet ein Versionswechsel immer eine Anschlussunterbrechung, während die STOPCOM-Routine der alten Version und die INIT-Routine der neuen Version ablaufen (siehe dazu auch "Austausch von Subsystemversionen").
CLOSE-CTRL-ROUTINE = *NO
Im betreffenden Subsystem ist keine Routine verankert, die das Deaktivieren oder Anhalten des Subsystems steuert.
CLOSE-CTRL-ROUTINE = *DYNAMIC
Der Aufruf dieser Routine erfolgt über Börse oder FITC-Port. Die notwendigen Parameter werden vom Subsystem am Ende der INIT-Routine dynamisch an die CLOSE-CTRL-Routine übergeben und DSSM über die Identifikation der Börse bzw. FITC-Ports in Kenntnis gesetzt.
Voraussetzung für die Nutzung der CLOSE-CTRL-Routine sind die Angabe einer INIT-Routine (Operand INIT-ROUTINE) und einer STOPCOM-Routine (Operand STOPCOM-ROUTINE= *NO/*DYNAMIC).
Beim Aufruf der CLOSE-CTRL-Routine muss die Holdertask des Subsystems als Arbeitstask genutzt werden (Anweisung ASSIGN-HOLDER-TASK).
CLOSE-CTRL-ROUTINE = <text 1..8 without-sep>
Name der Einsprungstelle der betreffenden Subsystemroutine.
STOPCOM-ROUTINE =
Legt fest, ob eine Routine in das Subsystem eingebunden ist, die das aktive Beenden der Aufträge durchführen kann.
STOPCOM-ROUTINE = *NO
Im betreffenden Subsystem ist keine Routine verankert.
STOPCOM-ROUTINE = *DYNAMIC
Der Aufruf dieser Routine erfolgt über Börse oder FITC. Die notwendigen Parameter werden vom Subsystem am Ende der CLOSE-CTRL-Routine oder (wenn eine solche nicht vorhanden ist) am Ende der INIT-Routine dynamisch an die STOPCOM-Routine übergeben. DSSM wird über die Identifikation der Börse bzw. FITC-Ports in Kenntnis gesetzt.Voraussetzung für die Nutzung der STOPCOM-Routine ist die Angabe einer INIT-Routine (Operand INIT-ROUTINE). Beim Aufruf der STOPCOM-Routine muss die Holdertask des Subsystems als Arbeitstask genutzt werden (siehe ASSIGN-HOLDER-TASK).
STOPCOM-ROUTINE = <text 1..8 without-sep>
Name der Einsprungstelle der betreffenden Subsystemroutine.
DEINIT-ROUTINE =
Legt fest, ob eine Routine in das Subsystem eingebunden ist, die die Deinitialisierung des Subsystems durchführen kann. Diese Deinitialisierungsroutine realisiert die Rückgabe der vom Subsystem angeforderten Betriebsmittel (Speicher, Dateien, Geräte).
Wird ein Subsystem (mit STOP-SUBSYSTEM oder HOLD-SUBSYSTEM) deaktiviert, so erhält es von DSSM in der Holdertask an der bezeichneten Einsprungstelle die Kontrolle oder es wird (bei *DYNAMIC) über Börsen- bzw. FITC-Linkage benachrichtigt (gesteuert von Rückmeldungen bei der Initialisierung).
Wird ein Subsystem mit einer INIT- und einer CLOSE-CTRL-Routine definiert, muss eine DEINIT-Routine - mit dem gleichen Operandenwert wie die CLOSE-CTRL-Routine - angegeben werden. Die übergebenen Parameter sind die gleichen wie bei INIT-ROUTINE. Beim Ansprung dieser Routine ist sichergestellt, dass aufrufende Tasks nicht mehr an das Subsystem angeschlossen werden und alle vorhandenen Aufruf-Beziehungen gelöst werden.
DEINIT-ROUTINE = *NO
Im betreffenden Subsystem ist keine Deinitialisierungsroutine verankert, die die Rückgabe der Betriebsmittel veranlasst; diesen Part übernimmt DSSM selbst.
DEINIT-ROUTINE = *DYNAMIC
Der Aufruf dieser Routine erfolgt über Börse bzw. FITC.
Die notwendigen Parameter werden vom Subsystem am Ende der STOPCOM-Routine oder (wenn eine solche nicht vorhanden ist) am Ende der CLOSE-CTRL-Routine oder am Ende der INIT-Routine, wenn weder eine STOPCOM- noch eine CLOSE-CTRL-Routine eingebunden ist, dynamisch an die DEINIT-Routine übergeben. DSSM wird über die Identifikation der Börse bzw. des FITC-Ports in Kenntnis gesetzt.
Voraussetzung für die Nutzung der DEINIT-Routine ist die Angabe einer INIT-Routine (Operand INIT-ROUTINE). Beim Aufruf der DEINIT-Routine muss die Holdertask des Subsystems als Arbeitstask genutzt werden (Anweisung ASSIGN-HOLDER-TASK).
DEINIT-ROUTINE = <text 1..8 without-sep>
Name der Einsprungstelle der betreffenden Subsystemroutine.
STOP-AT-SHUTDOWN =
Legt fest, ob das Subsystem nach Beendigung der Benutzertasks bei Shutdown automatisch entladen werden soll.
STOP-AT-SHUTDOWN = *NO
Das Subsystem wird nicht automatisch entladen.
Die Angabe sollte nicht für Subsysteme verwendet werden, die Adressbeziehungen zu anderen Subsystemen besitzen, die mit STOP-AT-SHUTDOWN=*YES definiert sind.
STOP-AT-SHUTDOWN = *YES
Das Subsystem wird bei Shutdown automatisch entladen.
Diese Angabe wird ignoriert, wenn keine STOPCOM-, DEINIT- oder CLOSE-CTRL-Routine angegeben wird. SSCM gibt eine Meldung aus.
INTERFACE-VERSION =
Bezeichnet die Einsprungstelle, über die DSSM auf diejenige Schnittstellenversion zugreifen kann, die für den Aufruf der INIT-, DEINIT-, STOPCOM- oder CLOSE-CTRL-Routinen benutzt werden soll.
INTERFACE-VERSION = *NO
Das Subsystem ruft keine INIT-, DEINIT-, STOPCOM- oder CLOSE-CTRL-Routine auf.
INTERFACE-VERSION = <text 1..8 without-sep>
Name der Einsprungstelle. Die Einsprungstelle verweist auf den Standardheader, in dem u.a. auch die Schnittstellenversion hinterlegt ist. Der Standardheader wird durch den Aufruf des Makros $ESMINT(I) mit MF=I/L generiert.
Dieser Operand ist Pflicht für Subsysteme, für die eine INIT-, DEINIT-, STOPCOM- oder CLOSE-CTRL-Routine definiert wurde.
SUBSYSTEM-HOLD =
Legt fest, ob das geladene Subsystem angehalten oder entladen werden kann.
SUBSYSTEM-HOLD = *ALLOWED
Das geladene Subsystem kann angehalten und entladen werden. Die Kommandos HOLD-
SUBSYSTEM und STOP-SUBSYSTEM sind für dieses Subsystem zulässig.
SUBSYSTEM-HOLD = *FORBIDDEN
Die Kommandos HOLD-SUBSYSTEM und STOP-SUBSYSTEM sind für dieses Subsystem nicht zulässig; das Subsystem wird - entsprechend den Angaben im Operanden STOP-AT-
SHUTDOWN - bei Shutdown entladen. Wird das Subsystem durch Austausch mit einem anderen Subsystem entladen, so erfolgt der Austausch unterbrechungsfrei.
STATE-CHANGE-CMDS =
Legt fest, ob die DSSM-Kommandos zur Steuerung des Subsystems im laufenden Betrieb (START-SUBSYSTEM, STOP-SUBSYSTEM, HOLD-SUBSYSTEM, RESUME-SUBSYSTEM) verwendet werden dürfen.
Wird von einer Version eines Subsystems in eine andere gewechselt, wird der bei STATE-CHANGE-CMDS angegebene Wert für die auszuwechselnde Version nicht berücksichtigt.
STATE-CHANGE-CMDS = *ALLOWED
Die Kommandos dürfen an der Bedienstation und unter der privilegierten Benutzerkennung (Benutzerkennung, die mit dem Systemprivileg SUBSYSTEM-MANAGEMENT ausgestattet ist) verwendet werden.
STATE-CHANGE-CMDS = *FORBIDDEN
Die Kommandos dürfen generell nicht - weder an der Bedienstation noch unter der privilegierten Benutzerkennung - verwendet werden.
STATE-CHANGE-CMDS = *BY-ADMINISTRATOR-ONLY
Die Kommandos dürfen nur unter der privilegierten Benutzerkennung verwendet werden; für den Operator an der Bedienstation sind die Kommandos gesperrt.
Wird ein Subsystem (mit STOP-SUBSYSTEM oder HOLD-SUBSYSTEM) deaktiviert, so erhält es von DSSM in der Holdertask an der bezeichneten Einsprungstelle die Kontrolle oder es wird (bei *DYNAMIC) über Börsen- bzw. FITC-Linkage benachrichtigt (gesteuert von Rückmeldungen bei der Initialisierung).
Die übergebenen Parameter sind die gleichen wie bei INIT-ROUTINE. Beim Ansprung dieser Routine ist sichergestellt, dass aufrufende Tasks nicht mehr an das Subsystem angeschlossen werden. Tasks, die noch in Aufruf-Beziehung zum Subsystem stehen, bleiben davon unberührt.
FORCED-STATE-CHANGE =
Legt fest, ob innerhalb der Kommandos STOP-SUBSYSTEM und HOLD-SUBSYSTEM die Verwendung des Operanden FORCED=*YES zulässig ist. Mit dieser Funktion kann das unbedingte Deaktivieren des Subsystems erzwungen werden.
FORCED-STATE-CHANGE = *FORBIDDEN
Das Deaktivieren des Subsystems kann nicht erzwungen werden. DSSM weist die Verwendung des Operanden FORCED in den entsprechenden Kommandos mit einer Fehlermeldung zurück.
FORCED-STATE-CHANGE = * ALLOWED
Die Verwendung des Operanden FORCED=*YES für dieses Subsystem ist zulässig. Dieser Operandenwert darf nicht zusammen mit SUBSYSTEM-HOLD=*FORBIDDEN angegeben werden.
RESET =
Legt fest, ob innerhalb der Kommandos START-SUBSYSTEM und RESUME-SUBSYSTEM die Verwendung des Operanden RESET=*YES zulässig ist. Mit dieser Funktion kann das unbedingte Laden bzw. Fortsetzen des Subsystems erzwungen werden, auch wenn sich das Subsystem im Zustand IN-DELETE bzw. IN-HOLD befindet.
RESET = *FORBIDDEN
Das Aktivieren des Subsystems kann nicht erzwungen werden. DSSM weist die Verwendung des Operanden RESET in den entsprechenden Kommandos mit einer Fehlermeldung zurück.
RESET = *ALLOWED
Die Verwendung des Operanden RESET=*YES für dieses Subsystem ist zulässig.
Dieser Operandenwert darf nicht mit SUBSYSTEM-HOLD=*FORBIDDEN angegeben werden.
RESTART-REQUIRED =
Legt fest, ob bei abnormaler Beendigung der Holdertask die Initialisierungsroutine für das Subsystem durchlaufen werden soll.
RESTART-REQUIRED = *NO
Die Initialisierungsroutine wird für einen Wiederanlauf des Subsystems nicht benutzt.
RESTART-REQUIRED = *YES
Die Initialisierungsroutine soll bei abnormaler Beendigung der Holdertask benutzt werden. Voraussetzung ist, dass die Durchführung dieser Routine im Operanden INIT-ROUTINE vorgesehen ist.
VERSION-COEXISTENCE =
Vereinbart, ob mehr als eine Version des gleichen Subsystems gleichzeitig aktiv sein darf.
VERSION-COEXISTENCE = *FORBIDDEN
Die aktuelle Version des Subsystems kann nicht gleichzeitig mit einer anderen Version des gleichen Subsystems koexistieren.
VERSION-COEXISTENCE = *ALLOWED
Die aktuelle Version des Subsystems kann gleichzeitig mit einer anderen Version des gleichen Subsystems koexistieren (Coexistence-Modus).
Bei der Definition des Auftragseingangs (Operand SUBSYSTEM-ENTRIES) darf keine indirekte Verbindung über System-Exit-Routinen gewählt werden. Sind verschiedene Versionen des gleichen Subsystems geladen, die mit dem gleichen Auftragseingang definiert wurden, wird der Anschluss immer an die höchste geladene Version des Subsystems realisiert.
Greifen koexistente Subsysteme auf koexistente Syntaxdateien zu, müssen diese im SSD-Object deklariert sein und können nicht von SDF verwaltet werden.
Bei Anschlüssen über SVC und ISL ist jedoch eine Versionsauswahl über die Operanden FUNCTION-NUMBER und FUNCTION-VERSION möglich.
VERSION-EXCHANGE =
Vereinbart, ob das Laden der aktuellen Subsystemversion im Exchange-Modus erlaubt ist. Der Exchange-Modus erlaubt die temporäre Koexistenz zweier Versionen des gleichen Subsystems. Wird die Version B eines Subsystems geladen, wenn bereits Version A des Subsystems aktiv ist, werden alle neuen Aufrufer an die Version B angeschlossen. Die Aufträge, die an die Version A angeschlossen sind, werden noch bearbeitet. Nach Bearbeitung aller Aufträge an Version A wird diese automatisch beendet.
Bei der Definition ist darauf zu achten, dass die zu ersetzende, „alte“ Version nicht abhängig von der ersetzenden, „neuen“ Version sein darf.
VERSION-EXCHANGE = *FORBIDDEN
Die aktuelle Version des Subsystems darf nicht ausgetauscht werden.
VERSION-EXCHANGE = *ALLOWED
Der Exchange-Modus, der die temporäre Koexistenz zweier Subsysteme erlaubt, ist für die aktuelle Subsystemversion zulässig.
ADD-SUBS-ENTRIES / MODIFY-SUBS-ENTRIES =
Bezeichnet, ob neue Auftragseingänge definiert (ADD) oder die Charakteristiken vorhandener Auftragseingänge verändert (MODIFY) werden sollen.
ADD-SUBS-ENTRIES / MODIFY-SUBS-ENTRIES = *NONE
Voreinstellung: es sollen weder neue Auftragseingänge hinzukommen, noch die Eigenschaften vorhandener Auftragseingänge modifiziert werden.
ADD-SUBS-ENTRIES / MODIFY-SUBS-ENTRIES = list-poss(100): <text 1..8>
Vereinbart durch Angabe des Namens der Einsprungstelle entweder maximal 100 neue Auftragseingänge für das Subsystem, deren Typ jeweils in den Unterstrukturen definiert werden muss (ADD), oder modifiziert bereits definierte Auftragseingänge (MODIFY).
MODE =
Legt den Typ eines vereinbarten Auftragseingangs für das Subsystem fest.
Wird der Typ des vereinbarten Auftragseingangs verändert, müssen alle Unteroperanden von MODE explizit mit einem Wert versehen werden; der Operandenwert *UNCHANGED (Voreinstellung bei MODIFY-SUBS-ENTRIES) wird abgewiesen.
MODE = *LINK
Der Auftragseingang kann nicht über indirektes Linkage erreicht werden, sondern nur über eine CONNECT-Beziehung mittels eines externen Binder-Symbols.
Bei verschiedenen Versionen des gleichen Subsystems, die das gleiche externe Binder-Symbol nutzen, stellt DSSM automatisch den Anschluss an die höchste geladene Version des Subsystems her.
MODE = *ISL(...)
Der Auftragseingang wird durch indirekte Verbindung über System Procedure Linkage (nur für privilegierte Subsysteme) erreicht. Wird zusätzlich noch eine Funktions- und Versionsnummer der ISL-Einsprungstelle spezifiziert, darf sich die Kombination aus Name der Einsprungstelle, Funktions- und Versionsnummer nicht mit einer anderen Kombination für die verschiedenen Subsysteme eines Kataloges oder die verschiedenen Versionen des gleichen Subsystems (bei Angabe von VERSION-COEXISTENCE=*ALLOWED) decken.
Bei ungleichen Subsystemen, deren Auftragseingang über die selbe ISL-Einsprungstelle erreicht werden soll, muss zur eindeutigen Unterscheidung die Funktions- und Versionsnummer angegeben werden.
Bei verschiedenen Versionen des gleichen Subsystems, die die selbe ISL-Einsprungstelle nutzen (ohne Angaben zur Funktions- oder Versionsnummer), stellt DSSM automatisch den Anschluss an die höchste geladene Version des Subsystems her.
Bei verschiedenen Versionen des gleichen Subsystems, die die selbe ISL-Einsprungstelle nutzen und deren Funktions- und Versionsnummer ungleich *NONE ist, ist die Auswahl, an welche Version der Anschluss erfolgen soll, von der Funktions- und Versionsnummer abhängig, die im Standard Header der Parameterliste des Aufrufers hinterlegt ist. Die Angabe CONNECTION-ACCESS=*ALL ist für ISL-Einsprungstellen nicht zulässig.
FUNCTION-NUMBER =
Vereinbart, ob eine bestimmte Funktions- und Versionsnummer der ISL-Einsprungstelle angesprochen werden soll, da die gleiche ISL-Einsprungstelle von verschiedenen Funktionen genutzt werden kann.
FUNCTION-NUMBER = *NONE
Es soll keine bestimmte Funktions- oder Versionsnummer angesprochen werden.
FUNCTION-NUMBER = <integer 0..255>(...)
Nummer der ISL-Einsprungstelle. Die Version ist in der folgenden Unterstruktur zu benennen.
FUNCTION-VERSION = <integer 1..255>
Version der spezifizierten ISL-Funktionsnummer.
MODE = *SVC(...)
Der Auftragseingang wird durch indirekte Verbindung über Supervisor Call (SVC) erreicht.
Wird zusätzlich noch eine Funktions- und Versionsnummer der SVC-Einsprungstelle spezifiziert, darf sich die Kombination aus SVC-Nummer, Funktions- und Versionsnummer nicht mit einer anderen Kombination für die verschiedenen Subsysteme eines Kataloges oder die verschiedenen Versionen des gleichen Subsystems (bei Angabe von VERSION-COEXISTENCE=*ALLOWED) decken.
Bei ungleichen Subsystemen, deren Auftragseingang über den selben SVC erreicht werden soll, muss zur eindeutigen Unterscheidung die Funktions- und Versionsnummer angegeben werden.
Bei verschiedenen Versionen des gleichen Subsystems, die den selben SVC nutzen (ohne Angaben zur Funktions- oder Versionsnummer), stellt DSSM automatisch den Anschluss an die höchste geladene Version des Subsystems her.
Bei verschiedenen Versionen des gleichen Subsystems, die den selben SVC nutzen und deren Funktions- und Versionsnummer ungleich *NONE ist, ist die Auswahl, an welche Version der Anschluss erfolgen soll, von der Funktions- und Versionsnummer abhängig, die im Standard Header der Parameterliste des Aufrufers hinterlegt ist.
NUMBER = <integer 0..255>
Nummer des SVCs, über den der Auftragseingang erreicht wird. In Verbindung mit CONNECTION-ACCESS=*ALL ist die Verwendung einer SVC-Nummer größer 191 nicht zulässig.
CALL-BY-SYSTEM-EXIT =
Legt fest, ob die angegebene SVC-Nummer von System-Exit-Routinen aus aufgerufen werden darf.
CALL-BY-SYSTEM-EXIT = *ALLOWED
Der Aufruf der angegebenen SVC-Nummer ist für System-Exit-Routinen zulässig.
CALL-BY-SYSTEM-EXIT = *FORBIDDEN
Der Aufruf der angegebenen SVC-Nummer ist für System-Exit-Routinen nicht zulässig.
FUNCTION-NUMBER =
Vereinbart, ob eine bestimmte Funktions- und Versionsnummer der SVC-Einsprungstelle angesprochen werden soll, da die gleiche SVC-Einsprungstelle von verschiedenen Funktionen genutzt werden kann.
FUNCTION-NUMBER = *NONE
Es soll keine bestimmte Funktions- oder Versionsnummer angesprochen werden.
FUNCTION-NUMBER = <integer 0..255>(...)
Nummer der SVC-Einsprungstelle. Die Version ist in der folgenden Unterstruktur zu benennen.
FUNCTION-VERSION = <integer 1..255>
Version der spezifizierten SVC-Funktionsnummer.
MODE = SYSTEM-EXIT(...)
Der Auftragseingang wird durch indirekte Verbindung über System-Exit-Routinen erreicht.
In Verbindung mit CONNECTION-ACCESS=*ALL ist die Verwendung dieses Operanden nicht zulässig.
NUMBER = <integer 0..127>
Nummer der System-Exit-Routine.
CONNECTION-ACCESS =
Vereinbart die Zugriffsberechtigung (Privilegierung) für das Subsystem.
CONNECTION-ACCESS = *ALL
Privilegierte und nicht-privilegierte Programmläufe sind zugriffsberechtigt.
In Verbindung mit MODE=*SYSTEM-EXIT/*ISL/*SVC (mit einer SVC-Nummer größer 191) ist die Verwendung dieses Operandenwertes nicht zulässig.
CONNECTION-ACCESS = *SYSTEM
Nur privilegierte Programmläufe sind zugriffsberechtigt.
CONNECTION-ACCESS = *SIH
Nur Tasks, die im Funktionszustand SIH laufen, sind zugriffsberechtigt.
Das aufgerufene Subsystem läuft ebenfalls im Funktionszustand SIH, d.h. es ist nicht unterbrechbar.
Die Angabe dieses Operandenwertes ist nur für Subsysteme zulässig, deren Auftragseingang definiert wird über
System Procedure Linkage (MODE=*ISL(FUNCTION-NUMBER=*NONE))
CONNECTION-SCOPE=*OPTIMAL
MEMORY-CLASS=*SYSTEM-GLOBAL(SUBSYSTEM-ACCESS=*SYSTEM)
CONNECTION-SCOPE =
Bezeichnet das Ereignis, das die automatische Auflösung des Anschlusses an den angegebenen Subsystem-Auftragseingang hervorruft.
CONNECTION-SCOPE = *TASK
Der Anschluss wird bei Taskbeendigung aufgehoben.
CONNECTION-SCOPE = *PROGRAM
Der Anschluss wird spätestens bei Programmbeendigung aufgehoben. Zusammen mit MEMORY-CLASS=*LOCAL-UNPRIVILEGED darf nur CONNECTION-SCOPE=*PROGRAM angegeben werden.
Die Angabe dieses Operandenwertes wird für Subsysteme empfohlen, die mit SUBSYSTEM-ACCESS=*LOW/*HIGH oder MEMORY-CLASS=*BY-SLICE deklariert wurden.
CONNECTION-SCOPE = *FREE
DSSM soll keine Kontrolle von Anschlüssen zu diesen Auftragseingängen durchführen. Der Anschluss wird - außer bei einer expliziten Anforderung - nicht automatisch aufgelöst. Um Probleme oder mögliche Fehler beim Entladen des Subsystems zu vermeiden, müssen die Anschlüsse vom Subsystem selbst verwaltet werden.
CONNECTION-SCOPE = *CALL
Nach Rückkehr aus diesem Auftragseingang führt DSSM automatisch die Auflösung der Anschlüsse durch.
Dieser Operandenwert steht nur für Subsysteme zur Verfügung, deren Auftragseingang über System Procedure Linkage (ISL) und Supervisor Call (SVC) definiert wird.
CONNECTION-SCOPE = *OPTIMAL
Das Subsystem wird deaktiviert bzw. angehalten, wenn keine Task mehr Anschluss zu diesem Auftragseingang hat.
Eine Routine, deren Einsprungstelle mit *OPTIMAL definiert wird, muss mit RETURN beendet werden.
Wird ein Auftragseingang eines Subsystems mit CONNECTION-SCOPE=*OPTIMAL definiert, müssen alle seine Auftragseingänge im Subsystemkatalog mit MODE!=*LINK definiert werden.
Während ein Subsystem deaktiviert oder angehalten wird, wird kein Aufruf des Subsystems mit CONNECTION-SCOPE=*OPTIMAL akzeptiert.
FIRST-CONNECTION =
Bestimmt, ob der Erst-Anschluss der Task an den angegebenen Auftragseingang des Subsystems erlaubt ist. Mindestens ein Auftragseingang eines Subsystems muss mit FIRST-CONNECTION=*ALLOWED definiert werden.
FIRST-CONNECTION = *ALLOWED
Der Erst-Anschluss an den angegebenen Auftragseingang ist erlaubt.
Für die Anweisung ADD-SUBS-ENTRIES ist dieser Wert die Voreinstellung.
FIRST-CONNECTION = *FORBIDDEN
Der Anschluss an den angegebenen Auftragseingang über SVC oder ISL ist nicht erlaubt, wenn die Task nicht bereits an einen anderen Auftragseingang des Subsystems angeschlossen ist.
Die Angabe dieses Operandenwertes ist für Auftragseingänge, die mit MODE=*LINK/*SYSTEM-EXIT oder CONNECTION-ACCESS=*SIH definiert wurden, nicht erlaubt.
MODIFY-SUBS-ENTRIES = *NONE / list-poss(100): <text 1..8> / *BY-PROGRAM(...)
Die Werte *NONE und list-poss(100): <text 1..8> sind beim Operanden ADD-SUBS-ENTRIES beschrieben.
MODIFY-SUBS-ENTRIES = *BY-PROGRAM(...)
Die Einsprungstellen des angegebenen Subsystems werden nicht statisch aus dem Katalog versorgt, sondern dynamisch zum Ladezeitpunkt aus dem BLS-Namensverzeichnis. Voraussetzung für diese Funktionalität ist der Einsatz von BLSSERV ab Version 2.1, das den Einsatz von EEN-Namen als Einsprungstellen für DSSM-Subsysteme unterstützt.
Die Anweisung wird zurückgewiesen, wenn das Subsystem nicht zuvor bei der Anweisung SET-SUBSYSTEM-ATTRIBUTES auch mit *BY-PROGRAM definiert wurde. MODIFY-SUBS-ENTRIES dient nur zum Ändern der Anschluss-Einstellungen.
Wird *BY-PROGRAM verwendet, müssen die Operanden ADD-SUBS-ENTRIES und REMOVE-SUBS-ENTRIES mit *NONE angegeben werden.
CONNECTION-SCOPE = *TASK / *PROGRAM
Der Anschluss wird bei Task- bzw. Programmbeendigung aufgehoben.
REMOVE-SUBS-ENTRIES =
Bestimmt, ob vorhandene Auftragseingänge, die für das Subsystem vereinbart sind, gelöscht werden sollen.
REMOVE-SUBS-ENTRIES = *NONE
Voreinstellung: Es sollen keine Auftragseingänge gelöscht werden.
REMOVE-SUBS-ENTRIES = list-poss(100): <text 1..8>
Gibt die Namen von maximal 100 Auftragseingängen an, die für das Subsystem nicht mehr gelten sollen.
MEMORY-CLASS =
Vereinbart den subsystemspezifischen Adressraum, in den das Subsystem geladen werden soll. Mit diesem Operanden kann die Systembetreuung die Adressraumvorgaben, die für das jeweilige Subsystem gelten, den speziellen Anforderungen der Installation anpassen.
Wird der subsystemspezifische Adressraum verändert, müssen alle Unteroperanden von
MEMORY explizit mit einem Wert versehen werden (der Operandenwert *UNCHANGED (Voreinstellung) wird abgewiesen).
MEMORY-CLASS = *SYSTEM-GLOBAL(...)
Das Subsystem wird in den Klasse-3- oder Klasse-4-Speicher geladen. Residente CSECTs erhalten Klasse-3-Speicher, alle anderen erhalten seitenwechselbaren Klasse-4-Speicher.
SUBSYSTEM-ACCESS =
Bezeichnet die Zugriffsrechte (Privilegierung) und die Lage des angeforderten Speichers.
SUBSYSTEM-ACCESS = *LOW
Es wird nicht-privilegierter Adressraum unterhalb der 16 MByte-Grenze zugewiesen.
SUBSYSTEM-ACCESS = *SYSTEM
Subsysteme, die mit diesem Operandenwert deklariert werden, sind privilegierte Subsysteme, denen privilegierter Adressraum oberhalb der 16 MByte-Grenze zugewiesen wird.
Die Angabe dieses Operandenwertes ist für die Subsysteme verpflichtend, deren Auftragseingang über SVC (MODE=*SVC), oder für die eine INIT-, STOPCOM-, DEINIT- oder CLOSE-CTRL-Routine vereinbart wird.
Der Operandenwert ist unzulässig in Kombination mit CONNECTION-ACCESS=*ALL und MODE=*LINK.
SUBSYSTEM-ACCESS = *HIGH
Es wird nicht-privilegierter Adressraum bis zu 2 GByte zugewiesen.
MEMORY-CLASS = *LOCAL-PRIVILEGED(...)
Das Subsystem erhält einen Memory Pool im nicht-privilegierten Klasse-5-Speicher, der unterhalb der 16 MByte-Grenze angelegt wird.
Die Angabe ist auf nicht-privilegierte Subsysteme zugeschnitten, die relativ viel Adressraum (+/- 1 MByte) beanspruchen und unterhalb der 16 MByte-Grenze anzulegen sind. Die Subsysteme werden in Memory Pools an der gleichen Adresse geladen, um mit dem knapp bemessenen Adressraum unterhalb 16 MByte zu haushalten.
Obwohl solche Subsysteme parallel im gleichen Adressraum geladen werden, können sie nicht simultan von einer Task genutzt werden (siehe auch Anweisung SEPARATE-ADDRESS-SPACE).
Das Subsystem darf keine residenten CSECTs enthalten, da ansonsten ein späteres Aktivieren abgebrochen wird.
SIZE = <integer 1..32767>
Größe des benötigten Adressraums (in 4KByte-Seiten) für den Memory Pool im Klasse-5-Speicher. Der Wert ist mindestens so groß zu wählen, dass das Subsystem und evtl. von diesem nachgeladene Selectable Units/Load Units in vollem Umfang geladen werden können. Die obere Grenze ist generierungsabhängig.
MEMORY-CLASS = *LOCAL-UNPRIVILEGED(...)
Das Subsystem erhält einen Memory Pool im nicht-privilegierten Klasse-6-Speicher. Die Angabe ist für Subsysteme reserviert, die wie ein Programm ausführbar sind. Analog dazu muss deren Zugriffsberechtigung (Privilegierung) im Operanden CONNECTION-ACCESS mit dem Wert *ALL definiert werden.
Dieser Operandenwert darf nicht zusammen mit einer Einsprungstelle angegeben werden, die mit CONNECTION-ACCESS=*SYSTEM definiert wurde.
Das Subsystem darf keine residenten CSECTs enthalten, da ansonsten ein späteres Aktivieren abgebrochen wird.
Wird dieser Operandenwert angegeben, ist zur Auflösung des Anschlusses an den angegebenen Subsystem-Auftragseingang nur CONNECTION-SCOPE=*PROGRAM erlaubt.
SIZE = <integer 1..32767>
Größe des benötigten Adressraums (in 4KByte-Seiten) für den Memory Pool im Klasse-6-Speicher. Der Wert ist mindestens so groß zu wählen, dass das Subsystem und evtl. von diesem nachgeladene Selectable Units/Load Units in vollem Umfang geladen werden können. Die obere Grenze ist generierungsabhängig.
SUBSYSTEM-ACCESS =
Bezeichnet die Lage des angeforderten Speichers.
SUBSYSTEM-ACCESS = *LOW
Es wird nicht-privilegierter Adressraum unterhalb der 16 MByte-Grenze zugewiesen.Da diese Angabe auf Subsysteme zugeschnitten ist, die wie Programme ausführbar sind, ist die zusätzliche Angabe CONNECTION-SCOPE=*PROGRAM anzuraten.
SUBSYSTEM-ACCESS = *HIGH
Es wird nicht-privilegierter Adressraum bis zu 2 GByte zugewiesen.
Da diese Angabe auf Subsysteme zugeschnitten ist, die wie Programme ausführbar sind, ist die zusätzliche Angabe CONNECTION-SCOPE=*PROGRAM anzuraten.
START-ADDRESS =
Legt die Anfangsadresse im Klasse-6-Speicher fest.
START-ADDRESS = *ANY
Die Lage des Subsystems im Klasse-6-Speicher wird von DSSM festgelegt.
START-ADDRESS = <x-string 7..8>
Start-Adresse im Segment-Raster, an der die Anfangsadresse des Subsystems liegen soll. Als Wert ist eine 8-stellige Hexadezimalkonstante anzugeben, die ein Vielfaches von X'100000' sein muss.
MEMORY-CLASS = *BY-SLICE(...)
Das angegebene Subsystem ist ein nicht-privilegiertes Subsystem und besteht aus einem LLM, das aus einem mehrbenutzbaren Code (Programmbereich) und einem nichtmehrbenutzbaren Code (Datenbereich) besteht.
Der Programmbereich wird in den gemeinsam benutzbaren Adressraum geladen (das entspricht MEMORY-CLASS=*SYSTEM-GLOBAL). Der Datenbereich wird in den Benutzeradressraum der Holdertask geladen und in die privaten Benutzeradressräume der angeschlossenen Tasks an die selbe Adresse kopiert.
Gemeinsam mit MEMORY-CLASS=*BY-SLICE müssen folgende Werte angegeben werden:
SUBSYSTEM-LOAD-MODE=*ADVANCED und CONNECTION-ACCESS=*ALL.
SIZE = <integer 1..32767>
Größe des angeforderten Speicherplatzes für den Datenbereich in 4K-Seiten.
Der Wert ist mindestens so groß zu wählen, dass der Datenbereich und evtl. vom Subsystem in den Benutzeradressraum nachzuladende Selectable Units/Load Units in vollem Umfang geladen werden können. Die obere Grenze ist generierungsabhängig.
LINK-ENTRY = <text 1..8 without-sep>(...)
Definiert den Namen des zum Laden benötigten Bindemoduls/ENTRY/CSECT (als Operand im Makroaufruf $PBBND1 an den dynamischen Bindelader DBL). Das Subsystem muss von diesem ENTRY vollständig (ggf. per Autolink) geladen werden.
AUTOLINK =
Steuert den Aufruf der Autolink-Funktion beim Binden und Laden.
Die Autolink-Funktion des Binders ermöglicht das automatische Einfügen von Modulen, die nicht mit entsprechenden Anweisungen explizit eingefügt werden. Die Funktion erspart vor allem den Benutzern der höheren Programmiersprachen, die zahlreich benötigten Module des Laufzeitsystems (= Run Time System) mit expliziten Anweisungen einzeln einzufügen. Ein nähere Beschreibung der Autolink-Funktion ist im Handbuch „BLSSERV“ [4] zu finden.
Die Autolink-Funktion kann auch implizit umgangen werden, wenn während des Bindens des zu ladenden Objektmoduls der erste Externverweis auf ein vorgebundenes Großmodul zielt. Der Vorteil dieser Vorgehensweise ergibt sich daraus, dass das Seitenwechselverhalten bei der späteren Ausführung bereits im Vorfeld (während des Bindens) optimiert werden kann. Zudem können Fehler während des Bindens auf diese Weise vermieden werden.
AUTOLINK = *ALLOWED
Die Autolink-Funktion wird zugelassen.
AUTOLINK = *FORBIDDEN
Die Autolink-Funktion wird unterdrückt.
ADD-REFER-SUBS / MODIFY-REFER-SUBS =
Legt fest, ob entweder eine Liste von Subsystemen anzulegen ist, zu denen Adressbeziehungen bestehen und die zur Auflösung von Externverweisen benutzt werden sollen (ADD), oder ob eine bereits bestehende Liste existiert, die zu verändern ist (MODIFY).
ADD-REFER-SUBS / MODIFY-REFER-SUBS = *NONE
Voreinstellung: es soll weder eine Liste angelegt, noch eine bereits bestehende Liste verändert werden.
ADD-REFER-SUBS / MODIFY-REFER-SUBS = list-poss(15):<structured-name 1..8>
Es sollen Externverweise angegeben (ADD) bzw. modifiziert (MODIFY) werden.
Es können Externverweise auf maximal 15 andere Subsysteme benannt werden, die zur Auflösung dieser Externverweise benutzt werden müssen. Fehlt eines der hier genannten Subsysteme beim Aktivieren oder Deaktivieren (und ist gleichzeitig eine Überprüfung der Externverweise mit dem Operanden CHECK-REFERENCE=*YES angefordert), wird die Aktion abgebrochen.
Auch das „Basis-Subsystem“ des BS2000, das Control Program, kann über diese Externverweise - mit dem Namen CP - angesprochen werden. Es kann in der folgenden Unterstruktur sowohl genau eine Version spezifiziert werden, als auch ein Bereich von Versionen angegeben werden, innerhalb dessen alle Versionen herangezogen werden sollen.
Wird die Version des Subsystems CP über eine Versionsbereichsliste eingegrenzt, prüft DSSM die Kompatibilität zwischen der aktuellen CP-Version und Versionen in der Bereichsliste. Nur wenn die Versionen kompatibel sind, wird das Subsystem geladen.
Auf folgende Einschränkungen bei der Angabe von Subsystemen, zu denen Adressbeziehungen bestehen, ist zu achten:
- Es dürfen keine Adressbeziehungen zu Subsystemen vereinbart werden, die das Attribut MEMORY-CLASS=*LOCAL-PRIVILEGED/*LOCAL-UNPRIVILEGED/*BY-SLICE besitzen.
Ist für das zu definierende Subsystem das Attribut SUBSYSTEM-ACCESS=*SYSTEM vergeben, dürfen keine Subsysteme angesprochen werden, die mit SUBSYSTEM-ACCESS=*LOW bzw. *HIGH definiert sind.
Subsysteme, die das Attribut STOP-AT-SHUTDOWN=*YES besitzen, dürfen Adressbeziehungen nur zu solchen Subsystemen aufweisen, die ebenfalls dieses Attribut besitzen.
Ein nicht-privilegiertes Subsystem darf generell keine Adressbeziehung zum Control Program CP aufweisen.
Wird auf ein Subsystem verwiesen, das zumindest eine Version besitzt, die im Coexistence- oder Exchange-Modus betrieben werden darf, ist die eindeutige Version anzugeben.
Die Adressbeziehungen müssen in Abhängigkeit der Startattribute (Operand CREATION-TIME) definiert werden, d.h. Subsysteme dürfen Beziehungen nur zu solchen Subsystemen aufnehmen, deren Start zeitgleich oder früher erfolgt.
LOWEST-VERSION =
Spezifiziert den unteren Wert (niedrigste Version) innerhalb der Versionsbereichsliste der Subsysteme.
LOWEST-VERSION = *LOWEST-EXISTING
Die niedrigste Version im Katalog soll angesprochen werden.
LOWEST-VERSION = <c-string 3..8> / <text 3..8>
Version eines Subsystems, die als Untergrenze des Versionsbereiches fungieren soll.
HIGHEST-VERSION =
Spezifiziert den oberen Wert (höchste Version) innerhalb der Versionsbereichsliste der Subsysteme.
HIGHEST-VERSION = *HIGHEST-EXISTING
Die höchste Version im Katalog soll angesprochen werden.
HIGHEST-VERSION = <c-string 3..8> / <text 3..8>
Version eines Subsystems, die als Obergrenze des Versionsbereiches fungieren soll.
MODIFY-REFER-SUBS =
Siehe Beschreibung bei ADD-REFER-SUBS.
REMOVE-REFER-SUBS =
Bestimmt, ob bestehende Externverweise auf andere Subsysteme gelöscht werden sollen.
REMOVE-REFER-SUBS = *NONE
Voreinstellung: Es sollen keine bestehenden Externverweise auf andere Subsysteme gelöscht werden.
REMOVE-REFER-SUBS = list-poss(15): <structured-name 1..8>
Gibt die Namen von maximal 15 Externverweisen an, die nicht mehr gültig sein sollen.
UNRESOLVED-EXTERNALS =
Vereinbart das Verhalten des Ladevorgangs, wenn Externverweise nicht aufgelöst werden können.
UNRESOLVED-EXTERNALS = *FORBIDDEN
Der Ladevorgang wird bei nicht auflösbaren Externverweisen abgebrochen.
UNRESOLVED-EXTERNALS = *ALLOWED
Der Ladevorgang wird fortgesetzt, nicht auflösbare Externverweise werden mit dem Wert X'FFFFFFFF' besetzt.
CHECK-REFERENCE =
Vereinbart, ob die im Operanden REFERENCED-SUBSYSTEM angegebenen Subsysteme im Hinblick auf deren Zustand und Verfügbarkeit hin überprüft werden sollen.
CHECK-REFERENCE = *YES
Die Referenz-Subsysteme werden überprüft. Fehlt eines der Subsysteme, bricht DSSM das Aktivieren oder Entladen des Subsystems ab.
CHECK-REFERENCE = *NO
DSSM soll keine Prüfung vornehmen.
Generiert der Anwender allerdings mit dieser Anweisung auch komplexe Subsysteme, führt DSSM die geforderten Funktionen trotz möglicher Konflikte durch:
Das Kommando START-SUBSYSTEM lädt das angegebene Subsystem, auch wenn ein Subsystem, zu dem definierte Beziehungen bestehen, noch nicht vollständig geladen ist.
Die Kommandos RESUME-SUBSYSTEM, STOP-SUBSYSTEM und HOLD-SUBSYSTEM werden ohne Prüfung von Beziehungen und Abhängigkeiten von DSSM ausgeführt.
ADD-RELATED-SUBS / MODIFY-RELATED-SUBS =
Legt fest, ob entweder eine Liste von Subsystemen aufgebaut werden soll, zu denen Abhängigkeitsbeziehungen bestehen (ADD), oder eine bereits bestehende Liste abhängiger Subsysteme modifiziert werden soll (MODIFY).
ADD-RELATED-SUBS / MODIFY-RELATED-SUBS = *NONE
Voreinstellung: es sollen für das Subsystem weder Abhängigkeitsbeziehungen definiert noch verändert werden.
ADD-RELATED-SUBS / MODIFY-RELATED-SUBS = list-poss(100):<structured-name 1..8>
Es sollen Abhängigkeitsbeziehungen zu maximal 100 anderen Subsystemen, ohne die das zu definierende Subsystem nicht funktionsfähig ist, definiert (ADD) oder verändert (MODIFY) werden.
Abhängigkeitsbeziehungen dürfen auch zum BS2000 Control Program CP definiert werden. Die Regeln und Einschränkungen, die hierbei zu beachten sind, gelten analog für Adressbeziehungen und sind dort näher erläutert (siehe Operand ADD-REFER-SUBS).
Die Abhängigkeitsbeziehungen zielen jeweils auf eine Version eines Subsystems. In der folgenden Unterstruktur kann sowohl genau eine Version spezifiziert werden, als auch ein Bereich von Versionen angegeben werden, innerhalb dessen alle Versionen herangezogen werden sollen.
Auf folgende Einschränkungen ist allgemein bei der Angabe von abhängigen Subsystemen ist zu achten:
- Die definierte Beziehung muss zyklenfrei sein. Ein Zyklus entsteht, wenn Subsystem A abhängig von B, B abhängig von C und dieses wieder abhängig von A ist.
Ist für das zu definierende Subsystem das Attribut MEMORY-CLASS=*SYSTEM-GLOBAL vergeben, dürfen keine Subsysteme angesprochen werden, die mit MEMORY-CLASS=*LOCAL-PRIVILEGED oder *LOCAL-UNPRIVILEGED definiert sind.
Für Subsysteme, die das Attribut SUBSYSTEM-ACCESS=*SYSTEM besitzen, darf keine Abhängigkeitsbeziehung zu Subsystemen definiert werden, für die SUBSYSTEM-ACCESS=*LOW bzw. SUBSYSTEM-ACCESS=*HIGH oder MEMORY-CLASS=*BY-SLICE gilt.
Die Abhängigkeitsbeziehungen müssen entsprechend den Startattributen (Operand CREATION-TIME) definiert werden, d.h. ein Subsystem darf nur von solchen Subsystemen abhängen, deren Start zeitgleich oder früher erfolgt.
LOWEST-VERSION =
Spezifiziert den unteren Wert (niedrigste Version) innerhalb der Versionsbereichsliste der Subsysteme.
LOWEST-VERSION = *LOWEST-EXISTING
Die niedrigste Version im Katalog soll angesprochen werden.
LOWEST-VERSION = <c-string 3..8> / <text 3..8>
Version eines Subsystems, die als Untergrenze des Versionsbereiches fungieren soll.
HIGHEST-VERSION =
Spezifiziert den oberen Wert (höchste Version) innerhalb der Versionsbereichsliste der Subsysteme.
HIGHEST-VERSION = *HIGHEST-EXISTING
Die höchste Version im Katalog soll angesprochen werden.
HIGHEST-VERSION = <c-string 3..8> / <text 3..8>
Version eines Subsystems, die als Obergrenze des Versionsbereiches fungieren soll.
MODIFY-RELATED-SUBS =
Siehe Beschreibung bei ADD-RELATED-SUBS.
REMOVE-RELATED-SUBS =
Bestimmt, ob bestehende Abhängigkeitsbeziehungen zu anderen Subsystemen gelöscht werden sollen.
REMOVE-RELATED-SUBS = *NONE
Voreinstellung: Es sollen keine bestehenden Abhängigkeitsbeziehungen zu anderen Subsystemen gelöscht werden.
REMOVE-RELATED-SUBS = list-poss(100): <structured-name 1..8>
Gibt die Namen von maximal 100 Subsystemen an, zu denen keine Abhängigkeitsbeziehungen mehr bestehen sollen.