Lademodule generieren (BS2000-Systeme)

Nur ein Teil der Anwendung muss statisch zum Anwendungsprogramm gebunden werden (Start-LLM, siehe openUTM-Handbuch „Einsatz von UTM-Anwendungen auf BS2000-Systemen“, Binden mit Binder). Die anderen Teile des Anwendungsprogramms können Sie in Form von dynamisch nachladbaren Lademodulen bereitstellen.

Bereits bei der KDCDEF-Generierung legen Sie fest, zu welchem Zeitpunkt die Anwendungsteile, die nicht statisch gebunden werden, nachgeladen werden und in welchen Speicherbereich sie geladen werden. Darüber hinaus legen Sie fest, welche Programmteile später im laufenden Betrieb austauschbar sein sollen.

Sie müssen für jedes Lademodul der Anwendung, das nicht zum statisch gebundenen Teil der Anwendung gehört, genau eine LOAD-MODULE-Anweisung absetzen. Dabei geben Sie an, wann das Lademodul dazugebunden und wohin es geladen werden soll. Die Reihenfolge der LOAD-MODULE-Anweisungen gibt die Reihenfolge an, in der die Lademodule geladen werden (siehe Beschreibung der LOAD-MODULE-Anweisung im Abschnitt "LOAD-MODULE - Lademodule (BLS) beschreiben (BS2000-Systeme)" und im openUTM-Handbuch „Einsatz von UTM-Anwendungen auf BS2000-Systemen“, Module laden).

Die Zuordnung von nicht statisch gebundenen Objekten (Teilprogramme und Areas) zu den Lademodulen wird ebenfalls bei der Generierung festgelegt. In den PROGRAM- und AREA-Anweisungen, in denen Teilprogramme bzw. Areas generiert werden, geben Sie dazu im Operand LOAD-MODULE den Namen des Lademoduls an, das dieses Teilprogramm bzw. die Area enthält und das Sie mit einer LOAD-MODULE-Anweisung generiert haben.

ACHTUNG!
Ob die mit der Anweisung LOAD-MODULE und den Operanden LOAD-MODULE in der PROGRAM- und AREA-Anweisung definierte Zuordnung der tatsächlichen Aufteilung der Lademodule in den Bibliotheken entspricht, kann von openUTM nicht verifiziert werden. openUTM verlässt sich beim Nachladen der Lademodule und beim Programmaustausch auf die in der Generierung gemachten Angaben. Sie müssen deshalb sicherstellen, dass die von Ihnen verwendeten Bindeprozeduren für die einzelnen Teile des Anwendungsprogramms mit den in der Generierung gemachten Angaben übereinstimmen. Andernfalls kann openUTM nicht sicherstellen, dass mit einem bestimmten Lademodul das gewünschte Programm in den Arbeitsspeicher geladen wird.

Die Lademodule werden bei der Generierung wie folgt beschrieben:

LOAD-MODULE-Anweisung im Abschnitt "LOAD-MODULE - Lademodule (BLS) beschreiben (BS2000-Systeme)" Die Eigenschaften der Lademodule werden mit den folgenden Operanden festgelegt:

• lmodname

  Name des Lademoduls. Über diesen Namen erfolgt bei der Generierung die Zuordnung der Objekte (Teilprogramme, Areas) zu den Lademodulen.

  Sie dürfen nur die Namen von OMs oder LLMs angeben. Aus Performancegründen unterstützt openUTM nicht das Nachladen über CSECT- oder ENTRY-Namen.

• LOAD-MODE=

  gibt an, wann ein Lademodul geladen werden soll, und legt den Speicherbereich fest, in den das Lademodul geladen werden soll. Die Lademodule können in den Standardkontext im tasklokalen Speicher, in einen Common Memory Pool oder in den Systemspeicher geladen werden.

  Die Teile des Anwendungsprogramms können:

  • statisch zum Anwendungsprogramm gebunden werden (LOAD-MODE=STATIC)

    Das ist der Teil des Anwendungsprogramms, der mit dem Kommando START-EXECUTABLE-PROGRAM bzw. LOAD-EXECUTABLE-PROGRAM in den Standardkontext der Anwendung geladen wird.

  • beim Start der Anwendung dynamisch in den Standardkontext des tasklokalen Speichers nachgeladen werden (LOAD-MODE=STARTUP)

    Das sollten Programmteile sein, die ständig von der UTM-Anwendung benötigt werden oder Externverweise zu shareable Teilen der Anwendung enthalten.

  • erst beim ersten Aufruf in den Standardkontext des tasklokalen Speichers geladen werden (LOAD-MODE=ONCALL)

    Das sollten Programmteile sein, die von der Anwendung nicht ständig benötigt werden.

  • in einen Common Memory Pool geladen werden (LOAD-MODE=(POOL,poolname,...))

    Der Common Memory Pool muss mit einer MPOOL-Anweisung generiert werden, siehe dazu Abschnitt "Shared Code im Common Memory Pool (BS2000-Systeme)".
    In einen Common Memory Pool sollten Sie Programmteile laden, die von allen Prozessen einer UTM-Anwendung gemeinsam benutzt werden können, wie z.B. die shareable Teile Ihrer Teilprogramme oder auch Formate oder Datenbereiche.

    Enthält ein LLM Public und Private Slices, dann wird die Public Slice in einen Common Memory Pool und die Private Slice in den Standardkontext im tasklokalen Speicher geladen. Dabei können Sie angeben, ob der non-shareable Teil beim Start der Anwendung nachgeladen werden soll (LOAD-MODE=(POOL, poolname, STARTUP)) oder erst zum Zeitpunkt des Teilprogrammaufrufs (LOAD-MODE=(POOL, poolname, ONCALL)). Zum Generieren von shared Code siehe auch Abschnitt "Shared Code und Common Memory Pools generieren (BS2000- Systeme)".

  • als nicht-privilegiertes Subsystem in den Systemspeicher geladen werden.

    Diese Anwendungsteile müssen vor dem Start der Anwendung vom BS2000-Systemverwalter in den Systemspeicher geladen werden.

    Die Private Slice zu einem shareable Teil, der sich in nicht-privilegierten Subsystemen befindet, kann man zum statischen Teil des Anwendungsprogramms binden, beim Start der Anwendung oder erst beim ersten Aufruf nachladen.
    Wie Sie den nicht-shareablen Teil generieren müssen ist im Abschnitt "Shared Code im Systemspeicher (BS2000-Systeme)" beschrieben.

