Die Ladezeit eines POSIX-Programms hängt erheblich von der Größe des Programms ab und macht in der Regel mindestens ca. 35% der Gesamtausführungszeit aus. Zurückzuführen ist dies größtenteils auf Bibliothekszugriffe in DMS/PLAM, die auf Anforderung von BLS durchgeführt werden. Durch den Einsatz von DAB lassen sich die Programmladezeiten erheblich verkürzen. Dies allerdings nur, wenn alle Bibliotheken, die an einem Ladevorgang beteiligt sind, auch tatsächlich erfasst werden.
Als Alternative wurde der POSIX-Lader entwickelt. Dieser betrachtet nicht Bibliotheken, sondern ablaufbereite Core-Images im Speicher nach einem kompleten Ladevorgang. Die Core-Images werden in Programm-Caches gesichert und für jeden weiteren Ablauf in den Speicher kopiert. Dies verkürzt die Ladezeiten im Vergleich zu BLS ohne DAB um bis zu 80% und im Vergleich zu BLS mit DAB um bis zu 65%.
In der folgenden exemplarischen Abbildung sind die normierten Ladezeiten des Beispielprogramms snet in POSIX relativ zueinander dargestellt.
Bild 29: Ladezeiten des Beispielprogramms snet
Der POSIX-Lader bietet zusätzlich noch den Vorteil, dass einzelne Programme aus dem UFS-Dateisystem je nach individueller Anforderung zwischengespeichert werden können, und zwar systemglobal, benutzerspezifisch oder sitzungsspezifisch.
Der POSIX-Lader ist Bestandteil des POSIX-Subsystems und gliedert sich in zwei Teile:
Privilegierter Teil
Dieser Teil wird vom Superuser verwaltet. Gehalten wird ein globaler Programm-Cache in skalierbarer Größe zur Speicherung ablauffähiger Core-Images von POSIX-Programmen. Diese Core-Images werden entweder automatisch beim ersten Aufruf eines POSIX-Programms aus einer der festgelegten Bibliotheken in den Programm-Cache gespeichert ("impliziter Linkvorgang") oder explizit vom Superuser mit Hilfe des Kommandos posdbl –b. Zum Laden eines gespeicherten Programms steht der globale Programm-Cache allen Benutzern zur Verfügung.
Nicht privilegierter Teil
Dieser Teil kann von jedem Benutzer verwendet werden. Es können benutzerspezifische Programm-Caches gehalten werden, die vom jeweiligen Nutzer selbst zu verwalten sind. Der Scope eines benutzerspezifischen Programm-Caches ist wahlweise
USERWIDE alle Prozesse einer User-ID sind angeschlossen oder SESSIONWIDE
alle Prozesse einer Sitzung sind angeschlossen.
Core-Images werden in benutzerspezifischen Programm-Caches mit Hilfe des Kommandos pdbl gespeichert. Zum Laden eines gespeicherten Programms werden die benutzerspezifischen Programm-Caches vorrangig herangezogen. Wird in keinem der Caches ein dem Programm entsprechendes Core-Image gefunden, so wird das Programm wie üblich über BLS geladen.
Folgende Vorgänge sind bei der Nutzung des POSIX- Laders zu unterscheiden:
Initialisierung (Programm-Cache einrichten)
Der globale Programm-Cache kann auf zwei Arten eingerichtet werden:
Wenn der Wert des DBLPOOL-Parameters in der POSIX-Informationsdatei größer als 0 ist, wird der globale Programm-Cache automatisch beim Start des Subsystems in der entsprechenden Größe (in MB) eingerichtet.
Ist der DBLPOOL-Wert gleich 0, kann der globale Programm-Cache explizit mit dem Kommando posdbl eingerichtet werden, und zwar in der zuvor mit dem Kommando usp vereinbarten Größe.
Die benutzerspezifischen Programm-Caches richtet der jeweillige Benutzer mit Hilfe des Kommandos pdbl ein.
Linkvorgang (Core-Image erstellen)
Mit Hilfe der Kommandos posdbl bzw. pdbl wird das Programm geladen und das Core-Image in den Programm-Cache kopiert. Für den globalen Programm-Cache wird u. U. auch ein impliziter Linkvorgang beim Systemcall exec() durch den POSIX-Kernel ausgelöst.
Ladevorgang (Core-Image laden und starten)
In den Programm-Caches wird nach einem Core-Image gesucht und das Core-Image beim Systemcall exec() durch den POSIX-Kernel zum Ablauf in den Speicher kopiert.
Administration (Programm-Caches verwalten)
Mit Hilfe der Kommandos posdbl bzw. pdbl werden Programm-Caches aktiviert bzw. deaktiviert, der Status abgefragt, Core-Images aufgelistet und gelöscht sowie Programm-Caches insgesamt gelöscht.
Die korrekte Funktion eines aus dem Programm-Cache geladenen Core-Images kann nicht gewährleistet werden, wenn dieses während des Ablaufs versucht, Programmteile dynamisch nachzuladen.