Die zweitschönste Nebensache der Welt

Montag, kurz vor Mitternacht, habe ich eine meiner Regeln verletzt und wäre auch fast bestraft worden. "Don't change a running system" vor einer Präsentation. Aber meine Neugierde überwog, und ich installierte kurzerhand die CSD8. Um sicher zu gehen, testete ich nochmals die Anwendung, über die ich am Dienstag reden wollte. Siegessicher starte ich sie, machte die nötigen Eingaben und ... nichts passierte. Das war nicht ok, irgendwas war falsch.

Kurzum: der Grund war ein SQL0818N "Ein Zeitmarkenkonflikt ist aufgetreten". Warum, weshalb? Dienstags um 0 Uhr hatte ich keine Ahnung. Offensichlich eine Verstimmung zwischen APL2 und DB2, denn der Zugriff auf die betroffene DB2-Tabelle funktionierte klaglos im DB2-Befehlszeilenprozessor.

Trotz allen Mutes, bin ich doch immer noch einigermaßen vorsichtig. Ich hatte als Netz und doppelten Boden die CSD7 noch auf der Platte. Das bin-Verzeichnis zurück kopiert, und alles war wieder gut.

Die Lösung des Rätsels gab's am kommenden morgen. Nancy, die Entwicklerin des AP127 ("eine 27-jährige entwickelte diesen AP") hatte dieses Problem schon am Freitag gesehen. Sie schlug gleich zwei Lösungen vor:

1. den AP127 neu binden
2. den AP127 der CSD7 in das aktuelle bin-Verzeichnis zurück kopieren.

Nächstes Jahr jährt sich zum fünfundzwanzigsten mal meine erste Berührung mit APL, dieser fantastischen Sprache. Nachdem ich mich die Jahre vorher mit Cobol, Assembler, Fortran und ähnlichen unangenehmen Dingen auf Computern herumgeschlagen habe, war dieser Erstkontakt der Beginn einer wunderschönen Beziehung mit der Spezies Computer.

Naja, Scherz beiseite. In 25 Jahren sammelt sich so einiges an Arbeitsbereichen, Funktionen, Operatoren und Variablen. Da verliert man schon mal den Überblick.

Wie oft habe ich Workspaces nach einer Funktion durchsucht, von der ich wusste, dass sie existiert, aber ich nicht wusste, wo. Auch kam es vor, dass ich mir absolut sicher war, vor einiger Zeit einen Workspace erstellt zu haben, aber ich wusste nicht mehr, in welchem Verzeichnis ich ihn abgelegt hatte

Über die Jahre haben sich auf meinem Rechner viele Verzeichnisse mit APL-Arbeitsbereichen angesammelt - Ordnung muss sein - und noch mehr Arbeitsbereiche und noch viel mehr Funktionen und Operatoren.

Es kann schon sehr lästig sein und viel Zeit kosten, eine Funktionen in ihrer aktuellsten Version in mehreren Workspaces in verschiedenen Verzeichnissen suchen zu müssen: Workspace laden, Funktion suchen, öffnen, inspizieren, Fix-Zeitpunkt merken, nächsten Workspace laden, Funktion suchen, ...

Gemäß den Datumsangaben in meinen Java-Klassen oder den APL2-Funktionen, die auf diese Klassen zugreifen, ist es nun zwei Jahre her ist, dass ich mich mit Java beschäftigt habe. Nicht, weil ich Java so toll finde, sondern um die Schnittstelle vom und zum APL2 zu nutzen. Das hat auch einiges Beständiges gebracht, Funktionen, die ich seitdem regelmäßig genutzt habe.

Java Klassen entwickelt habe ich seitdem nicht mehr. Damit ich es in zwei Jahren leichter habe, wenn ich mich evtl. wieder nach längerer Pause in Java einarbeiten muss, nutze ich diesen Blog als Merkzettel.

Die Installation und Anbindung ans APL2 hat ja reibungslos funktioniert.

Aber, was war das bloß, dass APL2Env_ nicht wie erwartet wollte? Das APL2 Hostwin meinte irgendwelche Klassen zu vermissen. Das kam alles bedeuten. Ich war sicher zu ungeduldig und habe wahrscheinlich was übersehen. Denn ...

Heute morgen habe ich eclipse installiert, einige Klassen von links nach rechts verschoben, "classpath" angepasst und - Überraschung! - APL2Env_ und Genossen zicken nicht mehr.

Hier noch drei weitere Merkposten:

Nachdem nun klar ist, dass APL2PIA kein "multi-threaded" APL2 ermöglicht, musste ich auch auf meinem neuen Rechner Java installieren, um meine Tools wie auf dem alten Rechner benutzen zu können.

Java installieren und einige Einstellungen vornehmen, testen und ok. Das war alles ganz einfach und ebenso "straight forward". Schließlich habe ich das gerade zum vierten oder fünften mal gemacht. Es lebe die Routine!

