Eigenschaften und Einsprungstellen eines Subsystems definieren
Funktionsbeschreibung
Mit dieser Anweisung können alle Eigenschaften und Einsprungstellen eines Subsystems definiert werden.
In welcher Weise die Definition eines neuen Subsystems aufgebaut wird, ist abhängig davon, welche Anweisung der Definition vorausging:
Nach der Anweisung START-CATALOG-CREATION kann das Subsystem in den Katalog integriert werden.
Nach der Anweisung START-SSD-CREATION kann das Subsystem in das SSD-Object integriert werden. In ein und demselben SSD-Object können jedoch nicht verschiedene Versionen des gleichen Subsystems angelegt werden.
Subsysteme, die mit dem Operanden MEMORY-CLASS=*SYSTEM-GLOBAL ..., SUBSYSTEM-ACCESS=*SYSTEM definiert werden, sind privilegierte Subsysteme.
Bei der Definition ist ferner auf Folgendes zu achten:
Der Name des Subsystems und seine Version dürfen noch nicht im Subsystemkatalog bekannt sein.
Zwei verschiedene Versionen ein- und desselben Subsystems können nicht in einem SSD-Object definiert werden.
Der Subsystem-Name CP ist für DSSM reserviert und darf nicht angegeben werden.
Die Namen der Einsprungstellen dürfen nicht doppelt genannt werden.
Der Name des zu definierenden Subsystems darf nicht in der Liste der Subsysteme enthalten sein, zu denen Adress- oder Abhängigkeitsbeziehungen bestehen.
Innerhalb dieser Liste darf keine Doppelnennung eines Subsystems auftauchen.
SET-SUBSYSTEM-ATTRIBUTES wird abgewiesen, wenn vorher keine der folgenden Anweisungen ausgeführt wurde:
START-SSD-CREATION
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
DEINIT-ROUTINE
INTERFACE-VERSION
SUBSYSTEM-ENTRIES
STOPCOM-ROUTINE
Format
SET-SUBSYSTEM-ATTRIBUTES | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Operandenbeschreibung
SUBSYSTEM-NAME = <structured-name 1..8>(...)
Vereinbart Name und Version des zu definierenden Subsystems.
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
Voreinstellung: Es wird kein Name vergeben. Für alle mit IMON installierten Subsysteme ist diese Voreinstellung nicht erlaubt.
INSTALLATION-UNIT = *STD
Der beim Operanden SUBSYSTEM-NAME angegebene Name wird als Name der installierten Liefergruppe genutzt.
INSTALLATION-UNIT = <text 1..30>
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 sich um ein lokales Subsystem handelt.
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
Voreinstellung: 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 den Namen der Programm- oder Bindemodulbibliothek (OML), aus der der Objectcode des Subsystems bei dessen Aktivierung geladen werden soll.
LIBRARY = *STD
Voreinstellung: 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 (CP=Control Program) verknüpft 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>
Neuer 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 = *ANY
Voreinstellung: das BLS wird im STD-Run-Mode aufgerufen und lädt das Subsystem als Objektmodul. Tritt während des Ladens ein Fehler ein, wird BLS ein zweites Mal aufgerufen. Der Aufruf erfolgt im ADVANCED-Run-Mode und das Subsystem wird als Bindelademodul (LLM) geladen.
Dieser Operandenwert wird nur aus Kompatibilitätsgründen weiter unterstützt.
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. Die 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 sollen.
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
Voreinstellung: 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
Voreinstellung: 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 automatisch aktiviert, beim Entladen automatisch deaktiviert (START-/ STOP-SUBSYSTEM).
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
Voreinstellung: 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 kein 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-/STOPCOM-/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-SUBSYSTEMS eine Abhängigkeitsbeziehung zum Subsystem SDF zu deklarieren.
SYNTAX-FILE = *NO
Voreinstellung: es soll keine Syntaxdatei aktiviert werden. Dieser Wert ist verpflichtend für alle Subsysteme, die mit dem Startzeitpunkt BEFORE-DSSM 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
Als Voreinstellung gilt, 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. Bei den beiden erstgenannten wird das Laden der Subsysteme mit der Startup-Routine synchronisiert (d.h. das Laden muss abgeschlossen sein), beim letztgenannten wird das Laden asynchron angestoßen. 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
Voreinstellung: 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/*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 oder dem Startattribut BEFORE-DSSM-LOAD definiert sind.
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 die Angabe 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.
Anschluss- 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 vollen Verantwortung des Subsystem-Entwicklers, sicherzustellen, dass zu jedem Zeitpunkt mindestens eine Version dieses Subsystems verfügbar ist (z.B. PLAM). Der Name des Link-Kontextes für diese Subsysteme muss eindeutig sein, da DSSM auch 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 liegen. 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. Eine INIT-Routine muss mit RESTART-REQUIRED=*YES deklariert werden.
INIT-ROUTINE = *NO
Voreinstellung: es wird keine Initialisierungsroutine durchlaufen.
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 SSCMCAT 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). Abhängig davon steht die Task dann weiter unter DSSM-Kontrolle oder unter Kontrolle des Subsystems.
CLOSE-CTRL-ROUTINE =
Legt fest, ob eine spezielle Routine für das Subsystem durchlaufen werden soll, wenn es angehalten oder deaktiviert wird.
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
Voreinstellung: im betreffenden Subsystem ist keine Routine verankert, die beim Deaktivieren oder Anhalten des Subsystems durchlaufen werden soll.
CLOSE-CTRL-ROUTINE = *DYNAMIC
Der Aufruf dieser Routine erfolgt über Börse oder FITC. 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 Arbeitstask sein (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.
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.
Wird CLOSE-CTRL-ROUTINE=*DYNAMIC vereinbart, muss der Operand STOPCOM-ROUTINE=*NO/*DYNAMIC angegeben werden.
STOPCOM-ROUTINE = *NO
Voreinstellung: 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 (Anweisung 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
Voreinstellung: im betreffenden Subsystem ist keine Deinitialisierungsroutine verankert, die die Rückgabe der Betriebsmittel veranlasst.
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
Voreinstellung: 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.
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.
Dieser Operand ist Pflicht für Subsysteme, für die eine Einsprungstelle angegeben wurde (INIT-, CLOSE-CTRL-, STOPCOM-, DEINIT-Routine).
INTERFACE-VERSION = *NO
Voreinstellung: 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
Voreinstellung: 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 und 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
Voreinstellung: 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.
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
Voreinstellung: 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
Voreinstellung: 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
Voreinstellung: 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
Voreinstellung: 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 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 eines Subsystems 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
Voreinstellung: 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.
SUBSYSTEM-ENTRIES =
Vereinbart die Einsprungstellen (Auftragseingänge), die mit dem Subsystem verbunden sind. Es können bis zu 100 Auftragseingänge vereinbart werden. Werden mehr als 100 Auftragseingänge für ein Subsystem gewünscht, können diese mit den Anweisungen MODIFY-SUBSYSTEM-ATTRIBUTES (für ein Subsystem im Katalog) bzw. ADD-SUBSYSTEM-ENTRIES (für ein Subsystem in einem SSD-Object) definiert werden.
SUBSYSTEM-ENTRIES = *NONE
Voreinstellung: es werden keine Einsprungstellen vereinbart.
SUBSYSTEM-ENTRIES = list-poss(100): <text 1..8>
Vereinbart durch Angabe des Namens der Einsprungstelle maximal 100 Auftragseingänge, deren Typ jeweils in den Unterstrukturen definiert werden muss.
MODE =
Legt den Typ eines vereinbarten Auftragseingangs für das Subsystem fest.
MODE = *LINK
Voreinstellung: 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 Standardheader der Parameterliste des Aufrufers hinterlegt ist.
Der Wert *ALL des Operanden CONNECTION-ACCESS 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
Voreinstellung: 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 Standardheader der Parameterliste des Aufrufers hinterlegt ist.
Bei Angabe dieses Operandenwertes sollte der Operand CONNECTION-ACCESS vorzugsweise mit dem Wert *SYSTEM statt *ALL belegt werden.
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
Voreinstellung: 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
Voreinstellung: 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
Voreinstellung: 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
Voreinstellung: 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) oder 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, sollten 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
Voreinstellung: Der Erst-Anschluss an den angegebenen Auftragseingang ist erlaubt.
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.
SUBSYSTEM-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 Extended External Names (EEN-Namen) als Einsprungstellen für DSSM-Subsysteme unterstützt.
Der Wert kann nicht zusammen angegeben werden mit dem Operanden SUBSYSTEM-ACCESS=*SYSTEM.
Wenn die Einsprungstellen mit diesem Wert definiert sind, werden die Operanden MODE,
CONNECTION-ACCESS und FIRST-CONNECTION mit den Standardwerten versorgt.
CONNECTION-SCOPE = *TASK / *PROGRAM
Der Anschluss wird bei Task- bzw. Programmbeendigung aufgehoben.
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.
MEMORY-CLASS = *SYSTEM-GLOBAL(...)
Voreinstellung: 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
Voreinstellung: Es wird nicht-privilegierter Klasse-3- oder Klasse-4-Speicher 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 Wert kann nicht zusammen mit einer Einsprungstelle angegeben werden, die zusammen mit CONNECTION-ACCESS=*ALL oder MODE=*LINK angegeben wurde.
Der Wert kann nicht zusammen angegeben werden mit dem Operanden SUBSYSTEM-ENTRIES=*BY-PROGRAM.
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 Speicherplatzes.
SUBSYSTEM-ACCESS = *LOW
Voreinstellung: Es wird nicht-privilegierter Klasse-6-Speicher 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 Klasse-6-Speicher 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
Voreinstellung: 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.
Der Wert kann nur zusammen angegeben werden mit den Operanden MODE=*LINK und CONNECTION-SCOPE=*TASK oder *PROGRAM.
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 = *FORBIDDEN /*ALLOWED
Voreinstellung: Die Autolink-Funktion wird unterdrückt oder zugelassen.
REFERENCED-SUBSYSTEM =
Legt fest, ob es eine Liste von Subsystemen gibt, zu denen Adressbeziehungen bestehen und die zur Auflösung von Externverweisen benutzt werden.
REFERENCED-SUBSYSTEM = *NONE
Voreinstellung: das zu definierende Subsystem besitzt keine Externverweise.
REFERENCED-SUBSYSTEM = list-poss(15): <structured-name 1..8>
Das zu definierende Subsystem besitzt Externverweise auf maximal 15 andere Subsysteme, 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.
Subsysteme, die das Attribut STOP-AT-SHUTDOWN=*NO besitzen, dürfen Adressbeziehungen nur zu solchen Subsystemen aufweisen, die auch dieses Attribut 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. SUBSYSTEM-ACCESS=*HIGH definiert sind.
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.
UNRESOLVED-EXTERNALS =
Vereinbart das Verhalten des Ladevorgangs, wenn Externverweise nicht aufgelöst werden können.
UNRESOLVED-EXTERNALS = *FORBIDDEN
Voreinstellung: 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
Voreinstellung: 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 oder HOLD-SUBSYSTEM werden ohne Prüfung von Beziehungen und Abhängigkeiten von DSSM ausgeführt.
RELATED-SUBSYSTEM =
Legt fest, ob es eine Liste von Subsystemen gibt, zu denen Abhängigkeitsbeziehungen bestehen.
RELATED-SUBSYSTEM = *NONE
Voreinstellung: das zu definierende Subsysteme besitzt keine Abhängigkeitsbeziehungen.
RELATED-SUBSYSTEM = list-poss(100): <structured-name 1..8>
Das zu definierende Subsystem besitzt Abhängigkeitsbeziehungen zu maximal 100 anderen Subsystemen, ohne die das zu definierende Subsystem nicht funktionsfähig ist.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 (Operand REFERENCED-SUBSYSTEM) und sind dort näher erläutert.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.