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 i.d.R. davon ausgehen, dass pro Maßnahme ein Mindestgewinn von 10% eintritt.

Bibliotheken reduzieren bzw. deren Inhalt optimieren

• Mischen der Altlibs

  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 i.A. nur dann anzuraten, wenn keine namensgleichen CSECTs oder ENTRIES existieren. Falls doch, so muss beim Mischen darauf geachtet werden, dass die "richtigen" CSECTs oder ENTRIES übernommen werden.

• 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 i.d.R. 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 ...,
     DBL-PARAMETERS=*PARAMETERS(RESOLUTION=*PARAMETERS(SHARE-SCOPE=*NONE)),
     ... 
  

  Dadurch wird verhindert, dass DSSM von BLS aufgerufen wird, um die Subsysteme nach dem Entry zu durchsuchen, 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 DSSM-Suche nach dem Entry auf bestimmte Subsysteme oder nur auf Shared-Programme zu beschränken.

• Nur aus User-Shared-Memory nachladen

  Bei /START-EXECUTABLE-PROGRAM bietet folgender Parameter die Beschränkung auf User-Shared-Memory:

  DBL-PARAMETERS= *PARAMETERS(RESOLUTION=*PARAMETERS(SHARE-SCOPE=*MEMORY-POOL(...)))

  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 benutzten Anwendungen vorgeladen werden (Beispiel: FOR1-RTS). Dadurch werden sie nur einmal geladen, und 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=<original-lib>,ELEMENT=<elem-name>
  //SAVE-LLM LIB=<new-lib>,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 Programms 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, aber etwa 40% mehr CPU-Zeit 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.