Und so geht's (s.a. APL2 User's Guide, S.168):

Java von java.sum.com downloaden. Da ich auch Java Klassen erstellen möchte, wähle ich das SDK, zur Zeit JDK 5.0 Update 6. Ansonsten reicht das Java Runtime Environemnt. Installieren ... und gut bis hier.

Möglicherweise ist Java, in welcher Variante auch immer, bereits installiert. In der Windows Eingabeaufforderung kann man dies mittels "java -version" herausfinden.

Damit ich unter APL2 auf die die Beispielklassen zugreifen und mittels Prozessor 14 ausführen kann, muss ich noch zwei Einstellungen vornehmen.

Am Montag, den 17. April 2006, schrieb ich unter "Warum nur, warum ...":

"... mag David den P12 nicht?"

Diese implizite Annahme entbehrt jeder Grundlage.

Weiter unten verstieg ich mich in der Frage:

"Warum also mag David den AP210 so sehr?"

Auch diese inhärente Behauptung entspicht nicht der Wahrheit.

Wahr ist, dass David den P12 hoch schätzt und ihn dem Hilfsprozessor 210 sogar vorzieht.

Die Redaktion entschuldigt sich an dieser Stelle in voraus eilendem Gehorsam für diesen rhetorischen Ausrutscher.

... mag David den P12 nicht? Warum zieht er den anspruchsvollen AP210 einem einfachen "File as Variable" vor?

Wenn ich schon vor einigen Jahren für den P12 die Sicht auf Dateien als Byte-Stream gewünscht habe und dies dann von Nancy auch so vorgesehen wurde, sollte ich dieses Feature zumindest promoten.

Mit dem P12 assoziiert man eine Datei mit einem Variablennamen. Danach kann man auf die Datei fast genauso zugreifen wie auf APL-Variable. Bei der Assoziierung muss man noch eine Struktur für die Variable definieren. Dies kann für flache Dateien eine Vektor von Zeichenvektoren oder Zeichenmatrizen sein.

Das waren die Formate, die für Flatfiles von Anfang an vorgesehen waren. Neu dazugekommen, und das auch nur für die Workstation-Plattformen, sind später Dateien als " Simple Character Vector" - Byte Streams:

"Each byte in the file is a single element in the character vector. Control characters, including line delimiters, are not handled in any special way. They are regular elements of the character vector." (APL2 User's Guide, S.165)

Und so geht's:

Mit Service Level 8 wird es ohne Umwege über Java, C-Programmierung oder VB möglich sein, aus einem APL2-Interpreter heraus weiter Interpreter zu starten und zu nutzen. David nennt Letztere "Slave Interpreter".

Ich bin mir noch nicht vollkommen schlüssig, wozu das gut sein soll.

Eine Anwendung wäre "Namescope Isolation", Eingriffe in andere Workspaces ohne mögliche Namenskonflikte befürchten zu müssen. Dazu habe ich bisher Namespaces genutzt, und dazu wurden Namespaces auch erfunden.

Eine weitere Anwendung wäre "Multi-Threading". Dies scheint zumindest mit der vorgesehenen externen Funktion nicht ohne Weiteres zu funktionieren. Vielleicht ist dies irgendwann mal Anlass für ein Requirement.

Das Starten eines Slave Interpreters mit APL2PIA erzeugt keinen neuen Prozess und nicht mal einen eigenen Thread im aufrufenden APL2-Prozess. Es bleibt bei den beiden Threads, die APL2 für sich wofür auch immer anlegt. Nur etwas mehr Speicher für den Prozess des "Master Interpreters" wird allokiert, wenn dieser einen Slave Interpreter startet.

Auf jeden Fall ist (nicht nur) in diesem Zusammenhang die von mir vor Jahren gewünschte und inzwischen verfügbarer externe COPY-Funktion offensichtlich sehr nützlich.

Ich dachte schon, ich könne Java loswerden, um das eine oder andere meiner APL2-Tools im Hintergrund laufen zu lassen.

Dieses kleine Helferlein gibt mir einen Überblick über die Umgebung meiner aktuellen APL2-Sitzung. Damit ich es von meiner Sitzung aus starten kann und es nicht sofort wieder beenden muss, um die Session für Eingaben wieder entsperrt zu bekommen, wird es über Java in einem eigenen Thread aufgerufen. Java wird also nur benötigt, um vom APL2 aus eine weitere APL2-Sitzung in einem eigenen Thread starten.

Nun wird es mit dem neuen Service Level eine externe Funktion geben, mit der aus einer APL2-Sitzung ein weiterer APL2-Interpreter gestartet werden kann. Dort können dann beliebige APL2-Anweisungen ausgeführt werden. Kling doch so, als könnte ich mit diesem neuen Feature den Umweg über Java loswerden.

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.