Die zweitschönste Nebensache der Welt

"Gone are the days of storing XML data as a CLOB or shredding to relational tables. DB2 9's pureXML feature has revolutionized support for XML data - handling XML as a new data type that is stored in a natural hierarchy - separated from relational data."

Mit diesen Worten kündigte IBM gestern die neue DB2 Version DB2 9 - the database formerly known as Viper - an.

Danach verspricht DB2 9 durch die vollständige XML-Integration eine effektivere Anwendungsentwicklung und eine wesentlich bessere Performance bei der Suche nach Daten in XML-Dokumenten. Dies wird erreicht durch die Verheiratung von SQL und XQUERY.

Das heißt aber auch, es gibt wieder was zu lernen!

Glückliches XML, denn es wird nicht mehr zerrissen, zerschnitzelt und zerfetzt bevor es in die Datenbank kommt, oder es wird dort nicht mehr als unhandliches, strukturloses großes Etwas behandelt.

Unglückliche Anwender von Oracle's DB oder Microsofts SQL-Server, ihr müsst leider noch warten. Oder migrieren ...

Ich bin gespannt, ob die "Kenner der Datenbankszene" der Computerwoche endlich kapieren, was hier geschehen ist.

Das andere Highlight dieser Ankündigung soll nicht unerwähnt bleiben: Mit einem vom Mainframe übernommenen Kompressionsalgorithmus verspricht DB2 9 ökonomischeren Umgang mit Computerressourcen.

Die nächste Ankündigung wird auch nicht lange auf sich waren lassen: DB2 9 Express-C.

Dies geht nur mit "vernünftiger" Software:

Bisher hatte ich keine Probleme APL2 Sessions mit verschiedenen CSD-Levels auf meinem Rechner zu fahren, und das sogar parallel.

Sicher ist sicher, daher speichere ich bei jedem APL2-Upgrade auf einen neuen CSD-Level den alten Stand in ein eigenes Verzeichnis. So ist zur Zeit die aktuelle CSD8 unter "[...]\ibmapl2w" abgelegt, den vorherigen Stand hatte ich nach "[...]\ibmapl2w CSD7" kopiert. Dass dies keine Probleme bereitet, ist selbstverständlich.

Ich kann nun mit oder ohne Batch-Dateien nacheinander, aber auch parallel, die jeweiligen apl2win.exe starten. Die "Beginning Session"-Meldung bestätigt mir den erwarteten CSD-Level. Bisher konnte ich so problemlos parallel mit CSD7 und CSD8 arbeiten. Und das ist nicht selbstverständlich.

Auch APL2 bedient sich, wie fast jede Software unter Windows der Registry. Das scheint aber so unkritisch zu sein, dass es bisher zu keinem offensichtlichen Versionskonflikt kam.

Daher kann ich immer mal wieder die Änderungen von CSD7 zu CSD8 auf meinem Rechner parallel darstellen.

"Hierzu kommt vor allem bei Microsoft das Argument, dass die Dienste für Data Warehousing und Datenintegration kostenlos mit der Datenbank erhältlich sind."

Dies war in einem Bericht über die "Data Management Expo" von Barc und der Computerwoche (" Nichts geht mehr ohne Daten-Management", CW 15.05.2006) in eben dieser zu lesen.

Lese ich Microsoft und Barc? Da war doch noch was? Gerade heute tollen sich Microsoft und Barc gemeinsam durch Deutschland unter dem Motto "Roadshow - Business Intelligence mit Microsoft". Barc und die CW beglückten die deutschen Daten-Manager gemeinsam mit einem Kongress. Bei so viel Gemeinsamkeit ist es keine Überraschung, dass solche Statements in meiner wöchentlichen Pflichtlektüre auftauchen.

Die CW konsultiert doch gerne "Kenner" irgendeiner Szene. Vielleicht hätte der eine oder andere "Kenner der Datawarehouse-Szene" das eine oder andere zurecht gerückt.

