Die zweitschönste Nebensache der Welt

Ich hätte ihn fast vergessen: den APL2 Keyboard Handler.

Ich kann mich noch erinnern wie David ihn auf einer GSE Tagung vorstellte. Ich glaube, das war in Augsburg. Enger Tagungsraum, ich kam zu spät und war unkonzentriert. In der Folge habe ich den Keyboard Handler einige male gestartet, konnte aber so recht nichts damit anfangen.

Der APL2 User's Guide widmet dem Handler einen kompletten Abschnitt (Seite 36f):

"The APL2 keyboard handler can also enable you to type APL characters in other applications. To enable APL input in other applications, either open the APL2 Keyboard Handler icon in the IBM APL2 folder or run the APL2KEY.EXE program. Then, select an APL font in the application in which you want to type APL characters."

Das funktioniert auf jeden Fall mit Excel und mit Word, aber leider nicht mit Powerpoint. Auch mein Mail-Client zickt mehr oder weniger. Dafür macht Notepad keine Probleme.

Das ist so nicht ganz korrekt. Es sollte heißen: Alles oder Ein. Ich weiß, Das ist kein Deutsch!

"Alles" meint Folgendes: Natürlich habe ich alle vorhandenen Lösungsfunktionen in einer Funktion verpackt, so dass ich mit einem Funktionsaufruf ein Sudoku lösen kann - soweit ich mit den implementierten Methoden komme:

RESULT SOLVE sudoku

SOLVE führt solange iterativ FILL, SCAN, ELIM u.a. aus, bis die Lösungsmatrix sich nicht mehr verändert. Ergänze ich SOLVE noch um ein Trial-and-Error, so löst SOLVE jedes Sudoku. Das zeigt mir dann aber nur, ob ein vorgegebenes Problem überhaupt lösbar ist, also ein gültiges Sudoku. Das interessiert mich aber nicht wirklich, dazu reicht schon eine Trial-and-Error Funktion.

So zeigt SOLVE wie weit ich mit den eingebauten Methoden komme. Mit eingeschalteter Erklärungsfunktion wird mir sogar Schritt für Schritt erläutert, wie sich der Lösung genähert wird.

Apropos "Schritt für Schritt" oder "Ein":

... ein Sudoku lösen: Ohne Versuch und Irrtum, nur durch logisches Kombinieren oder Ausschließen von Lösungen. So gehen menschliche Sudoku-Löser an die Sache, solange bis es mit diesen Methoden nicht weitergeht.

Nachdem ich meine Darstellung eines Sudokus bzw. seiner möglichen Lösungen im APL festgelegt hatte, habe ich verschiedene "logische" Lösungsmethoden implementiert. Nicht alle, aber die einfachsten und wichtigsten, da mit ihnen alle leichten, mittel- und die meisten schweren Sudokus lösbar sind. Die dazugehörigen Funktionen heißen FILL, SCAN, ELIM, ELIMB und PAIR.

Jede dieser Funktionen wendet eine spezifische Methode nacheinander entlang der Zeilen, der Spalten und Blöcke an. Dafür ist jeweils nur eine Implementierung nötig. Denn die Anwendung einer Methode auf die Zeilen eines Sudokus ist das gleiche wie die Anwendung der Methode auf die Spalten des zugehörigen transponierten Sudokus. Das gleiche gilt für Zeilen und Blöcke (wegen Transitivität dann auch für Spalten und Blöcke) .

Dafür war die Darstellung einer Sudoku-Lösung als logische Matrix vom Rang 5 gedacht.

So gefällt er mir ...

... mein Sudoku-Löser. Der, den ich nie schreiben wollte.

Es ist auch ok, wenn er - Stand heute - nicht alle Sudokus lösen kann. Leichte, mittelschwere und schwere scheinen kein Problem zu sein. Bei sehr schweren erhalte ich schon mal nur einen Zwischenstand.

Aber mein Sudoku-Löser soll mir beim Lösen von Sudokus helfen. Und das tut er auch: Wenn ich nicht weiterkomme, kann ich mir Tipps für eine weiterbringende Methode holen.

Aber nicht nur das: Mein Sudoku-Löser kann mir auch "erklären" was er Zug um Zug getan hat.

Es fehlen nun noch einige weitere "logische" Eliminierungsmethoden und die finale Lösungsmethode - Trial and Error. Letztere ist auch die, die der menschliche Löser anwenden muss, wenn er mit den "logischen" Methoden nicht mehr weiterkommt.

Gerüchte, alles Gerüchte.

Schon vor Jahren hörte ich, dass IBM Cognos kaufen will. Soll heißen, dass Cognos gerne von IBM gekauft würde.

Daraus ist bisher nichts geworden. Vielleicht demnächst in diesem Kino ...

Publik wurde vor einem Jahr, dass Microsoft SAP kaufen wollte. Hat nicht funktioniert. Gut so. Aber die Drohung besteht weiterhin. Dazu passt folgendes Gerücht, das Christiane mir gestern erzählte:

