[Allegro] V34.8 ist da

Do Dez 11 11:35:52 CET 2014

... und zwar hier:  ftp://134.169.20.101/inst-all.exe

Verlautbarung 265 der Entw.Abt.                              2014-12-11
-------------------------------

V34.8 ist da - die "Nikolausversion"
------------------------------------

FLEX-Doku überarbeitet
----------------------
Jetzt steht überall "acon", wo "acon" gemeint ist und nicht"avanti".
Die Ursache lag in der Frühgeschichte von FLEX: Es war zuerst fest
eingebaut in ein Programm  avanti.exe. Das vereinigte in sich die
Funktionen eines Datenbankservers und eines TCP/IP-Kommunikations-
Programms. Der Webserver konnte diesem Programm direkt Jobs zusenden,
avanti führte die aus und gab die Resultate zurück an den Webserver.
Später wurde das dann getrennt: "avanti" wurde auf die Kommunikation
mit dem Webserver reduziert, ein neues "avanti-cl" (und daraus wurde
dann "acon") entstand als eigenständiges Programm, welches von "avanti"
für jeden Job gestartet wird und von ihm dann über die Standard-Eingabe
den Jobtext empfängt, um dann per Standard-Ausgabe (die sonst auf der
Konsole erscheint) die Resultate an avanti zu geben. Die Jobsprache
wurde in a99 übernommen, mußte aber dafür in mancher Weise modifiziert
und erweitert werden, vor allem um interaktive Funktionen, die in
acon als Konsolprogramm nicht vorkamen, weil es keine Oberfläche
mit Nutzerdialog hat. Das meiste davon passierte bis 1999, als a99
(daher der Name) herauskam und zu einer mächtigeren Alternative
zu PRESTO wurde. In der damals noch mageren FLEX-Doku stand aber schon
"avanti" an etlichen Stellen, und so blieb das dann stehen...
Siehe allegro-news 54 "ReFLEXionen über FLEXibilität":
   http://www.allegro-c.de/news/acn992/acn992.htm
Darin der Abschnitt "Was ist ein FLEX?"

Neuer FLEX-Befehl: check
------------------------
Mit "check" läßt man den Inhalt der iV daraufhin prüfen, ob er eine
gültige Kategorienummer hat. In der iV steht anschließend eine
Fehlermeldung, im Fall der Korrektheit der unveränderte Inhalt.
Wenn es eine Fehlermeldung ist, beginnt die iV mit zwei Leerzeichen,
d.h. der Fehlerzustand ist mit  if "  "  leicht abprüfbar.
Mit "check f" wird zusätzlich geprüft, ob der Inhalt nur die erlaubten
Unterfelder umfaßt, wie es die CFG vorschreibt. Auch hier gibt es
im Fehlerfall Meldungen, die mit "  " beginnen.
Achtung: Im Fehlerfall ist der iV-Inhalt zerstört! Man sorgt also
besser dafür, eine Kopie zusätzlich in einer Variablen vorzuhalten,
wenn man den Inhalt noch braucht.

Auch neu: var sk  liefert Umfang der Indexeinträge des Satzes
----------------
Eine weitere neue Kontrollmöglichkeit bietet jetzt  var sk.
Damit wird seit je die Liste der Indexeinträge des aktuellen Satzes
gebildet. Nun entsteht ganz oben eine zusätzliche Zeile mit zwei
Zahlen, z.B.
(69/1046)
Das bedeutet: Der Satz generiert 69 Einträge, und deren gesamte Länge
ist 1046 Bytes.
Mit  var (e")" f"(")  kann man die zwei Zahlen dann bequem extrahieren.
Schnell mal ausprobieren: Irgendeinen Satz nehmen und eingeben
x var sk\sho IV
Mit F7 kriegt man übrigens diese Zeile nicht - das würde nur Irritation
auslösen.

a99 FLEX: fetch  [a99 und acon]
---------------
fetch m : Lesezeiger in Datei positionieren
In a99 und acon kann man den Lesezeiger in einer geöffneten Datei
mit "fetch m" auf die Position setzen, die als Dezimalzahl in der iV
steht. Wenn man also schreibt:
var "100"
fetch m
get
dann wird der Zeiger auf die Position 100 gesetzt (Zählung beginnt
mit 0) und dann wird von da an gelesen bis zum nächsten Zeilenende,
das Ergebnis landet in der iV.
Statt der "100" wird man i.d.R. eine Variable $x setzen, in der man
sich vorher mittels  fetch p\ins $x  eine Position gemerkt hat, wo in
dem Moment der Zeiger stand und zu der man der ihn zurücksetzen will.
Schön und gut, aber in a99 klappte das nicht mehr. Es wurde repariert.

