Nachdem wir uns Fehlersuche und Coding mit Bob angeschaut hatten, wollten wir nun mit einem richtigen “Projekt” starten – aber etwas Überschaubarem und deswegen auch die Anführungszeichen. Als zentrale Problemstellung entschieden wir uns wieder für das selektive Löschen von Spoolfiles in IBM i und damit für die Erstellung einer Lösung bezüglich unseres Ausgangsproblems, doch diesmal als Webanwendung mit IBM i Backend.
Eine der ersten Fragen war natürlich, welche Programmiersprache wir wählen wollten. Wir sind keine professionellen RPG Programmierer, verfügen aber über einige Python-Kenntnisse. Somit entschieden wir uns dafür und favorisierten Flask für den Webteil. Beides steht IBM i in PASE zur Verfügung. Die auf unserem System installierte Version ist Python 3.9, was wir Bob als Restriktion wohl mitteilen sollten (aktuell ist Python 3.13 für IBM i verfügbar).
Des Weiteren entschlossen wir uns die existierende “quick and dirty” Lösung als “Minimal Value Product” Bob mitzugeben, damit das Tool leichter erkennt, was es tun soll, und wir nicht so viel im Prompt erklären müssen:
#!/usr/bin/bash
echo =====================================================================
db2util -o csv “SELECT SPOOLED_FILE_NAME, JOB_NAME FROM QSYS2.OUTPUT_QUEUE_ENTRIES_BASIC where ((OUTPUT_QUEUE_NAME=’QEZJOBLOG’) AND (CREATE_TIMESTAMP > ‘2025-12-08 10:00:00.000000’) AND (CREATE_TIMESTAMP < ‘2025-12-12 18:00:00.000000’)) fetch first 5 rows only” > Liste.txt
echo =====================================================================
while read -r zeile; do
SPLFNAME=$(echo $zeile | cut -f1 -d, | sed ‘s/”//g’)
JOBNAME=$(echo $zeile |cut -f2 -d, | sed ‘s/”//g’)
echo “dltsplf file($SPLFNAME) JOB($JOBNAME) SPLNBR(*any) SELECT(*ALL)”
cl “dltsplf file($SPLFNAME) JOB($JOBNAME) SPLNBR(*ANY) SELECT(*ALL)” < /dev/null
done < Liste.txt
echo Fertig!
Den Prompt formulierten wir dann wie folgt:
„Hi Bob,
in the following folder ‘MVP-DLTSPLFL/dltsplf_while_do.sh’ (see below for file content) you can find a script to delete spool files in a certain timeframe.
I want to create a client/server webapp that gives me the possibility to execute the script and select/change the following parameters: OUTQUEUE, SPLFNAME, JOBNAME, SPLNBR, START_TIMESTAMP, END_TIMESTAMP.
Additionally, there should be a functionality to select certain spool files in a table to delete. Default should be all within the stated timeframe.
Please use python3.9 as the main programming language together with flask as the web framework.
The application backend will be deployed on IBM i. Please also create a bash script that installs all the requirements for this webapp.
Can you help me plan this? “
Danach gab es einige Rückfragen zur Klärung der Anforderungen. Unsere Antworten sind im blauen Abschnitt im unteren Bild zu finden.
Quelle: IBM Deutschland GmbHAm Ende bekamen wir einen unserer Meinung nach professionellen Projektplan, den Sie herunterladen (Hyperlink auf Zip-File) können. Dieser ist gut strukturiert und scheint alles berücksichtigt zu haben – nur Code wurde nicht produziert.
Was uns auch erstaunte, war die Aufgliederung in Projektphasen und was wöchentlich zu erledigen ist. Ob mit Hilfe von Bob oder ohne – wir haben jetzt einen Plan!
Schauen wir uns einige Abschnitte aus dem Projektplan an. Auch wenn die Struktur sicherlich immer ähnlich ist, sind die Inhalte doch individuell projektbezogen:
| ### Functional Requirements – Users can authenticate with username/password – Optional MFA verification works – Users can connect to multiple IBM i instances – Spoolfiles can be filtered by all required parameters – Spoolfiles display in sortable table – Users can select spoolfiles for deletion – Confirmation dialog prevents accidental deletion – Deletion executes successfully via CL commands – Success/error feedback is clear | ### Non-Functional Requirements – Application starts/stops via scripts – Page load time < 2 seconds – Query response time < 1 second – UI is intuitive and easy to use – Error messages are helpful – Application logs all operations – Security best practices followed |
Für die Entwicklungszeit werden etwa fünf Wochen geplant – aus meiner Sicht etwas zu hoch.
### Timeline
– **Week 1**: Setup, Database Layer, Authentication (50% complete)
– **Week 2**: Authentication, Core Logic (75% complete)
– **Week 3**: Core Logic, Frontend (90% complete)
– **Week 4**: Frontend, Testing (95% complete)
– **Week 5**: Documentation, Deployment (100% complete)
Als nächstes folgen die “Resource Requirements” und beim Entwicklungsteam fällt auf, dass Bob einen erfahrenen Programmierer für sinnvoll hält. (Entwickler werden also trotz Bob nach wie vor gebraucht!)
### Development Team
– 1 Full-stack Developer (Python/Flask/JavaScript)
– 1 IBM i System Administrator (for testing and deployment)
– 1 QA Tester (part-time)
Interessant ist auch die Risk Assessment Vorlage, die auf einige wichtige Punkte hinsichtlich Kompatibilität, Skalierbarkeit, Security und Komplexität hinweist.
### Technical Risks
| Risk | Impact | Probability | Mitigation |
|——|——–|————-|————|
| ODBC driver compatibility issues | High | Medium | Test early, have IBM support contact |
| CL command execution failures | High | Low | Comprehensive error handling, logging |
| Performance with large result sets | Medium | Medium | Implement pagination, optimize queries |
| Session management issues | Medium | Low | Use Flask-Session, test thoroughly |
| MFA implementation complexity | Low | Medium | Make MFA optional, use proven libraries |
Insbesondere der Punkt ODBC Treiber für das Backend unter IBM i erfordert Klärung, bevor das Projekt begonnen wird, da der von uns vorgeschlagene Algorithmus die Ausführung von SQL erfordert. Ein erfahrener „Full-stack” Developer benötigt dazu neben Python auch IBM i Kenntnisse.
Erfahrungen mit ODBC unter AIX/Linux sind ebenfalls wünschenswert. Ohne hier weiter darauf einzugehen, sollte es dann mit einigen Recherchen im Internet gelingen, das zu klären. Bob hat jedenfalls mit der Auswahl des pyODBC Moduls eine funktionierende Option für Python unter IBM i gefunden.
Da ODBC zusätzlich für Verbindungen noch Konfigurationen für jedes System benötigt, muss mit weiterem Konfigurationsaufwand gerechnet werden.
Bezüglich MFA warnt Bob vor Komplexität. Tatsächlich ist fraglich, ob der verwendete ODBC Treiber MFA unterstützt. Ansonsten bleibt nur der Weg, die Anmeldung über MFA unterstützende Dienste, z.B. ssh, zu erledigen und über ein großes TOTP Intervall die Authentifizierung für ODBC zu erhalten.
Ein anderer Abschnitt weist auf Risiken bei einer künftigen Verwendung hin:
### Operational Risks
| Risk | Impact | Probability | Mitigation |
|——|——–|————-|————|
| User adoption resistance | Medium | Medium | Provide training, maintain bash script as backup |
| Insufficient user permissions | High | Low | Document required permissions clearly |
| Network connectivity issues | Medium | Low | Implement connection retry logic |
| Configuration errors | Medium | Medium | Provide clear documentation, validation |
Mit dem Hinweis auf Berechtigungen hat Bob Recht. Für normale User wäre dieses Programm deswegen auch nicht einsetzbar.
Alles in allem hatten wir uns über solche Risiken bisher jedenfalls keine Gedanken gemacht und gegebenenfalls müssen wir das gesamte Projekt nochmal überdenken beziehungsweise ändern.
Insgesamt hat Bob in dieser Planungsphase sieben Dateien generiert:
- API_SPECIFICATION.md
- ARCHITECTURE.md
- IMPLEMENTATION_GUIDE.md
- PROJECT_PLAN.md
- README.md
- UI_SPECIFICATION.md
- WORKFLOW_DIAGRAMS.md
Fazit:
Für eine erste Diskussion mit Entscheidern oder im Entwicklerteam ist dieser Projektplan eine sehr schöne Grundlage, vor allem unter den Gesichtspunkten Aufwand und Zeit. Insgesamt ist sowas für ein Softwarehaus sicherlich gut, aber für eine schnell benötigte “quick and dirty“ Lösung würde das 10-zeilige oder das von Bob entwickelte Bash Skript für IBM i Administratoren sicherlich ausreichen.
Man sollte eben vorher gründlich überlegen, was man will. Dabei hat Bob uns auf alle Fälle geholfen.
Weitere Informationen zu Project BOB finden Sie hier.
Weitere Informationen zu IBM finden Sie hier.