Montag, kurz vor Mitternacht, habe ich eine meiner Regeln verletzt und wäre auch fast bestraft worden. "Don't change a running system" vor einer Präsentation. Aber meine Neugierde überwog, und ich installierte kurzerhand die CSD8. Um sicher zu gehen, testete ich nochmals die Anwendung, über die ich am Dienstag reden wollte. Siegessicher starte ich sie, machte die nötigen Eingaben und ... nichts passierte. Das war nicht ok, irgendwas war falsch.
Kurzum: der Grund war ein SQL0818N "Ein Zeitmarkenkonflikt ist aufgetreten". Warum, weshalb? Dienstags um 0 Uhr hatte ich keine Ahnung. Offensichlich eine Verstimmung zwischen APL2 und DB2, denn der Zugriff auf die betroffene DB2-Tabelle funktionierte klaglos im DB2-Befehlszeilenprozessor.
Trotz allen Mutes, bin ich doch immer noch einigermaßen vorsichtig. Ich hatte als Netz und doppelten Boden die CSD7 noch auf der Platte. Das bin-Verzeichnis zurück kopiert, und alles war wieder gut.
Die Lösung des Rätsels gab's am kommenden morgen. Nancy, die Entwicklerin des AP127 ("eine 27-jährige entwickelte diesen AP") hatte dieses Problem schon am Freitag gesehen. Sie schlug gleich zwei Lösungen vor:
1. den AP127 neu binden
2. den AP127 der CSD7 in das aktuelle bin-Verzeichnis zurück kopieren.
"Neu binden" vollständig lesen
ap127