Speicher- und Taskkonzept

Speicherkonzept

Subsysteme werden je nach Deklaration folgendermaßen geladen:

• in den Systemadressraum (Klasse-3- oder Klasse-4-Speicher)
  bei MEMORY-CLASS=*SYSTEM-GLOBAL

• in den Benutzeradressraum (Memory Pool: Klasse-5- oder Klasse-6-Speicher) bei MEMORY-CLASS=*LOCAL-PRIVILEGED/*LOCAL-UNPRIVILEGED

• in beide Adressräume bei MEMORY-CLASS=*BY-SLICE

Anschlüsse an Subsysteme im Benutzeradressraum sind nur möglich, wenn der zugewiesene Adressraum auch in der eigenen Task frei ist. Der Code muss nach dem Anschluss immer an der gleichen Adresse liegen. Für allgemein verfügbare Subsysteme im Benutzeradressraum, die jederzeit und von allen Tasks angesprochen werden können, wird ein fester Bereich im Klasse-5-Speicher reserviert, der so genannte Adressraum-Streifen. Diesen Adressraum-Streifen teilen sich alle allgemein verfügbaren Subsysteme, wobei für nicht-privilegierte Subsysteme je ein eigener Streifen zur Verfügung steht.

Für Benutzertasks können bei nicht ausreichendem Klasse-5-Speicher Probleme auftreten. Der für Subsysteme reservierte Adressraum-Streifen kann durch das DSSM-Kommando RELEASE-SUBSYSTEM-SPACE freigegeben werden, um mehr Klasse-5-Speicher zur Verfügung zu haben.

Subsysteme, die nicht gleichzeitig gebraucht werden (die sich also nicht gegenseitig aufrufen), können im Adressraum parallel liegen. Je mehr Subsysteme parallel liegen, umso kleiner ist der benötigte Adressraum-Streifen. Dabei ist auf die Ausgewogenheit der parallelen Subsysteme zu achten, da hohe Parallelität einerseits eine Einsparung des Adressraums, andererseits eine mögliche Verschlechterung der Performance zur Folge haben kann (je mehr Parallelität, umso mehr gegenseitige Verdrängung). Die Verteilung der Subsysteme im Adressraum-Streifen kann mit der SSCM-Anweisung SEPARATE-ADDRESS-SPACE geregelt werden.

Adressraum-Haushalt

Der Adressraum-Haushalt von DSSM gibt die Möglichkeit, den Systemadressraum (Klasse-3- und Klasse-4-Speicher) zu entlasten, indem Subsysteme in den Benutzeradressraum der Holdertask gelegt werden. Das ist jedoch nur für nichtprivilegierte Subsysteme relevant, denn alle privilegierten Subsysteme werden immer in den Systemadressraum geladen (MEMORY-CLASS=*SYSTEM-GLOBAL).
Die Verlagerung ist dann problemlos, wenn die Subsysteme sich nicht gegenseitig aufrufen und nicht über ein drittes Programm voneinander abhängen oder im Klasse-6-Speicher als Hauptprogramm ablaufen können.
Zu beachten ist, dass nur die Verlagerung nicht-privilegierter Subsysteme angestrebt werden kann, die unterhalb der 16 MByte-Grenze angesiedelt sind.
Für alle anderen nicht-privilegierten Subsysteme wird das Laden oberhalb der 16 MByte-Grenze empfohlen (SUBSYSTEM-ACCESS=*HIGH).

Auch Subsysteme, die reentrant-fähig sind und als Hauptprogramme laufen, können aus dem Systemadressraum ausgelagert werden. Sie müssen durch MEMORY-CLASS=*LOCAL-UNPRIVILEGED im Memory Pool im Klasse-6-Speicher verfügbar sein.

Für Subsysteme, die aus einem mehrbenutzbaren Code (Programmbereich) und einem nicht-mehrbenutzbaren Code (Datenbereich) bestehen, gibt es das Konzept zur Minimierung der Systemadressraum-Belegung:
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 zum Zeitpunkt des Anschlusses einer Task an das Subsystem in deren privaten Benutzeradressraum an dieselbe Adresse kopiert.
Dieses Konzept wird mit der Definition eines Subsystems mit MEMORY-CLASS=*BY-SLICE realisiert.

Die Vorteile dieses Konzepts sind:

• Adressbezogene Referenzen zwischen Programm- und Datenbereich sind immer möglich, weil die Kopie des Datenbereichs an derselben Adresse beginnt wie das Original.

• Die Performance wird durch diese Art der Adressraumaufteilung wesentlich erhöht, weil beim Anschluss einer Task an das Subsystem kein Zugriff zur Programm- oder Bindemodulbibliothek erfolgt und Externverweise nicht aufgelöst werden müssen.

Die Nachteile dieses Konzepts sind:

• Der zum Startup-Zeitpunkt bestimmte und vorreservierte Adressraum für den Datenbereich kann nur sehr begrenzt erweitert werden. Eine Speicherplatzoptimierung ist wegen der strengen Adressraumaufteilung nicht möglich.

• Ist der zur Aufnahme des Datenbereichs vorgesehene Adressraum der sich anschließenden Task bereits belegt, wird der Subsystemcode (Daten- und Programmbereich!) vollständig in den Benutzeradressraum dieser Task geladen.

Die Verlagerung vom Systemadressraum in den Benutzeradressraum lohnt sich nur in folgenden Fällen:

1. Subsysteme, die voneinander unabhängig sind und von Benutzerprogrammen nicht gleichzeitig benutzt werden, können parallel in den Benutzeradressraum gelegt werden. Ist dies nicht der Fall, ist eine Verlagerung nicht sinnvoll, da der Verbrauch im Benutzeradressraum ungünstiger ausfällt als im Systemadressraum.

2. Die Subsysteme sind ausreichend groß, um den auftretenden Verschnitt durch die Verwendung von Memory Pool auszugleichen (min. Größe eines Memory Pools: 1 MByte).

3. Das Subsystem muss unterhalb der 16 MByte-Grenze angesiedelt sein. (Für Subsysteme, die auch oberhalb der Grenze geladen werden dürfen, kann der Operand SUBSYSTEM-ACCESS=*HIGH verwendet werden, um einer Überlastung der unteren 16 MByte zu begegnen.)

Zusammenfassung:
Unabhängige Subsysteme parallel in Memory Pools zu konfigurieren ist nur dann sinnvoll, wenn die Summe der Größe aller Subsysteme mehr als 1 MByte beträgt und kein Subsystem die 1 MByte-Grenze in seiner Größe überschreitet.

Taskkonzept - Holdertask

Die Aktivierung eines Subsystems erfolgt unter einer eigenen Task, der Holdertask. Abhängig vom Typ des Subsystems kann diese Task als Subsystem-Arbeitstask oder nur als reine Holdertask verwendet werden. Der Benutzeradressraum dieser Task kann für die Auslagerung aus dem Systemadressraum genutzt werden.

Die Anzahl der benötigten Holdertasks sollte möglichst gering gehalten werden. Eine hohe Taskanzahl beeinflusst zwar die Parallelität günstig, da umso mehr Subsysteme installiert werden können, je mehr Tasks gleichzeitig angelegt werden. Andererseits benötigen mehr Tasks auch mehr taskspezifische Tabellen.

DSSM selbst minimiert die Anzahl der Holdertasks; die Verteilung der Subsysteme kann aber durch die SSCM-Anweisung ASSIGN-HOLDER-TASK (siehe "ASSIGN-HOLDER-TASK") bei der Generierung des Subsystemkatalogs mit SSCM gesteuert werden.
Standardmäßig werden alle Subsysteme, die mit MEMORY-CLASS=*BY-SLICE definiert wurden, an dieselbe Holdertask angeschlossen.

Im Fehlerfall wird automatisch der Wiederanlauf der Holdertask initiiert, um nicht alle Subsysteme, die an die Holdertask angeschlossen sind, in Mitleidenschaft zu ziehen. Gesteuert durch den Operanden RESTART-REQUIRED (Anweisung SET-SUBSYSTEM-ATTRIBUTES) ist auch der Wiederanlauf eines Subsystems vorgesehen. Der Operand ermöglicht, die Subsystem-Initialisierung dann noch einmal aufzurufen, wenn die Holdertask während des Ablaufs von Subsystem-Routinen beendet wurde (siehe "Fehlerbehandlung in DSSM").