Durch Zufall bin ich auf einen inzwischen recht alten Artikel im "The Register" gestoßen. Am 9. Dezember 2004 tat Philip Howard von Bloor Research seine Meinung zur damals frischen Ankündigung der nächsten DB2 Datenbankgeneration kund: "IBM moves the database goalposts". Damals schon sehr vorausschauend in Hinblick auf die am Freitag beginnende WM.

Aber eben nicht nur in diesem Sinne vorausschauend: Einige Dinge, die ich hier über DB2 Viper und auch über die Reaktionen darauf, geschrieben habe, hat der Autor bereits Ende 2004 in besagtem Artikel zusammengefasst. Zu der Zeit konnte ich es noch nicht tun, weil dieser Blog noch nicht existierte.

Aber nun ernsthaft zum Thema "Schaum vorm Mund", das, was nach Philip Howard Oracle nun schon eine Weile mit sich rumträgt. Zu Beginn lade ich ihn als Zeuge für mein "Ceterum Censeo":

"IBM has concluded, rightly in my view, that using a relational approach is not adequate for processing XML. Either you store it in relational format, in which case you get a major performance hit because you have to convert it to and from tabular format whenever you store or retrieve it, or you have to store it as a binary large object, in which case you can’t do any processing with it."

Im Nachhinein lasse ich mir von Howard des weiteren bestätigen, dass der XML-Unterstützung durch Viper die direkten Konkurrenten zur Zeit nichts entgegen zu setzen haben:

konstatierte Gartner in seiner "Gartner Study on DBMS Identifies Spending and Deployment Trends". Da diese recht umfangreich ist, zitiere ich hier für Lesefaule eine aus meiner Sicht erfreuliche Stelle:

"The biggest surprise is DB2 from IBM, with 19 percent planning to install DB2. This is nearly 50 percent higher than the number planning to install Oracle. DB2 has long been a strong DBMS offering, but has suffered from multiple versions, perceived lack of portability and a lack of third-party support. IBM has been marketing heavily during the past several years to change this perception and encourage software vendors to port to DB2. It would appear their efforts are working."

IBM hat lange Zeit die Marktentwicklung bei relationalen DBMS verschlafen, obwohl die erste relationale Datenbank in einem IBM-Labor implementiert wurde.

Die Jagd auf Oracle scheint noch mehr in Asien zu fruchten:

"Even more interesting is that IBM DB2 is at 27 percent planned in the Asia/Pacific region, and Oracle is only at 10 percent. This is partially due to Oracle's broad penetration in this market, but also because of IBM's strong marketing efforts. The overall numbers so strongly in favor of DB2 indicate a pending increase in IBM's market share for DBMS during the next few years."

Es scheint so, dass gerade hier die Anwender Spaß daran haben "Oracle eine aufs Maul hauen".

Der APL2 Object Editor ist ein eigenständiges Programm und kommuniziert mit dem Session Manager über das Shared Variable Interface. Doppelklick auf einen Funktionsnamen bedeutet, dass die Funktion über eine Shared Variable (AP120_EDIT) an den Editor geschickt wird und dort in einem eigenen Fenster angezeigt wird.

Aber was heißt hier "die Funktion"?

Nach den Problemen, die wir mit dem Editieren einer gigantischen Funktion hatten, kann man davon ausgehen, dass die besagte Funktion in ihrer Character Representation verschickt wird. Alleine der Versuch diese Funktion, deren CR größer als 12 MB ist, in den Editor zu klicken, schlägt mit der Meldung "System Limit - Interface capacity" fehl. Erhöhung des Wertes für MAXSV auf 13 MB führt zumindest dazu, dass die Funktion ordentlich im Editor angezeigt wird.

Die CR einer Funktion zu transferieren bedeutet im vorliegenden Fall. extrem viele irrelevante Leerzeichen durch den Kanal zu schieben. Diese werden zum Auffüllen der Zeilen auf die Länge der längsten Zeile - hier der 6 KB langen Kopfzeile - produziert. Lässt man diese nichtssagenden Blanks außer Acht, ist die Funktion nur noch knapp 100 KB groß. Eine solche offensichtlich wesentlich sparsamere Darstellung einer Funktion erhält man mit 2 ⎕TF, einer Darstellung, die auch von )OUT benutzt wird.

Warum wird also die CR durch den Kanal zum Editor geschoben?

Alles hat seine Grenzen, so auch der APL2 Object Editor.

Denn sehr große Funktionen können schon mal Probleme beim Editieren bereiten. Ich meine damit nicht, dass man sich schlecht in ihnen orientieren kann, lange nach zu ändernden Stellen suchen und sehr viel vor und zurück blättern muss. Die Probleme können rein technischer Art sein:

Es fängt schon damit an, dass Doppelklick auf den Namen der Funktion diese nicht in den APL2 Object Editor lädt. Immerhin verrät der Session Manager in der Statusleiste, was ihn stört: "System Limit - Interface Capacitiy". Alles klar?

Es kann auch passieren, dass, nachdem die Funktion klaglos in der Object Editor geladen wurde, vorgenommene Änderungen an der Funktion nicht gespeichert werden können. Auch der Editor versucht uns in der Statusleiste zu erklären, was ihm fehlt: "System Error - Shared Memory Shortage". Kling gefährlich, ist es aber nicht.

Bevor es allzu abstrakt wird, hier ein Beispiel aus meinem wirklichen Leben:

Wozu sind Standards eigentlich gut, wenn sich keiner an sie hält. So einen Standard kann man eigentlich in die Tonne drücken.

Ich meine hier den ISO-SQL-Standard. Hier kocht jeder Datenbank-Hersteller sein eigenes proprietäres Süppchen. Die einen, damit zahlende Kunden sich nicht mehr aus der Umklammerung des Herstellers befreien können, die anderen, weil sie die Bedeutung von Standards nicht erkannt haben oder erkennen wollen. Erstes gilt in jedem Fall für Oracle, zweiteres muss ich leider bei MySQL annehmen.

Trotzdem ist der SQL-Standard seit Jahren von unschätzbarer Bedeutung (und hat auch nichts in einer Tonne verloren).

Was aber fast noch mehr nervt, aus heutiger Sicht fast schon ein Skandal ist, ist, dass die ISO für das Herunterladen der Standard-Dokumente richtig abkassieren will. Die etwas kostengünstigere Alternative wäre nur der Kauf eines Buches.

Aber zurück zur Standardtreue der Hersteller.

Das ist mal ein richtig lustiger Artikel auf heise online. Danke, David Triedl, für den Hinweis. Ich befürchte, ohne diesen Tipp hätte ich dieses Beispiel für absurde Dialektik eventuell übersehen können. So habe ich viel Spaß gehabt.

Aber die Sache, um die es geht, ist zu ernst: Mangelnde Softwarequalität, Sicherheitslücken en masse. Man muß den Eindruck bekommen, dass wir nicht in der Lage sind, die wachsende Komplexität von Software zu beherrschen. Immer mehr Anwender beklagen sich zu recht, dass sie als zwangsverpflichtete kostenlose Tester missbraucht werden.

Mary Ann Davidson, immerhin bei Oracle "Chief Security Officer" (CSO), "platzte auf der W3C-Konferenz in Edinburgh der Kragen angesichts einer Software-Industrie, die von unausgereiften Produkten komplett durchsetzt sei", heißt es bei heise-online. Das ist erstaunlich und seltsam zugleich.

Denn Frau Davidson hat recht, sie muss es ja auch schließlich wissen. Und es sollte eigentlich gut sein, dass eine Managerin eines der größten Software-Herstellers das Gebaren ihrer Kollegen öffentlich anprangert.

Aber es beschleicht mich immer mehr ein seltsames Gefühl bis hin zu einem bösen Verdacht.