IBM will SAP kaufen. Das passt schon besser in meine "politische" Landschaft. Das ist gut für alle SAP Kunden mit einer Oracle-Datenbank. Die würden dann eine vernünftige Datenbank geradezu automatisch erhalten. Ferdinand for SAP President!

Ganz nebenher: SAP wäre ja auch mit dem Klammerbeutel gepudert, wenn sie nicht versuchen würden, ihre Kunden von den Oracle-Datenbanken weg zu bewegen.

Jetzt wird es lustig:

FJH hat Pylon gekauft (das ist noch nicht wirklich lustig), nur, damit FJH attraktiv für SAP ist. FJH, heißt es, würde gerne bei SAP unterkriechen. Bei SAPs desaströsen Erfahrungen im Versicherungsgeschäft keine schlechte Idee.

Mal sehen, was als nächstes passiert.

Ich bin ja kein Oracle-Experte. Ich habe nicht mal eine Oracle-Datenbank auf meinem Rechner installiert. Ich möchte dies diesem armen, unschuldigem Ding auch nicht zumuten.

Daher muss ich mich auf anderer Leute Erfahrungen verlassen. Auf Leute also, die es wissen müssen, da sie mit beiden Datenbanken - Oracle und DB2 - arbeiten.

Gestern traf ich so jemanden: Thomas Ruf. Ein alter Profi mit reichlich praktischer Erfahrung mit beiden Datenbanken.

Und der sagte, dass eine Anwendung, die er betreute, mit DB2 wesentlich besser performte als mit einer Oracle-Datenbank - um 80%. Eigentlich kaum zu glauben. So etwas sagt man nicht vor Publikum, wenn da überhaupt nichts dran ist.

Ludger hat schon vor ungefähr 10 Jahren ähnliche Erfahrungen gemacht, vielleicht nicht gerade in der Größenordnung von 80%.

Mast- und Schotenbruch für alle Oracle-Looser, äh, -User!

Ich habe mein Bestes getan, um Alan davon zu überzeugen, seine MySQL-Datenbank nach DB2 Express-C zu migrieren. Das hat auch fast geklappt, bis er fragte, ob DB2 Indizes auf BLOBs legen kann. Natürlich geht das nicht! Aber macht das überhaupt Sinn?

Hat Alan hier möglicherweise etwas falsch verstanden? Meinte er vielleicht, dass MySQL die Möglichkeit bietet in LOBs zu suchen?

Also mal sehen, was MySQL dazu sagt ...

Dabei stoße ich auf einen Link zu einem Migration Tool Kit. Das ist spannend! Für DB2 gibt es das ja auch.

Nur MySQL und DB2 scheinen sich geflissentlich zu ignorieren: Beide bieten Migrationshilfen vom MS-SQL Server oder von Oracle an, aber nicht von DB2 (oder Informix) bzw. MySQL.

Zumindest ist dies jeweils nicht dokumentiert. Denn mit Hilfe des DB2 Migration Toolkits wurde bereits testweise mindestens eine MySQL-Datenbank nach DB2 portiert. Das geht also, ist aber nur nicht dokumentiert.

Alans Frage beantwortet das alles nicht.

Ja, ich weiß: Ich treibe mit dieser Operation mehr als doppelt soviel Aufwand wie nötig.

Denn es ist S[i;;]=S[j;;] genau dann,wenn S[j;;]=S[i;;]. Und die Information, dass jede Spalte mit sich selbst identisch ist, ist auch nichts Neues. Die gewünschte Information steht also bereits oberhalb der Diagonalen der 9x9-Ergebnismatrix. Ist UTM0 die obere 9x9-Dreiecksmatrix ohne Diagolale, also

0 1 1 1 . . . 1
0 0 1 1 . . . 1
0 0 0 1 . . . 1
....
0 0 0 0 0 0 1
0 0 0 0 0 0 0

so enthält

UTM0^^⌿¨(⊂[2 3]S)∘.=(⊂[2 3]S)

bereits die gewünschten Informationen. Also mehr als 50% Luftoperationen!

Also warum die Vergleiche nicht nur für Indexpaare i,j mit i<j durchführen?

APL2 kann ja so schnell sein. Das liegt auch daran, dass die Rechner inzwischen immer leistungsfähiger geworden sind. Wenn ich Folgendes Anfang der 80er - als ich meine ersten APL-Schritte unternahm - auch nur ansatzweise einer 5120 zugemutet hätte, hätte selbige mir die APL-Funktion um die Ohren geschlagen.

Ich habe 9 9x9-Matrizen mit booleschen Werten, organisiert als 9x9x9-Array. Die Aufgabe lässt sich so formulieren:

Finde die Spalten in jeder der 9x9-Matrizen, die mit der entsprechenden Spalte einer anderen Matrix identisch ist. Für zwei Matrizen A und B ist das genau

^/[1]A=B   (oder ^⌿A=B)

Dies soll paarweise mit den Ebenen der 9x9x9-Matrix S geschehen:

^/[1]S[i;;]=S[j;;]

Diese Kategorie war in letzter Zeit so frei von den tieferen Wahrheiten unseres Universums. Es ging nur noch um böse Orakel. Ich wende mich nun wieder mit Freuden den schönen Dingen des Lebens zu: APL2 und die Viper. Dies habe ich u.a. auch Nancy geschrieben (allerdings in Englisch):

IBM wird eine neue DB2-Version ankündigen, die auf der DB2-Weiterentwicklung unter dem Namen Viper basiert. Ich bin sicher, dass besonders die Erweiterungen zu XML für AP127-Nutzer von großem Interesse sind. Es handelt sich hierbei um die Möglichkeit auf gespeicherte XML-Dokumente mittels XQUERY zuzugreifen.

Wird Nancy Gefallen an XQUERY finden? Und überhaupt: Habe ich recht in der Annahme, dass eine Erweiterung des AP127 um die XQUERY Syntax außer mir irgendeinen APL2-Nutzer interessiert?

Und dann noch mein Cetero Censeo: Ich denke, die DB2 Express-C könnte wirklich interessant für APL2-Entwickler sein. Ja sicher, aber was soll Nancy damit?

Das ging schnell!

Ich hatte gerade einen Link zu meinem Blog-Eintrag mit dem schönen Oracle-Mastbruch-Gif (Vielen Dank, Dirk) verschickt, und prompt wurde er weiterverraten:

"... ein interessamter Blog Eintrag eines true blue BP´s"

Damit musste ich natürlich rechnen. Also für alle, die es wissen oder auch nicht wissen wollen:

Dies ist mein großer grauer Notizzettel, da kommt alles rein, was ich mir merken will, und was in meinen Kopf nicht mehr reinpasst. Da ich offensichtlich kein DB2-Spezialist bin, kommen hier also auch simple Anmerkungen rein.

Dirk hat mich damit auch enttarnt:

Ja, ich gestehe, ich bin sehr einseitig, was Datenbanken angeht. Ich mag aus mehr als einem Grunde Oracle nicht (wie überraschend!), und präferiere definitiv DB2, aber auch Informix. Nicht nur, weil dies die weltbesten Datenbanken mit ihren spezifischen Stärken sind. Einen weiteren Grund verrate ich hier nicht.

Die IDS muss man alleine schon deshalb mögen, weil von dort all die schönen Fußball-Statistiken kommen.

Und wohin?



Wir haben ja gelernt, dass Oracle-Software - und dazu gehört nun mal auch die Datenbank - ein Sicherheitsrisiko darstellt. Also weg mit diesem DBMS.

Aber nicht mit den Daten! Diese können z.B. nach DB2 übernommen werden. Dazu gibt es das DB2 Migration Toolkit.

Als Quell-DBMS für das Toolkit kommen außer Oracle auch andere Plattformen in Frage. Auch MySQL!

Im DB2 Befehlsfenster kann man sich ganz einfach die Struktur einer Datenbank als Sequenz von DDL-Statements erstellen:

db2look -d [Datenbankname] -e -l -x -c

Was die einzelnen Parameter bedeuten, schaue man sich mit db2look ? an.

Abgespeichert in einer Datei können diese Anweisungen wie gewohnt mit

db2 -tf [Dateiname]

ausgeführt werden. Vorher können natürlich einzelne Statements in der Datei geändert werden, z.B. kann als erstes mit einer anderen Datenbank verbunden werden.

Disclaimer: Folgendes gilt offensichtlich nur für DB2. Ähnlichkeiten mit Befehlen anderer DBMS sind wahrscheinlich rein zufällig.

Für diese triviale Frage hatte ich keine triviale Antwort parat:

Wie kann ich eine Datenbank (samt Inhalt) von einem System auf ein anderes transportieren? Auf dem Zielsystem ist noch keine Datenbank bzw. Struktur zur Aufnahme der Quelldatenbank angelegt.

Unter DB2 gibt es einen Befehl der diese Aufgabe fast komplett erledigt.

Da war ich doch der Meinung, dass Oracle nirgends die Nummer 1 ist: Nicht bei Datenbanken, nicht bei ERP-Software, auch nicht beim Segeln. Das war ein Irrtum:

Oracle ist auf dem besten Wege dieses Jahr Microsoft, den bisher ungeschlagenen Champ, in seiner Domäne zu schlagen. Nein, nicht beim Abzocken mit Betriebssystemen oder Office-Software. Es sieht so aus, dass Oracle-Produkte mehr Sicherheitsprobleme erzeugen als die Software des üblichen Verdächtigen auf diesem Spielfeld.

"Oracle hat ein Sicherheitsproblem" titelte die Computerwoche in ihrer Ausgabe von 06.03.2006.