[Allegro] Vb.265 Vorabdruck

Bernhard Eversberg ev at biblio.tu-bs.de
Mi Nov 19 13:17:50 CET 2014



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

V34.8 ist da
------------

... zunächst nur eine Vorab-Version  V34.7.9  zum Testen:

    ftp://134.169.20.101/inst-test.exe

Das Testen wird dringend empfohlen! Gemeldeten Problemen werden wir mit
allem Nachdruck nachgehen, aber nur bis zur Festschreibung in etwa
zwei Wochen. Dann ist erstmal Feierabend.


FLEX-Doku überarbeitet
----------------------
Jetzt steht überall "acon", wo "acon" gemeint ist und nicht"avanti".
Die Ursache liegt 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
und danach die Resultate entgegennehmen. 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 "avanti" für jeden
Job startet und ihm dann über seine Standard-Eingabe den Jobtext
übergibt, um dann von der Standard-Ausgabe (die sonst auf der Kon-
sole erscheint) die Resultate herauszulesen. 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 kleinen FLEX-Doku stand aber schon
"avanti" an etlichen Stellen, und so wurde das dann beibehalten...
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 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.


Auch neu: var sk  liefert Umfang der Indexeinträge des Satzes
----------------
Eine weitere neue Kontrollmöglichkeit bietet jetzt  var sk.
Dabei 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 diese bestehen aus
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
---------------
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, der dann vom
Server der UB besorgt wurde und in den eigene FLEX-Ordner kopiert,
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 von einem Abruf 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.


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 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 dann
wirklich schief. Die beobachteten Meldungen weisen 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.

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.




Mehr Informationen über die Mailingliste Allegro