Ein weiteres kaum genutztes Systemkommando war und ist )QUOTA. Ich habe es auf dem Host das letzte mal vor einigen Jahren benutzt und mehrfach versucht, es unter Windows auszuführen. Zu blöd, denn Workstation APL2 kennt dieses Kommando nicht und wird es wahrscheinlich auch nicht kennen lernen.

)QUOTA gibt manchmal hilfreiche Größenangaben zum Workspace, zur APL2-Bibliothek und zum Shared Variable Interface. Diese Angaben machen aber teilweise nur in der Host-Umgebung Sinn. So müssten in Workstation-Umgebungen der Werte für die Größe der privaten APL2-Bibliothek und der dort noch verfügbare Speicherplatz uminterpretiert werden.

Auf der Workstation kann ich anders als auf dem Host die Workspace-Größe "dynamisch" vorgeben: starte bei einer minimalen Vorgabe, falls eine Anwendung mehr Platz benötigt, erhöhe sie um schrittweise um eine bestimmte Größe solange bis die Grenze des Erträglichen erreicht ist.

Leider ist es nur schwer herauszufinden, wie viel Platz APL2 in einer konkreten Situation für sich beansprucht. Aus der Sicht der Entwicklers von APL-Systemen scheint eine solche Information sinnlos oder gar schwer ermittelbar zu sein, aber ich habe sie schon häufiger vermisst.

Apropos "vermissen": Wo finde ich im Workstation-APL2 die )QUOTA-Angaben zur maximalen Anzahl gleichzeitig aktiver Shared Variables und zur Größe des "Shared Storage"?

Ich glaube, )CHECK WS gehört zu den kaum bekannten und daher wenig genutzten Systemkommandos. Ich gebe gerne zu, dass ich es selbst lange nicht mehr verwendet habe.

Warum auch? Denn )CHECK WS wird automatisch beim Laden und Speichern eines Workspaces ausgeführt. Ist was faul im WS, so gibt es Meldungen wie in "Schuld war nur die Platte" beschrieben. Wer wie ich häufig eine Workspace während der Entwicklung und des Testens speichert bekommt also )CHECK WS geschenkt.

Nun gibt es aber noch eine Variante von )CHECK WS, die ich total vergessen hatte:

)CHECK WS [ON|OFF]

Man muss schon recht verzweifelt sein, um diesen Schalter umzulegen. Denn danach wird nach jeder Ausführung einer APL2-Grundfunktion ("primitive function") der Workspace ausgiebig geprüft. Bei größeren Anwendungen kann man ruhig ein Tasse Kaffee trinken gehen.

Die hiernach angesagte Tuning-Maßnahme wäre dann )CHECK WS OFF. Ich habe selten mit so wenig Aufwand eine Anwendung um das Vielfache beschleunigt. Mit )LOAD und )CLEAR erzielt man übrigens in diesem Falle das gleiche Ergebnis: Diese Kommandos setzen einen gesetzten )CHECK WS Schalter wieder zurück.

Dies alle und noch viel mehr kann im APL Language Reference (S.418) nachgelesen werden.

Wer kennt ihn nicht, den SYSTEM ERROR/CLEAR WS. APL2 ist auch unter Windows inzwischen ein sehr stabiles System, aber manchmal zerreißt es auch das beste System. Ich denke, häufig ist es Windoof, das den Speicher zerbröselt, so dass die Pointer-Verwaltung im APL2 nicht mehr stimmt.

Aber es muss nicht immer der übliche Verdächtige sein.

Ich habe vor einigen Wochen einen CONTINUE geschickt bekommen, der nach dem Laden folgende Meldung ausgab:

Checkws: mentry does not point back, ri = 0x350d0

Auf dem Rechner des Entwicklers gab es kurz vor dem SYSTEM ERROR/CLEAR WS eine schier unendlich lange Liste (immerhin ca. 1000 Zeilen) mit solchen Ausgaben und darauf folgend noch Meldungen wie

Checkws: points to mentry with different ri, ri = 0xdbda

Zu guter Letzt beklagt sich Checkws noch über ein "negative-length object".

Das erste, was ich in einem solchen Fall mache, ist ein WS-Reorg: )CLEAR, )COPY und )SAVE. Das räumt auf und reduziert den belegten Speicher. Dies wollte aber hier nicht die erwartete Heilung bringen. In nerviger Regelmäßigkeit stürzte das APL2 per SYSTEM ERROR ab.

