Die zweitschönste Nebensache der Welt

Als jemand, der Mathematik studiert hat, wird man schon mal von "normalen" Menschen mit unausgesprochenem Mitleid versehen. Schließlich haben doch Mathematiker nur Zahlen im Kopf, und es mangelt ihnen häufig an sozialer Kompetenz. Aber dafür können wir auf unserer Habenseite eine erlernte Sorgfalt im Umgang mit Zahlen und Statistiken verbuchen.

Zahlen alleine sind weder wahr noch falsch. Zahlen aus statistischen Erhebungen werden nur im Zusammenhang mit Aussagen über das Untersuchungsgebiet interpretierbar. Und diese sollten stets mit dem reinen Zahlenwerk angegeben werden.

Der Sündenfall

Daher hat mich die folgende "Untersuchung" geradezu fassungslos das Heft 22 der Computerwoche zuschlagen lassen. Unter "Zahlen - Prognosen - Trends" (Seite 58) ist dort Folgendes zu lesen:

"Im Markt für relationale Datenbanksysteme gelang es Oracle auch im letzten Jahr. den Wettbewerb in Schach zu halten."

So weit, so unproblematisch. Doch dann geht's ans Zahlenwerk unter dem Titel "Weltweiter Markt für relationale Datenbanksysteme (RDBMS), 2005": Oracle 44,6%, IBM 21,4%, Microsoft 16,8% usw. Die Angaben beziehen sich gemäß der Fußnote auf einen Gesamtmarkt von 14.6 Mrd. Dollar. Quelle: IDC.

IDC, klingt doch seriös. Ist es aber nicht, es grenzt eher an einen üblen Versuch von Verdummung. Bei ein wenig journalistischer Sorgfalt hätte der zuständige Redakteur mal ins eigene Archiv geschaut - was ich dann getan habe.

Im Vergleich zur Darstellung von Umlauten in einem Grid ist die Situation bei Listviews komplexer. Das Wesentliche vorweg: Auch hier gibt es Unterschiede zwischen CSD 8 und CSD 7 (und früher).

Betrachten wir zuerst Schriftarten, die keine APL-Zeichen enthalten, also z.B. MS Shell Dlg, MS Sans Serif oder Tahoma. Sollten mit CSD 7 Umlaute auch als solche in einem Listview dargestellt werden, mussten sie vorher z.B. durch APL2_TO_WINDOWS umgesetzt werden. Mit CSD 8 sollte man das nicht tun, denn sie werden bereits ohne Umwandlung korrekt angezeigt.

Unicode-Fonts enthalten zwar APL-Zeichen, verhalten im Vergleich von CSD 7 und CSD 8 wie Schriftarten ohne APL-Zeichen.

Mag sein, dass der Computer nicht ausschließlich in den USA erfunden wurde, aber die EDV- bzw. IT-Standards wurden eben dort in den letzten Jahrzehnten gesetzt. So auch die Zeichensätze, seien es ASCII oder EBCD. Und was dort nicht bekannt war, floss eben nicht in die Definitionen ein.

Dazu gehören leider auch unsere Umlaute und das Eszet. Nach nun mehr als 30 Jahre Arbeit mit Computern befürchte ich, dass wir allgemein länderspezifische Sonderzeichen immer noch nicht im Griff haben (Unicode lässt grüßen). Das fällt diesmal beim Wechsel von APL2 CSD7 auf CSD 8 auf, zwar nur marginal, aber immerhin:

Die Darstellung der Umlaute in einem APL2-Grid war schon immer abhängig vom gewählten Zeichensatz. Sie wurden korrekt ausgegeben, soweit der Zeichensatz der Wahl z.B. "APL2 Image" war, bei anderen wurden Umlaute erst als solche angezeigt, wenn sie vorher z.B. durch APL2_TO_WINDOWS (aus 2 WINDOWS) umgewandelt wurden.

Dies gilt auch fast so für die CSD 8, aber nur fast: Den Unterschied macht die Schriftart MS Sans Serif. Das ist der Font, der verwendet wird, soweit kein spezieller Font spezifiziert wurde. Schickt man nun Umlaute vorher - wie bei früheren Releases nötig - durch APL_TO_WINDOWS, so werden im Grid irgendwelche Zeichen ausgegeben, aber keine Umlaute.

Meine Freude über die stetig wachsende Marktdurchdringung des IE-Konkurrenten Firefox wird umgehend leicht getrübt durch eine heise-Meldung:

"Nachdem die Ad- & Spyware-Szene bereits seit Jahren auf diesem Weg Lücken des Internet Explorer ausnutzt, geraten durch die steigende Verbreitung jetzt offenbar auch vermehrt Firefox-User ins Visier."

Jede Medaille hat eben zwei Seiten.

Ich habe bisher nie behauptet, dass die Computerwoche zum erweiterten Kreise der Microsoft-Apologeten gehöre, auch wenn sie schon mal einen solchen Verdacht nahe legt. Im einem CW-Artikel unter dem Titel "Mozilla-Chefin: Datenschutz treibt Marktanteil von Firefox an" ist weiter unten folgende Aussage zu finden:

"Netscape und Microsoft hatten sich in den neunziger Jahren in einem erbittert geführten "Browser-Krieg" gegenübergestanden, den Microsoft - auch durch den Einsatz von illegalen Geschäftspraktiken - für sich entscheiden konnte."

