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.