Die zweitschönste Nebensache der Welt

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.

Letztes Jahr kaufte Oracle Innobase Oy, den Hersteller der Transaktions-Engine InnoDB. Das wäre eigentlich nichts Besonders, denn Oracle kauft seit einiger Zeit alles, was nicht niet- und nagelfest ist.

Das Besondere hier ist, dass MySQL InnoDB als Transaktions-Engine verwendet. Das macht den Kauf natürlich explosiv - für MySQL. Offensichtlich atmet inzwischen MySQL auf und durch, denn Oracle stimmte einer Verlängerung des dieses Jahr auslaufenden Vertrages zwischen MySQL und Innobase zu.

"... good news for MySQL customers and for the open source community" meint MySQL Vice President Zack Urlocker in seinem Blog.

Aber kann man Oracle tatsächlich trauen?

Wer Larry Ellison schon einmal tief in seine blauen Augen schauen konnte, der weiß ...

Stand-alone Data Mining Software kommt aus der Mode. Data Mining hört auf eine exklusive Tätigkeit von Elfenbeinturm-Analytikern zu sein. Schade und gut so.

Alle drei großen Datenbank-Hersteller haben in ihren Warehouse-Paketen Mining-Anwendungen gebundlet: Oracle seinen "Data Miner", IBM den "DB2 Intelligent Miner for Modelling and Scoring". Microsoft bietet seinen Data Analyzer als Mining Werkzeug an.

Aber hier beginnt das Problem: MS lizenziert den Analyzer und das Visualisierung-Werkzeug pro Windows Client. Das bedeutet, dass je mehr Anwender Mininganalysen ausführen wollen, desto teuer wird es für das Unternehmen.

Mining a la Microsoft ist und bleibt so eine esoterische Nischentätigkeit betrieben von verschrobenen Einzelkämpfern.

Dieses Preismodell macht das Microsoft Data Warehouse Softwarepaket letztendlich teurer als die vergleichbaren Angebote von IBM und Oracle.

Hier noch zwei Ergebnisse, die ich dem "2006 Enterprise Data Warehouse Software Survey" von Market Magic Research (Januar 2006) entnehme:

In "Was gibt's Neues in CSD8" habe ich folgende Erweiterung vergessen:

- Windows XP themes will be recognized and used in all APL2 GUI windows.

Tatsächlich habe ich das nicht übersehen oder gar vergessen, nein, viel schlimmer, ich habe die Weitergabe dieser Info unterdrückt. Denn bis heute wusste ich nicht, was das konkret bedeutet und wie ich eine Änderung erfahrbar machen kann.

Jetzt habe ich den Unterschied sichtbar machen können:

Alles klar?

Windows XP Themes können in den "Eigenschaften von Anzeige" (Microsoft deutsch) aktiviert, geändert und gespeichert werden.

Mit dieser Erweiterung sehen APL2 GUI "besser" aus. Das liegt sicher daran, dass sie sich besser in das "look" meiner anderen Desktop-Anwendungen einfügen.

Eine absolut sinnvolle Erweiterung und Schande über mein Haupt, dass ich sie vorher nicht auch nur eines Wortes gewürdigt habe.

Oh, du mein elektronisches Tagebuch. Ich habe einen neuen Auftrag für dich. Fungiere als Merkzettel für interessante Erkenntnisse, die nicht in die anderen Kategorien passen.

Hier der erste Eintrag:

Port- und Linereset!

Ein Zauberwort für die Telekom. Veranlasst bei Selbiger Verwirrung, aber auch zielgerichtete Aktivität.

Und in welcher Situation hilft das Zauberwort? Bei "Internet tot" und Telekom betreibt den Zugang.

Vielen Dank für den Tip!

Vista? Wer oder was ist Vista?

Das könnte mir ja eigentlich egal sein. Wenn die nächste Version von Windows gemeint sein sollte, wird es ja wohl noch etwas dauern, bis MS damit meint fertig zu sein. Dann beginnt erst der weltweite kostenpflichtige Testphase durch die Early Adaptors. Armes Völkchen!

Selbst das danach erscheinende SP1 wird mich dazu verleiten nach Vista upzugraden. Warum auch? Ich habe mich noch nie von SPs überzeugen lassen.

Aber man sollte stets mit der ordnungsgemäßen Planung deutscher Unternehmen rechnen. Es gibt doch tatsächlich Unternehmen, die Vista nach Verfügbarkeit ausrollen wollen, und das muss geplant sein. Das wirft dann folgende Frage auf:

Welche APL+Win Version läuft unter Vista.

Eine Frage an den Hersteller, hier zusammengefasst und ohne Gewähr die Antwort:

- die aktuelle Version 6.0 wird sicher unter Vista laufen
- Version 5.2 wurde schon frühzeitig unter Longhorn getestet
- bei Version 5.0 könnte man noch optimistisch sein

Alle Versionen vor 5.0 liegen mehr als 3 Jahre zurück, also teilweise noch vor XP. So gab es z.B. Probleme ⎕wi in APL+Win 3.0 unter 2000 und XP.

Ordnungsgemäß planende deutsche Unternehmen sollten also sehr alte APL+Win Versionen upgraden.

Das Leben kann ja so einfach sein:

Das beste DBMS wird es auch frei geben.

Auch auf die Gefahr hin, dass ich das schon mal hier geschrieben habe: Gleichzeitig mit der Verfügbarkeit von DB2 Viper als DB2 Version 9 etwa Mitte des Jahres wird Boris sie als Express-C zur Verfügung stellen.

Die zugrunde liegende Technologie wird die gleiche sein, keine Abstriche bei Express-C, also auch voller XML-Support. Für Entwickler das Tor zu einer besseren Welt.

Als Zeuge für diese Aussagen nominiere ich Boris Bialek, der muss es schließlich wissen.

Ich bete das nun schon seit Tagen, das ist fast schon ein Ceterum Censeo:

Die XML-Unterstützung durch DB2 Viper ist anders und besser als das, was Oracle, MS und auch DB2 V8.x hier zu bieten haben.

Ich habe in einer IBM-Publikation eine andere, präzisere Formulierung gefunden:

Managing XML as data, instead of managing XML files/documents as content, is an opportunity for competitive advantage. In addition, DB2 Viper dramatically lowers business application development time, increases application performance and enables cost-effective use of XML data.

Gut gebrüllt, Löwe.

Denn das ist der Casus Knaxus: XML wird als Datentyp behandelt und nicht als irgendetwas Fremdartiges, dass als LOB weggespeichert wird oder gar geshreddert (zerrissen, zerschnitzelt, zerfetzt) wird. Das ist neu und einzigartig unter den großen Datenbankanbietern.

Don't cry, Oracle!

Die XML-Integration in DB2 Viper scheint Oracle tatsächlich ernsthafte Probleme zu bereiten. Bisher war die Speicherung von XML-Dokumenten in einer Datenbank nur als Large Object oder in geshredderter Form möglich. Das eine bringt Nachteile in der Arbeit mit oder Suche nach Teilen von XML-Dokumenten, das andere bedeutet die stete Umwandlung einer hierarchischen Darstellung in eine relationale. Beides ist umständlich, "unnatürlich" und geht eindeutig zu Lasten der Performance.

Das war alles bisher eher halbherzig. Das wäre auch egal, wenn XML nur irgendein weiteres Datenformat wäre. XML hat sich aber in den letzten Jahren zu dem Standard für den Austausch von Daten gemausert. In diesem Zusammenhang ist auch interessant, was Boris Bialek zu Viper, XML und SOA schreibt.

Verständlich, dass Oracle nervös wird.

Kein Entwickler, der was auf sich hält, wird sich nicht dafür interessieren, wie ein notwendiges Feature implementiert ist. "It does matter", wenn es schlecht unterstützt, umständlich zu nutzen und auch noch unperformant ist.

Eigentlich könnten man ja solche Aussagen kommentarlos dorthin verfrachten, wo sie hingehören: in den Müll. Aber leider wirkt Oracles Propaganda bereits auf "Kenner der Datenbankszene".

"Viper als Testversion verfügbar". So betitelte die Computerwoche in Ausgabe 15, 14.04.2006, auf Seite 8 einen kleinen Artikel, in dem die freie Verfügbarkeit der DB2 Viper für Beta-Tester angekündigt wurde. Kurz wird beschreiben, dass XML-Dokumente nativ verarbeitet werden können, sowohl mit SQL als auch mit XQuery.

Soweit so gut. Beim Lesen fallen so einige seltsame Formulierungen auf. Der Autor, Stefan Ueberhorst (ue) - immerhin Ressortleiter - , scheint nicht so recht zu wissen, was er schreibt. Offensichtlich ist er kein "Kenner der Datenbankszene". Muss er auch nicht. Also was macht er?

Richtig: Er holt sich Rat bei "Kennern der Datenbankszene". Und das sieht dann so aus:

"Kenner der Datenbankszene sehen das kritischer: Microsoft erlaube in SQL Server 2005 ebenfalls die Indizierung von XML-Dateien, und Oracle habe XML-Datentypen bereits in Version 9i R2 eingeführt."

Frei nach Karl Kraus: Diese Aussage ist so falsch, dass nicht einmal das Gegenteil wahr ist.

Ich meine hier nicht den kleinen grammatikalischen Fehler im Zitat, auch übersehe ich geflissentlich den Unsinn mit der Indizierung von XML-Dateien. Auch bei solch allerbesten Willen bleibt die obige Feststellung nicht nachvollziehbar.