fetch b : Nächstes Byte aus der Datei lesen
Bisher kam mit fetch b1 kein korrektes Ergebnis, es mußte fetch b
lauten. Jetzt klappt auch fetch b1 und liefert den ASCII-Wert des
gelesenen Zeichens, also z.B.  32  für das Leerzeichen.

a99 FLEX: var q  [a99]
---------------
Mit  var q  bekommt man zwei Angaben  n/N, z.B.  10/13.
Dabei ist n die Nummer der aktuellen Erg.menge in der Reihenfolge der
momentan vorliegenden Erg.Mengen (mit Alt+e sieht man die Liste),
und N ist deren Gesamtzahl. Nr. 1 ist immer die Bookmark-Liste,
Nr. 2 die Liste der "Vorher angezeigten Daten".
Ds Problem war: Wenn mit  close res  die aktuelle Erg.Menge geschlossen
wurde (auf dem Balken erscheint dann: "Momentan keine Erg.Menge"),
änderte sich die Angabe n bei var q nicht, was zu einer Irritation
führen konnte. Dies wurde bereinigt, der Wert n geht dann auf 0.

getfile : a99 kann Dateien aktualisieren
----------------------------------------
Schon seit einer Weile konnte man z.B. mit
X getfile dnb.flx
sich eine aktualisierte Version des  dnb.flx  holen, d.h. diesen vom
Server der UB besorgen und in den eigenen FLEX-Ordner kopieren,
um den veralteten zu ersetzen.
Dieses Verfahren ist nun erweitert auf die sonstigen Dateien, die
evtl. auch mal aufgefrischt werden müssen. U.U. muß man schauen,
ob die Datei an den richtigen Ort gelangt. Es wird keine Datei in
das eigene DbDir geschrieben, sondern Parameter- und Konfig-Dateien
in das ProgDir, RTF- und .VW-Dateien in den HELP-Ordner.
Was aber ist mit Programmen? Nun, normalerweise wird man die besser
vom FTP-Server holen! Es kann aber vorkommen, daß mal ein Programm
per getfile bereitgestellt werden soll. EXE-Dateien oder auch ZIP
werden u.U. aber vom Sicherheitssystem beim Versuch eines Abrufs aus
dem Internet blockiert. Dafür wurde ein Verfahren gefunden, mit dem
dies gefahrlos umgangen wird:

ZAP : Transportsicherung für Dateien
------------------------------------
Eine Datei, die an einer Firewall scheitern könnte, z.B. asort.exe,
oder dieselbe verpackt in asort.zip, wird vor dem Bereitstellen mit
einem FLEX namens  zap.flx  umcodiert. Wir geben in a99 hier den
Befehl:   X zap asort.exe   bzw.  X zap asort.zip
Es entsteht dann eine Datei  asort.exe.zap  bzw.  asort.zip.zap,
die ein wenig größer ist. Diese besorgt man sich mit
X getfile asort.exe.zap  bzw.  X getfile asort.zip.zap
Die so besorgte Datei "entzappt" man mit:
X unzap asort.exe.zap  bzw.  X unzap asort.zip.zap
Die Originaldatei wird dann wiederhergestellt. In Falle .zip muß man
sie dann noch ganz normal entpacken.
Der FLEX  unzap.flx  ist mit im GP V34.8, der zap.flx wird zunächst
nicht mit ausgeliefert, um Verwirrung zu verhüten - er ist ja nur zur
Verwendung hier bei uns gedacht.

Gesamtexport
------------
Die gebotenen Optionen auf dem Menü für "Gesamtexport" wurden ein
wenig erweitert:  "Gesamtexport der Datenbank" anwählen auf dem
Quick-Menü (Alt+4), dann auf "mehreren Möglichkeiten" klicken.

update.job : "Befehl nicht korrekt geformt"
EXCEPTION-Error (memory-access) in program "acon.exe" !!
Drücken Sie eine beliebige Taste . . .
--------------------------------------------------------

Solche Fehlermeldungen konnten vorkommen, wenn man mit "update ..."
eine Grunddatei in eine Datenbank einspeisen wollte.

Das war ein seltener Folgefehler. Der eigentliche Grund war:
Es entstanden bei einem Satz mehr als 1000 Indexeinträge.
Der dafür vorgesehene Platz (32.000 Byte) reichte aus: die Schlüssel
bauchten nur 24k. Aber die Zahl 1000, die war der Grund: Es wird intern
eine Adressenliste der zum Satz gebildeten Schlüssel angelegt, und die
ist auf 1000 dimensioniert. Nachdem aber die 999 erreicht war und der
Schlüssel an die Liste angehängt, hat das Programm in die Adresse 1000
schon mal prophylaktisch eine 0 reingeschrieben. Weil aber die Zählung
mit 0 beginnt, ist die 1000 um 1 zu groß. Ob dann wirklich was passiert,
hängt davon ab, was im Speicher hinter diesem Adressenbereich liegt
und mit der 0 dann überschrieben wird. In diesem Fall ging's zumeist
wirklich schief. Die beobachteten Meldungen wiesen auf den eigentlichen
Tatbestand nicht hin, das ist aber in solchen Fällen ebenso typisch wie
tückisch.

