APL2

... das war vor CSD 10 die Frage.

Die Erkennung und Markierung von URLs in Kommentaren hat wohl vielen APL2-Fans nicht so recht zugesagt. Ich kann das nachvollziehen. Es wurden Dinge als URL erkannt, die nie als solche gemeint waren.

In der Regel hätte mich das auch nicht weiter gestört, denn ich lasse einem Doppelpunkt stets eine Leerstelle folgen. Dies widerspricht der Definition einer URL.

CSD 10 bietet nun eine richtige Lösung: Die Markierung von Zeichenfolgen in Kommentaren als HTTP-Link gibt es nun als Option. Im APL2 Objekt-Editor kann unter "Options/System Options" mit "Underline URL" entschieden werden, ob aus dem Editor heraus direkt auf Web-Seiten zugegriffen werden kann.

Als Voreinstellung ist diese Option nicht aktiviert.

Dies ist für alle die beste Lösung: Ein sinnvolles Feature, das bei Bedarf eingeschaltet werden kann.

Das ist nicht die einzige Neuerung der CSD 10. Doch dazu später mehr ...

Gestern hatte ich den Eindruck, eine magische Hand hat eine APL2-Funktion auf meinem Rechner verändert. Wenn überhaupt habe ich diese Funktion seit fast 2 Jahren nicht mehr angefasst, trotzdem fällt sofort eine Änderung ins Auge:

Diese Zeile (deren Inhalt hier unerheblich ist), ein vorher ganz unschuldiger Kommentar, erscheint urplötzlich unterstrichen

⍝LBAR:→(0∊⍴SP←(E_VKDA[⍙VKDA_INH⍳⊂'TANR';]∊2288 2480)/⍳2⊃⍴E_VKDA)/LTHV

Ich war es nicht, aber wer war es dann?

Viele, viele APL2-Fans tragen dafür die Verantwortung. Allen voran Bernd, daneben auch die Teilnehmer einer GSE-Arbeitsgruppensitzung (wovon ich auch einer war) und schließlich David.

Als ich diese Veränderung an einer anderen Stelle von ca. zwei Jahren das erste Mal sah, erinnerte ich mich an ein damals aktuelles GSE-Requirement. Wir hielten Bernds Vorschlag für sinnvoll, in Kommentaren von APL-Funktionen URLs einbetten und verlinken zu können. Damit erhält der APL2-Nutzer die Möglichkeit, aus einer APL2-Funktion heraus sich eine Web-Seite in seinem Standardbrowser anzeigen zu lassen.

Offensichtlich fand auch David die Idee interessant und die Umsetzung nicht zu aufwändig. Mit der nächsten CSD war dieses Feature verfügbar.

Eine unterstrichene Kommentarzeile ist als kein Bug in der Darstellung einer Funktion, sondern ein Feature.

Von "Multi-row Fetch" oder "Multi-row Insert" hatte ich bisher nichts gehört, bis mich David fragte mich heute morgen danach fragte. Ein APL2-Fan wünscht sich wohl, dass der AP127 diese DB2-Features nutzt. Recht hat er.

Seit der Version 8 bietet die Programmierschnittstelle der DB2 für z/OS die Möglichkeit, mit nur einem Fetch auf mehr als nur eine Zeile des Resultsets zuzugreifen. Eine sehr sinnvolle Erweiterung, die mit der Version 8.2 dann auch für andere DB2-Plattformen zur Verfügung gestellt wurde. Es liegt wohl nur an der Beschränkheit der Mainstream-Programmiersprachen, dass obwohl ein SQL-Select eine Menge von Tabellenzeilen als Ergebnis ergibt, aber auf Elemente dieser Menge nur einzeln zugegriffen werden kann - Zeile nach Zeile per Schleife.

Für APL mit seiner hervorragenden Fähigkeit, komplette Datenstrukturen verarbeiten zu können, stellt diese Einschränkung eher einen ärgerlichen Logikbruch dar. Nur gut, dass mit dem AP127 per Parameter für den Fetch mehrere Ergebniszeilen mit einer Anweisung zum APL2 übertragen werden können.

Es war im Frühjahr 2005, vor etwas weniger als zwei Jahren. David arbeitete an der COM-Schnittstelle für APL2 und ich durfte sie hier und da testen. Parallel arbeitete ich an einem Vortrag für die kommende Tagung der GSE APL2-Arbeitsgruppe. Irgendwie schien es nahe liegend, in den Vortrag helfend die MS Agents einzubeziehen.

Die Idee war nicht neu: Im Mai 1999 hatte ich mir von Merlin und Konsorten einige Erklärungen zu dem damals neuen APL2-Runtime Feature (das es inzwischen so auch nicht mehr gibt) abnehmen lassen. Zur Programmierung der Agents bot sich damals VBA unter Powerpoint an, obwohl ich auch APL+Win hätte nehmen können - APL2 dagegen nicht.

Ich versuchte vor zwei Jahren also, die Szenarien, die ich 1999 in VBA entwickelt hatte, mit APL2 und der neuen COM-Funktion nachzubauen. Das klappte erwartungsgemäß auch ohne prinzipielle Probleme. Nur zwei Dinge konnte ich nicht wie gewünscht umsetzten:

"Bookmarks" waren nicht umsetzbar, "Housekeeping" erst nach Ende einer Szene nur händisch oder durch Setzen von ⎕DL. Der Grund für beides war die damals fehlende Unterstützung für COM-Events.

Und die gibt es inzwischen - seit Service Level 7 - und damit konnte ich mir nun beide Wünsche erfüllen.