Der Hinweis zur Lösung war dann letztendlich, dass obige Probleme auf anderen Rechnern nicht auftraten. Schuld war wohl die Festplatte. Denn nachdem diese "repariert" wurde, tritt der SYSTEM ERROR nicht mehr auf.

Es ist schön, wenn auch indirekt, Recht vom eigenen Sohn zu bekommen.

Ich hoffe, man kann mir nicht nachsagen, dass ich etwas gegen MySQL habe. Im Gegenteil, ich habe MySQL immer gemocht, da es Open Source und frei verfügbar ist, und so jedem einen leichten Einstieg in die Datenbankwelt ermöglicht.

Für den "professionellen" Einsatz hat MySQL seine Grenzen. Auch heute noch. Das muss nicht für alle Zukunft gelten. An diese Grenzen sind nun schon einige Anwender gestoßen. Einer ist Bernd. Weil es so instruktiv ist, zitiere ich die hierfür wesentliche Stelle:

"Schon seit langem habe ich die Vermutung, dass die darunterliegende Datenbank für ein solches Datenvolumen nicht wirklich gebaut ist und so ihre Problemchen damit hat und so dauert allein die Anfrage an die Tabelle mit den vielen Datensätzen schonmal mehrere Minuten - obwohl es einen wunderschönen Primary Key und 11 weitere Indizies gibt."

Früher hieß es "Trau keinem über 30". Das galt für Menschen. Für Unternehmen in der IT-Welt reicht sogar schon "Trau keinem", auch nicht Oracle.

Das gilt auch für die sich gerne als unabhängige und neutrale Berater gerierenden Technologie-Analysten und IT-Research-Unternehmen wie Forrester, Gartner, IDC, Ovum oder Barc.

"Forrester Research (NASDAQ: FORR) is an independent technology and market research company ..."
"Ovum is a resolutely independent advisory organisation."

Barc fabuliert, äh formuliert, unter der Überschrift "Neutralität"

"... In seiner Stellung als unabhängiges Institut ist BARC strikt neutral gegenüber Softwareanbietern. Dies bedeutet, dass keine Gebühren für die Aufnahme in Studien oder Provisionen bei der Empfehlung von Software erhoben werden und BARC auch keine Implementierung von Software anbietet, um keine internen Interessen zu erzeugen. ..."

Mir war schon immer nicht ganz wohl bei dem Gedanken an die angebliche Unabhängigkeit dieser und anderer IT-Research-Unternehmen. Sie verdienen doch alle auch durch direkte Aufträge von Hard- und Software-Herstellern. So kaufte sich Microsoft diverse Studien von Forrester, BearingPoint, IDC und anderen für seine "Fakten" zur Kampagne gegen Linux.

Apropos Microsoft: Die beglücken nicht nur amerikanische Analysten, sondern auch hiesige:

"Red Hat wickelt Linux in proprietäre Scheiße ein."
"Red Hat ist ein Verpacker, keine Technologiefirma."
"Red Hat entwickelt keine nennenswerte Technologie"

Dies und noch viel mehr über Red Hat schrieb Jboss-Chef Marc Fleury einst in seinem Blog.

Aber wir sind doch alle irgendwo bestechlich. Leider auch Menschen aus der Open Source Welt. Nachdem Fleury seinen Laden an Red Hat für teuer Geld verkauft hatte, versuchte er seine Sprüche zu seinem neuen Arbeitgeber aus der Web-Welt zu tilgen. Aber er hatte die Rechnung ohne den Google-Cache gemacht. Dort konnte der Blog-Eintrag noch lange besichtigt und kopiert werden.

Das Original-Zitat kann z.B. bei Wolfgang Sommergut bestaunt werden. Solange, bis dieser von Rad Hat gekauft wird.

Wie nun unser Wendehals Marc mit seinem neuen Arbeitgeber klarkommt bleibt zu verfolgen.