Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Strukturelle Maßnahmen zur Reduzierung des Betriebsmittelbedarfs

Es ist leider nur selten möglich, den Effekt jeder einzelnen der folgenden Maßnahmen genauer zu beziffern. Er hängt zu stark von der Struktur der Ladeobjekte, Subsysteme und Bibliotheken ab. Man kann jedoch in der Regel davon ausgehen, dass pro Maßnahme ein Mindestgewinn von 10% eintritt.

Bibliotheken reduzieren bzw. deren Inhalt optimieren

  • Mischen der alternativen Bibliotheken (hier Altlibs genannt)

    Durch Mischen der Altlibs z.B. in eine einzige Bibliothek (dies könnte sogar die spezifizierte Lade-Bibliothek sein) werden die Suchvorgänge in BLS/PLAM stark reduziert, wodurch z. T. deutlich mehr als 10% an Ein-/Ausgaben und CPU-Zeit eingespart werden.

    Das Mischen ist im Allgemeinen nur dann anzuraten, wenn keine namensgleichen CSECTs oder ENTRIES existieren.

  • Module aus Bibliotheken fest einbinden

    Falls sich die Inhalte der Altlibs und der spezifizierten Bibliothek nie bzw. nur selten ändern, empfiehlt es sich eventuell, die Module in das Ladeobjekt fest einzubinden. Dadurch wird der CPU-Bedarf beim Laden verringert. Allerdings wird durch das statische Binden das Ladeobjekt größer und damit werden in der Regel mehr Ein-/Ausgaben durchgeführt, was wiederum zur Verlängerung der Laufzeit führt. Diese Maßnahme ist demnach günstig, wenn nur kleine Module betroffen sind und wenn die Altlib(s) besonders viele Entries enthalten.

    Wird diese Variante der Performance-Steigerung gewählt, so ist natürlich darauf zu achten, dass der Bindevorgang bei jeder Altlib-Änderung erneut durchzuführen ist.

  • Mischform

    Falls sich z.B. der Inhalt von nur einer der beteiligten Altlibs häufig ändert, so empfiehlt es sich eventuell, die Mischform der beiden Methoden zu wählen.

Nachladen aus Shared-Code einschränken

  • Kein Nachladen/Binden aus Shared-Code

    Viele Programme benötigen kein Nachladen/Linken aus einem Subsystem/Shared-Programm oder User-Shared-Memory. Diese Programme sollten wie folgt gestartet werden:

    /START-EXECUTABLE-PROGRAM ...,RESOLUTION=(SHARE-SCOPE=*NONE),...

    Dadurch wird verhindert, dass BLS die Subsysteme nach dem passenden Entry durchsucht, und es ergibt sich eine z. T. erhebliche Einsparung an CPU-Zeit.

  • Nur aus System-Memory nachladen

    Dieser Fall ist der Default-Fall; es gibt keine Möglichkeit, die Suche nach dem Entry auf bestimmte Subsysteme oder nur auf Shared-Programme zu beschränken.

  • Nur aus User-Shared-Memory nachladen

    Beim Kommando START-EXECUTABLE-PROGRAM-kann man mit dem Parameter

    RESOLUTION(...,SHARE-SCOPE=*MEMORY-POOL(...)...)

    die Beschränkung auf User-Shared-Memory definieren. Es ist dabei zusätzlich möglich, sich auf ausgewählte Memory-Pools zu beschränken.

  • Vorladen des User-Shared-Memory

    Sofern möglich, sollten alle shareable Teile der benützten Anwendungen vorgeladen werden (Beispiel: FOR1-RTS). Dadurch werden sie nur einmal geladen; bei jedem weiteren Ladevorgang muss nur noch die (aufwandsarme) Verknüpfung durchgeführt werden. Damit können meist deutlich mehr als 10% der Ein-/Ausgaben und des CPU-Bedarfes eingespart werden.

ESD-Information eliminieren

  • Vollkommene Eliminierung

    Diese Maßnahme ist nur für "standalone"-Programme durchführbar. Dies sind LLMs, die von anderen Programmen nicht aufgerufen werden und die vollständig vorgebunden sind. Für sie sollte zur Beschleunigung des Ladevorgangs die ESD- und sonstigen BLS-Informationstabellen durch einen entsprechenden BINDER-Aufruf eliminiert werden. Dazu ist der BINDER wie folgt aufzurufen:

    /START-BINDER
    //START-LLM-UPDATE LIB=<orig-biblio>,ELEMENT=<elem-name>
    //SAVE-LLM LIB=<neue lade-biblio>,TEST-SUPPORT=*NO,MAP=*NO,
               SYMBOL-DICTIONARY=*NO,LOGICAL-STRUCTURE=*NO,
               RELOCATION-DATA=*NO
    //END
    

    Durch diese Parameterwahl werden nur die zum Laden notwendigen BLS-Strukturen eines einfachen Programmes erzeugt. Damit wird das Objekt kleiner. Beim Laden des Programmes werden somit CPU und weitere Ein-/Ausgaben eingespart. Alle für die Bearbeitung notwendigen Informationen sind danach nicht mehr vorhanden.
    Das bedeutet:

    • Diese Parameter können nicht für Ladeobjekte, die in mehrere Slices aufgeteilt sind, verwendet werden.

    • Mit solch einem Objekt können keine LLM-Updates durchgeführt werden.

    • Relocatable Objekte (z.B. als Teil eines Runtime-Systems) können nicht erzeugt werden.

    Die (zusätzliche) Parameter-Einstellung REQUIRED-COMPRESSION=*YES sollte nicht gewählt werden, da dadurch zwar max. 10% der Ein-/Ausgaben eingespart werden, aber etwa 40% mehr CPU benötigt werden.

  • Teilweise Eliminierung

    Beim Mischen von LLMs oder Sub-LLMs in einen Großmodul mit einer einzigen CSECT sollte bei der BINDER-Anweisung MERGE-MODULES angegeben werden, welche ESD-Informationen im Extern-Adressbuch bleiben sollen. Damit kann der BLS-Aufwand beim Laden stark reduziert werden.