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.
Ich ziehe Variante 1 vor, obwohl das etwas mehr Aufwand bedeutet. Hier nochmal kurz, was zu tun ist:
1. Datei apldb2.bat von ibmapl2w\samples nach ibmapl2w\bin kopieren
2. das DB2 "Befehlsfenster" starten
3. dort zum APL2 bin-Verzeichnis wechseln
4. apldb2.bat mit der Datenbank, an die der APL2 gebunden werden soll, als Parameter ausführen, z.B.:
apldb2 sample
Keiner weiß zur Zeit, warum der AP127 der CSD8 neu gebunden werden muss. Nancy meint, sie hätte nichts geändert, also gäbe es keine Notwendigkeit für die Prozedur. Beim Übergang von CSD6 nach CSD7 war das anders, da für die CSD7 ein anderer Compiler benutzt wurde.
Ansonsten muss der AP127 nur bei
Neuinstallation an DB2 gebunden werden, oder wenn es in der readmec.txt empfohlen wird.
ap127