"Illegale Geschäftspraktiken" - so klare Einschätzungen wünsche ich mir häufiger.

Es sieht tatsächlich so aus, dass wir in diesem unseren Lande eine vorbildliche Fußball-Weltmeisterschaft hinlegen: Stimmung super, Stadien voll, Organisation typisch deutsch - Franz und Co. sei Dank.

Mir war bisher noch nicht bekannt, dass wir Deutschen kollektiv so durchknallen können.

Aber wir sind wohl nicht nur in Sachen Fußball-WM vorbildlich, sondern in der korrekten Nutzung von Web-Browsern:

Nach eine Studie von Techconsult (s. CW 21, 26.05.2006) nutzen in Deutschland bereits 30% Firefox als Browser. In Europa sind es dagegen im Durchschnitt erst 20%, auf den anderen Kontinenten sogar noch weniger.

Erfreulich ist auch, dass die Popularität von Firefox weltweit weiterhin stark ansteigt. In Deutschland wuchs der Anteil der Firefox-Nutzer im Vorjahrsvergleich um ca. 20%, in Europa sowie auch weltweit um ca. 30%.

Ein Grund für diese erfreulich vernünftige Entwicklung sind nach Ansicht der Mozilla-Präsidentin Datenschutz- und Sicherheitsüberlegungen der Anwender.

Weiter so, der IE hat immer noch zu viele Nutzer und Löcher.

Nach dem Start von APL2 sind werden sofort und automatisch zwei Shared Variables deklariert. Dies kann man mit dem APL2 SVP Monitor gut beobachten:

Entweder die apl2svpt.exe im APL2 bin-Verzeichnis ausführen oder - seit CSD 8 - den Monitor einfach durch Klick auf das "APL2 SVP Monitor"-Symbols in der Werkzeugleiste aktivieren. Dort findet man unter Info/Processors die mit APL2 gestarteten Partnerprogramme: den Session-Manager (AP120), den Interpreter (AP1), den Stacksprozessor (AP101) und die ID der Sitzung.

Schaut man sich die gemeinsamen Variablen zu diesen Prozessoren an, so sieht man, dass bereits zwei Variablen zwischen dem AP120 und dem AP1 deklariert wurden: AP120_SIGNAL und APL2. Öffnet man ein APL2-Objekt in den Object Editor, so gesellt sich als dritte Variable AP120_EDIT hinzu.

Über die Variable APL2 beschickt der Session Manager den APL2-Interpreter mit allen möglichen APL2-Anweisungen und Kontrollsignalen. Im Gegenzug erhält die Variable APL2 vom Interpreter das Ergebnis der Ausführung der Anweisung bzw. Informationen über aufgetretene Fehler.

Es geht aber auch ohne den Session Manager. Jedes beliebige selbst geschriebene Programm kann über das APL2 SVP Programming Interface die Variable APL2 ansprechen. Sobald der Interpreter als AP 1 ein Angebot für eine gemeinsame Variable namens APL2 erhält, wird dieses auch akzeptiert und der Interpreter erhält seine Anweisungen von jenem Programm.

So kann jeder, der der C-Programmierung mächtig ist seinen eigenen Session Manager schreiben. Ich kann mir aber kaum vorstellen, das dies irgend jemand ernsthaft tun würde.

Die Kommunikation mittels der Variablen APL2 mit dem Interpreter wird im User's Guide unter der Überschrift "Shared Variable Interpreter Interface" ab Seite 120 beschrieben. Das "SVP Programming Interface" ist dort wird ab Seite 604 dokumentiert.

Hier einige Presse Reaktionen auf das DB2 9 Announcement:

Die Computerwoche titelte am 8.6.2006 "IBM setzt im Kampf gegen Oracle auf XML". Langsam scheint die CW es gefressen zu haben, dass Oracle und Microsoft der XML-Integration in DB2 9 zur Zeit nichts entgegen zu setzen haben. Die berüchtigten "Kenner der Datenbankszene" kommen nicht mehr zu Wort.

Aber einen kleinen Seitenhieb konnte die CW sich doch nicht verkneifen. Da wird zuerst ein IBM-Oberer zitiert mit den Worten: "In Viper stecken alleine 68 Patente, und 750 Entwickler haben daran mehr als fünf Jahre lang gearbeitet." und "Niemand sonst hat so etwas, und die anderen werden Jahre brauchen, um das aufzuholen." Verschämt geklammerter Kommentar des Redakteurs: "(Ob das die Software AG wohl genauso sieht?)". Ich denke, Tamino wird von IBM nicht als der Wettbewerb angesehen. Die Stoßrichtung der zitierten Aussage geht eher in Richtung Oracle und Mickeysoft. Ich würde mir von der CW solche Nörgeleien auch mal zu deren Datenbank-Elaboraten wünschen.

Durchweg sachlich und informativ kommentierte heise am 9.6.2006 mit der Headline "IBM bringt neuen Datenbankserver".

Hat man beide Artikel gelesen, bringt zdnet Beitrag "IBM will mit XML-Funktionen Oracle-Kunden locken" eigentlich keine weiteren Informationen. Eine Unstimmigkeit mit der Computerwoche fällt hier auf:

"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: