Die zweitschönste Nebensache der Welt

Auch mit APL2 Service Level 12 gilt, was bereits für vorangehende Versionen angemerkt wurde:

• APL-Zeichen wie z.B. "∆" in Namen von APL2-Objekten werden in der Titelleiste des Objekteditors nicht als solche angezeigt - soweit man den Schicki-Micki Aero-Desktop verwendet.
  
  Die Korrektur ist wohl schwieriger als man erwarten sollte. Microsoft legt den APL2-Entwicklern (und nicht nur denen) auch schwere Steine in den Weg.
  


• Bei deaktivierter Benutzerkontensteuerung entfällt die Einschränkung in der readmec.txt bezüglich des Zugriifes auf Dateien im APL2-Installationsverzeichnis.
  

Eine der wesentlichen Neuerungen der CSD 12 betrifft die DB2-Schnittstelle:

"As of Service Level 12, AP 127 has been re-written to use the CLI interface to DB2."

Dahinter steckt eine große Erleichterung: Nie wieder muss ich APL2 an eine DB2-Datenbank binden bevor ich auf diese per AP127 zugreifen kann.

Aber Vista zerstört so manche Verbesserung: Nach Installation der CSD 12 funktionierte das Deklarieren einer gemeinsamen Variablen mit dem AP127 schlicht und ergreifend nicht. Jeder Versuch brachte nur einen Kopplungsgrad von 1, einen zuwenig, um mit dem AP127 sprechen zu können.

Und wer stand wohl zwischen APL2 und dem AP127? Wie so oft die Benutzerkontensteuerung. Erst nachdem ich sie komplett ausgeschaltet hatte, konnte ich auf eine DB2-Datenbank zugreifen.

Netter Nebeneffekt: Bein Starten von Vista taucht nebenstehende DB2-Fehlermeldung nicht mehr auf und mit DB2 lässt sich wieder so bequem arbeiten wie unter XP.

Aber das ist nicht der einzige Grund, die Benutzerkontensteuerung entgegen der Empfehlung von Mickeysoft auszuschalten.

... einige Tage vor dem 11.11. wurde auf der GSE-Tagung der Service Level 11 für APL2 mit 11 Neuerungen und Verbesserungen vorgestellt. Wie jede CSD enthält auch diese einige Bug-Fixes, möglicherweise sogar 11 an der Zahl, ich habe sie aber nicht gezählt. Hier die 11 Neuerungen kurz gefasst:

Von "Multi-row Fetch" oder "Multi-row Insert" hatte ich bisher nichts gehört, bis mich David fragte mich heute morgen danach fragte. Ein APL2-Fan wünscht sich wohl, dass der AP127 diese DB2-Features nutzt. Recht hat er.

Seit der Version 8 bietet die Programmierschnittstelle der DB2 für z/OS die Möglichkeit, mit nur einem Fetch auf mehr als nur eine Zeile des Resultsets zuzugreifen. Eine sehr sinnvolle Erweiterung, die mit der Version 8.2 dann auch für andere DB2-Plattformen zur Verfügung gestellt wurde. Es liegt wohl nur an der Beschränkheit der Mainstream-Programmiersprachen, dass obwohl ein SQL-Select eine Menge von Tabellenzeilen als Ergebnis ergibt, aber auf Elemente dieser Menge nur einzeln zugegriffen werden kann - Zeile nach Zeile per Schleife.

Für APL mit seiner hervorragenden Fähigkeit, komplette Datenstrukturen verarbeiten zu können, stellt diese Einschränkung eher einen ärgerlichen Logikbruch dar. Nur gut, dass mit dem AP127 per Parameter für den Fetch mehrere Ergebniszeilen mit einer Anweisung zum APL2 übertragen werden können.

Wie gesehen kann der AP127 noch nicht mit dem XML-Datentyp umgehen, er kennt ihn schlicht und ergreifend nicht.

Das bedeutet aber nicht, dass jedes SQL-Statement, in dem XML-Daten angefasst werden, zwangsläufig zu einem AP127-Fehler führt. Solange das Ergebnis einer Query keine Daten vom Typ XML (988) enthält, ist alles gut.

