Binderverzeichnisse erleichtern eine zweistufige Kompilierung von ILE-Objekten. Anstatt alle verwendeten Module und Service-Programme im Binder-Schritt einzeln aufzulisten, können Binderverzeichnisse verwendet werden. Binder-Verzeichnis enthalten eine Liste von Modulen und/oder Service-Programmen, die während des Binder-Schritts durchsucht werden, um die aufgerufenen Prozeduren zu lokalisieren, um dann entweder die entsprechenden Module oder die Signaturen der Service-Programme einzubinden. Mit Hilfe des IBM Services BINDING_DIRECTORY_INFO können Binder-Verzeichnisse analysiert werden. Wie das funktioniert, wird in diesem Artikel gezeigt.
Je modularer die Anwendung wird, um so mehr exportierte Prozeduren werden erstellt. Die exportierten Prodzeduren sind i.d.R. in unterschiedlichen Quellen-Teil-Dateien und damit in unterschiedlichen Modulen hinterlegt. Die Module wiederum werden in unterschiedliche Service-Programme gebunden.
Die exportierten Prozeduren, auf die in den zu erstellenden bzw. zu bindenden Modulen zugegriffen wird, müssen zum Erstellungszeitpunkt lokalisiert werden können, anderenfalls ist eine Kompilierung nicht möglich.
Die zubindenen Service-Programme und/oder Module können bei einer 2-stufigen Kompilierung in den Binder-Befehlen CRTPGM (Programm erstellen) bzw. CRTSRVPGM (Service-Programm erstellen) aufgelistet werden. Bei vielen Service-Programmen und/oder Modulen verliert man jedoch leicht die Übersicht und vergißt schon einmal das eine oder andere Service-Programm oder Modul aufzulisten und schon kann das (Service-)Programm nicht gebunden werden.
Dieses Problem kann man durch die Verwendung von Binder-Verzeichnissen umgehen.
In einem Binderverzeichnis können die Service-Programme und/oder Module hinterlegt werden. Diese Binderverzeichnisse können sowohl in den Binder-Befehlen als auch in dem Compile-Befehl CRTBNDRPG (RPG-Binderprogramm erstellen) angegeben. werden. Es ist außerdem möglich Binder-Verzeichnisse über das Schlüssel-Wort BNDDIR in den H-Bestimmungen von RPG-Quellen zu hinterlegen.
Zum Erstellungszeitpunkt werden die Binderverzeichnisse bzw. die darin enthaltenen Module und Service-Programme nach den aufgerufenen Prozeduren durchsucht und im Anschluss wird entweder das entsprechende Modul oder die Signatur des Service-Programs und die laufende Nr. der exportierten Prozedur eingebunden.
Binderverzeichnisse werden lediglich während des Binder-Schrittes benötigt, um die zubindenden Service-Programme bzw. Module zu lokalisieren. Zur Laufzeit werden keine Binderverzeichnisse mehr gebraucht, da die Module oder die Signaturen der Prozeduren in den Service-Programme im (Service-)Programm-Objekt eingebunden sind. Dadurch sind Binderverzeichnisse auf einer Produktiv-Maschine weder notwendig noch müssen sie übertragen oder entsprechend angepasst werden.
Es stellt sich nun die Frage, welche Binderverzeichnisse gibt es überhaupt und welche Module und/oder Service-Programme sind in welchen Binderverzeichnissen hinterlegt.
BINDING_DIRECTORY_INFO
Die View BINDING_DIRECTORY_INFO liefert diese Informationen, die weitgehend den Informationen entsprechen, die mit dem CL-Befehl DSPBNDDIR (Binderverzeichnis anzeigen) angezeigt werden können.
Detaillierte Informationen über die View BINDING_DIRECTORY_INFO sind unter diesem Link zu finden.
In dem folgenden Beispiel werden die Einträge in allen Binderverzeichnissen angezeigt.
Quelle: HauserIdealerweise sollte man pro Anwendung oder Bibliothek maximal 2 Binderverzeichnisse, eines für Service-Programme und ein anderes für Module haben.
Es gibt jedoch auch andere Ansätze, z.B. dergestalt, dass pro (Service-)Program ein eingenes Binderverzeichnis erstellt wird, in dem alle zur Ausführung bzw. Erstellung des (Service-)Programms notwendigen Module und/oder Service-Programme hinterlegt werden. In diesem Fall kann man davon ausgehen, dass es a) eine Vielzahl von Binderverzeichnissen gibt und b) Service-Programme und/oder Module in mehreren Binderverzeichnissen aufgelistet sind. Was wiederum einen erhöhten Wartungsaufwand und eine erhöhte Fehleranfälligkeit bedingt.
In solchen Fällen muss man natürlich zunächst einmal feststellen können, welche Binder-Verzeichnisse in welchen Bibliotheken vorhanden sind.
In der folgenden Abfrage werden alle Binderverzeichnisse, die sich in Bibliotheken befinden, die mit HS beginnen aufgelistet.
Das Ergebnis zeigt u.a. dass Binderverzeichnisse mit dem gleichen Namen und unterschiedlichen Bibliotheken vorhanden sind. Ob die Einträge in diesen Binderverzeichnissen identisch sind, wird an dieser Stelle nicht geprüft.
Quelle: HauserSofern man mit einem oder zwei Binderverzeichnissen pro Anwendung oder Bibliothek arbeitet, sollte ein Service-Programm oder Modul nur in einem einzigen Binderverzeichnis hinterlegt sein. Wenn man allerdings pro (Service-)Programm ein eigenes Binderverzeichnis anglegt, wird das gleiche Service-Programm bzw. Modul zwangsläufig in mehrere Binderverzeichnisse eingetragen.
In dem folgenden Beispiel werden alle Service-Programme ermittelt, die in Binderverzeichnissen, die mit BX, DW oder WX beginnen hinterlegt sind und die in mehr als einem von diesen Binderverzeichnissen eingetragen sind.
Quelle: HauserJetzt wäre es interessant zu wissen, in welchen Binderverzeichnissen diese Service-Programme eingetragen sind.
In dem folgenden Beispiel wird die SQL-Abfrage aus dem vorhergehenden Beispiel als Common-Table-Expresson X hinterlegt. Im endgültigen SELECT-Statement wird diese Common-Table-Expression mit der View BINDING_DIRECTORY_ENTRY über den Binder-Verzeichnis-Eintrag (ENTRY), den Typ des Binderverzeichnis-Eintrags (ENTRY_TYPE – *SRVPGM oder *MODULE) und die Bibliothek des Binderverzeichnis-Eintrags (ENTRY_LIBRARY) verknüpft.
Quelle: HauserDas Ergebnis zeigt, dass die meisten Service-Programme in dem Binderverzeichnis BXBNDDIR eingetragen sind. Dieses Binderverzeichnis befindet sich sowohl in der Bibliothek BXOBJ als auch in der Bibliothek BXOBJOLD. Da es sich bei der Bibliothek BXOBJOLD um eine Sicherungsbibliothek handelt, sind die doppelten Einträge zulässig.
Das Service-Programm DWXUSLOBJ wurde sowohl in dem Binderverzeichnis DWBNDDIR in der Bibliothek DIRWEB hinterlegt und ebenso in der Bibliothek TESTBHASRC in dem Binderverzeichnis GCBNDDIR. Bei der Bibliothek TESTBHASRC handelt es sich um eine Test-Bibliothek, die völlig unabhängig von den aktuellen Anwendungen ist. Somit ist also auch dieses Duplikat zulässig.
Wenn man nur mit einem oder zwei Binderverzeichnissen für die ganze Anwendung oder für eine bestimmte Bibliothek arbeitet, sollten auch alle Service-Programme und/oder Module in diesen Binderverzeichnissen eingetragen sein.
Über das folgende SQL-Statement wird geprüft, ob alle Service-Programme in der Bibliothek DIRWEB auch in dem Binderverzeichnis DWBNDDIR in der Bibliothek DIRWEB eingetragen sind. Dazu wird zunächst die View PROGRAM_INFO mit einem LEFT EXCEPTION JOIN über den Programm-Namen (PROGRAM_NAME – in PROGRAM_INFO und ENTRY in BINDING_DIRECTORY_INFO) und den Objekt-Typen (OBJECT_TYPE in PROGRAM_INFO und ENTRY_TYPE in BINDING_DIRECTORY_INFO) mit der View BINDING_DIRECTORY_INFO verknüpft. Es werden nur Service-Programme aus der Programm_Bibliothek (PROGRAM_LIBRARY) DIRWEB selektiert, die sich in dem Binderverzeichnis (BINDING_DIRECTORY) DWBNDDIR in der Bibliothek (BINDING_DIRECTORY_ENTRY_LIBRARY) DIRWEB befindet.
Fehlen Einträge in dem Binderverzeichnis, so werden diese in dieser Abfrage ausgegeben. Im Umkehrschluß heißt das, wenn alle Service-Programme eingetragen sind, wird kein Datensatz ausgegeben, so wie in diesem Fall.
Quelle: HauserSoweit eine Übersicht über die View BINDING_DIRECTORY_INFO und wie sie eingesetzt werden.
Mit dieser View und mit den anderen Services, die in den vorhergehenden Artikeln beschrieben wurden, sollten Sie in der Lage sein Ihre ILE-Objekte zu analysieren und lokalisieren.
Und nun viels Spaß beim Analysieren Ihrer ILE Objekte.
Die Autorin Birgitta Hauser schreibt regelmäßig für den MIDRANGE Deep Dive.