Anhand von Beispieldaten war das Problem reproduzierbar. Es handelte
sich um sehr lange Datensätze aus der ZDB, umgewandelt ins A-Format
mit Anwendung der HFM-Technik für einige hochfrequente Felder.
Es stellte sich bei den konkreten Daten heraus, daß der Titel
"Bundesanzeiger" schuld war (ZDB 33414-5). Der will 1011 Schlüssel
generiert haben. Es entstehen korrekt nur 1000, aber die besagte
Adresse an der Position 1000 (also 1001), die wird eben überschrieben...
Auch a99 konnte Probleme mit solchen Datensätzen kriegen, z.B. waren
Abstürze nach F7 dabei nicht auszuschließen.

Die Reparatur war nach dieser Diagnose kein Problem.
Nebenbei wurde die Anzahl von Schlüsseln pro Satz in a99 und acon
hochgehebelt auf 1200. (Und die 1201 wird nicht zum Problem, d.h.
der Knackpunkt wird nicht einfach nur verschoben, sondern ist weg.)

Sowas zehrt und zerrt an den Nerven von Entwicklern und betroffenen
Anwendern gleichermaßen. Kenner zeitgenössischer Softwareparadigmen
fragen sich (oder sogar uns) dann, warum man nicht strikt
objektorientiert programmiere mit C++ oder, noch besser, alles in
Java um- oder neu schreibe. Das liegt vor allem daran, daß eine
ausgereifte und verfügbare Version von C++ erst 1998 erschien, und Java
wurde erstmals 1995 vorgestellt. Die allegro-Enwicklung in C++ begann
1985. Der Umfang der 1995/98 vorliegenden Codebasis war leider zu groß,
bzw. die Entwicklungsressourcen zu klein.
Außerdem werden zeitgenössische Entwickler schon noch ein System
hervorbringen, vor 2020, das den genannten Vorstellungen entspricht
und allegro in mehr als nur solcher Hinsicht hinter sich läßt. Für den
Publikumsbereich (Retrieval) liegt mit VuFind schon ein Exempel vor,
für andere Bereiche (Katalogisierung, Ausleihe, etc.) wohl noch nicht.

Fehlermeldung bei zu grosser Schluesselzahl
-------------------------------------------
Zwar gibt es keinen unkontrollierten Abbruch mehr bei zu großer oder
zu voluminöser Schlüsselmenge eines Satzes beim Updating, aber nun
wird auch noch eine Fehlermeldung generiert:
   mehr als 1200 Schl. ...
oder
   Schl. brauchen zuviel Platz ...
und dahinter jeweils die ersten zwei Felder des delinquenten Satzes,
womit man ihn in aller Regel identifizieren kann.

Außerdem gibt es eine neue Kontrollmöglichkeit zur Feststellung des
Umfangs der Schlüssel zu einem Satz; siehe oben unter "check".

ald-chk.flx : Verbessertes Werkzeug
-----------------------------------
Die Funktion "Adressen checken" auf dem Check-Menü wird erledigt
von dem FLEX  ald-chk.flx, der sich die .ald-Dateien einzeln oder
insgesamt vorknöpft und die darin steckenden Satzadressen vergleicht
mit den Einträgen in der .tbl. Er protokolliert auch die gelöschten
und die gesperrten Sätze.
Ferner ist jetzt probeweise der check-Befehl eingebaut (s.o.), der
die Datenfelder durchprüft, ob sie alle gemäß CFG zulässig sind.
Wenn nicht, wird eine Meldung ausgeworfen. So lassen sich auch
schadhafte Datensätze finden, in denen z.B. mittendrin in einem
Feld ein Code 0 steht oder eben hinter einem Code 0 eine falsche
Kategorienummer.
Dieses Werkzeug soll weiter verbessert werden. Außerdem gibt's
aber noch ein neues:

Zugabe: shrec.flx und shuft.flx
-------------------------------

Wer
-- neugierig ist und mal sehen will, wie ein Datensatz denn ganz
    genau, Byte für Byte, tatsächlich in der Datenbank gespeichert ist,
oder
-- darüber zwar Bescheid weiß, aber einen bestimmten Satz mal schnell
    inspizieren will, ob damit womöglich was faul ist, so z.B. ob ein
    unerwünschtes Steuerzeichen (Codes 1-10, 13, 26, 27) sich mittendrin
    verbirgt,

der kann sich seit je eines "Hex-Editors" bedienen, wie etwa WinVi,
mit dem man Datendateien laden und dann auf die hexadezimale Anzeige
umschalten kann. Nicht jeder hat aber ein solches Werkzeug parat
oder weiß es sachgerecht zu handhaben UND den Anblick dann korrekt
zu interpretieren. KEINESFALLS sollte man mit einem solchen Editor eine
Datenbankdatei wirklich editieren, also bearbeiten und dann wieder
speichern!!! Es sei denn, man ist sich 100% sicher, daß nichts
kaputtgehen wird.

Es wurde nun ein FLEX namens shrec.flx geschrieben ["show record"], der
einen Datensatz im Anzeigefeld in zwei Spalten anzeigt: Links als
lesbaren Text, rechts als Liste von hexadezimalen Codes.
Schnell mal ausprobieren? Einen Satz anzeigen lassen, dann F8 und
die letzte (neue) Funktion wählen: "HexaDez-Anzeige des aktuellen
Satzes". Dasselbe kriegt man mit Eingabe von  X shrec

Steuerzeichen erscheinen in verfremdeter Weise, weil ihnen keine
druckbare Gestalt entspricht. Man sieht dann links in grüner Farbe
ein druckbares Zeichen, z.B. @ für den Code 0, A für 1, J für 10,
M für 13 usw.
In der rechten Spalte dagegen werden die Hex-Zahlen dieser Zeichen
ebenfalls in grün angezeigt.
Unerlaubte Zeichen innerhalb von Datenfeldern (die o.g. Codes)
erscheinen rot.
Das Programm checkt ferner die Satznummer und das erste Byte, und
es zeigt die nächsten 48 byte, die auf den Satz folgen. So könnte man
evtl. Fehler entdecken, wie man sie früher manchmal sah: daß ein
Satz nach Verlängerung den Anfang des nächsten überschrieben hatte.

Die Frage wird kommen: "Nun ja, was nutzt das schon, wenn man da einen
Fehler findet, der sonst nicht sichtbar wird! Man sollte ihn dann
sofort korrigieren können!"
Einerseits ist es zwar denkbar, daß die angezeigte Hex-Liste nicht nur
editierbar wäre (das ist sie) sondern dann auch speicherbar! Doch
andererseits ginge das am Logging vorbei, und das wiederum könnte man
nicht wünschen. Es sei denn, man würde dann auch noch das Kopieren des
solchermaßen korrigierten Satzes in die log-Datei mit in den FLEX
einbauen. Vorstellbar ist auch das, zwingend müßte dazu aber auch
strikte Absicherungen gehören, um irreparable Schäden zu verhüten.

Und es wird gefordert werden: "Das Programm müßte nicht einzelne Sätze,
sondern ganze Datendateien durchforsten, und dann eine Liste derjenigen
auswerfen, die irgendwelche Fehler enthalten." Ja, das wär was.

Warum aber nur Datenbankdateien, nicht auch andere? Eine Fehlerdiagnose
für beliebige Dateistrukturen wäre unmöglich, aber das reine Anzeigen
der Inhalte ist nicht weiter schwer. Dazu wurde ein kleines Tool
namens "shuft.flx" geschrieben - "show unmodified file text". Es ist
aber keine Frage, daß man mit Fremdwerkzeugen wie WinVi erheblich
besser bedient ist, um Dateiinhalte auf Byte-Ebene zu studieren!
Und mit Programmierwerkzeugen wie Perl, um mit diesen Inhalten dann
irgendwas anzustellen, wie Diagnostik, Auswertungen, Änderungen aller
Art, etc. Wir können jedoch keine Fremdwerkzeuge im allegro-Gesamtpaket
mitliefern und auch nicht die zu deren Nutzung nötigen Kenntnisse.

Gibt man ein  X shuft
dann kommt zuerst eine Dateiauswahlbox, in der man sich jede beliebige
Datei an jedem Ort im Dateisystem aussuchen kann.
Sofort wird im Anzeigefeld der Anfang der Datei (die ersten 160
Bytes) erscheinen, angeordnet wie beim FLEX "shrec". Dies mag
gelegentlich nützlich sein, um sich die innere Struktur von Fremddaten
schnell mal eben anzuschauen.

import : Kleinere Verbesserung
------------------------------
Beim Vergleichsbefehl  R  (Kap. 11.2.3.5) gab es einen selten
auftretenden Fehlerfall. Er wurde beseitigt.