Qshell db2 Utility auf IBM i – SQL-Skripte sauber ausführen, automatisieren und prüfen

Kompakt, skriptbar und erstaunlich nützlich: So nutzt Du das Qshelldb2Utility für Db2 for i richtig – inklusive Stolperfallen, Beispiel-SQL und sauberem Workflow.

1. Was ist das Qshell db2 Utility?

Qshell ist eine Unix-ähnliche Shell- und Skriptumgebung auf IBM i. Das darin verfügbaredb2Utility ist ein Kommandozeilenwerkzeug für Db2 for i. Es nutzt die SQL CLI und kann SQL-Statements direkt, interaktiv oder aus einer Datei ausführen.

Das ist besonders praktisch, wenn Du SQL-Skripte ohnehin im IFS liegen hast – zum Beispiel unter/home/deinuser/sql, in einem Git-Checkout, in einem Deployment-Verzeichnis oder in einer technischen Testumgebung.

2. Wann ist das Utility sinnvoll?

Das Tool ist kein Ersatz für IBM i Access Client Solutions, Navigator for i oder saubere Deployment-Prozesse. Aber es ist verdammt nützlich, wenn Du einfache SQL-Aktionen wiederholbar ausführen möchtest.

3. Nicht verwechseln: Qshell db2, RUNSQLSTM, ACS und PASE db2util

Auf IBM i gibt es mehrere Wege, SQL auszuführen. Das ist gut – aber auch eine Quelle für Verwirrung, weil ähnlich klingende Werkzeuge nicht automatisch dasselbe tun.

4. Grundlagen: interaktiv, direkt oder aus Datei

Du kannst Qshell über den BefehlQSHstarten oder ein Qshell-Kommando direkt aus CL aufrufen. Für erste Tests reicht ein einfaches SELECT.

qsh

# Direktes SQL-Statement ausführen
db2 "select current date from sysibm.sysdummy1"

Wenn ein SQL-Statement Leerzeichen oder Shell-Sonderzeichen enthält, gehört es sauber in Anführungszeichen. Das ist keine IBM-i-Spezialschikane, sondern schlicht Shell-Alltag. Bei mehrzeiligen Statements behandelt das Utility außerdem einen Backslash am Zeilenende als Fortsetzungszeichen.

db2 -i

select current timestamp from sysibm.sysdummy1;
quit

Für echte Wiederholbarkeit sind SQL-Dateien meist besser als handgetippte Kommandos. Genau hier spielt das Utility seine Stärke aus.

db2 -t -v -f /home/deinuser/sql/createTables.sql

5. Wichtige Optionen: -t, -f, -v, -S und Default Library

Die wichtigsten Optionen sind schnell erklärt, aber sie machen den Unterschied zwischen „funktioniert zufällig“ und „läuft reproduzierbar“.

# Der zweite Parameter nach dem Dateinamen ist die Default Library.
# Das hilft bei unqualifizierten Tabellennamen im SQL-Skript.
db2 -t -v -f /home/deinuser/sql/createTables.sql MYLIB

6. Das Beispiel-Repository: SQL-Skripte zum Rumtesten

Zum Artikel gibt es passende Beispielskripte im GitHub-RepositoryZeus-Commons-APIs. Du findest sie unterexamples/sqlScriptsSampleData/db2_400. Der Ordner enthält aktuell drei SQL-Dateien:createTables.sql,insertData.sqlunddropTables.sql. Der Aufbau ist bewusst überschaubar: Tabellen anlegen, Beispieldaten einfügen, Ergebnisse prüfen und danach wieder aufräumen.

Der Aufbau ist absichtlich einfach gehalten:

• createTables.sqllegt Beispieltabellen wieAGENTS,CUSTOMERS,ORDERS,AGENT_REVENUEsowie kleine EAV-Demotabellen an.
• insertData.sqllädt kompakte Beispieldaten in einer Reihenfolge, die zu den Foreign-Key-Beziehungen passt.
• dropTables.sqlräumt die Tabellen wieder auf und muss dabei die Abhängigkeiten beachten: Child-Tabellen werden vor Parent-Tabellen gelöscht.

Beispiel: Cleanup-Reihenfolge

Beim Löschen zählt die tatsächliche Constraint-Abhängigkeit. In diesem Beispiel referenziertORDERSdie TabellenCUSTOMERSundAGENTS;CUSTOMERSreferenziert wiederumAGENTS. Deshalb wird zuerstORDERSgelöscht, danachCUSTOMERSund erst danachAGENTS. Die Summary-TabelleAGENT_REVENUEund die EAV-Demotabellen sind in diesem Beispiel unabhängig.

SET SCHEMA YOUR_LIB;

DROP TABLE ORDERS;
DROP TABLE CUSTOMERS;
DROP TABLE AGENTS;
DROP TABLE AGENT_REVENUE;
DROP TABLE EAV_DATA;
DROP TABLE EAV_METADATA;

