Die zweitschönste Nebensache der Welt

So überschrieb Alan Zeichick seinen Blog-Eintrag zu 40 Jahre APL. Für mich ist Alan ein APL-Unbekannter. Nach eigener Aussage hat er Ende der 70er Jahre mit APL gearbeitet. Das kann aber nicht sehr ernsthaft gewesen sein: "I have no idea why we had APL on our System/370; it was never used for anything but fooling around."

Ich habe einige Ideen, wozu er und seine Kollegen hätten APL sinnvoll einsetzen können. Viele haben das ja gerade zu der Zeit getan. Dies ist übrigens auch heute noch eine wahre Aussage - nicht dass jemand jetzt auf die Idee kommt zu meinen, APL sei heute tot. Dem ist glücklicherweise nicht so.

Doch weiter zu Alan's Blog-Eintrag "Amazingly, IBM still sells APL tools today, 40 years later ...". Aber das sollte Dich doch nicht wirklich überraschen, Alan, denn Gutes hält sich ewig.

"You can perform complex calculations with only a few characters; designing algorithms to be concise (and often unreadable) is a marvelous talent." Talent hin oder her, die Fähigkeit, Algorithmen prägnant zu formulieren, ist auch eine typisch mathematische Eigenschaft. APL ist hier genauso lesbar oder unlesbar wie Mathematik. Und diese Präzision, die dem mathematischen Denken inne wohnt, ist Basis für die erstaunlichsten Fortschritte in den letzten Jahrhunderten.

"Sadly, I didn't spend enough time with APL to develop much skill. My "real" work involved PL/1, COBOL and FORTRAN, and noodling with APL was essentially a hobby." Dem kann man nur zustimmen. Tatsächlich ein trauriges Leben als ITler.

Tatsächlich startet Alan's Beitrag zur APL-Geburtstagsparty nicht sonderlich stark. Macht nichts, denn das Ende ist herrlich ("that article" meint den Beitrag zu APL in en.wikipedia.org):

"However, that article merely scratches the surface, and doesn't show the beauty and elegance of APL programming."

Dem ist nichts mehr hinzuzufügen.

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.