MicroRelease V22.02: Ausmerzungen

[Bernhard Eversberg]

Weiter unten: neuer FLEX zum Pruefen der Leersaetze!!

Wie gestern angekuendigt: das Weisweiler-Problem des unerwarteten, 
unerklaerlichen und folglich unerwuenschten, irritierenden und somit 
inakzeptablen Doppelklicks nach dem Programmstart ist ausgemerzt.
  a99.lzh,  a99a.lzh,  a99b.lzh,  inst-all.exe   liegen bereit

Inakzeptabel war auch, dass die globalen Ersetzungen in a99 nur noch teilweise 
funktionierten: die kategoriespezifischen taten es nicht. Sowohl in Export-
wie in Indexparametern. Auch dieser Mangel wurde ausgemerzt. avanti wird
noch untersucht. DOS-Programme waren unbetroffen.

Damit sich's aber lohnt, wurde noch folgendes eingebaut:

Die cstring-Variable  j  (Dateinummer des aktuellen Satzes) wurde um zwei
Optionen erweitert:

jb   Laenge des aktuellen Satzes in Byte (aendert sich bei der Bearbeitung!)
        enthaelt nicht die Fuellzeichen
jf   Laenge des Satzes in der Datei (aendert sich erst beim Speichern!)
        enthaelt auch die Fuellzeichen, daher oft jf>jb

Das wird verwendet in dem neuen FLEX  check-e.flx, der die Leerschluessel
untersucht. Diese Schluessel haben die Form  //nnnnnn, wobei nnnnn die
Laenge eines geloschten Satzes ist, incl. Fuellzeichen, und das ist genau
der Wert jf.
Der FLEX  check-e.flx  vergleicht nun fuer saemtliche Leerschluessel, ob die Zahl
uebereinstimmt mit seiner tatsaechlichen Laenge jf. Wenn nicht, wird eine
Meldung in die Datei protok.txt geschrieben, die am Ende dann gezeigt wird.
Achtung:
check-e.flx ist auch in a99b.lzh mit drin, Sie muessen also nicht unbedingt das
Gesamtpaket holen!

Starten Sie den FLEX mit   X check-e
dann laeuft das alles automatisch. (aber auch eingebunden in org.rtf)

Wer viele Leersaetze hat, sollte dies unbedingt mal machen, denn eine falsche
Zahl waere eine potentielle Gefahr. Wir haben in unseren Datenbanken noch keinen
solchen Fall entdeckt, aber wir wollen diese Fehlerquelle ausschliessen koennen.
DENKBAR waere, dass ein Leerschluessel bei Umspeicherung eines Satzes nicht
geloescht wird (wegen Netzwerkproblem oder was immer), dann waere der Fall 
gegeben, dass der Wert nnnnn groesser waere als der tatsaechliche Leerraum.
Und dies wuerde zu einer "Satzvermischung" fuehren koennen.
(Der Fall ist unwahrscheinlich, weil das Programm (PRESTO, UPDATE, a99) prueft, 
ob das Loeschen geklappt hat!)

Also: Lassen Sie  check-e  mal laufen und teilen Sie uns sofort mit,
wenn es eine Meldung gibt. Machen Sie dann eine Entlueftung oder eine
Index-Erneuerung! Dann ist die Gefahr weg.


Bernhard Eversberg
Universitaetsbibliothek, Postf. 3329, 
D-38023 Braunschweig, Germany
Tel.  +49 531 391-5026 , -5011 , FAX  -5836
e-mail  B.Eversberg at tu-bs.de