Wenn Tabellen noch nicht existieren, kann ein einfaches Drop-Skript erwartbar mit Fehlern abbrechen oder Meldungen erzeugen. Für ein Lernbeispiel ist das okay, solange Du bewusst in einer Testbibliothek arbeitest. Für produktionsnahe Abläufe würdest Du zusätzlich mit Prüfungen, Rollback-Konzept, Protokollierung und Deployment-Regeln arbeiten.

7. Ein sauberer Praxis-Workflow mit SQL-Skripten

Für einen kleinen Testaufbau würde ich die Skripte heute in drei Phasen denken: vorbereiten, Schema-Platzhalter setzen, ausführen und prüfen.

Phase 1: Bibliothek vorbereiten

CRTLIB LIB(TTDEMO) TEXT('tiny-tool Demo library for Qshell db2 article')

Phase 2: Schema-Platzhalter im Skript ersetzen

Die Beispielskripte beginnen mitSET SCHEMA YOUR_LIB;. ErsetzeYOUR_LIBvor dem Ausführen durch Deine eigene Testbibliothek. Nicht in Produktion herumzaubern. Nicht „mal eben“ mit QGPL testen, weil es gerade bequem ist. Ja, QGPL ist geduldig. Genau das ist das Problem.

cd /home/deinuser/sql/db2_400

# Beispiel: neue Dateien für die Testbibliothek TTDEMO erzeugen
sed 's/SET SCHEMA YOUR_LIB/SET SCHEMA TTDEMO/g' createTables.sql > createTables_TTDEMO.sql
sed 's/SET SCHEMA YOUR_LIB/SET SCHEMA TTDEMO/g' insertData.sql   > insertData_TTDEMO.sql
sed 's/SET SCHEMA YOUR_LIB/SET SCHEMA TTDEMO/g' dropTables.sql   > dropTables_TTDEMO.sql

Phase 3: Skripte ausführen und prüfen

db2 -t -v -f /home/deinuser/sql/db2_400/createTables_TTDEMO.sql

db2 -t -v -f /home/deinuser/sql/db2_400/insertData_TTDEMO.sql

db2 -t -v "select count(*) as order_count from TTDEMO.ORDERS;"

8. Automatisieren aus CL, Qshell und Jobsteuerung

Du kannst das Utility direkt aus CL heraus starten. Das ist praktisch für kleine technische Jobs oder Abläufe, bei denen Du SQL-Skripte im IFS versionierst.

QSH CMD('db2 -t -v -f /home/deinuser/sql/db2_400/createTables_TTDEMO.sql')

Für wiederholbare Abläufe ist ein kleines Shell-Skript oft angenehmer. Dann kannst Du Pfade, Bibliothek und Logdatei an einer Stelle pflegen.

#!/bin/sh
set -e

LIB="TTDEMO"
BASE="/home/deinuser/sql/db2_400"
LOG="/home/deinuser/sql/db2_400/run_${LIB}.log"

{
  echo "Start: $(date)"
  db2 -t -v -f "${BASE}/createTables_${LIB}.sql"
  db2 -t -v -f "${BASE}/insertData_${LIB}.sql"
  db2 -t -v "select count(*) as order_count from ${LIB}.ORDERS;"
  echo "End: $(date)"
} > "${LOG}" 2>&1

9. Ausgabe, Protokollierung und Fehleranalyse

Das Qshell-Utility ist schlicht. Das ist Stärke und Schwäche zugleich. Es gibt keine hübsche UI, keine magische Diagnose und keinen freundlichen Dialog, der Dich vor Deiner eigenen SQL-Datei rettet.

db2 -t -v -f /home/deinuser/sql/check.sql \
  > /home/deinuser/sql/check.log 2>&1

Wenn Du Query-Ergebnisse maschinell weiterverarbeiten willst, hilft manchmal-S, weil Spaces und Padding reduziert werden. Für echte Schnittstellen würde ich trotzdem eher gezielt CSV, JSON, Views oder ein kleines Export-Programm bauen. Das Qshelldb2Utility ist ein Werkzeug für Ausführung und einfache Ausgabe – kein vollständiges ETL-Framework.

db2 -S "select agent_code, cumulative_revenue from TTDEMO.AGENT_REVENUE"

10. Sicherheit: Bibliotheken, Berechtigungen und Passwörter

Bei SQL-Skripten ist Sicherheit nicht nur ein Passwortthema. Der gefährlichste Fehler ist oft die falsche Bibliothek.

• Arbeite mit Testbibliotheken:Für Beispiele und Blog-Code niemals produktive Libraries verwenden.
• Qualifiziere bewusst:Entweder explizitMYLIB.TABLEoder bewusst unqualifiziert mit Default Library.
• Prüfe Drop-Skripte doppelt:Besonders bei generischen Namen wieORDERS,CUSTOMERSoderTEST.
• Keine Passwörter in Skripte:Die Optionen-uund-pgehören in den Remote-Kontext mit-r. Klartextpasswörter in Skripten sind keine gute Idee.
• Berechtigungen minimal halten:Ein technischer User für DDL braucht andere Rechte als ein User für Read-only-Checks.

11. Best Practices

12. Fazit

Quellen & weiterführende Ressourcen