Shared Code im Common Memory Pool (BS2000-Systeme)

In einen Common Memory Pool können Sie Objekte laden, die beim Binden des Anwendungsprogramms nicht statisch dazugebunden wurden. In einen Common Memory Pool können Sie mehrere Lademodule dynamisch laden.
Einen Common Memory Pool müssen Sie mit der KDCDEF-Anweisung MPOOL generieren.

MPOOL-Anweisung im Abschnitt "MPOOL - Common Memory Pool beschreiben (BS2000-Systeme)" Die wichtigsten Eigenschaften eines Common Memory Pools legen Sie mit den folgenden Operanden fest:

• poolname

  Namen des Common Memory Pools. Über diesen Namen ordnen Sie bei der Generierung dem Pool die Lademodule zu, deren Public Slice in den Pool geladen werden soll (siehe LOAD-MODULE-Anweisung).

• SCOPE=

  legt den Geltungsbereich des Pools fest (anwendungslokal mit SCOPE=GROUP oder anwendungsglobal mit SCOPE=GLOBAL). BLS unterstützt pro BS2000-Benutzerkennung maximal acht Common Memory Pools mit SCOPE=GROUP und acht Common Memory Pools mit SCOPE=GLOBAL.

• PAGE=

  Hexadezimale Adresse in der Form X’xxxxxxxx’.

  Werden globale Common Memory Pools gleichen Inhalts/Namens in mehreren UTM-Anwendungen verwendet, muss der Parameter PAGE=X’xxxxxxxx’ mit gleicher Adresse in allen Anwendungen angegeben werden. Die mit PAGE= angegebene Adresse ist so zu wählen, dass der damit reservierte Adressbereich in all diesen Anwendungen verfügbar ist.

• SIZE=

  legt die Größe des Common Memory Pools fest.

  Die Größe wird in Einheiten von 64 KB angegeben. Sie ist bei 24-Bit-Adressierung immer ein Vielfaches von 64 KB. Bei 31-Bit-Adressierung errechnet sich die Größe des Common Memory Pools durch n * 1MB >= SIZE * 64 KB (wobei n minimal gewählt wird).

Es sollte nur ein Common Memory Pool mit SCOPE=GROUP definiert werden. In diesen können Sie mehrere vorgebundene Lademodule laden. Damit wird die Zeit zum Einrichten und Laden der Common Memory Pools verkürzt und somit die für den Start der Anwendung benötigte Zeit minimiert.

Shareable Objekte generieren, die in einen Common Memory Pool geladen werden

Im folgenden wird beschrieben, wie Sie shareable Objekte generieren, die in einen Common Memory Pool geladen werden sollen.

• Aus Performancegründen sollten Sie, soweit möglich, alle shareable Teile eines Anwendungsprogramms, die in einen Common Memory Pool geladen werden sollen, zu einem Lademodul zusammenfassen.

• Das vom Compiler erzeugte shareable Code-Modul des Programms muss in einem LLM oder OM enthalten sein. LLMs mit Slices können Sie mit einer einzigen LOAD-MODULE-Anweisung generieren:

  LOAD-MODULE llm-name ,VERSION= version -
    ,LOAD-MODE=(POOL, poolname ,{STARTUP|ONCALL}-
    ,LIB= program-lib -
    ,ALTERNATE-LIBRARIES={YES|NO}

  Durch diese Anweisung wird die Public Slice des LLM in den Common Memory Pool poolname geladen, die Private Slice wird entweder bei Anwendungsstart (STARTUP) oder bei Programmaufruf (ONCALL) nachgeladen. Für die durch openUTM aufzurufenden Programme dieses LLMs sind zusätzlich PROGRAM-Anweisungen notwendig.

  Erzeugt ein Compiler für den shareable und den nicht-shareable Teil zwei getrennte Objektmodule, dann sollten Sie diese Module mit dem Binder zu einem LLM mit Slices vorbinden. Dieses LLM können Sie dann wie oben angegeben generieren.

  Alternativ dazu können Sie auch das shareable und das nicht-shareable Modul durch zwei LOAD-MODULE-Anweisungen generieren. Dies sollten Sie jedoch möglichst vermeiden, da sich diese beiden Module nicht ohne Konsistenzlücke austauschen lassen.

• Einen gemeinsam nutzbaren Datenbereich (Area), der in den Common Memory Pool geladen werden soll, müssen Sie mit einer AREA-Anweisung beschreiben. Die Area muss dann in dem Lademodul enthalten sein, der folgendermaßen generiert wird:

  LOAD-MODULE ar-share ,VERSION= version -
    ,LOAD-MODE=(POOL, poolname ,NO-PRIVATE-SLICE) -
    ,LIB= libname

  AREAs, denen beim Übersetzen oder durch den Binder das Attribut PUBLIC zugeordnet wurde, können auch zusammen mit anderen Modulen in ein LLM mit Slices vorgebunden werden. Dieses LLM kann dann folgendermaßen generiert werden:

  LOAD-MODULE llm-with-slices ,VERSION= version -
    ,LOAD-MODE=(POOL, poolname ,STARTUP)-
    ,LIB= libname

Beispiel

Das Beispiel geht davon aus, dass zum Übersetzen der COBOL85-Compiler verwendet wurde und dass der Compiler die Objekte in ein LLM abgelegt hat.

In den anwendungslokalen Pool LCPOOL sollen die shareable Module der COBOL-Teilprogramme TP1 und TP2 und der Datenmodul DATAMOD geladen werden. LCPOOL soll auf Adresse X’020000’ geladen werden, 128 KB belegen können und schreibgeschützt sein.

MPOOL LCPOOL,SIZE=2,SCOPE=GROUP,ACCESS=READ,PAGE=X'20000'
LOAD-MODULE LLM-LCPOOL,VERSION=1, - 
            LOAD-MODE=(POOL,LCPOOL,STARTUP), -
            LIB=libname    
PROGRAM PU1 ,LOAD-MODULE=LLM-LCPOOL,COMP=ILCS
PROGRAM PU2 ,LOAD-MODULE=LLM-LCPOOL,COMP=ILCS
AREA DATAMOD,LOAD-MODULE=LLM-LCPOOL

Die Objektmodule müssen Sie vor dem Start der Anwendung zu dem LLM LLM-LCPOOL vorbinden und dabei in der BINDER-Anweisung START-LLM-CREATION die OptionBY-ATTRIBUTES(PUBLIC=YES) angeben, wodurch das LLM in eine Public und eine Private Slice unterteilt wird. Das so erzeugte LLM müssen Sie in der Bibliothek libname bereitstellen.