Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

START-SUBSYSTEM

&pagelevel(3)&pagelevel

Subsystem aktivieren

Komponente:

DSSM

Funktionsbereich:

Subsysteme verwalten

Anwendungsbereich:

SYSTEM-MANAGEMENT                                                                                        

Privilegierung:

OPERATING
SUBSYSTEM-MANAGEMENT

Berechtigungsschlüssel:

R

Funktionsbeschreibung

Mit diesem Kommando kann die Systembetreuung ein beliebiges Subsystem aktivieren. Für die Aktivierung des Subsystems werden folgende Informationen aus dem dynamischen Subsystemkatalog benutzt:

  • Angaben zum Laden und Binden des Subsystems

  • Angaben zur Initialisierung/Deinitialisierung und zum Beenden der Auftragsbeziehungen

  • Angaben zu Aufrufstellungen, Nebenkomponenten und betrieblichen Abhängigkeiten (siehe die entsprechenden SSCM-Anweisungen im Handbuch „Verwaltung von Subsystemen“ [49]).

Das Kommando wird abgewiesen, wenn

  • das Subsystem im dynamischen Subsystemkatalog nicht gefunden wird

  • eine andere Version des Subsystems bereits existiert und die Koexistenz nicht zugelassen ist (siehe Operand VERSION-PARALLELISM)

  • Subsysteme, von denen das zu aktivierende Subsystem abhängt, nicht geladen sind

  • eine benötigte Datei (z.B. Meldungsdatei, Bibliothek) fehlt.

Eine entsprechende Meldung informiert die Systembetreuung über die Annahme/Zurückweisung des Kommandos. Über den Operanden RESET=*YES kann auch für solche Subsysteme, die sich im Abbau befinden, die erneute Initialisierung des Subsystems erzwungen werden. Es können beliebig viele START-SUBSYSTEM-Kommandos in verschiedenen Tasks unter einer privilegierten Benutzerkennung der Systembetreuung abgesetzt werden, es sei denn, die vereinbarten Parameter bei der Subsystem-Definition lassen dies nicht zu.

Abhängig von der Subsystemdefinition (SSCM-Anweisung SET-/MODIFY-SUBSYSTEM-ATTRIBUTES, Operand SUBSYSTEM-LOAD-MODE) kann es auf verschiedenen Arten aktiviert werden:

  • 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).

  • SUBSYSTEM-LOAD-MODE = *ANY
    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. Ist der erste Aufruf des BLS nicht erfolgreich, wird an der Konsole eine Fehlermeldung des BLS ausgegeben.

Format

START-SUBSYSTEM

 SUBSYSTEM-NAME = <structured-name 1..8>

,VERSION = *STD / <product-version mandatory-man-corr> / 