Wie gesehen kann der AP127 noch nicht mit dem XML-Datentyp umgehen, er kennt ihn schlicht und ergreifend nicht.

Das bedeutet aber nicht, dass jedes SQL-Statement, in dem XML-Daten angefasst werden, zwangsläufig zu einem AP127-Fehler führt. Solange das Ergebnis einer Query keine Daten vom Typ XML (988) enthält, ist alles gut.

Hierzu ein Beispiel mit der Tabelle XMLCUSTOMER:

select c.cid from xmlcustomer c where xmlexists(''$i/customerinfo[name = "Kathy Smith"]' passing c.info as "i")

XMLEXISTS ist ein neues Prädikat. Es prüft, ob ein XQuery-Ausdruck ein nicht-leeres Ergebnis bringt. Im Ergebnis der Query selbst tauchen dagegen nur die Integer-Werte der Spalte CID auf.

Auch diese Query verleitet den AP127 nicht zu einer Fehlermeldung:

select X.* FROM XMLCUSTOMER C, XMLTable(''$cu/customerinfo'' PASSING C.INFO as "cu" COLUMNS "NAME" CHAR(20) PATH ''name'', "STREET" CHAR(20) PATH ''addr/street'', "CITY" CHAR(20) PATH ''addr/city'') AS X

Denn die Tabelle X enthält nur dem AP127 bekannte Datentypen. Dass in der Query irgendwo XML-Dokumente verarbeitet werden, bekommt er nicht mit. Gut so!

Nichtdestotrotz wäre es mehr als sinnvoll, den AP127 mit dem Datentyp 988 vertraut zu machen.

Eines der herausragenden neuen Features der neuen DB2-Version ist der XML-Datentyp und die daraus resultierende Möglichkeit, komfortabel mit XML-Dokumenten in DB2 zu arbeiten.

Nun besitzt APL2 mit dem AP127 eine direkte Schnittstelle zu DB2, ohne Umwege über Interfaces wie ODBC. Nachdem ich auch auf diesem Rechner DB2 9 installiert habe, hat es mich geradezu in den Fingern gejuckt, mal auf XML-Daten von APL2 aus zuzugreifen.

Das Ergebnis zeigt, dass noch Einiges zu tun ist. Dazu ein erstes Beispiel:

Ich nehme die Tabelle XMLCUSTOMER aus der DB2 Sample-Datenbank. Sie hat zwei Spalten, CID und INFO. CID ist vom Typ Integer, INFO vom Typ XML.

Ein einfaches 'Select * from XMLCUSTOMER' mittels AP127 ergibt einen AP2X127105 "SQL DATATYPE 989 (COLUMN INFO) NOT SUPPORTED BY AP 127". Das ist nicht wirklich überraschend.

Der neue Datentyp muss also dem AP127 noch vorgestellt werden.

Das habe ich nun davon, dass ich mich nicht an eine sinnvolle Empfehlung zur Benutzung von Windows gehalten habe. Hätte ich mich aber daran gehalten, wäre ich nicht auf dieses seltsame Verhalten von DB2 gestoßen.

Meinen vorherigen Rechner "Number9" habe ich ausschließlich den User "Administrator" benutzt. Dies habe ich inzwischen für meinen aktuellen Rechner geändert. Auf unseren Linux-Systemen arbeite ich schließlich auch nicht standardmäßig als "root". Number9 hat natürlich auch ein DB2, seit Kurzem sogar in zwei unterschiedlichen Versionen. Da ich mich normalerweise unter meiner Windows UserID auch bei DB2 anmelde, habe ich mich wohl nie explizit mit UserID und Passwort mit einer Datenbank verbunden ("connect to ...") - weder über das DB2-Befehlsfenster, noch über den AP127 mit APL2. Ich bin nun mal schreibfaul.

Nun geschah es aber letzte Woche, dass DB2 von mir UserID und Passwort haben wollte (da ich mich mit dem zweiten DB2-Exemplar als entfernte Instanz verbinden wollte). Der

connect to apl2lib9 user Administrator

im Befehlszeilenprozessor funktionierte klaglos. Aber der Connect über AP127 zickte: Nach

CTL127←'CONNECT' 'APL2LIB9' 'Administrator' PASSW

beschwert sich AP127 mit einem(1 0 0 1 162): "THE USERID ARGUMENT TO CONNECT MUST BE A CHARACTER VECTOR OF LENGTH 1 TO 8".

Das Highlight des letzten APL2 Release (CSD 8) ist definitiv der APL2 Library Manager. Wieder ein Tool, das dem APL2 Workaholic viel Zeit spart. Es spricht für die sachliche Bescheidenheit der Entwickler, dass sie diese Erweiterung nur kurz und knapp aus einer rein technischen Perspektive beschreiben. Wer es lieber deutsch mag, schlage bei DPC nach.

Seitdem hat mir der APL2LM schon oft das APL2-Leben erleichtert.

Ich habe tatsächlich verschiedene Versionen eine Workspaces vergleichen. Das ist an und für sich nichts Neues. Es gab ja schon vor dem APL2LM den 1 WSCOMP. Mit dem APL2LM muss ich dazu nicht extra eine Workspace laden.

Und hier liegt der eigentliche Gewinn, den ich durch den Library Manager habe. Wenn ich mal schnell in einem Workspace etwas nachschauen will, brauche ich diesen nicht mehr zu laden. Dazu stelle man sich folgendes vor:

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.

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.

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.

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:

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