Wie in den vorangegangenen Berichten erwähnt, sind weder Sejid Canoski noch ich professionelle Anwendungsprogrammierer. Für uns ist das ein Grund, uns bei Softwareprojekten Unterstützung zu suchen – auch wenn unsere Anforderungen „überschaubar“ sind. Denn wir wollten lediglich eine Python-Flask-Lösung unter IBM i entwickeln, um Spoolfiles aus einer IBM i Output Queue zwischen zwei Zeitstempeln zu löschen, wofür Bob uns bereits einen passenden Projektplan erstellt hatte.

Insgesamt schien uns der Aufwand dafür etwas übertrieben, denn eine ähnliche Funktionalität hatten wir bereits als Bash-Skripte implementiert und sie ist auch im IBM i Navigator verfügbar.

Uns ging es jedoch nicht primär um eine „schöne“ Lösung, sondern darum, Erfahrungen zu sammeln, wie sich mit Bob Software entwickeln lässt. Wir starteten also den Modus „Code“ und gaben Bob die Anweisung, den zuvor vorgeschlagenen Plan in den einzelnen Phasen abzuarbeiten.

Code zu generieren ist für Bob kein Problem – so schnell kann man kaum mitlesen, wie die Zeilen entstehen. Die interessantere Frage ist jedoch, ob das Programm auch fehlerfrei ist. Um dies zu überprüfen, erstellte Bob zusätzlich ein Setup-Programm zur Einrichtung der Runtime- und Testumgebung sowie entsprechende Testroutinen.

Aus unserer Sicht bemerkenswert war, dass im generierten Code von Anfang an aktuelle Sicherheitsfeatures integriert waren – Aspekte, die in der Softwareentwicklung als „non-functional requirements“ häufig erst nachgelagert betrachtet werden. (Pluspunkt für Bob!)

Allerdings stellten uns die Sicherheitsanforderungen auf unserem IBM i-Testsystem vor einige Herausforderungen, da Sicherheit dort bislang nicht die höchste Priorität hatte. Hinzu kam, dass sich einige Python-Module wie pip nicht direkt aus dem Quellcode kompilieren ließen. Als Alternative standen jedoch fertige Pakete im Open Source Package Management zur Verfügung, die wir nutzen konnten. Erst nachdem wir diese Hürden überwunden hatten, konnten wir mit dem eigentlichen Testen des Codes beginnen.

Schon die Anmeldeseite überraschte uns:

Anfangs versuchten wir, fehlerhafte Links im Quellcode manuell zu korrigieren, bis wir dazu übergingen, solche Fehler einfach Bob mitzuteilen und von dem Tool beheben zu lassen.

Oft gelang Bob dies bereits mit den ersten Anpassungen. Manchmal jedoch – wie im wahren Leben – führte ein Korrekturversuch zu neuen oder bereits bekannten Problemen. Letztendlich erschien uns dieser Ansatz jedoch effektiver, als den Code vollständig selbst zu verstehen und Änderungen eigenständig vorzunehmen.

Kenntnisse im Umgang mit Debuggern waren dabei notwendig, um Bob gezielt Informationen über auftretende Fehler liefern zu können.

So formulierten wir beispielsweise folgenden Prompt:

________________________________________________________________________________________

Hi Bob, help us to understand application errors. When executing the application in folder Phase-5-bob-unverified we get an error message: 400 Bad request and the Edge browser shows the following error messages:

api.js:29

POST http://172.17.17.76:5000/api/v1/spoolfiles 500 (INTERNAL SERVER ERROR)

request @ api.js:29

querySpoolfiles @ api.js:75

loadSpoolfiles @ spoolfiles.js:127

handleSearch @ spoolfiles.js:177

api.js:62

API request failed: Error: Failed to query spoolfiles

at SpoolfileAPI.request (api.js:57:23)

at async loadSpoolfiles (spoolfiles.js:127:26)

request @ api.js:62

await in request

querySpoolfiles @ api.js:75

loadSpoolfiles @ spoolfiles.js:127

handleSearch @ spoolfiles.js:177

spoolfiles.js:144

Error loading spoolfiles: Error: Failed to query spoolfiles

at SpoolfileAPI.request (api.js:57:23)

at async loadSpoolfiles (spoolfiles.js:127:26)

loadSpoolfiles @ spoolfiles.js:144

await in loadSpoolfiles

handleSearch @ spoolfiles.js:177

________________________________________________________________________________________

Bob genügt in der Regel die Fehlermeldung. Wir betrachteten diese Art der Zusammenarbeit jedoch als einen Dialog mit der KI, zumal Bob nach erneuter Sichtung des Codes meist sehr höflich antwortete:

________________________________________________________________________________________

Now I see the issue! The column `JOB_NUMBER` doesn’t exist. Let me check the current queries.py file to see what columns we’re using:

<read_file>

<args>

<file>

<path>app/database/queries.py</path>

<line_range>1-60</line_range>

</file>

</args>

</read_file>

________________________________________________________________________________________

„Long story short”: Die Hauptarbeit war:

Code-Änderungen von Bob durchführen lassen
Verhalten der Anwendung prüfen
Fehlermeldungen und Debug-Information zurückgeben
Code Änderungen von Bob durchführen lassen
Usw.

