Shared Code im Systemspeicher

Shareable Teile der Anwendungsteilprogramme und Teile der Laufzeitsysteme können mit Hilfe der im BS2000 vorgesehenen Schnittstellen als shareable Programme in nichtprivilegierte Subsysteme geladen werden.

Shared Code, der in nicht-privilegierte Subsysteme geladen ist, kann während des Betriebs der Anwendung ausgetauscht werden.

Die shareable Module müssen durch den Administrator in den Speicher geladen werden, bevor die Anwendung gestartet wird. Sehen Sie hierzu auch die Hinweise am Ende dieses Abschnitts. Im Gegensatz zu Shared Code in Common Memory Pools, der unter Kontrolle von openUTM geladen und ausgetauscht werden kann, können Sie die shareable Module im Systemspeicher nicht selbst verwalten.

Nicht-shareable Teile der Teilprogramme müssen mit der PROGRAM-Anweisung beschrieben und ggf. mit der LOAD-MODULE-Anweisung einem Lademodul zugeordnet werden.
Das Lademodul bzw. dessen private Slice wird beim Start des Anwendungsprogramms dynamisch in den task-lokalen Speicher (Klasse-6-Speicher) geladen. Über die Externbezüge zu den shareable Modulen werden die Verknüpfungen in den Shared Code dynamisch hergestellt.
Die Lademodule (OM-Format), die die shareable Module des Teilprogramms enthalten, müssen nicht zusammen mit den Lademodulen, die die nicht-shareable Programmteile enthalten, in einer Programmbibliothek stehen.

Hinweise

• Subsysteme sollten im LLM-Format erstellt werden, da diese Subsysteme im laufenden Betrieb der Anwendung ohne Konsistenzlücke ausgetauscht werden können. Beim Austausch des Subsystems wird eventuell der Public Slice des alten LLMs in den tasklokalen Teil des Anwendungsprogramms geladen, bis auch der Private Slice ausgetauscht wird (z.B. mit KDCPROG initiiert).

  Subsysteme im OM-Format haben hingegen beim Austausch im laufenden Betrieb eine Konsistenzlücke, die zwischen dem DSSM-Subsystemkommando

  START-SUBSYSTEM SUBSYSTEM-NAME=subsystemname -
                 , VERSION=new-version         -
                 , VERSION-PARALLELISM=*EXCHANGE-MODE
  

  und dem UTM-Administrationskommando (oder einen entsprechenden KDCADMI-Aufruf an der Programmschnittstelle zur Administration)

  KDCPROG LOAD-MODULE=load-module,VERSION=new-version

  existiert. Hier kann es beispielsweise vorkommen, dass nach dem DSSM-Kommando und vor dem UTM-Administrationskommando ein UTM-Anwendungsprogramm mit PEND ER beendet wird und die betroffene Task des UTM-Anwendungsprogramms mit dem alten Private Slice und einem neuen Public Slice in einem neuen Subsystem startet.

• Beim Austausch von Subsystemen verschiedener Versionen, deren Module in der gleichen Bibliothek stehen (Bedingung zum Austausch von Lademodulen bei openUTM), ist darauf zu achten, dass unterschiedliche LINK-ENTRYs angegeben werden, da sonst das DSSM ggf. den Austausch nicht durchführen kann.

• Beim Erstellen eines Subsystems sollte das entsprechende LLM-Format (z.B. Format 2) verwendet werden, da hier nur ein Subsystemeintrag angegeben werden muss, siehe auch „BINDER Benutzerhandbuch“.