• LIB=

  gibt an, aus welcher Bibliothek das Lademodul geladen werden soll

  Sie können Bindemodulbibliotheken (OML) oder Programmbibliotheken (PL), die Elemente vom Typ R oder L enthalten, angeben.

• VERSION=

  gibt an, welche Version eines Lademoduls geladen werden soll

  In einer Programmbibliothek können gleichzeitig mehrere Versionen eines Elements enthalten sein. Mit der Versionsangabe legen Sie fest, welche Version eines Elements geladen werden soll.

• ALTERNATE-LIBRARIES=

  gibt an, ob mit Autolink gebunden werden soll.

  Die shareable Teile der Lademodule werden stets ohne die Autolink-Funktion geladen. Bei den nicht-shareable Teilen können Sie über die ALTERNATE-LIBRARIES= steuern, ob mit oder ohne Autolink-Funktion geladen werden soll.

  Geben Sie ALTERNATE-LIBRARIES=NO an, dann unterdrückt openUTM beim Nachladen und beim Programmaustausch die Autolink-Funktion des BLS. Das Lademodul darf ausschließlich offene Externverweise auf Programmteile besitzen, die zum Zeitpunkt des Ladens dieses Moduls bereits im Arbeitsspeicher vorhanden sind.
  Bei Lademodulen, die mit POOL oder STARTUP generiert werden, ist die Reihenfolge der LOAD-MODULE-Anweisungen bei der Generierung ausschlaggebend für die Auflösung der unbefriedigten Externverweise beim Laden. Die Reihenfolge der LOAD-MODULE-Anweisungen gibt die Reihenfolge an, in der die Lademodule geladen werden.

  ALTERNATE-LIBRARIES=YES bewirkt, dass beim Laden die Module, die zusätzlich benötigt werden, nachgebunden werden. Die Autolink-Funktion darf nur für Module des Laufzeitsystems, nicht jedoch für benutzereigene Module verwendet werden, da per Autolink geladene Module bei einem nachfolgenden Austausch nicht mehr entladen werden.

Module, die weder Teilprogramme des Anwendungsprogramms noch Areas sind (z.B. die Module der Laufzeitsysteme der Programmiersprachen), brauchen Sie, selbst wenn diese Module nicht statisch eingebunden sind, nicht einzeln mit dem Generierungstool KDCDEF als nachzuladende Module zu deklarieren. Sie können diese Module zu größeren Lademodulen (LLM) vorbinden und müssen nur den Namen des Lademoduls in der LOAD-MODULE-Anweisung generieren.

Die Zuordnung der Teilprogramme und Areas zu den Lademodulen wird bei der Generierung wie folgt festgelegt:

AREA-Anweisung im Abschnitt "AREA - Zusätzliche Datenbereiche (Areas) definieren" PROGRAM-Anweisung im Abschnitt "PROGRAM - Teilprogramme definieren" Die Zuordnung zu einem Lademodule wird mit folgendem Operanden festgelegt:

• LOAD-MODULE=

  Name des Lademoduls (lmodname aus der LOAD-MODULE-Anweisung), zu dem das Programm gehört.

  Teilprogramme, Module und Datenbereiche müssen statisch zum Anwendungsprogramm gebunden werden, wenn sie keinem Lademodul zugeordnet sind.

  Die Administrationsmodule (z.B. das Administrationsprogramm KDCADM) sollten entweder statisch zum Start-LLM oder zu einem eigenen Lademodul gebunden werden. Dieses Lademodul muss beim Start der Anwendung geladen werden (LOAD-MODE=STARTUP). Dasselbe gilt für die Event-Exits START, SHUT, INPUT und FORMAT und die Event-Services BADTAC, MSGTAC und SIGNON.

Wenn bei der Generierung Angaben zu Objekten in den Anweisungen AREA, LOAD-MODULE, MPOOL, PROGRAM und TAC geändert werden, muss nur eine neue KDCFILE erzeugt werden. Der nächste Start der Anwendung muss dann mit der neuen KDCFILE erfolgen.