In dem letzten Artikel haben wir uns mit der Analyse von gebundenen Modulen mit Hilfe des IBM Service BOUND_MODULE_INFO beschäftigt. Nun ist das (mehrfache) Binden von Modulen nicht unbedingt der beste Weg um flexible ILE-Anwendungen zu schreiben. Vielmehr werden Module mit exportierten Prozeduren in Service-Programmen hinterlegt. Die einzelnen (exportierten) Prozeduren können dann von allen anderen Programmen und Prozeduren aufgerufen werden. Nun stellt sich u.a. die Frage wo werden diese Service-Programme verwendet. In diesem Artikel beschäftigen wir uns mit dem Service BOUND_SRVPGM_INFO, der die entsprechenden Antworten liefert.
Module werden direkt in Programme oder Service-Programme gebunden. Prozeduren, die sich in Modulen befinden, die in Programmen gebunden wurden, können nur innerhalb des Programms aufgerufen werden.
Module, die in Service-Programme gebunden werden enthalten i.d.R eine oder mehrere exportierte Prozeduren. Diese exportierten Prozeduren können dann aus jeder anderen Prozedur in einem andereren Service-Programm oder aus einem Programm aufgerufen werden.
Service-Programme werden nicht by Copy gebunden, sondern per Referenz. Das bedeutet, dass anstatt des Service-Programs (bzw. des entsprechenden Moduls) lediglich die eindeutige Signatur des Service-Programs sowie die Position der aufgerufenen Prozedur (innerhalb des Service-Programs) in das rufende Programm oder Service-Programm eingebunden werden.
BOUND_SRVPGM_INFO – Verwendete Service-Programme
BOUND_SRVPGM_INFO liefert Informationen darüber, in welchen (Service-)Programmen Prozeduren aus anderen Service-Programmen aufgerufen werden. Dabei wird nicht nur ausgegeben, welche Service-Programme gebunden wurden, sondern auch mit welcher Signatur die Bindung erfolgt ist.
Die Tabellen-Funktion bzw die View BOUND_SRVPGM_INFO liefert eine Kombination von Informationen, die ansonsten über die folgenden CL-Befehle und System-API (Application Programming Interface) ermittelnt werden können:
- 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 von BOUND_SRVPGM_INFO zugegriffen werden: https://www.ibm.com/docs/en/i/7.5?topic=services-bound-srvpgm-info-view
Anmerkung: Abfragen über die View BOUND_SRVPGM_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 (Service-)Programme befinden in denen die Service-Programme verwendet wurden, selektiert werden
In dem folgenden Beispiel wird gezeigt, welche Signaturen (BOUND_SERVICE_PROGRAM_SIGNATURE) von welchen Service-Programmen (BOUND_SERVICE_PROGRAM) in dem Service-Program DWCVTTEXT (PROGRAM_NAME) in der Bibliothek DIRWEB (PROGRAM_LIBRARY) eingebunden sind. Es wird außerdem der Aktivierungspzeitpunkt (BOUND_SERVICE_PROGRAM_ACTIVATION) ausgegeben. Unter Aktivierung versteht man ein (Service-)Programm in Laufbereitschaft zu setzen. *IMMED bedeutet, dass die Aktivierung sofort mit der Aktivierung des rufenden Programs/Service-Programs erfolgt. Bei *DEFER wird mit der Aktivierung solange gewartet, bis der erste Aufruf einer Prozedur aus dem Service-Program erfolgt.
Da die Selektions-Kriterien in diesem Fall den Parametern der Tabellen-Funktion BOUND_SRVPGM_INFO entsprechen, wird die Tabellen-Funktion BOUND_SRVPGM_INFO verwendet.
Quelle: HauserDas Ergebnis zeigt, dass neben individuellen Service-Programmen, (alle gebundenen Service-Programme – BOUND_SRVICE_PROGAM, die in diesem Fall mit DW beginnen) auch einige System-Service-Programme, die sich in der Bibliothek QSYS befinden und die mit Q beginnen, gebunden werden. Die System-Service-Programme werden alle sofort bei der Aktivierung aktiviert, während die individuellen Service-Programme erst beim Aufruf der ersten Prozedur aus dem Service-Programm aktiviert werden.
In dem folgenden Beispiel wird umgekehrt ermittelt, in welchen Programmen oder Service-Programmen (PROGRAM_NAME), die sich in der Bibliothek DIRWEB (PROGRAM_LIBRARY) befinden Prozeduren aus dem Service-Programm DWCVTTEXT (BOUND_SRVPGM_INFO) aufgerufen werden.
Außerdem wird angezeigt mit welcher Signatur (BOUND_SERVICE_PROGRAM_SIGNATURE) das Service-Programm eingebunden wurde. Idealerweise sollte überall die gleiche Signatur eingebunden sein. Arbeitet man jedoch mit Bindersprache und lässt die Signatur automatisch ermitteln, können in den Service-Programmen unterschiedliche Signaturen eingebunden sein. Die automatisch generierte Signatur verändert sich immer dann, wenn eine neue Prozedur in das Service-Programm hinzugefügt wird.
Quelle: HauserUm einen Überblick darüber zu bekommen, welche Module und Signaturen aus Service-Programmen in einem (Service-)Programm enthalten sind, können die beiden Services BOUND_MODULE_INFO und BOUND_SRVPGM_INFO über eine Union-Anweisung zusammengemischt werden.
In dem folgenden Beispiel werden die in dem Service-Program DWSQLLIB in der Bibliothek DIRWEB gebundenen Module und Service-Programme, inklusive der Signatur der eingebundenen Service-Programme aufgelistet. In dem ersten Sub-Select werden alle eingebunden Service-Programme (BOUND_SERVICE_PROGRAM_LIBRARY und BOUND_SERVICE_PROGRAM) über den Service BOUND_SRVPGM_INFO ermittelt. Der Objekttyp (OBJECT_TYPE) wird mit *SRVPGM fix vorgegeben.
In einer zweiten Abfrage werden die gebundenen Module (BOUND_MODULE_LIBRARY und BOUND_MODULE) über den Service BOUND_MODULE_INFO aufgelistet. Der Objekttyp (OBJECT_TYPE) wird mit *MODULE fix vorgegeben. Da Module by Copy und nicht by Reference eigebunden werden, gibt es für die Module keine Signatur. Da beide Abfragen über einen UNION ALL zusammengemischt werden und dabei die Anzahl der Spalten identisch sein muss und die Spalten außerdem identische zumindest jedoch kompatible Datentypen haben müssen, wurde eine zusätzliche Spalte ohne Wert (‘‘) eingefügt, der explizit auf VARBINARY (Datentyp der Signatur) gecastet wurde eingefügt..
Das zusammengemischte Ergebnis wird dann nach der Programm-Bibliothek, dem Programm-Namen, dem eingebundenen Objekt-Typen und dem Modul oder Service-Programm-Name sortiert.
Quelle: HauserService-Programme werden in der Regel mehrfach gebunden, da die exportierten Prozeduren aus beliebigen anderen Prozeduren in Programmen oder Service-Programmen aufgerufen werden (können).
Wenn ohne Bindersprache gearbeitet wird, oder wenn zwar mit Bindersprache gearbeitet wird, die Signatur nicht fix vorgegeben, sondern automatisch generiert wird, können Service-Programme mit unterschiedlichen Signaturen eingebunden worden sein.
Wenn man mit Bindersprache arbeitet und lediglich die Signatur automatisch ermitteln lässt, hat das keine weiteren Folgen. Problematisch wird es jedoch, wenn ohne Bindersprache gearbeitet wird, also wenn beim Binden der Service-Programme im Befehl CRTSRVPGM die Option EXPORT *ALL angegeben wird. In diesem Fall ändert sich beim Hinzufügen von Prozeduren die Signatur und die Reihenfolge der Prozeduren, die alphabethisch angeordnet werden. Die Folge ist, dass alle Programme und Service-Programme, in denen eine der Prozeduren aufgerufen wird neu erstellt, zumindest jedoch neu gebunden werden müssen.
Wie kann man nun prüfen, ob und welche Service-Programme mit welcher Signatur eingebunden sind?
Mit der folgenden Abfrage wird ermittelt welche Service-Programme (BOUND_SERVICE_PROGRAM) mit unterschiedlichen Signaturen (BOUND_SERVICE_PROGRAM_SIGNATURE) eingebunden wurden.
In der Common-Table-Expression x werden zunächst die Service-Programme ermittelt, die mehrere Signaturen haben. Dies geschieht in der Having-Anweisung in der die Anzahl unterschiedlicher Signaturen ermittelt wird. Werden für ein Service-Programm mehrere Signaturen gefunden, wird das Service-Programm selektiert (HAVING COUNT(DISTINCT BOUND_SERVICE_PROGRAM_SIGNATURE) > 1).
In dem endgültigen SELECT-Statement wird die Common-Table-Expression x mit der View BOUND_SRVPGM_INFO über den Service-Programm-Namen (BOUND_SERVICE_PROGRAM) verknüpft und nur die (Service-)Programme ermittelt, die sich in der Bibliothek DIRWEB befinden. Die Daten werde auf Service-Programm und Signatur verdichtet und die Anzahl der (Service-)Programme (PROGRAM_LIBLRARY), in die die unterschiedlichen Signaturen (BOUND_SERVICE_PROGRAM_SIGNATIRE) gebunden wurden ermittelt.
Das Ergebnis zeigt insgesamt 4 Service-Programme, die jeweils mit 2 unterschiedlichen Signaturen gebunden wurden.
Quelle: HauserWie aus dem Ergebnis ersichtlich wird wurden die meisten Service-Programme mit der gleichen Signatur gebunden. Das Ziel ist es nun die Service-Programme zu finden, in denen die „Ausreißer“-Signaturen eingebunden sind, damit diese Service-Programme neu und mit der aktuellen Signatur gebunden werden können. Dies erfolgt im nächsten Beispiel, das auf dem vorherigen Beispiel aufbaut. Das endgültige SELECT-Statement aus dem vorherigen Beispiel wird als Common-Table-Expression y in das SELECT-Statement eingebunden..
In der nächsten Common-Table-Expression z wird für die unterschiedlichen Signaturen eine Nummerierung vergeben. Die Signatur der jeweiligen Service-Programme, die am häufigsten verwendet wurden erhalten die Nr. 1 und alle anderen Signaturen abhängig von der Häufigkeit der Verwendung erhalten den nächsten Zähler in absteigender Reihenfolge ROW_NUMBER() OVER(PARTITION BY BOUND_SERVICE_PROGRAM ORDER BY NBRPROGRAMS DESC).
In dem endgültigen SELECT-Statement wird die Common-Table-Expression z mit der View BOUND_SRVPGM_INFO über den Service-Programm-Namen (BOUND_SERVICE_PROGRAM) und die Service-Programm-Signatur (BOUND_SERVICE_PROGRAM_SIGNATURE) verknüpft. Es werden nur die Signaturen ausgewählt, die nicht der am häufigsten gebundenen Signatur entsprechen ROWNBR > 1. Das Ergebnis zeigt die (Service-)Programme in denen diese Signaturen eingebunden sind.
Quelle: HauserSoweit ein kurzer Überblick über den IBM Service BOUND_SRVPGM_INFO mit einigen Beispielen, wie dieser Service eingesetzt werden kann. In dem nächsten Artikel werden wir sehen, wie man Daten-Exporte und exportierte Prozeduren ermitteln kann.
Bis dahin schon einmal viel Spaß beim Analysieren von gebundenen Service-Programmen.
Die Autorin Birgitta Hauser schreibt regelmäßig für den MIDRANGE Deep Dive.