[Allegro] Verschmelzung von ALD-Dateien [war: avanti]

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Grieser, liebe Liste,

> Wir haben jetzt schone eine Ald-Datei, die über 16MB groß ist.Heißt
> das, man müßte jetzt schon den Befehl ii=5 oder ähnlich in die cat.api
> schreiben? Was passiert, wenn man das nicht tut? Wir haben nämlich
> massive Speicher- und Verzögerungsprobleme und auch Einfrieren von
> Allegro und wissen nicht, warum. Arbeite ich lokal, dann ist die
> Geschwindigkeit von allegro hervorragend. Ist das Konzept, nur in eine
> Datei zu schreiben überhaupt sinnvoll?

Mal von hinten nach vorne beantwortet:

Es ist gewiss nicht sinnvoll, ueber den Speicherort eine permanente
Aussage ueber einen Datensatz machen zu wollen (in Datei 2 sind die
Saetze fuer das Projekt xy).

Eine Sicherheitsmassnahme ist allerdings, verschiedene
Schreiboperationen in verschiedene Dateien zu lenken (Normdaten
nach 140, 160, 130) und auch Verwaltungssaetze von ORDER leben
gerne in 248-255: Volltextsuchen sind dann auf einen Teilbereich
der Dateien einschraenkbar, aber wann macht man schon Volltextsuchen.

Im Fall von massiven Netzwerkproblemen kann es helfen, jedem
Bearbeiter eine eigene Datei zuzuweisen, es gibt dann zwar noch
genau so viele Crashs oder mehr, aber Datenverluste werden minimiert...
Das Zugriffslevel -a1 funktioniert ebenfalls nach diesem Schema,
Bearbeiter duerfen nur in "ihrer eigenen" Datei Datensaetze aendern.
Werden die Eingabedateien jedoch zu voll, so hilft das nicht, ausser
man bohrt auf (vgl. Mail von Herrn Eversberg), niemand weiss jedoch,
wie sich DOS-ALF und ORDER damit vertragen (die anderen Module scheinen
inzwischen sauber, das Feature ist ja auch viele Jahre alt).

Was Sie an Verzoegerungsproblemen erleben, kommt durch die
Leersatzverwaltung von allegro zustande: Umgespeicherte Datensaetze
setzen ihren ehemaligen Speicherort in den Bereich "//" von Register
1 zur Nachnutzung durch andere Speichervorgaenge ("Dieser Satz wurde
getilgt"). Die Schluessel hierfuer enthalten die Satzlaenge, aber
nicht die zugehoerige .ald-Datei. Ein Neu- oder Umspeichervorgang
fordert aber nicht nur eine gewisse Groesse, damit die Daten passen,
sondern auch eine spezifische .ald-Datei an. Daher werden langfristig
immer mehr Leersatz-Schluessel sequentiell abgesucht um letztendlich
zu entscheiden, dass alle aus falschen .ald-Dateien sind. Das Problem
verschaerft sich betraechtlich, wenn eine .ald-Datei voll ist.

In dieser Situation hilft "Entlueften" oder auch komplette
Reorganisation in zu bestimmenden Abstaenden. Ob man davon betroffen
ist, kann man durch Spielen mit dem Schalter "-N" (PRESTO) bzw. der
.ini-Einstellung NewMode herausfinden:
Standard ist 2: D.h. Leersaetze "funktionieren" wie oben beschrieben.
Bei Setzung 1 werden Saetze weggeschrieben, wo auch immer ein passender
Leersatz zu finden ist, d.h. die sequentielle Suche nach einem in der
angeforderten .ald-Datei liegendem Satz entfaellt.
Bei Setzung 0 entsteht immer ein Neusatz, wenn der alte Speicherort
nicht mehr ausreicht. Besonders diese Setzung erhoeht die Performance
und auch die Stabilitaet.



viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCrY0wENVh3bB0lwMRAtYDAJ94YEdzH4JDnUSs6lmtqWr7TovWpACggqEQ
B/1N2L71dy5pGd6ymyCQkQM=
=p8K0
-----END PGP SIGNATURE-----