Hierzu ein Beispiel mit der Tabelle XMLCUSTOMER:

select c.cid from xmlcustomer c where xmlexists(''$i/customerinfo[name = "Kathy Smith"]' passing c.info as "i")

XMLEXISTS ist ein neues Prädikat. Es prüft, ob ein XQuery-Ausdruck ein nicht-leeres Ergebnis bringt. Im Ergebnis der Query selbst tauchen dagegen nur die Integer-Werte der Spalte CID auf.

Auch diese Query verleitet den AP127 nicht zu einer Fehlermeldung:

select X.* FROM XMLCUSTOMER C, XMLTable(''$cu/customerinfo'' PASSING C.INFO as "cu" COLUMNS "NAME" CHAR(20) PATH ''name'', "STREET" CHAR(20) PATH ''addr/street'', "CITY" CHAR(20) PATH ''addr/city'') AS X

Denn die Tabelle X enthält nur dem AP127 bekannte Datentypen. Dass in der Query irgendwo XML-Dokumente verarbeitet werden, bekommt er nicht mit. Gut so!

Nichtdestotrotz wäre es mehr als sinnvoll, den AP127 mit dem Datentyp 988 vertraut zu machen.

Eines der herausragenden neuen Features der neuen DB2-Version ist der XML-Datentyp und die daraus resultierende Möglichkeit, komfortabel mit XML-Dokumenten in DB2 zu arbeiten.

Nun besitzt APL2 mit dem AP127 eine direkte Schnittstelle zu DB2, ohne Umwege über Interfaces wie ODBC. Nachdem ich auch auf diesem Rechner DB2 9 installiert habe, hat es mich geradezu in den Fingern gejuckt, mal auf XML-Daten von APL2 aus zuzugreifen.

Das Ergebnis zeigt, dass noch Einiges zu tun ist. Dazu ein erstes Beispiel:

Ich nehme die Tabelle XMLCUSTOMER aus der DB2 Sample-Datenbank. Sie hat zwei Spalten, CID und INFO. CID ist vom Typ Integer, INFO vom Typ XML.

Ein einfaches 'Select * from XMLCUSTOMER' mittels AP127 ergibt einen AP2X127105 "SQL DATATYPE 989 (COLUMN INFO) NOT SUPPORTED BY AP 127". Das ist nicht wirklich überraschend.

Der neue Datentyp muss also dem AP127 noch vorgestellt werden.

Das habe ich nun davon, dass ich mich nicht an eine sinnvolle Empfehlung zur Benutzung von Windows gehalten habe. Hätte ich mich aber daran gehalten, wäre ich nicht auf dieses seltsame Verhalten von DB2 gestoßen.

Meinen vorherigen Rechner "Number9" habe ich ausschließlich den User "Administrator" benutzt. Dies habe ich inzwischen für meinen aktuellen Rechner geändert. Auf unseren Linux-Systemen arbeite ich schließlich auch nicht standardmäßig als "root". Number9 hat natürlich auch ein DB2, seit Kurzem sogar in zwei unterschiedlichen Versionen. Da ich mich normalerweise unter meiner Windows UserID auch bei DB2 anmelde, habe ich mich wohl nie explizit mit UserID und Passwort mit einer Datenbank verbunden ("connect to ...") - weder über das DB2-Befehlsfenster, noch über den AP127 mit APL2. Ich bin nun mal schreibfaul.

Nun geschah es aber letzte Woche, dass DB2 von mir UserID und Passwort haben wollte (da ich mich mit dem zweiten DB2-Exemplar als entfernte Instanz verbinden wollte). Der

connect to apl2lib9 user Administrator

im Befehlszeilenprozessor funktionierte klaglos. Aber der Connect über AP127 zickte: Nach

CTL127←'CONNECT' 'APL2LIB9' 'Administrator' PASSW

beschwert sich AP127 mit einem(1 0 0 1 162): "THE USERID ARGUMENT TO CONNECT MUST BE A CHARACTER VECTOR OF LENGTH 1 TO 8".