SQL ist als festes Werkzeug seit jeher mit der Datenbank DB2 unserer Systeme verbunden. SQL wird aber auch heute noch oft in seiner Leistungsfähigkeit und seinen Einsatzbereichen unterschätzt. Zu häufig wird SQL nur als interaktives Abfragetool für den schnellen Zugriff auf Datenbankinhalte gesehen und genutzt – ein STRSQL gefolgt von einer SELECT Anweisung steht da nur als eines der Beispiele.
Es ist eine Strategie der IBM (und in diesem Fall sogar eine solche, die sich seit Jahren fortsetzt und als beständig bezeichnet werden kann), dass immer mehr Funktionen rund um das Betriebssystem IBM i und die dazugehörige Datenbank mit SQL Funktionen abgebildet und umgesetzt werden. In dieser Ausgabe möchte ich Ihnen zeigen, mit welchen SQL Werkzeugen wir in einem Programm automatisiert Analysen zu Objekten, Daten und so weiter vornehmen können.
Sicher sind Ihnen die gängigen Befehle zum Anzeigen von Objekteigenschaften für Dateien oder Programme in Form von zum Beispiel DSPOBJD, DSPPGM, DSPPGMREF und weitere bekannt. Diese IBM i Befehle sind seit jeher wichtige Bestandteile, wenn es um die Auskunft von spezifischen Informationen zu den unterschiedlichen Teilebereichen der Objekte geht. Dabei können diese nach Bedarf zur Anzeige oder auch zur Ausgabe in Druck oder Ausgabedateiform eingesetzt werden.
Möchte man aber zum Beispiel größere Analysen über Objekte auf einem System durchführen, Abhängigkeiten ermitteln oder potentielle Doubletten oder deren Abweichungen analysieren, dann kann das schon eine größere Aufgabe werden, da sich die IBM i Befehle nur schwer in einem Programm elegant einbinden lassen. Natürlich können wir uns hier der Steuersprache CL bedienen oder im RPG mit QCMDEXC die meisten IBM i Befehle implementieren – aber zeitgemäß geht es etwas anders.
Hier kommt dann zum Beispiel SQL mit seinen administrativen Derivaten zum Einsatz, die IBM uns in den letzten Jahren verstärkt durch Technology Refreshes oder neue Releaseversionen zur Verfügung gestellt hat.
An dieser Stelle möchte ich Ihnen exemplarisch einige dieser SQL Admin Funktionen vorstellen.
Beginnen wir mit der SQL Funktion OBJECT_STATISTICS.
Diese SQL Funktion liefert uns Objektinformationen. Die Funktion kann also durchaus mit dem IBM i Befehl DSPOBJD verglichen werden. Schauen wir uns den Einsatz der SQL Funktion OBJECT_STATISTICS einmal an. Diese SQL Funktion steht Betreibern des IBM i seit der Version 7.2 und den entsprechenden PTFs zur Verfügung. Voraussetzung für den Einsatz der SQL Funktion OBJECT_STATISTICS sind die auf Betriebssystemseite auch erforderlichen Berechtigungen. Der Aufruf kann wahlweise für alle Objekte in einer Bibliothek, einzelne Objekte oder auch mit Einschränkungen auf Art und alle anderen Feldinhalte durchgeführt werden. Allein die SQL Funktion OBJECT_STATISTICS kann für viele verschiedene Einsatzbereiche genutzt werden. So lassen sich zum Beispiel in einem RPG Programm alle Objekte ermitteln, die eine gewisse Zeit nicht zum Einsatz gekommen sind. Das „Datum der letzten Benutzung“ ist Administratoren des Systems natürlich auch aus dem Befehl DSPOBJD bekannt. Analog kann man die mit DSPOBJD gelieferten Informationen auch mit der SQL Funktion OBJECT_STATISTICS abrufen.
Wie andere SQL Funktionen auch, so finden wir OBJECT _STATISTICS in der Bibliothek QSYS2. SELECT und FROM sind hier unsere Freunde. In dem nachfolgenden Beispiel habe ich exemplarisch einige Spalten selektiert, die für die Anzeige der Objekteigenschaften selektiert werden können. Um zum Beispiel alle physischen Dateien (oder SQL Tabellen) in einer bestimmten Bibliothek abzurufen, geben wir das nachfolgende SQL an.
select ObjName, ObjLib, OBJCreated, ObjText, Last_Used_Timestamp
Days_Used_Count, Source_Library, Source_File, Source_Member,
Source_Timestamp
from TABLE(QSYS2.OBJECT_STATISTICS(‚ZEIG‘, ‚*FILE‘)) a
where OBJAT00001 = ‚PF‘ and Last_Used_Timestamp > ‚2023-01-01 00:00:00.000‘ ;
Das Ganze kann dann in einem beliebigen SQL Editor zur Ausführung gebracht werden:
Quelle: ZeigAusführung in SQL-Editor
Beachten Sie in dem SQL Beispiel nach der FROM Angabe den Buchstaben außerhalb der Klammer.
Der Buchstabe „a“ ist in älteren Releaseversionen notwendig, damit OBJECT_STATISTICS ausgeführt werden kann. Seit 7.4 kann die Angabe dieser Erweiterung optional vorgenommen werden. Es schadet aber nicht, das Codieren auch in den neueren Versionen – wie in dem Beispiel gezeigt – vorzunehmen.
Wie Sie sehen, können wir uns beliebige Objekte in beliebigen Bibliotheken auswerten.
Für die Bibliotheksebene können wir die folgenden Auswahlen treffen:
- *ALL
- Alle Bibliotheken
- *ALLUSR
- Alle Benutzerbibliotheken
- *ALLUSRAVL
- Alle Bibliotheken in einem ASP
- *CURLIB
- Aktuelle Bibliothek
- *LIBL
- Alle Bibliotheken in der Bibliotheksliste
- *USRLIBL
- Alle Benutzerbibliotheken der Bibiliotheksliste
- Bibliotheksname
- Der Name der gewünschten Bibliothek
Leider gibt es eine Einschränkung – OBJECT_STATISTICS kann nicht zusammen mit generischen Namen genutzt werden – aber da ist IBM konsequent – denn DSPOBJD verfügt auch nicht über diese Option.
Natürlich können wir die SQL Funktion OBJECT_STATISTICS nun flexibel einsetzen. So kann zum Beispiel das SQL auch in ein RPG Programm eingebunden werden. Auf diese Weise lassen sich zusammen mit anderen SQL Funktionen viele administrative Tätigkeiten elegant automatisieren – eine Konkurrenz für CL?
In dem nachfolgenden RPG Codeausschnitt finden Sie den Einsatz von OBJECT_STATISTICS exemplarisch dargestellt. Hier nutzen wir die RPG und embedded SQL Regeln, die natürlich auch für die in RPG eingebundenen SQL Funktionen anzuwenden sind. Um zum Beispiel mehrere Ergebnisse verarbeiten zu können, deklariere ich im RPG einen Cursor für die SQL FETCH Ausführung.
Natürlich kann ich den Bibliotheksnamen in einem RPG auch als Variablennamen (in dem Beispiel W_pLIB1) codieren. So lassen sich in einem Prozess mehrere Bibliotheken nacheinander verarbeiten.
// Test Analyse File
exec sql close crs001 ;
exec sql declare crs001 cursor for
select ObjName, ObjLib, OBJCreated, ObjText, Last_Used_Timestamp,
Days_Used_Count, Source_Library, Source_File, Source_Member,
Source_Timestamp
from TABLE(QSYS2.OBJECT_STATISTICS(:W_pLib1,’*FILE‘)) a
where OBJAT00001 = ‚PF‘;
exec sql open crs001 ;
exec sql fetch next from crs001 into :ds_DSPOBJD :NullIndObjD;
dow sqlcode = 0 ;
w_ODOBNM = ds_DSPOBJD.do_ObjName;
exec sql fetch next from crs001 into :ds_DSPOBJD :NullIndObjD;
enddo;
IBM bietet für OBJECT_STATISTICS eine Fülle an Spalten mit umfassenden Objektinformationen.
Diese hier aufzuführen wäre zu komplex – deshalb verweise ich an dieser Stelle auf die IBM Webseite für die SQL Funktion OBJECT_STATISTICS.
Wenn wir schon bei SQL Funktionen und den Objekten sind. Dateien oder Tabellen sind natürlich extrem wichtige Objekte auf System i. Und auch hier hat IBM SQL Funktionen geschaffen, die uns eine Fülle an Einsatzmöglichkeiten zusammen mit Dateien bieten. Dabei bedeutet „Dateien“ die reinen DB2 Inhalte – nicht IFS Komponenten!
QSYS2.SYSTABLES ist die SQL Funktion, die wir zusammen mit Dateien nutzen können um zum Beispiel den Dateityp zu ermitteln, die Anzahl der Datensätze abrufen, festzustellen, ob es gelöschte Datensätze gibt und vieles mehr.
Eine spezielle View (SYSTABLESTAT) beinhaltet für jede DB2 Tabelle einen Eintrag mit einer Fülle an Informationen.
Analog zum Einsatz der zuvor gezeigten SQL Funktion können wir SYSTABLES in einem SQL Editor genauso nutzen, wie auch als embedded SQL in einem RPG Programm eingebunden.
Möchte ich zum Beispiel die Anzahl der Datensätze in den Dateien in einer Bibliothek ermitteln, dann kann ich das folgende SQL anwenden:
SELECT TABLE_NAME ,
NUMBER_ROWS
FROM qsys2.systablestat
WHERE SYSTEM_TABLE_SCHEMA = ‚ZEIG‘;
Quelle: ZeigSQL: Anzahl der Datensätze
Jörg Zeig berät freiberuflich im System i Umfeld.
Er berichtet regelmäßig für den TechKnowLetter.
Für 88 Euro gibt’s hier sechs Monate lang tiefgreifendes IBM i und SQL Wissen. Hier kann man abonnieren.
