Ein anwendungslokaler Pool wird von der ersten Task einer Anwendung angelegt. Alle weiteren Tasks dieser Anwendung greifen ebenfalls darauf zu, d.h. der Pool wird im Sinne der Memory-Pool-Verwaltung des BS2000 mit SCOPE=GROUP angelegt. Auch Tasks weiterer UTM-Anwendungen, die unter derselben Benutzerkennung gestartet wurden, können sich an diesen Common Memory Pool anschließen.
Der anwendungslokale Pool bietet folgende Vorteile für den Anwender:
Die Nutzung der in diesen Pool geladenen Programme ist nur von dieser Benutzerkennung aus möglich.
Der Benutzer hat die volle Kontrolle über die Verwendung von shareable Objekten, unabhängig von der System-Initialisierung.
Der Pool existiert nur so lange die Anwendung läuft, bzw. wenn mehrere Anwendungen auf den Pool zugreifen, bis die letzte Anwendung beendet wird. Mit dem Ende der Anwendung wird der Pool aufgelöst und die Programme werden - wie alle anderen Anwenderprogramme auch - entladen.
Die in einen Common Memory Pool geladenen Programme können unter bestimmten Voraussetzungen während eines Anwendungslaufs dynamisch ausgetauscht werden. Näheres hierzu finden Sie in Kapitel „Programmaustausch im Betrieb".
Der physikalische Speicher wird besser ausgenutzt.
Mit dem Beenden der (letzten) Anwendung wird der Pool aufgelöst und die Programme werden - wie alle anderen Anwenderprogramme auch - entladen.
ACHTUNG!
Alle Module, Formate und Datenbereiche haben innerhalb eines Pools die gleiche Zugriffsberechtigung.
Programme in Common Memory Pools dürfen keine offenen Externverweise auf Adressen außerhalb des Common Memory Pools enthalten, die auf Module in anderen Common Memory Pools oder nicht-privilegierten Subsystemen im Klasse 5/6-Speicher zeigen. Diese CSECTs und ENTRYs werden nicht gefunden. Weiterhin dürfen offene Externverweise nur auf Shared Code zeigen, der für alle Tasks auf derselben Adresse liegt. Sehen Sie dazu die DSSM-Handbücher.