Letztendlich bestand unsere Entwicklungsarbeit also hauptsächlich aus Tests und dem Sammeln von Informationen, die wir an Bob zurückspielten – aber eben nicht nur …

Manchmal schien es notwendig, Bob konkrete Hinweise zu geben, wie er einen Fehler beheben könnte. So kennt Bob beispielsweise nicht immer die exakte Syntax eines IBM i SQL-Services oder die erforderlichen Eingabewerte. Entsprechend kam es vor, dass Bob etwa Folgendes postulierte:

The user’s IBM i system version does not have a job number column in the `QSYS2.OUTPUT_QUEUE_ENTRIES_BASIC` view.

… was natürlich nicht stimmte. Ein Beispiel für die Ausführung dieses Service auf dem Zielsystem beantwortete Bob mit:

Changed BASE_VIEW back to `QSYS2.OUTPUT_QUEUE_ENTRIES_BASIC` (confirmed working on user’s system)

Ein anderes Mal versuchte Bob Spoolfiles zu finden, die auf dem Status HOLD stehen und verwendete „*HELD“ und „HLD“ als Suchkriterien. Ein Hinweis durch ein Beispiel einer funktionierenden SQL Query mit „HELD“ ohne Asterix:

SELECT * FROM QSYS2.OUTPUT_QUEUE_ENTRIES where STATUS = ‘HELD’

half dem Tool die Query richtig zu formulieren. Insofern sind Kenntnisse und Erfahrungen im Umgang mit dem Zielsystem hilfreich und notwendig, zumal sowas auch vom jeweiligen IBM i Release und dem PTF-Stand abhängen können.

Letztendlich haben wir es mit Geduld und Ausdauer geschafft. Der Zeitaufwand lag bei etwa drei bis vier Tagen – vorausgesetzt, wir hätten kontinuierlich daran gearbeitet.

Das Ergebnis bietet mehr, als wir ursprünglich geplant hatten: Statt einer einfachen Webanwendung zum Löschen von Spoolfiles verfügten wir nun über einen Spoolfile-Manager mit ähnlicher Funktionalität wie der IBM i Navigator – umgesetzt als Webanwendung auf Basis von Python.

Nachfolgend ein paar Screenshots:

Verbesserungen sind immer möglich. Wir waren jedenfalls mit dem, was wir durch Bob erreicht haben, mehr als zufrieden.

Nachtrag:

Natürlich gab es noch einen „letzten“ Fehler: Die Output-Queue-Seite funktionierte nicht so, wie erwartet. Zwar hatten wir uns schon gewundert, dass es – wie im obigen Bild zu sehen – nur drei Output Queues auf dem System gab, aber dass alle den Status „HELD“ hatten, verwunderte uns noch mehr. Also drückten wir den „Release“-Button – womit der Disput mit Bob wieder begann.

Nachdem einige Korrekturversuche nicht zum Erfolg führten und wir im Change Log lasen, dass Bob sich unsicher war, welche Spaltennamen in der View verwendet wurden, gaben wir ihm erneut ein korrekt ausführbares SQL-Statement:

SELECT OUTPUT_QUEUE_NAME, OUTPUT_QUEUE_LIBRARY_NAME, OUTPUT_QUEUE_STATUS

FROM QSYS2.OUTPUT_QUEUE_INFO

womit wir Bob einerseits einen IBM i SQL Service für die Task vorschlugen und gleichzeitig auch die korrekten Spaltennamen zeigten.

Dann rätselte Bob, welche Werte für den Status in der View verwendet wurden und bat um Hilfe:

I need to know the exact status values (e.g., is it “HELD”, “RELEASED”, “*HELD”, “*RELEASED”, or something else?) so I can update the frontend logic to correctly interpret them.

Später hatten wir Probleme, wenn der Status einer Output Queue geändert werden sollte. War der Status beispielsweise „RELEASED“ und wir drückten den „Release“-Button, trat ein Fehler auf, der entsprechend behandelt werden musste. Dasselbe galt für „Hold“, wenn der Status bereits „HELD“ war.

Prinzipiell kann man solche Fehler abfangen und gar nichts tun, aber wir gaben Bob vor:

Let only release an output queue if the status is “HELD” and give a short message, that it is already on “HELD” – do the same for “RELEASED”

was er mit

Good idea! Let me add client-side validation to check the queue status before attempting hold/release operations

quittierte und auch gleich umsetzte.

Schließlich lösten wir es doch anders:

On the output queue page show only a “Release” button if the queue is on “HOLD” and vice versa

Dies wurde in Sekunden erledigt:

Nun war alles in Ordnung – oder haben wir doch nur den „vorletzten“ Fehler beseitigt?

Die Autoren Sejid Canoski (TD Synnex) und Dr. Wolfgang Rother (IBM) berichten in mehreren Artikeln über ihre Erfahrungen mit IBM Bob.

Zu Teil 1

Zu Teil 2

Zu Teil 3

IBM Bob ist seit dem 24. März offiziell verfügbar. Hier erfahren Sie mehr.

Entwicklung im Dialog: BOB – „Ich bleibe Dein Fan!“

Nachtrag:

Verwandte Beiträge