ILE (Integrated Language Environment) Programme oder Service-Programme können aus mehreren Modulen, die in unterschiedlichen Programmiersprachen geschrieben wurden bestehen. Die Module wiederum können mehrere interne und exportierte Prozeduren behinhalten. Um herauszufinden welches Modul wo gebunden ist oder welche Prozedur aus welchem Service-Programm exportiert wird, konnten bislang entweder CL-Befehle oder System-APIs (Application Programming Interface) verwendet werden. Beides war ziemlich mühsam.
Mit den letzten Technologie Refreshes hat IBM jedoch einige IBM Service bereitgestellt, mit denen ILE-Objekte mit SQL-Abfragen einfach analysiert werden können. In diesem Artikel erhalten Sie zunächst einen Überblick über die vorhandenen Services.
Db2 und IBM i Services
Bereits seit einigen Releasen stellt IBM eine Reihe von Db2 und IBM-Services (Views, User defined Functions, User Defined Table Functions oder Stored Procedures) für die verschiedensten Bereiche zur Verfügung. Mit jedem neuen Technology Refresh werden weitere Services hinzugefügt und/oder vorhandene Services erweitert.
Soweit so gut! Doch …
Welche Services gibt es, wo findet man die entsprechenden Dokumentationen und kann der Service unter dem aktuellen IBM i Release-Stand verwendet werden?
Sämtliche Db2 und IBM i Services sind in der Tabelle SERVICES_INFO in der Bibliothek QSYS2 hinterlegt. Neben dem Namen und Typen (View, Table, Stored Procedure…) des Services und der Bibliothek enthält die Tabelle noch weitere Informationen (z.B. unter welchem Release der Service eingeführt wurde). Außerdem enthält die Tabelle für jeden Service ein Bespiel, das man kopieren, modifizieren und ausführen kann.
Das folgende Beispiel zeigt einen Auszug aus der Tabelle SERVICES_INFO in der Bibliothek QSYS2.
Quelle: HauserDetaillierte Beschreibungen für die einzelnen Services befinden sich in der Online-Referenz unter dem entsprechenden Release unter Datenbase à Performance and Query Optimitzation:
- DB2 for i Services: https://www.ibm.com/docs/en/i/7.5?topic=optimization-db2-i-services
- IBM i Services: https://www.ibm.com/docs/en/i/7.5?topic=optimization-i-services
IBM Services für ILE Objekte
Für die Analyse von ILE Objekten wurden die folgenden Services bereitgestellt:
- BOUND_MODULE_INFO: liefert Informationen über die in Service-Programme oder Programme gebundenen Module
- BOUND_SRVPGM_INFO: liefert Informationen über die in Service-Programmen oder Programmen verwendeten Service-Programme bzw. über die eingebundenen Signaturen
- PROGRAM_EXPORT_IMPORT_INFO: liefert Informationen übe die (exportierten) Daten und Prozeduren
- PROGRAM_INFO: liefert Informationen (z.B. Compile-Optionen) über die Programme und Service-Programme
- BINDING_DIRECTORY_INFO: bietet Informationen über die Binder-Verzeichnisse und den darin eingetragenen Modulen und Service-Programmen
Alle zuvor aufgelisteten Services werden sowohl als View als auch User Defined Table Function (UDTF) bereitgestellt. Sowohl die View als auch die Tabellen-Funktion liefern das gleiche Ergebnis. Da bei der Tabellen-Funktion jedoch Parameter übergeben werden können, ist die Verarbeitung bei Verwendung der Tabellen-Funktion schneller, zumindest dann wenn die Parameter den Selektions-Kriterien entsprechen.
Soweit zur Theorie und nun wollen wir uns die einzelnen Services und deren Verwendung im Detail anschauen.
BOUND_MODULE_INFO – Modul-Informationen
Mit der Tabellen-Funktion bzw. der View BOUND_MODULE_INFO können Informationen über die gebundenen Module ausgewertet werden.
- CL-Befehl DSPPGM: Programm Anzeigen
- CL-Befehl DSPSRVPGM: Service-Programm Anzeigen
- System-API QBNLPGMI: Auflistung von ILE-Programm-Informationen
- System-API QBNLSPGM: Auflistung von ILE-Service-Programm-Informationen
Unter dem folgenden Link kann auf die Detail-Beschreibung des Services BOUND_MODULE_INFO zugegriffen werden: https://www.ibm.com/docs/en/i/7.5?topic=services-bound-module-info-view
Anmerkung: Abfragen über die View BOUND_MODULE_INFO können sehr lange dauern, da ggf. die Daten von allen (gebundenen) Modulen in allen Bibliotheken durchsucht werden. Deshalb sollte zumindest die Bibliothek in der sich die (Service-)Programme befinden in die die Module gebunden wurden, selektiert werden.
Mit dem folgenden Beispiel werden alle Module, die in dem Service-Programm DWCGI in der Bibliothek DIRWEB eingebunden sind, aufgelistet. Da die Selektions-Kriterien den Parametern in der Tabellen-Funktion entsprechen, wird an dieser Stelle die Tabellen-Funktion BOUND_MODULE_INFO aufgerufen.
In der Ausgabe werden neben der Programm-Bibliothek (PROGRAM_LIBRARY) und dem Programm_Namen (PROGRAM_NAME) auch die die einzelnen Module (BOUND_MODULE) aufgelistet. Zusätzlich wird die Quellen-Bibliothek (SOURCE_FILE_LIBRARY), die Quellen-Datei (SOURCE_FILE), die Quellen-Teildatei (SOURCE_FILE_MEMBER) sowie der Modul-Erstellungszeitpunkt (MODULE_CREATE_TIMESTAMP) und die letzte Quellen-Änderung (SOURCE_CHANGE_TIMESTAMP) angezeigt. Des weiteren wird für jedes Modul die Anzahl der exportierten Prozeduren (NUMBER_PROCEDURES) und die Anzahl der SQL-Statements (SQL_STATEMENT_COUNT), die sich innerhalb des Modules befinden ausgegeben. Beide Informationen werden direkt von BOUND_MODULE_INFO geliefert, d.h. es ist also keine zusätzliche Gruppierung oder Summierung erforderlich.
Quelle: HauserDa der Service BOUND_MODULE_INFO sowohl den Modul-Erstellungs-Zeitpunkt als auch den Zeitpunkt der letzten Quellen-Änderung beinhaltet, kann auf einfache Art- und Weise festgestellt werden, ob und welche Quellen zwar geändert jedoch noch nicht als Modul erstellt wurden und folglich auch noch nicht innerhalb des (Service-)Programms aktualisiert wurden.
Das folgende Beispiel listet alle Programme- oder Service-Programme in der Bibliothek DIRWEB auf, in denen sich Module befinden, deren Erstellungs-Zeitpunkt vor dem letzten Änderungszeitpunkt der Quelle befindet. Idealerweise sollten an dieser Stelle (wie auch hier in diesem Beispiel) keine Datensätze gefunden werden.
Quelle: HauserIn dem folgenden Beispiel werden alle Module (BOUND_MODULE) aufgelistet, die aus der gleichen Quelle (SOURCE_FILE_LIBRARY, SOURCE_FILE, SOURCE_FILE_MEMBER) mit dem gleichen Quellen-Änderungs-Datum (SOURCE_CHANGE_TIMESTAMP) erstellt wurden und die mehrfach, d.h. in unterschiedlichen Programmen oder Service-Programme gebunden wurden. Außerdem wird ermittelt in wie vielen unterschiedlichen (Service-)Programm-Objekten die Module gebunden sind (TIMES_BOUND).
Quelle: HauserDas folgende Beispiel geht noch einen Schritt weiter und listet nicht nur die mehrfach gebundenen Module auf, sondern zeigt außerdem an, in welchen (Service-)Programm-Objekten diese Module gebunden sind.
Dazu wird das SQL-Statement aus dem vorhergehenden Beispiel als Common Table Expression x hinterlegt. Diese Common-Table-Expression wird im endgültigen SELECT-Statement erneut mit der View BOUND_MODULE_INFO über das gebundene Modul (BOUND_MODULE) und die Quellen-Informationen (Quellen-Bibliothek – SOURCE_FILE_LIBRARY, Quellen-Datei – SOURCE_FILE und Quellen-Teildatei – SOURCE_FILE_MEMBER) verknüpft.
Das Ergebnis zeigt dann in welchen (Service-)Programmen (y.PROGRAMM_LIBRARY, y.PROGRAM_NAME) die Module direkt gebunden sind.
Quelle: HauserSoweit ein Überblick über die Db2 und IBM Services zur Analyse von ILE-Objekten, sowie Bespiele zur Verwendung des Services BOUND_MODULE_INFO.
Im nächsten Artikel werden wir uns dann mit den nächste Services zur Analyse von ILE-Objekten beschäftigen.
Und jetzt schon einmal viel Spaß beim Analysieren der in Programme und Service-Programme gebundenen Module.
Birgitta Hauser ist IBM Champion und Spezialistin für SQL- sowie RPG-Programmierung.
Frau Hauser gibt regelmäßig Workshops im Rahmen der MIDRANGE ACADEMY.
Sie schreibt regelmäßig für MIDRANGE und den MIDRANGE Deep Dive.