<product-version without-man-corr> /*HIGHEST

,SUBSYSTEM-PARAMETER = *NONE / <c-string 1..254>

,RESET = *NO / *YES

,SYNCHRONOUS = *NO / *YES

,VERSION-PARALLELISM = *NONE / *EXCHANGE-MODE(...) / *COEXISTENCE-MODE


*EXCHANGE-MODE(...)



|

SUBSYSTEM-PARAMETER = *NONE / <c-string 1..254>

,MONJV = *NONE / <filename 1..54 without-gen-vers>

Operandenbeschreibung

SUBSYSTEM-NAME = <structured-name 1..8>
Name des Subsystems, das aktiviert wird.

VERSION = *STD / <product-version mandatory-man-corr> / <product-version without-man-corr> /
*HIGHEST

Vereinbart die Version.
Bei Angabe einer Version muss das hier angegebene Format mit dem bei der Definition des Subsystems benutzten Format übereinstimmen (Freigabe- und Korrekturstand müssen angegeben werden oder dürfen nicht angegeben werden; siehe auch „SDF-Syntaxdarstellung").

VERSION = *STD
Existieren für das angegebene Subsystem mehrere Versionen und wird keine Version oder explizit *STD angegeben, wird das Subsystem, das mit dem Startattribut CREATION-TIME=*AT-SUBSYSTEM-CALL (siehe SSCM-Anweisung SET-SUBSYSTEM-ATTRIBUTES im Handbuch „Verwaltung von Subsystemen“ [49]) deklariert wurde, geladen. Trifft diese Bedingung nicht zu, wird die niedrigste im statischen Subsystemkatalog für dieses Subsystem angelegte Version ausgewählt.


Ausnahme

Soll eine Version eines Subsystems automatisch beim ersten SVC-Aufruf aktiviert werden, so gilt diese Version als Standardversion.

VERSION = *HIGHEST
Es wird die höchste Version des Subsystems, die im statischen Subsystemkatalog eingetragen ist, ausgewählt.

SUBSYSTEM-PARAMETER = *NONE / <c-string 1..254>
Vereinbart, ob spezielle Parameter, die nur das angegebene Subsystem auswerten kann, verarbeitet werden.

RESET =
Beeinflusst Verhalten und Dringlichkeit der Kommandobearbeitung.

RESET = *NO
Befindet sich das betreffende Subsystem im Abbau, wird das Kommando solange abgewiesen, bis dieser blockierende Prozess beendet ist.

RESET = *YES
Das Kommando wird ohne Rücksicht auf einen evtl. noch ausstehenden Abbau-Prozess akzeptiert und das Subsystem oder einige Komponenten initialisiert (siehe auch Hinweise im Abschnitt "START-SUBSYSTEM").
Der Versionsparameter ist für diesen Operanden verpflichtend.

SYNCHRONOUS =
Erlaubt die Wahl zwischen synchroner und asynchroner Verarbeitung.

SYNCHRONOUS = *NO
Das Kommando soll asynchron, d.h ohne auf die Ausführung des Kommandos warten zu müssen, verarbeitet werden. Nach der Syntaxprüfung des Kommandos erhält die aufrufende Task die Meldung ESM0216. Fehlermeldungen über den Ablauf des Kommandos werden nicht ausgegeben.

SYNCHRONOUS = *YES
Die Ausführung des Kommandos muss abgewartet werden.
Entsprechende Fehlermeldungen über den Ablauf werden ausgegeben.
Im Fall eines Versionsaustauschs ist diese Angabe nur für die neu zu aktivierende Version relevant. Die Deaktivierung der anderen, „alten“ Version geschieht immer asynchron.

VERSION-PARALLELISM =
Vereinbart, ob verschiedene Versionen des gleichen Subsystems gleichzeitig aktiv sein dürfen.

VERSION-PARALLELISM = *NONE
Eine Koexistenz verschiedener Versionen eines Subsystems - unabhängig von den Vorgaben bei der Definition - soll nicht zulässig sein. Ist der Status einer Version ungleich NOT-CREATED, wird die Aktivierung zurückgewiesen.

VERSION-PARALLELISM = *EXCHANGE-MODE(...)
Eine temporäre Koexistenz zweier Versionen eines Subsystems soll zulässig sein. Die Aktivierung ist nur erlaubt, wenn sich keine oder nur eine Version des Subsystems im Zustand „CREATED“ befindet. Haben bereits zwei Versionen diesen Zustand eingenommen, wird für die zuletzt gestartete Version eine implizite Deaktivierung eingeleitet.
Ist eine Version eines Subsystems gesperrt (Zustand LOCKED), wird diese von DSSM als NOT-CREATED behandelt.
In folgenden Fällen wird das Kommando mit diesem Operanden zurückgewiesen:

  • die zu ersetzende Version ist mit HOLD=*NO, aber ohne CLOSE-CTRL-Routine definiert

  • das Kommando MODIFY-SUBSYSTEM-PARAMETER CHANGE-STATE=*NO wurde für die zu ersetzende Version verwendet

  • es wurde gleichzeitig RESET=*NO angegeben

  • der Status der Version ist ungleich CREATED, NOT-CREATED oder LOCKED

SUBSYSTEM-PARAMETER = *NONE / <c-string 1..254>
Vereinbart, ob spezielle Parameter, die nur die angegebene Version des Subsystems auswerten kann, verarbeitet werden.

VERSION-PARALLELISM = *COEXISTENCE-MODE
Eine uneingeschränkte Koexistenz zweier oder mehrerer Versionen des gleichen Subsystems soll zulässig sein. Voraussetzung ist hierbei, dass dies für alle beteiligten Versionen in der SSCM-Anweisung SET-SUBSYSTEM-ATTRIBUTES zugelassen wurde.

MONJV = *NONE / <filename 1..54 without-gen-vers>
Vereinbart den Namen einer Monitor-Jobvariable. Die Monitor-Jobvariable zeigt an, ob das Subsystem aktiv, angehalten, unterbrochen oder gesperrt ist. Die angegebene Jobvariable wird nur zur überwachenden Jobvariable, wenn das Subsystem noch nicht gestartet war. Die Monitor-Jobvariable kann folgende Inhalte haben:

Byte

Länge

Inhalt

Werte

1

3

Status

$R (running) /
$A (abnormal end) /
$L (loaded) /
$T (terminate)

4

1

reserviert

0

5

4

TSN

???? (4 Fragezeichen)

9

4

Katalogkennung des Home-Pubsets


13

4

reserviert


17

1

Typ

J / P / S

18

53

reserviert


71

3

Session-Nummer


74

8

Name des Subsystems


82

7

Version des Subsystems


89

15

Zustand des Subsystems

für $R: created
für $A: abnormal end / locked
für $L: in create
für $T: not created / not resumed / in delete / in resume / in hold

104

24

unbenutzt


128

127

reserviert für Anwender des Subsystems


Kommando-Returncode

(SC2)

SC1

Maincode

Bedeutung


0

CMD0001

Ohne Fehler

1

0

CMD0001

Keine Aktion notwendig; Subsystem bereits aktiv


1

ESM0414

Syntaxfehler: es wurde eine ungültige Version angegeben


32

ESM0224

Kommando wird nicht verarbeitet


32

ESM0228

Kommando abnormal beendet

Hinweise

  • Subsysteme weisen in der Regel vielfältige Beziehungen (Abhängigkeitsbeziehungen, Ladebeziehungen) zu anderen Subsystemen auf. Um die Leistungen des einzelnen Subsystems zu gewährleisten, müssen diese Beziehungen berücksichtigt werden. DSSM versucht, mögliche Konflikte, die sich aus Anforderungen des Anwenders ergeben könnten, zu vermeiden und weist daher entsprechende Kommandos zurück. Aktionen, wie die Installation fehlender Subsysteme oder das Entladen abhängiger Subsysteme, werden nicht durchgeführt. Generiert der Anwender allerdings mit Anweisung CHECK-REFERENCE=*NO auch komplexe Subsysteme (siehe SSCM-Anweisung SET-SUBSYSTEM-ATTRIBUTES), 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.

  • Um ein hohes Maß an Parallelität und Datenintegrität zu gewährleisten, werden zeitaufwändige Verwaltungsaufgaben nicht unter der Kontrolle der aufrufenden Task ausgeübt, sondern einer DSSM-Task übertragen. In der Regel wird nur die Prüfung der geforderten Funktion synchron (d.h. verbunden mit einem Wartezustand für die aufrufende Task) realisiert. Die eigentliche Verarbeitung jedoch führt DSSM asynchron und unabhängig von der aufrufenden Task durch.

  • Nach dem Kommando STOP-SUBSYSTEM wird START-SUBSYSTEM abgewiesen, wenn DSSM die Aktion „Subsystem entladen“ noch nicht vollständig durchführen konnte. Mit dem Operanden RESET=*YES kann die Systembetreuung jedoch das unbedingte Laden des Subsystems erreichen; die vollständige Abarbeitung eines STOP-SUBSYSTEM-Kommandos muss nicht abgewartet werden. In diesem Fall wird die Initialisierungsroutine angestoßen, das betreffende Subsystem, das über den RESET informiert wird, kann den Umfang der Init-Routine (vollständige Initialisierung, Teil-Initialisierung, keine Initialisierung) selbst festlegen.

        
    Ausnahme:

Befindet sich das betreffende Subsystem noch im Zustand IN-DELETE, wurde aber bereits deinitialisiert, wird die Verarbeitung „Subsystem entladen“ trotz RESET= *YES nicht unterbrochen. Das Kommando START-SUBSYSTEM wird zurückgewiesen, bis das Subsystem den Zustand NOT-CREATED erreicht und alle Betriebsmittel freigegeben hat.

  • Sollen zwei Versionen eines Subsystems ausgetauscht werden, ist bei Verwendung des Parameters RESET=*YES auf Folgendes zu achten:

    • befindet sich Version A im Zustand IN-DELETE und Version B im Zustand CREATED, ist RESET=*YES für A nur zulässig, wenn für beide Versionen bei der Definition (SSCM) Koexistenz zugelassen wurde.

    • befinden sich beide Versionen im Zustand IN-DELETE, ist RESET=*YES für eine dieser Versionen zulässig, wenn diese mit RESET=*ALLOWED, VERSION-EXCHANGE=*ALLOWED definiert wurde.

  • Ein Wiederanlauf (d.h. Aufruf der INIT-Routine für mit RESTART-REQUIRED=*YES definierte Subsysteme) wird unterbunden, da dies ansonsten zu unerlaubten Koexistenzen führen kann.