Der DBL sucht das Modul, das in den Kommandos START/LOAD-EXECUTABLE-PROGRAM (bzw. START/LOAD-PROGRAM) oder im Makroaufruf BIND angegeben wurde, in verschiedenen Containern.
Der angegebene Modulname kann sein:
der Name einer CSECT oder eines ENTRY, die nicht maskiert sein dürfen,
der externe Name eines Bindemoduls oder eines LLMs,
der Name eines Programms im Shared Code im Klasse-3/4/5-Speicher (geladen als unprivilegiertes Subsystem),
der Name eines Programmes im Shared Code des Benutzers.
Der Suchvorgang verläuft in folgenden Stufen:
Suche im Link-Kontext, der vom Benutzer angegeben wurde (siehe "Kontext als Umgebung für das Binden und Laden"). Findet der DBL nicht maskierte CSECTs oder ENTRYs, die dem angegebenen Symbolnamen im Ladeaufruf entsprechen, dann übergibt er die Startadresse an die Benutzertask und der Ladevorgang wird beendet.
Die Suche im Link-Kontext erfolgt nur beim Makroaufruf BIND.
Suche im Shared Code des Benutzers, der mit dem ASHARE-Makro des DBL in den Common Memory Pool geladen wurde. Der Suchvorgang endet, wenn der DBL ein gemeinsam benutzbares Programm (definiert mit dem Parameter PROGRAM im ASHARE-Makro) oder eine nicht maskierte CSECT bzw. ein ENTRY mit diesem Namen findet. Eine Startadresse wird übergeben und der Ladevorgang wird abgeschlossen.
Die Suche im Shared Code des Benutzers wird nur im RUN-MODE=*ADVANCED ausgeführt.
Die Suche im Shared Code des Benutzers wird nicht ausgeführt, wenn beim Kommando START/LOAD-EXECUTABLE-PROGRAMM NAME-SCOPE=*ELEMENT angegeben ist.
In Common Memory Pools wird nur dann gesucht, wenn der Benutzer SHARE-SCOPE=*MEMORY-POOL(...)/*ALL angegeben hat, da Default-Wert für SHARE-SCOPE=*SYSTEM-MEMORY ist. Die Suche kann auf Common Memory Pools mit einem definierten Geltungsbereich eingeschränkt oder ganz unterdrückt werden (SHARE-SCOPE=*NONE).
Suche im Shared Code des Systems, der aus den unprivilegierten Subsystemen im Klasse-3/4/5-Speicher besteht (siehe Handbuch „Verwaltung von Subsystemen“ [10]). Werden nicht maskierte CSECTs oder ENTRYs gefunden, die dem angegebenen Symbolnamen im Ladeaufruf entsprechen, übergibt der DBL die Ladeadresse an die Benutzertask und der Ladevorgang wird beendet. Der DBL baut also eine Verbindung zwischen der Benutzertask und dem Subsystem auf.
Im RUN-MODE=*ADVANCED kann der Benutzer im Ladeaufruf das Durchsuchen der unprivilegierten Subsysteme unterdrücken (Operand SHARE[-SCOPE]=*NONE).Die Suche im Shared Code des Systems wird nicht ausgeführt, wenn beim Kommando START/LOAD-EXECUTABLE-PROGRAMM NAME-SCOPE=*ELEMENT angegeben ist.
Durchsuchen der Bibliothek, die der Benutzer im Ladeaufruf angegeben hat (Operand LIBRARY bzw. LIBNAM@/LIBNAM/LIBLINK). Wenn im RUN-MODE= *ADVANCED eine solche Bibliothek nicht angegeben wurde, aber der Link-Name LSLIB einer Bibliothek zugewiesen wurde, dann verwendet der DBL diese Standardbibliothek mit dem Link-Namen BLSLIB. Ist die angegebene Bibliothek fehlerhaft oder existiert sie nicht, so wird die Verarbeitung mit einer Fehlermeldung abgebrochen.
Durchsuchen von alternativen Bibliotheken.
Es gibt zwei Gruppen von alternativen Bibliotheken:
Alternative Bibliotheken, die über Dateikettungsnamen vereinbart wurden.
Hierbei unterscheidet man zwischen
alternativen Benutzerbibliotheken mit den Dateikettungsnamen BLSLIBnn und
alternativen Systembibliotheken mit den Dateikettungsnamen $BLSLBnn Alternative Systembibliotheken werden für Komponenten des von der Fujitsu ausgelieferten Laufzeitsystems benötigt. Sie werden über den Dateikettungsnamen $BLSLBnn (00
<=nn<=99) von der jeweiligen Laufzeitkomponente selbst zugewiesen. Der Benutzer hat darauf keinen Einfluss. Die Dateikettungsnamen der alternativen Systembibliotheken werden von der Software-Entwicklung der Fujitsu Technology Solutions GmbH verwaltet und sind ausschließlich für deren Softwareprodukte reserviert.
System- und Benutzer-Tasklibs
Hierbei handelt es sich um Bibliotheken mit dem Namen TASKLIB oder um eine Bibliothek, die mit dem Kommando SET-TASKLIB zugewiesen wurde.
Über Dateikettungsnamen vereinbarte alternative Bibliotheken werden in folgender Reihenfolge durchsucht:
Alternative Systembibliotheken mit den Dateikettungsnamen $BLSLB00 .. 49
Alternative Bibliotheken, die vom Benutzer mit dem Dateikettungsnamen BLSLIBnn (00
<=nn<=99) zugewiesen wurden.Alternative Systembibliotheken mit den Dateikettungsnamen $BLSLB50 .. 99
Innerhalb einer Gruppe von Bibliotheken werden diese nach aufsteigenden Nummern „nn“ durchsucht.
System- und Benutzertasklibs werden in folgender Reihenfolge durchsucht:
Die Bibliothek, die vom Benutzer mit dem Kommando SET-TASKLIB zugewiesen wurde
Die Bibliothek „$userid.TASKLIB“
oder, falls diese nicht existiert:
Die Bibliothek „$defluid.TASKLIB“.
Dabei ist „defluid“ der Name der System-Standardkennung (Wert des Klasse-2-Systemparameters DEFLUID, siehe Handbuch „Einführung in die Systembetreuung“ [9]).
Welche alternativen Bibliotheken durchsucht werden, hängt davon ab, auf welche Weise der Ladevorgang durchgeführt wird:
Laden mit START/LOAD-EXECUTABLE-PROGRAM
oder mit dem BIND-Makro (mit INTVERS=SRVxxx, wobei xxx>=002)Der Benutzer kann mit dem Operanden ALTERNATE-LIBRARIES bzw. ALTLIB festlegen, welche der genannten Bibliotheken in welcher Reihenfolge durchsucht werden.
Laden mit START/LOAD-PROGRAM und RUN-MODE=*ADVANCEDoder mit dem BIND-Makro (INTVERS=BLSP2/SRV001)
Nur die mit den Dateikettungsnamen BLSLIBnn bzw. $BLSLBnn vereinbarten alternativen Bibliotheken werden durchsucht, falls ALTERNATE-LIBRARIES=*YES angegeben wurde.
Laden mit START/LOAD-PROGRAM und RUN-MODE=*STD
Nur die System- und Benutzer-Tasklibs werden durchsucht.
Auswahl und Zuweisung einer Programmversion
ES ist möglich, eine Programmversion auszuwählen, die der DBL bei Suchen nach der Primäreingabe und bei der Befriedigung von Externverweisen verwenden soll. Ein Programm ist aus der Sicht von DBL eine Ladeeinheit mit einer bestimmten Version. Alle Programmdefinitionen (CSECT, ENTRY, COMMON, ...), die in der Ladeeinheit enthalten sind, erben diese Version.
Die Auswahl einer Programmversion ist auf zwei Arten möglich:
Versionsauswahl vor dem Laden und Starten:
Mit dem Kommando SELECT-PROGRAM-VERSION oder dem Makroaufruf SELPRGV wird die Version einer Ladeeinheit ausgewählt, die DBL bei späteren Ladeaufrufen verwenden soll. Die Ladeeinheit muss zum Zeitpunkt der Versionsauswahl noch nicht geladen sein; es können aber auch schon mehrere Versionen dieser Ladeeinheit geladen sein.
Versionsauswahl im Ladeaufruf:
Beim Ladeaufruf mit den Kommandos LOAD- und START-EXECUTABLE-PROGRAM (bzw. LOAD- und START-PROGRAM) oder mit den Makros BIND und ASHARE kann eine Version angegeben werden (Operand PROGRAM-VERSION bzw. PGMVERS). Der DBL sucht dann unter den bereits geladenen Objekten eine Ladeeinheit mit diesem Namen und genau dieser Version. In diese Suche werden auch DSSM-Subsysteme einbezogen. Der DBL betrachtet die Subsystemversion als Programmversion und berücksichtigt alle „Connectable Entries“ (siehe "Shared Code des Systems") des Subsystems.
Die Versionsauswahl im Ladeaufruf überschreibt eine vorhergehende Versionsauswahl.
Der DBL weist einer zu ladenden Ladeeinheit eine Version zu, wenn er unter den bereits geladenen Objekten nicht die ausgewählte Version (siehe 1. und 2.) findet.
Mit dem Makro GETPRGV kann der Benutzer abfragen, welche Version für ein Programm ausgewählt ist.
Die Programmversion kann auch beim Entladen und Entbinden angegeben oder als Binde- und Ladeinformation ausgegeben werden.