Wir, Sejid Canoski und ich (Wolfgang Rother), sind keine professionellen Anwendungsentwickler. Nachdem wir eine erste Problemstellung mit Bob lösen konnten, war unsere Freude groß und unsere Neugier geweckt. Kleine Experimente, nicht funktionierenden Code erklären und korrigieren zu lassen, wich einem vollen Eintauchen in die Materie: „Wie gut kann Bob Bash-Skripte unter PASE in IBM i erstellen?“ In diesem Beitrag möchten wir nun unsere Erfahrungen teilen, wie wir zusammen mit Bob ein umfangreiches Bash-Skript automatisiert erstellt, analysiert und in Teilen korrigiert haben, um Spoolfiles in definierten Zeitabständen zu löschen.

Um herauszufinden, wie gut Bob Bash-Skripte unter PASE in IBM i erstellen kann, haben wir ihn mit folgendem Prompt aufgefordert, uns ein „Delete-Spoolfile“-Skript zu schreiben:

„Hi Bob, write a bash program called “dltsplf_bob.sh” in IBM i PASE for deleting all spoolfiles between two timestamps. “

Die Codegenerierung verlief fix und sah auch ziemlich gut aus. Eingabeüberprüfungen, Fehlermeldungen, gut strukturiert und sogar Optionen für die Ausführung:

–dry-run, -d Zeige, was gelöscht werden würde, ohne es tatsächlich zu tun

–verbose, -v Verbose Ausgabe aktivieren

–help, -h Zeigen Sie diese Hilfemeldung an

Ein erster Test ohne Eingabe zeigte die Hilfe an:

[ERROR] 2025-12-18 16:18:21 – Both START_TIMESTAMP and END_TIMESTAMP are required

Usage:

./dltsplf_bob_wr.sh START_TIMESTAMP END_TIMESTAMP [OPTIONS]

Timestamp Formats:

YYYY-MM-DD-HH.MM.SS (e.g., 2025-12-01-08.00.00)

YYYYMMDDHHMMSS (e.g., 20251201080000)

Nächster Test mit Timestamps: Fehler!

Trotz mehrmaliger Überprüfung der Timestamps kam immer wieder eine mysteriöse Fehlermeldung „Value too great for base (error token is “08”)“ mit Angabe der Zeile im Code, was eigentlich nur eine Überprüfung war, ob die Stundenangabe in einem Timestamp zwischen 0 und 23 liegt. Wir hatten 8 Uhr angegeben, im Timestamp also als „08“. Was also ist hier falsch?

if [[ hour -lt 0 || $hour -gt 23 ]]; then

log_message ERROR “Invalid hour: $hour”

return 1

Eine kurze Recherche im Internet lehrte uns, dass Bash die Zeichenketten 00 bis 09 als Oktalwert interpretiert. Wir kannten nun die Ursache, aber kennt das auch Bob?

Klar, nach einem Grund für den Fehler gefragt, bekamen wir auch eine ziemlich gute Erklärung und einen Vorschlag, das Problem zu umgehen, indem man „führende Nullen“ löscht:

fi if [[ ${hour#0} -lt 0 || ${hour#0} -gt 23 ]]; then

log_message ERROR “Invalid hour: $hour”

return 1

Da klar war, dass dies auch bei der Überprüfung von Tag, Monat, Minuten und Sekunden auftauchen kann, ließen wir Bob die Änderungen ebenfalls durchführen.

Neuer Test – nächstes Problem! Das Programm fand keine Spoolfiles, obwohl welche existierten.

Das Select-Statement war, wie ein Test im SQL-Script-Center von ACS zeigte, in Ordnung, und das Resultset war auch nicht leer. Allerdings wurde die Abfrage mit dem Tool „db2“ ausgeführt, welches zu den QShell Utilities von IBM i gehört.

Ich kannte dieses Problem! Wir führten unsere Tests nicht in einer „grün-schwarzen“ QShell-Session aus, sondern in einem VT100-Terminal mit SSH, wo „db2“ mit einer Fehlermeldung abbricht – welche aber nicht von Bob abgefangen und behandelt wurde.

Okay, woher soll die KI auch wissen, in welcher Zielumgebung wir das Skript verwenden wollen? Das nächste Mal geben wir das an. In unserer VT100-Umgebung existiert das Open-Source-Tool „db2util“, welches das Statement ausführen und ein Resultset im gleichen Format erzeugen kann wie „db2“.

Wir haben das selbst entsprechend geändert und uns vorgenommen, dass wir dies das nächste Mal in unseren Anforderungen mit angeben.

In einem weiteren Test konnten wir nun mit der Option –dry-run das Löschen von Spoolfiles simulieren. Sieht gut aus – lasst uns nun das Löschen von Spoolfiles durchführen.

Während in der Simulation mehrere Spoolfiles gefunden wurden, löschte das Skript exakt ein Spoolfile. Das Problem hatten wir doch schon mal (siehe Teil1), und Bob hatte uns die Lösung schon einmal gezeigt.

Damit war dieses Problem schnell behoben.

Nach gut 3 Stunden waren wir fertig. Jetzt lief das Programm fehlerfrei.

Fazit:

Gemeinsam mit unserem (natürlichen) Wissen und Erfahrungen, mit Unterstützung der künstlichen Intelligenz, haben wir es geschafft!

Interessant war, dass Bob zwar die Ursachen für die gefundenen Fehler „kannte“, aber sie trotzdem machte. (Irgendwie menschlich?)

Letztendlich waren wir auch diejenigen, die sich die Tests ausgedacht und die Fehler gefunden haben. Beim Analysieren der Ursachen und beim Fixen des Codes hat Bob sehr geholfen.

Wir haben wieder viel gelernt, und wir sind zuversichtlich, dass Bob uns bei weiteren leichten bis hin zu komplexen Programmierherausforderungen helfend zur Seite steht. Auf jeden Fall wurde das Coding beschleunigt. Allein hätten wir das in der Zeit wahrscheinlich nicht in diesem Umfang geschafft.

Hinweis: Bob kann nicht nur bei vielen Programmiersprachen unterstützen, er kann auch in mehreren Sprachen angesprochen werden, wie beispielsweise Deutsch:

„Hi Bob, kannst Du mir bitte ein Bash Programm schreiben, dass “shwsplf_bob.sh” heißt.
Das Programm wird in IBM i Pase ausgeführt und soll alle existierenden Spoolfiles anzeigen.“

Wir empfehlen trotzdem die Benutzung von Bob auf Englisch, um nicht über sprachliche Ungereimtheiten oder eingedeutschte technische Begrifflichkeiten zu stolpern.

Ein Beitrag von Sejid Canoski, TD Synnex und Dr. Wolfgang Rother, IBM.

Hier geht’s zum Teil 1.

Bob – „Ich bin Dein Fan!“

KI-Assistent für Softwareentwicklung: Bob – „Ich bin immer noch Dein Fan!“

Fazit:

Verwandte Beiträge